Rendered at 23:26:02 GMT+0000 (Coordinated Universal Time) with Cloudflare Workers.
0xbadcafebee 3 days ago [-]
Yes this is to be expected. I've mentioned multiple times over the years that TLS CA issuance & validation's many security holes (>=14 at last count) could be solved by changing how certificates are issued. I've never had the kind of clout to get that message wide enough that anyone would take it serious.
One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.
The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Maybe if this keeps happening, people will realize it's worth working on? But I doubt it, as a lot of money is at stake, and nobody wants to risk that just to stop governments and cybercriminals from spying on the occasional connection. If it was blatant and obvious then they might have to act; as long as it's kept covert and hard to prove, things stay the same.
cyphar 2 days ago [-]
> One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.
In case you were not aware, Moxie Marlinspike spoke about this at length back in the early 2010s[1]. His view was that the problem is that certificate authority trust is controlled by the wrong people (web hosts, not users -- or browsers, as a proxy for user wishes) and is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.
> The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Unfortunately, this is problematic for a bunch of other reasons. Yes, this means that a classic Comodo or DigiNotar attack might be blocked (though it is also just as likely they would've been included on the allow-list for American websites), but it also means that registrars could force you to use VeriSign and you would have no choice in the matter -- that is what originally happened with TLS and was what originally happened with DNSSEC too. It seems prudent to me to avoid creating schemes that allow that kind of institutional capture.
There is also in my view a mistake to assume that anyone with a ".com" or ".us" address would want to have the US government decide who they can get certificates from, ditto for any national TLD (let's not forget all of the Rust projects with ".rs" which is controlled by Serbia, tech websites with ".io" that is controlled by the UK, and so on).
If you really wanted to do this, DANE would allow website owners to do this by pinning the CA root and intermediate certificates hashes via DNSSEC -- basically acting as a client-side (and more strict) version of CAA (which I'm guessing is what you were referring to in your comment). Unfortunately it's not supported by Chrome and Firefox, and it would be quite fragile. It would be nice to have this as an option, and I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.
Who should decide that the assignment domain name -> public key is valid?
Certificate authorities?
Domain registrars?
Both of them are subject to government control and regulation and as such Web PKI provides normal commercial level of security, it doesn't protect from government agencies.
To protect from government agencies we would need to move from addressing web pages using domain names to addressing web pages using public keys. This is hard because of Zooko's triangle.
You seem to be talking about registries (who manage tlds, so you have no choice for a particular tld). OP talked about registrars (who sell domains, and there's a wide choice). Though I'm not sure how that's supposed to work.
0xbadcafebee 2 days ago [-]
> once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.
If you switched CAs you would only need to trust the old one until the previous cert expired, or when you get a newer cert. Once the cert expires there's no point in trusting the old CA - for that domain. (In my solution you still keep all the CAs in your cert store, but they can't validate a cert that wasn't also signed by the domain owner's and registrar's keys)
> it also means that registrars could force you to use VeriSign
The check on that is the combination of the CA/Browser Forum and ICANN. The CA/Browser Forum is a proxy for Google, Apple and Microsoft, who control the browser market, and ICANN who controls the accreditation of domain registrars. A single registrar has a lot less money and influence today than back in the day.
> would want to have the US government decide who they can get certificates from
Because of the aforementioned bodies I don't believe registrars would be allowed to enforce specific CAs (architecturally they would just be signing requests on a REST API based on the CA keys the domain owner authorized, so there's no need to integrate into specific CAs). I also think CA/Browser Forum would want to enable Let's Encrypt to be used everywhere (LE usage is in the interest of the CA/Browser Forum) so that would mean they need rules to allow CAs independent of registrars.
DANE and DNSSEC are not a good solution architecturally or security-wise. DANE is duct tape; duct tape is a temporary fix, not a permanent one.
tptacek 2 days ago [-]
I think a lot of people who work on the root programs would push back on the idea that the CAB Forum is a proxy for Google, Apple, and Microsoft.
0xbadcafebee 2 days ago [-]
They control the OS and the Browser, the two things that specify what CA certs can be validated and how. CAs can disagree all they want, but they can't do anything about it. The big 3 don't want to be in the CA business, so they haggle over rules, but it's not a level playing field
tptacek 2 days ago [-]
Oh, I agree about their market power, just saying CAB is complicated.
tialaramex 2 days ago [-]
> is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever
So, the fun thing about historical claims is that you can do Science (insert sound effect) by assuming they're right to make a prediction from that baseline and comparing what actually happened against that prediction.
Moxie gave that talk in August 2010, hence the "DEF CON 19" background. So almost 16 years ago. Over that time of course there have been numerous incidents that would give you good cause to distrust companies such as DigiNotar, StartCom and Symantec. Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.
> I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.
This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.
cyphar 2 days ago [-]
> Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.
Yes, he did say "forever" and (to borrow a phrase) nothing lasts forever so you do have a point there. But the original point still does stand, even in the modern world with a very active CAB, do you honestly think they would blacklist Lets Encrypt if they had some hack or violated some CAB policy that would normally result in expulsion? The fact that trust decisions are very hard to revoke (even though it is possible in practice) is still a problem with the design of PKI.
(It's also a little funny you didn't mention Comodo -- they are still kicking around, despite their history.)
> This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.
Yes, because that usage was the intended usage that is how the scheme must be interpreted. But that doesn't mean that it couldn't have been made to be interpreted differently -- in our modern world of short-lived certificates it would've been very easy to tweak it so that it would've allowed you to specify historical CAs during the (short) transition period.
The issue with CAA is that (as formulated) it is an incredibly weak protection mechanism -- it relies on CAs to obey it and if a CA gets hacked (or forced via legal threats) there is no mechanism for users to be protected from them issuing certificates for sites that did not wish for that. Google is well aware of this issue, which is why Chrome has proper CA certificate pinning but only for Google-owned domains. Non-Google website owners have no access to a similar mechanism, and even if CAA was not as good as some theoretical alternative, for the vast majority of websites it would be a strict improvement if clients validated against CAA -- which is why I'm disappointed that it is explicitly not permitted with MUST NOT (not even a SHOULD NOT -- which is a stance I would understand).
tialaramex 1 days ago [-]
I'm not sure you could consider Let's Encrypt "too big to fail" but if you can it seems like Moxie's position doesn't help? The "too big to fail" afflicts basically everybody in that case.
Comodo / Sectigo is actually useful to illustrate how these decisions are made because we actually care whether you can stop having problems. Think like air safety or medical safety. Things go wrong, our job is to avoid scenarios where they keep going wrong for the same reasons. The first guy who trips and plummets off a bridge into the river below is enough, OK, yeah, barriers, we need to prevent you accidentally falling off the bridge. When you build the next bridge and somebody falls off because you didn't add barriers now that's a failure to learn and do better.
Outfits like StartCom and Symantec the problem wasn't "A thing went wrong" it was "Things kept going wrong and either you lied to us about preventing them, or you're incompetent and your attempts failed utterly". There are a lot of boring "Brown M&M" record keeping steps, and for WoSign and Symantec the evidence available strongly suggested they were deliberately lying to us, but even if they weren't lying they were spectacularly incompetent, and that's not OK. As I've explained previously I strongly prefer to not care whether you're incompetent or lying, I want either explanation to have the same consequences.
If we thought there was a problem with Let's Encrypt and it must be distrusted I think a transition plan like for Symantec is a lot more plausible than the sort of "Everybody makes their own correct decisions" fantasy Moxie promoted which, frankly, I think sounds like Libertarian claptrap. Such an approach requires that almost everybody cares and that's just not true about anything at all.
> But that doesn't mean that it couldn't have been made to be interpreted differently
But now you're talking about a different protocol. Feel free to go design your own protocol, like Moxie's. I doubt yours will fare better than his did, but "Why didn't everybody else focus on my preferences?" is silly.
3 days ago [-]
account42 1 days ago [-]
If you're using the DNS as the root of trust then you can just skip CAs entirely and have the DNS system authenticate certificates directly. Turns out we already built system.
mtucker502 3 days ago [-]
How would clients receive the trusted CA data from the registrar? DNS?
This would very easily be susceptible to MITM attacks. Any DNS security to prevent MITM attacks is going to have the same CA issue we currently have.
account42 1 days ago [-]
DNSSEC is a thing you know. And not it doesn't allow a random Chinese agency sign records for my .de domain.
tptacek 21 hours ago [-]
You mean until major DNS providers turn DNSSEC off for .DE to work around misconfigurations, which literally just happened.
account42 16 hours ago [-]
Operators making reckless choices like that, especially when DNSSEC is barely being used, does not invalidate the technology. And it would also not have impacted DNSSEC used for DANE as the client would be verifying the DNSSEC chain in that case and not just the recursive resolver. But don't let that stop your eternal butthurt about DNSSEC. Whatever issues DNSSEC might have, at least its not broken by design like the current web PKI where we have hundreds single point of failures.
tptacek 9 hours ago [-]
The "operators" you're referring to are the .DE TLD operators, right?
skybrian 2 days ago [-]
If the wrong CA issued a certificate then wouldn’t that show up in the transparency logs? It seems like by monitoring them, you could see if a security bug is being exploited.
aleksejs 3 days ago [-]
The jabber.ru post referenced here presents clear evidence (in the section titled "Network") that the malicious actor was able to reroute traffic going to the legitimate jabber.ru server. An attacker in this position does not need an RCE to get a cert, they can just get one issued the normal way, because they do effectively control the IP address that the domain is pointing to.
8organicbits 3 days ago [-]
One suggestion for anyone concerned about this weakness. You can use the CAA record to pin the domain to a specific certificate authority, issuance method, and account. This is imperfect, as CAA record validation (edit: of CAA extensions) is not mandatory yet. But by March 2027 all the CAs a supposed to have support.
Sprinkle some DNSSEC on the CAA record too, if you'd like.
cobertos 3 days ago [-]
Just be careful, if you host your DNS at Cloudflare (maybe others?), they will rewrite your CAA record[0] if you use TLS with them. This is in the name of convenience but it was surprising when I first learned.
CAA checking is mandatory, so you can always restrict to a given CA.
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
j16sdiz 3 days ago [-]
DNSSEC is the weakest link here.
It is too fragile (multiple point of failure). It is high volume (=it need be cacheable).
Puting authentication cert in dns sounds good in theory, but we have never get that reliability
mcpherrinm 3 days ago [-]
Even without DNSSEC, the CAA record approach can help, as it requires MITMing between the CA and the DNS server, which may be harder in some cases than just MITMing a target site.
If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.
> It is high volume (=it need be cacheable).
It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.
tptacek 3 days ago [-]
It is self-evidently not correct that companies that can't keep DNSSEC running can't keep certs running. Entire TLDs have fallen off the Internet because DNSSEC has broken. A certificate never took Slack down for half a day. It's just obviously not true.
Hizonner 2 days ago [-]
It's amazing what practice and investment can do, even for a fragile system like X.509. Yet certs still break constantly. Like permanently killing people's "perpetual" Microsoft Word licenses in a story posted within hours of this one.
8organicbits 3 days ago [-]
I have it partially right. The extensions are not yet mandatory.
That's right, it's easier to setup such MiTM using an intermediate server, because only getting the private key of the certificate won't get you the user's traffic due to PFS.
You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.
arowthway 2 days ago [-]
We should have listened to Rachel!
>I've been aware of the ACME protocol for a while. I have tech notes going back as far as 2018, and every time I looked at it, I recoiled in horror. The whole thing amounts to "throw in every little bit of webshit tech that we can", and it makes for a real problem to try to implement this in a safe and thorough way. Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my private keys and/or ability to frob the web server (as root!) with their careless ways.
Parallel *Re*construction is a play on words I wrote related to a lot of the nuance at play I wasn’t able to cover in the blog without making it very long.
crystaln 2 days ago [-]
Thanks for explaining. It's an interesting turn of phrase. I don't see how it relates to parallel construction.
crystaln 3 days ago [-]
Indeed. Parallel construction is when law enforcement doesn't want to burn their source or their source is unlawful, so they find another way to justify a warrant or prosecution even tho their initial justification comes from a different source.
This has been upheld as lawful, but also can unfortunately be used to disguise unlawful behavior.
Reverse engineering is not related to parallel construction.
crystaln 3 days ago [-]
Parallel construction would be if LE unlawfully intercepted transmissions using this technique and discovered a crime, then found other unrelated evidence to begin an investigation of that crime.
ls612 3 days ago [-]
I thought certificate transparency was the thing that was supposed to prevent exactly what this article is describing. What if anything is incorrect about my model of the world in this respect?
zinekeller 3 days ago [-]
Basically, CT did indeed worked as designed, but there was no monitoring by the domain authors (which to be fair there are a dearth of solutions of the time).
On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).
jerrythegerbil 3 days ago [-]
Certificate transparency worked exactly as designed in this case. Monitoring public certificate transparency logs for anomalies is a different story entirely.
By breaking the software facilitating https via ACME itself, no anomalous certificate transparency logs would have needed to have been created at all.
The front door is locked quite tightly with a watchful security camera, but the window has been left unlocked. Also no one is watching the camera feed.
perching_aix 3 days ago [-]
Nothing, although it's more mitigate than prevent per se. They simply did not have alerting set up against the CT logs. It is one of the lessons they highlighted in their own postmortem.
ls612 3 days ago [-]
Yeah I suppose the prevent part came from the Browser/CA forum giving the CA that did it the death penalty like they did for Kazakhstan's CA in 2015 but if the men with guns point them at executives of browser providers and say "trust this CA or else" then CT is more of a cosmetic system than anything else.
perching_aix 3 days ago [-]
What I more meant is that it's a reactive arrangement rather than a proactive one, so it cannot be preventative outright. Domain owners are expected to actively monitor the CT logs for abuse, and take action if they see any. This necessarily means that abuse can still happen, at least for a little while.
XorNot 3 days ago [-]
Do the executives implement program features?
The most striking thing about these types of conspiracy theories is people seem to completely forget that whoever you imagine you can threaten generally doesn't have the ability to do the thing you want them to do: they'd have to delegate it.
ls612 3 days ago [-]
So given that this is widely accepted to have actually happened why has the CA involved not received the death penalty like the Kazakh one did?
perching_aix 3 days ago [-]
Because unlike in that case, the CA in this story is not suspected to have done anything wrong, despite what the post's wording might suggest. See my other comment: https://news.ycombinator.com/item?id=48340259
0xbadcafebee 3 days ago [-]
If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it. And the attack isn't stopped even if they do publish in CT. And you have to monitor for it anyway.
Every single mitigation for known Web PKI vulns can be worked around (if people use them, which virtually nobody does).
joxdosba 3 days ago [-]
> If you're a CA you can just issue a cert and not publish it in the CT logs. You're not supposed to do that, but there is nothing stopping it.
Browsers have mandated CT logging for years and will not accept such a certificate.
Why is it so common to incorrectly assume that the people who came up with CT were stupid?
crote 2 days ago [-]
> Browsers have mandated CT logging for years
They did, yes. Any CA caught issuing a non-logged cert would be in big trouble.
> ... and will not accept such a certificate
Do they not?
According to RFC 9162 including CT information inside the cert itself is optional, and the extension is noncritical. Clients are not required to support CT, and they MAY fetch inclusion proofs. Servers are supposed to send CT info via one of various methods - but they aren't required to supply a complete proof of inclusion. Considering how OCSP was implemented in practice, I highly doubt any browser is willing to completely block the connection until it has managed to fetch an inclusion proof - both from a speed perspective and a privacy perspective.
CT's main value is in giving the browser vendors a stick to hit the CA with in case of non-logging, which is indication that something fishy is going on. Send the cert itself to a mailing list and anyone can check with the logs. Log getting DDoSed? Just try again tomorrow, the CAs judgement can wait another day. This is completely different from having a browser verify the proof in realtime while setting up the connection, and having it fail hard if it can't be 100% sure.
nickf 2 days ago [-]
If a cert doesn't contain the requisite number of valid SCTs from logs that are specifically usable in the browser - it will not work.
CT indeed worked out pretty well. At least until bots started hammering crt.sh making it unreliable, and those that want to be alerted to newly issued certificated appeared in the logs need to pay for some purpose-built service instead of just adding a relevant query to their feed reader.
codedokode 3 days ago [-]
The wrong part is that Let's Encrypt was willing to issue a valid cert to anyone who can temporarily redirect traffic. The authorization should have been done better, for example, sending a certificate to operator's email.
crote 2 days ago [-]
There is no such thing as an "operator's email". Over time there has been a wild growth of webmaster@, admin[istrator]@, root@, postmaster@ and so on, but having access to them proves very little. Some email operators just aren't very restrictive with their allowed usernames, and that's before we get into the corporate world where the first-line helpdesk person weeding out the email received on that address probably isn't supposed to issue certificates!
This method has been (mostly?) banned for a reason, see for example CA/B's ballot SC080v3.
edelbitter 3 days ago [-]
>the various ACME clients like acme.sh are run with elevated privileges
Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.
wahern 3 days ago [-]
That capability should be added to acme.sh, etc so that it automatically runs with minimal privileges for the invoked task. But people seem to assume privilege management is the sole responsibility of the packager or caller, despite the tool itself being better placed to know precisely which privileges are needed for the particular task it's performing.
acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.
LelouBil 3 days ago [-]
I'd say it's usually on the packager (or caller) because specying privileges depends on the platform you run on, which is better known by the packager or caler
perching_aix 3 days ago [-]
> TLS wiretapping with root-CA-signed certificates is a thing that both happens and verifiably has happened. (...) This being a fact rather than a conspiracy theory tends to upset people.
Maybe what people get upset about is catchy misleading [0] summaries like this, which suggest [0] a CA - nation state collusion, despite the actual story going in a completely different [0] direction? The thing that would be actually big news [0]?
[0] in the eye of the beholder of course, as always
ranger_danger 3 days ago [-]
I could see this actually being a real parallel reconstruction for a state actor that did issue certificates from a compromised CA. If any evidence points back to them, they can just say the server was hacked with the acme RCE to generate different certs. There probably won't be a way to legally verify that such a thing never happened.
3 days ago [-]
codedokode 3 days ago [-]
This is a reminder why you should use E2EE messengers only.
matheusmoreira 3 days ago [-]
One day that'll be illegal. End to end encryption? That obviously means you're a drug trafficking money laundering pedophile terrorist. Off to jail with you despite zero evidence. Maybe they'll declare your efforts to protect yourself as being in contempt of court and then jail you indefinitely until full decryption.
To absolutely no sane person's surprise, the main audience of e.g. anti-censorship platforms is exactly people who typically feel or find themselves censored, which in a harmonious or at least well-functioning society will not be a particularly cheritable set of individuals. In one where that's not the case, the audience would change alongside too, sure, but clearly these narratives mismatch reality, at least for now.
Conversely, (actually) high privacy platforms will be primarily seeked out and leveraged by those who value precisely that. While the privacy scares have been pretty serious for a while, for now that is still both evidently, and indeed obviously, in good part criminals or other high risk individuals.
It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?
Performative victimhood only works so well, and until such blatantly deceptive narrative is being pushed, you may very well see your doomsday scenario realized. It's a trivially vulnerable position, so much so that it feels like a rhetorical trap almost. Like a poet self-sabotaging the monetization of their work, while waxing poetic about how they're (financially) un(der)appreciated. Although people have been getting into anti-government conspiracies pretty hard in the past few years, and governments have been working hard to demolish whatever good standing they have in parallel, so that does help your case I suppose. One may even recognize this miraculously well oiled process and nosedive in social trust as uncoincidental, in fact. But I digress. I wouldn't wanna spread conspiracy theories after all, would I?
cyphar 2 days ago [-]
Well-funded criminal networks like the ones in the video you linked would have little issue if all e2ee chat apps disappeared tomorrow, they have enough money and operational incentives to pay someone to make custom encrypted chat apps (not to mention the myriad of open source ones available).
The only people actually hurt by banning e2ee are regular people.
> It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?
Based on public metrics, 3% of Tor traffic is .onion traffic and it is incredibly likely the vast majority of that is the Facebook .onion service (based on some stats posted by Facebook a few years ago).
So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.
perching_aix 2 days ago [-]
Despite that, for some reason, these well funded criminal networks keep buying into these weird phone deals instead. I genuinely don't understand why, but they do.
> So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.
How does the burden of proof fall on me for a claim I (intentionally) did not make?
cyphar 2 days ago [-]
> Despite that, for some reason, these well funded criminal networks keep buying into these weird phone deals instead. I genuinely don't understand why, but they do.
Given how many of them have been CIA honeypots, they must have amazing marketing.
> How does the burden of proof fall on me for a claim I (intentionally) did not make?
Nice trick -- make a very clear implication and claim that you didn't make a positive claim.
perching_aix 2 days ago [-]
The implication (representing a belief, not a claim) was about the nature of item purchases on .onion webshops (that they're primarily contraband), not about the composition of .onion or Tor traffic. If anything, the attempt to pivot to that was a trick.
You may still fault me for mixing in beliefs into an argument, it is of poor form from me. Up to you. But then I don't think sentiments are just pure hard logic and evidence, so it'd have been potentially more dishonest from me to exclude it than to not.
jodrellblank 2 days ago [-]
I skim-watched your link and it doesn’t seem to support your thesis.
First, the secure end-to-end encryption was broken by international police and messages were read without making it illegal.
Second they suggest reading hundreds of thousands of people’s messages to catch a dozen or so gang members - not supporting your claim that only crooks use it.
Third, the video ends by the gang leader saying he was working for the President; not supporting your implication that criticism of government is all baseless conspiracy theories.
perching_aix 2 days ago [-]
I have very serious concerns on the human vs LLM effort that went into this comment, but sure, let's go point by point then.
The first counterpoint I can't even decipher, it makes no grammatical sense. Are you saying that law-enforcement-intercepted encrypted messages are not necessarily illegal? ...why would they be? Sounds like a strawman.
The second is explicitly a strawman. I intentionally left space for legitimate use, because it's a trivial rhetorical target, so I just said that it primarily interests "illegitimate" use for now. While I do not have actually comprehensive data on the Sky userbase, the way these devices were distributed, the volume of criminal-use-connected messages uncovered, and the globally dispersed gang use presented in the video did suggest to me exactly what I said. I'm not sure why you think "just catching a dozen or so gang members" is a reasonable takeaway either, given that the video's focus was exactly just those people.
We can take issue with this, and downgrade this to just being evidence of significant (in the statistical terminology sense of the word) criminal use rather than primary criminal use. I just both fail to find that particularly compelling, and don't really feel like arguing on your behalf.
The third counterpoint I also struggle to decipher. It seems to also build on a strawman like the other two points. You accuse me of implying that "criticism of govt is all baseless conspiracy theories". I don't know how you managed to extract such a thing out of what I wrote, so I'm not sure how to respond. Governments around the world are routinely criticized, have plenty of perfectly valid things going against them, on which both the media and the general public report on plenty. It is - thankfully - only a select few places in the world where such speech is actually restricted. Now that was more a part of my point.
jodrellblank 2 days ago [-]
The first counterpoint is that you took the position E2E Encrypted messaging will be made illegal because of criminals. The video you linked to support this shows criminals being caught without banning E2E encrypted messaging. Therefore your link does not support the claim that catching criminals needs E2EE apps banning.
The second is not a strawman, you claimed that only criminals are attracted to E2EE messaging when the link you gave showed some 170 thousand users of that specific messaging app with no suggestion that most of them were criminals. "I just said that it primarily interests "illegitimate" use for now" yes you did say that, and that thing you said is not supported by your link.
The third is about your writing about how people who want privacy are performative victims who are falling into anti-government conspiracy theories, but your link shows a thing which was not a conspiracy theory and the government in question actually was accused of targetting their political enemies with gangs, and it would be reasonable to want privacy against such.
> "I don't know how you managed to extract such a thing out of what I wrote"
> "But I digress. I wouldn't wanna spread conspiracy theories after all, would I?"
maybe write less of this winky-face bs and just say what you mean.
perching_aix 2 days ago [-]
> you took the position E2E Encrypted messaging will be made illegal because of criminals
That is not the position I took (and as such, the video I link to was not in support of this either). The position I took is encoded in this sentence:
> (...) until such blatantly deceptive narrative is being pushed, you may very well see your doomsday scenario realized.
This is to say, I consider the "narrative" the person above is "pushing" to be "blatantly deceptive", given the well published and significant cases of criminal use, which I then linked to a recent example of, and in which stories private comms play a key role. That the fairy tale where encrypted comms is "merely just for innocent people to protect their privacy" is indeed "both obviously and evidently" phony, and pretending that it isn't thus only harms their political case, rather than help it.
It's frustrating that this has to be argued tooth and nail, because it is common sense. Private communications is essential for covert operations. Obviously by preventing such communications, you'll be harming such operations, a goal which can be trivially made politically compelling and for good reason. To say that this is "obvious" is an understatement.
> shows criminals being caught without banning E2E encrypted messaging
The video doesn't actually feature E2EE. It speaks of intelligence authorities extracting decryption keys from server memory, and using that to decrypt traffic. This suggests ordinary encrypted messaging (if even that), not E2EE. You'll notice I also wasn't singling out E2EE.
The video also spends a great deal of time on how those captured messages provided crucial evidence for their various crimes.
> Therefore your link does not support the claim that catching criminals needs E2EE apps banning.
Indeed, that link never meant to support such a claim to begin with. What it was meant to demonstrate was encrypted messaging directly supporting criminal use, and being an evidently attractive feature for criminals. So much so that they'll actively seek out weird-ass phone deals, like SkyECC.
> you claimed that only criminals are attracted to E2EE messaging
That is not what I claimed. What I claimed is that it is primarily individuals who are high risk that will be attracted, who will be "in good part" criminals:
> While the privacy scares have been pretty serious for a while, for now that is still both evidently, and indeed obviously, in good part criminals or other high risk individuals.
I could pretend I didn't mean majority use, but I'll spare you. Rewatching the video, I do concede that it does not outright claim the 70K monthly active users were found to be primarily criminals. It merely suggests so, such as by referencing the port of Antwerp dealings, and mentioning that there was a hotspot of users there. That is thus borrowed speculation on my behalf, although I do think it is plenty compelling enough. You're free to disagree or chase it further.
> The third is about your writing about how people who want privacy are performative victims who are falling into anti-government conspiracy theories
That is exceedingly not what I said. The person I was portraying to be a "performative victim" was OP, because they wrote in a sarcasm-laden, self-victimizing style, like so:
> That obviously means you're a drug trafficking money laundering pedophile terrorist. Off to jail with you despite zero evidence.
I then explained that people who already believe in anti-government conspiracy theories will likely be the ones to find it compelling, because what they said is against government control on encrypted comms, is conspiratorial in nature, and because governments have been abusing their power more and more lately:
> Although people have been getting into anti-government conspiracies pretty hard in the past few years, and governments have been working hard to demolish whatever good standing they have in parallel, so that does help your case I suppose.
This doesn't mean they have been specifically "falling into anti-government conspiracy theories" either. It means they're the ones actively sowing some, or at the very least are riffing off the trope hard and willfully. And that this is indeed weak against the evidenced criminal cases, even if they feel it shouldn't be.
> your link shows a thing which was not a conspiracy theory and the government in question actually was accused of targetting their political enemies with gangs, and it would be reasonable to want privacy against such
This is a non-sequitur. The gangs in question were not depicted to have relied on surveillance technologies or harvested comms intelligence, not on their own terms, nor through governmental means. One of the gangs being in bed with the local government being proven to be not a conspiracy also has little bearing on conspiracies at large. Some conspiracy theories are true, some aren't, some partially. Why would I make such an obviously fallible claim that government-related conspiracy theories are never true?
But maybe your point is more that being able to privately communicate can be helpful in cases like this. And I agree. Even beyond it, I do think that private communications are important, even essential, and I'd like to see them protected. I just also happen to think that very obviously bullshit deflections like this do not serve that cause. I mentioned the .onion webshop example, but I could have really brought up e.g. torrent as well. Is it exclusively for piracy? No, it cannot actually be: it transmits arbitrary data. Is it obviously the main attraction and what people use it for? Very much so. Does this mean it shouldn't proliferate further and be used in legitimate settings? No. It just means that defending it by pointing at it "not necessarily being for piracy" is a hideously weak, laughably phony political position, that would not at all stand up to scrutiny in a sufficiently adversarial environment. Like come on...
A robust argument for private comms, encrypted comms, and E2EE comms, in my opinion, does 100% need to have a compelling explanation on how it hopes to mitigate issues like this. Because beyond the sob story of the person above, these are very real avenues of abuse, avenues that these technologies do uniquely support, and this does matter. And I'm yet to encounter such an explanation. So much so, that some individuals even flagrantly refuse to address it, like the person above. They'd rather spend their time moping, and pretending that it's only ever the government conspiring against the people, painting them as terrorists, gangsters, and pedophiles falsely, just to get their data decrypted and stolen. This can and does happen too, but also, they do indeed could absolutely be all that, and sometimes are. As per the example above.
If I was holding a position where I'm arguing for backdooring private, encrypted, or E2EE comms, I'd need to similarly have a compelling story on how to mitigate governmental abuse. I do not hold such a position however, exactly because I have no proposal in the way of that. I do recognize this at least, and am more than willing to acknowledge it. This is a complex matter, and I think it should be discussed accordingly. Not with tired self-victimizing brainwash like the person above.
> maybe write less of this winky-face bs and just say what you mean.
All the points you ran into issues with were delivered in very direct terms.
upofadown 3 days ago [-]
I guess there is an interesting possibility here. Perhaps the targets were encrypting end to end (that is more or less the default now with XMPP clients). With the TLS over top of everything the attackers would not know that. Perhaps they went to all this trouble for nothing.
TZubiri 3 days ago [-]
What LI vendors can break https?
jerrythegerbil 3 days ago [-]
The sloppy ones who want a huge headache and leave a publicly auditable trail a mile long that get analysis blogs written about their mistakes.
Peacefulz 3 days ago [-]
Can we get an RSS feed? Loved the post.
janmo 3 days ago [-]
So it looks like Hetzner is doing the same thing OVHCloud did with EncroChat and SkyECC. But hey, we have GDPR, keep your data hosted in the EU it is very "safe" there (ironic).
One of Web PKI's security holes is the fact that any CA can issue valid certs for any domain. The only official "mitigation" for that is voluntary and can be defeated.
The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Maybe if this keeps happening, people will realize it's worth working on? But I doubt it, as a lot of money is at stake, and nobody wants to risk that just to stop governments and cybercriminals from spying on the occasional connection. If it was blatant and obvious then they might have to act; as long as it's kept covert and hard to prove, things stay the same.
In case you were not aware, Moxie Marlinspike spoke about this at length back in the early 2010s[1]. His view was that the problem is that certificate authority trust is controlled by the wrong people (web hosts, not users -- or browsers, as a proxy for user wishes) and is not possible to revoke because once a web host uses a particular CA you are stuck trusting them forever otherwise the internet will break.
> The solution to that is to rearchitect the Web PKI ecosystem to use domain registrars as the sole source of truth for which CA is allowed to issue valid certs, in addition to cryptographic fingerprints of the source of the originator and issuer. I won't rehash it here but it's not technically difficult and would make it so only the domain owner could issue certs, and valid certs could only come from the CA the domain owner authorizes.
Unfortunately, this is problematic for a bunch of other reasons. Yes, this means that a classic Comodo or DigiNotar attack might be blocked (though it is also just as likely they would've been included on the allow-list for American websites), but it also means that registrars could force you to use VeriSign and you would have no choice in the matter -- that is what originally happened with TLS and was what originally happened with DNSSEC too. It seems prudent to me to avoid creating schemes that allow that kind of institutional capture.
There is also in my view a mistake to assume that anyone with a ".com" or ".us" address would want to have the US government decide who they can get certificates from, ditto for any national TLD (let's not forget all of the Rust projects with ".rs" which is controlled by Serbia, tech websites with ".io" that is controlled by the UK, and so on).
If you really wanted to do this, DANE would allow website owners to do this by pinning the CA root and intermediate certificates hashes via DNSSEC -- basically acting as a client-side (and more strict) version of CAA (which I'm guessing is what you were referring to in your comment). Unfortunately it's not supported by Chrome and Firefox, and it would be quite fragile. It would be nice to have this as an option, and I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.
[1]: https://youtu.be/UawS3_iuHoA?t=292
Certificate authorities?
Domain registrars?
Both of them are subject to government control and regulation and as such Web PKI provides normal commercial level of security, it doesn't protect from government agencies.
To protect from government agencies we would need to move from addressing web pages using domain names to addressing web pages using public keys. This is hard because of Zooko's triangle.
https://en.wikipedia.org/wiki/Zookos_triangle
If you switched CAs you would only need to trust the old one until the previous cert expired, or when you get a newer cert. Once the cert expires there's no point in trusting the old CA - for that domain. (In my solution you still keep all the CAs in your cert store, but they can't validate a cert that wasn't also signed by the domain owner's and registrar's keys)
> it also means that registrars could force you to use VeriSign
The check on that is the combination of the CA/Browser Forum and ICANN. The CA/Browser Forum is a proxy for Google, Apple and Microsoft, who control the browser market, and ICANN who controls the accreditation of domain registrars. A single registrar has a lot less money and influence today than back in the day.
> would want to have the US government decide who they can get certificates from
Because of the aforementioned bodies I don't believe registrars would be allowed to enforce specific CAs (architecturally they would just be signing requests on a REST API based on the CA keys the domain owner authorized, so there's no need to integrate into specific CAs). I also think CA/Browser Forum would want to enable Let's Encrypt to be used everywhere (LE usage is in the interest of the CA/Browser Forum) so that would mean they need rules to allow CAs independent of registrars.
DANE and DNSSEC are not a good solution architecturally or security-wise. DANE is duct tape; duct tape is a temporary fix, not a permanent one.
So, the fun thing about historical claims is that you can do Science (insert sound effect) by assuming they're right to make a prediction from that baseline and comparing what actually happened against that prediction.
Moxie gave that talk in August 2010, hence the "DEF CON 19" background. So almost 16 years ago. Over that time of course there have been numerous incidents that would give you good cause to distrust companies such as DigiNotar, StartCom and Symantec. Moxie's prediction tells us that we were "stuck trusting them forever" but er... nope, DigiNotar went bankrupt, StartCom exists only as some branding for the (now distrusted) Chinese company which bought it, and Symantec "pivoted" away from the CA business and now exists largely as branding as well.
> I am quite disappointed with the fact that clients are expressly forbidden from parsing CAA by RFC 8659.
This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.
Yes, he did say "forever" and (to borrow a phrase) nothing lasts forever so you do have a point there. But the original point still does stand, even in the modern world with a very active CAB, do you honestly think they would blacklist Lets Encrypt if they had some hack or violated some CAB policy that would normally result in expulsion? The fact that trust decisions are very hard to revoke (even though it is possible in practice) is still a problem with the design of PKI.
(It's also a little funny you didn't mention Comodo -- they are still kicking around, despite their history.)
> This is a bad idea because it doesn't signal what you think it does. CAA is a signal about who may issue right now not a signal about who has issued in the past whether that's five seconds ago or five weeks ago. That's why it's a signal for the CAs and not for you.
Yes, because that usage was the intended usage that is how the scheme must be interpreted. But that doesn't mean that it couldn't have been made to be interpreted differently -- in our modern world of short-lived certificates it would've been very easy to tweak it so that it would've allowed you to specify historical CAs during the (short) transition period.
The issue with CAA is that (as formulated) it is an incredibly weak protection mechanism -- it relies on CAs to obey it and if a CA gets hacked (or forced via legal threats) there is no mechanism for users to be protected from them issuing certificates for sites that did not wish for that. Google is well aware of this issue, which is why Chrome has proper CA certificate pinning but only for Google-owned domains. Non-Google website owners have no access to a similar mechanism, and even if CAA was not as good as some theoretical alternative, for the vast majority of websites it would be a strict improvement if clients validated against CAA -- which is why I'm disappointed that it is explicitly not permitted with MUST NOT (not even a SHOULD NOT -- which is a stance I would understand).
Comodo / Sectigo is actually useful to illustrate how these decisions are made because we actually care whether you can stop having problems. Think like air safety or medical safety. Things go wrong, our job is to avoid scenarios where they keep going wrong for the same reasons. The first guy who trips and plummets off a bridge into the river below is enough, OK, yeah, barriers, we need to prevent you accidentally falling off the bridge. When you build the next bridge and somebody falls off because you didn't add barriers now that's a failure to learn and do better.
Outfits like StartCom and Symantec the problem wasn't "A thing went wrong" it was "Things kept going wrong and either you lied to us about preventing them, or you're incompetent and your attempts failed utterly". There are a lot of boring "Brown M&M" record keeping steps, and for WoSign and Symantec the evidence available strongly suggested they were deliberately lying to us, but even if they weren't lying they were spectacularly incompetent, and that's not OK. As I've explained previously I strongly prefer to not care whether you're incompetent or lying, I want either explanation to have the same consequences.
If we thought there was a problem with Let's Encrypt and it must be distrusted I think a transition plan like for Symantec is a lot more plausible than the sort of "Everybody makes their own correct decisions" fantasy Moxie promoted which, frankly, I think sounds like Libertarian claptrap. Such an approach requires that almost everybody cares and that's just not true about anything at all.
> But that doesn't mean that it couldn't have been made to be interpreted differently
But now you're talking about a different protocol. Feel free to go design your own protocol, like Moxie's. I doubt yours will fare better than his did, but "Why didn't everybody else focus on my preferences?" is silly.
This would very easily be susceptible to MITM attacks. Any DNS security to prevent MITM attacks is going to have the same CA issue we currently have.
Sprinkle some DNSSEC on the CAA record too, if you'd like.
[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...
Is that true? My read of Section 1.2.1 in [1] suggests CAA checking has been mandatory since 2017‐09‐08.
[1] https://cabforum.org/working-groups/server/baseline-requirem...
To get complete control with DNSSEC, you also need the accounturi and validationmethod extensions (which you need to guarantee only your account can issue, and only with the DNS validation type).
Those aren't yet mandatory, but you can restrict to a CA today which implements them, like Let's Encrypt.
It is too fragile (multiple point of failure). It is high volume (=it need be cacheable).
Puting authentication cert in dns sounds good in theory, but we have never get that reliability
There’s some upcoming attempts at transport security for authoritative DNS servers which might help too: https://datatracker.ietf.org/doc/html/draft-hoffman-deleg-se...
Re: DNS security and NTP and Decentralized DNS/PKI with web standards like W3C DID and DID micro-ledgers for record signing:
"Cert Authorities Check for DNSSEC from Today" (2026-03-26) https://news.ycombinator.com/item?id=47401716
If your DNS isn't working, you're not going to be making connections anyway. And if you can't keep DNSSEC running, you can't keep certs up to date either. DNSSEC is actually much simpler, with fewer failure points, once you set it up.
> It is high volume (=it need be cacheable).
It is. Unlike certificates. And the cache lifetimes are much shorter than typical certificate lifetimes.
https://www.feistyduck.com/newsletter/issue_137_acme_caa__ex...
You either need to disable PFS on the server, or export TLS master keys for each session in some way, or MiTM.
>I've been aware of the ACME protocol for a while. I have tech notes going back as far as 2018, and every time I looked at it, I recoiled in horror. The whole thing amounts to "throw in every little bit of webshit tech that we can", and it makes for a real problem to try to implement this in a safe and thorough way. Many of the existing clients are also scary code, and I was not about to run any of them on my machines. They haven't earned the right to run with privileges for my private keys and/or ability to frob the web server (as root!) with their careless ways.
https://rachelbythebay.com/w/2025/05/22/ssl/
Parallel *Re*construction is a play on words I wrote related to a lot of the nuance at play I wasn’t able to cover in the blog without making it very long.
This has been upheld as lawful, but also can unfortunately be used to disguise unlawful behavior.
Reverse engineering is not related to parallel construction.
On a related note, Let's Encrypt also issued the presumably-interception certificates. This can be possibly something that requires interception at the VPS level (otherwise we already detected the BGP leaks). Presumably, Hetzner was forced to do a raw interception and then redirecting all relevant ports to a middlebox for inspection and CA issuance (and since that the ACME spec is well-defined, they can simply check if the handshake contains the TLS ALPN challenge and then redirect them to special code that will reply with the correct things).
By breaking the software facilitating https via ACME itself, no anomalous certificate transparency logs would have needed to have been created at all.
The front door is locked quite tightly with a watchful security camera, but the window has been left unlocked. Also no one is watching the camera feed.
The most striking thing about these types of conspiracy theories is people seem to completely forget that whoever you imagine you can threaten generally doesn't have the ability to do the thing you want them to do: they'd have to delegate it.
Every single mitigation for known Web PKI vulns can be worked around (if people use them, which virtually nobody does).
Browsers have mandated CT logging for years and will not accept such a certificate.
Why is it so common to incorrectly assume that the people who came up with CT were stupid?
They did, yes. Any CA caught issuing a non-logged cert would be in big trouble.
> ... and will not accept such a certificate
Do they not?
According to RFC 9162 including CT information inside the cert itself is optional, and the extension is noncritical. Clients are not required to support CT, and they MAY fetch inclusion proofs. Servers are supposed to send CT info via one of various methods - but they aren't required to supply a complete proof of inclusion. Considering how OCSP was implemented in practice, I highly doubt any browser is willing to completely block the connection until it has managed to fetch an inclusion proof - both from a speed perspective and a privacy perspective.
CT's main value is in giving the browser vendors a stick to hit the CA with in case of non-logging, which is indication that something fishy is going on. Send the cert itself to a mailing list and anyone can check with the logs. Log getting DDoSed? Just try again tomorrow, the CAs judgement can wait another day. This is completely different from having a browser verify the proof in realtime while setting up the connection, and having it fail hard if it can't be 100% sure.
This method has been (mostly?) banned for a reason, see for example CA/B's ballot SC080v3.
Its really not that difficult to not grant excessive privileges - at the very least for recurring ("cron") runs, once filesystem structure, cache invalidation triggers and web server configuration are in place. Its a shame this is still taught in the "just run as admin" style.
acme-client on OpenBSD does this, using privilege separated processes that each in turn use pledge and unveil. You wouldn't know without looking at the source code because it's entirely transparent.
Maybe what people get upset about is catchy misleading [0] summaries like this, which suggest [0] a CA - nation state collusion, despite the actual story going in a completely different [0] direction? The thing that would be actually big news [0]?
[0] in the eye of the beholder of course, as always
To absolutely no sane person's surprise, the main audience of e.g. anti-censorship platforms is exactly people who typically feel or find themselves censored, which in a harmonious or at least well-functioning society will not be a particularly cheritable set of individuals. In one where that's not the case, the audience would change alongside too, sure, but clearly these narratives mismatch reality, at least for now.
Conversely, (actually) high privacy platforms will be primarily seeked out and leveraged by those who value precisely that. While the privacy scares have been pretty serious for a while, for now that is still both evidently, and indeed obviously, in good part criminals or other high risk individuals.
It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?
Performative victimhood only works so well, and until such blatantly deceptive narrative is being pushed, you may very well see your doomsday scenario realized. It's a trivially vulnerable position, so much so that it feels like a rhetorical trap almost. Like a poet self-sabotaging the monetization of their work, while waxing poetic about how they're (financially) un(der)appreciated. Although people have been getting into anti-government conspiracies pretty hard in the past few years, and governments have been working hard to demolish whatever good standing they have in parallel, so that does help your case I suppose. One may even recognize this miraculously well oiled process and nosedive in social trust as uncoincidental, in fact. But I digress. I wouldn't wanna spread conspiracy theories after all, would I?
The only people actually hurt by banning e2ee are regular people.
> It's like trying to pretend people are shopping for regular items on .onion webshops rather than for contraband. I'm sure that crowd exists, but like, who are we trying to fool here exactly?
Based on public metrics, 3% of Tor traffic is .onion traffic and it is incredibly likely the vast majority of that is the Facebook .onion service (based on some stats posted by Facebook a few years ago).
So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.
> So no, I think the burden of proof falls on you to show that the vast majority of .onion usage is illegal.
How does the burden of proof fall on me for a claim I (intentionally) did not make?
Given how many of them have been CIA honeypots, they must have amazing marketing.
> How does the burden of proof fall on me for a claim I (intentionally) did not make?
Nice trick -- make a very clear implication and claim that you didn't make a positive claim.
You may still fault me for mixing in beliefs into an argument, it is of poor form from me. Up to you. But then I don't think sentiments are just pure hard logic and evidence, so it'd have been potentially more dishonest from me to exclude it than to not.
First, the secure end-to-end encryption was broken by international police and messages were read without making it illegal.
Second they suggest reading hundreds of thousands of people’s messages to catch a dozen or so gang members - not supporting your claim that only crooks use it.
Third, the video ends by the gang leader saying he was working for the President; not supporting your implication that criticism of government is all baseless conspiracy theories.
The first counterpoint I can't even decipher, it makes no grammatical sense. Are you saying that law-enforcement-intercepted encrypted messages are not necessarily illegal? ...why would they be? Sounds like a strawman.
The second is explicitly a strawman. I intentionally left space for legitimate use, because it's a trivial rhetorical target, so I just said that it primarily interests "illegitimate" use for now. While I do not have actually comprehensive data on the Sky userbase, the way these devices were distributed, the volume of criminal-use-connected messages uncovered, and the globally dispersed gang use presented in the video did suggest to me exactly what I said. I'm not sure why you think "just catching a dozen or so gang members" is a reasonable takeaway either, given that the video's focus was exactly just those people.
We can take issue with this, and downgrade this to just being evidence of significant (in the statistical terminology sense of the word) criminal use rather than primary criminal use. I just both fail to find that particularly compelling, and don't really feel like arguing on your behalf.
The third counterpoint I also struggle to decipher. It seems to also build on a strawman like the other two points. You accuse me of implying that "criticism of govt is all baseless conspiracy theories". I don't know how you managed to extract such a thing out of what I wrote, so I'm not sure how to respond. Governments around the world are routinely criticized, have plenty of perfectly valid things going against them, on which both the media and the general public report on plenty. It is - thankfully - only a select few places in the world where such speech is actually restricted. Now that was more a part of my point.
The second is not a strawman, you claimed that only criminals are attracted to E2EE messaging when the link you gave showed some 170 thousand users of that specific messaging app with no suggestion that most of them were criminals. "I just said that it primarily interests "illegitimate" use for now" yes you did say that, and that thing you said is not supported by your link.
The third is about your writing about how people who want privacy are performative victims who are falling into anti-government conspiracy theories, but your link shows a thing which was not a conspiracy theory and the government in question actually was accused of targetting their political enemies with gangs, and it would be reasonable to want privacy against such.
> "I don't know how you managed to extract such a thing out of what I wrote"
> "But I digress. I wouldn't wanna spread conspiracy theories after all, would I?"
maybe write less of this winky-face bs and just say what you mean.
That is not the position I took (and as such, the video I link to was not in support of this either). The position I took is encoded in this sentence:
> (...) until such blatantly deceptive narrative is being pushed, you may very well see your doomsday scenario realized.
This is to say, I consider the "narrative" the person above is "pushing" to be "blatantly deceptive", given the well published and significant cases of criminal use, which I then linked to a recent example of, and in which stories private comms play a key role. That the fairy tale where encrypted comms is "merely just for innocent people to protect their privacy" is indeed "both obviously and evidently" phony, and pretending that it isn't thus only harms their political case, rather than help it.
It's frustrating that this has to be argued tooth and nail, because it is common sense. Private communications is essential for covert operations. Obviously by preventing such communications, you'll be harming such operations, a goal which can be trivially made politically compelling and for good reason. To say that this is "obvious" is an understatement.
> shows criminals being caught without banning E2E encrypted messaging
The video doesn't actually feature E2EE. It speaks of intelligence authorities extracting decryption keys from server memory, and using that to decrypt traffic. This suggests ordinary encrypted messaging (if even that), not E2EE. You'll notice I also wasn't singling out E2EE.
The video also spends a great deal of time on how those captured messages provided crucial evidence for their various crimes.
> Therefore your link does not support the claim that catching criminals needs E2EE apps banning.
Indeed, that link never meant to support such a claim to begin with. What it was meant to demonstrate was encrypted messaging directly supporting criminal use, and being an evidently attractive feature for criminals. So much so that they'll actively seek out weird-ass phone deals, like SkyECC.
> you claimed that only criminals are attracted to E2EE messaging
That is not what I claimed. What I claimed is that it is primarily individuals who are high risk that will be attracted, who will be "in good part" criminals:
> While the privacy scares have been pretty serious for a while, for now that is still both evidently, and indeed obviously, in good part criminals or other high risk individuals.
I could pretend I didn't mean majority use, but I'll spare you. Rewatching the video, I do concede that it does not outright claim the 70K monthly active users were found to be primarily criminals. It merely suggests so, such as by referencing the port of Antwerp dealings, and mentioning that there was a hotspot of users there. That is thus borrowed speculation on my behalf, although I do think it is plenty compelling enough. You're free to disagree or chase it further.
> The third is about your writing about how people who want privacy are performative victims who are falling into anti-government conspiracy theories
That is exceedingly not what I said. The person I was portraying to be a "performative victim" was OP, because they wrote in a sarcasm-laden, self-victimizing style, like so:
> That obviously means you're a drug trafficking money laundering pedophile terrorist. Off to jail with you despite zero evidence.
I then explained that people who already believe in anti-government conspiracy theories will likely be the ones to find it compelling, because what they said is against government control on encrypted comms, is conspiratorial in nature, and because governments have been abusing their power more and more lately:
> Although people have been getting into anti-government conspiracies pretty hard in the past few years, and governments have been working hard to demolish whatever good standing they have in parallel, so that does help your case I suppose.
This doesn't mean they have been specifically "falling into anti-government conspiracy theories" either. It means they're the ones actively sowing some, or at the very least are riffing off the trope hard and willfully. And that this is indeed weak against the evidenced criminal cases, even if they feel it shouldn't be.
> your link shows a thing which was not a conspiracy theory and the government in question actually was accused of targetting their political enemies with gangs, and it would be reasonable to want privacy against such
This is a non-sequitur. The gangs in question were not depicted to have relied on surveillance technologies or harvested comms intelligence, not on their own terms, nor through governmental means. One of the gangs being in bed with the local government being proven to be not a conspiracy also has little bearing on conspiracies at large. Some conspiracy theories are true, some aren't, some partially. Why would I make such an obviously fallible claim that government-related conspiracy theories are never true?
But maybe your point is more that being able to privately communicate can be helpful in cases like this. And I agree. Even beyond it, I do think that private communications are important, even essential, and I'd like to see them protected. I just also happen to think that very obviously bullshit deflections like this do not serve that cause. I mentioned the .onion webshop example, but I could have really brought up e.g. torrent as well. Is it exclusively for piracy? No, it cannot actually be: it transmits arbitrary data. Is it obviously the main attraction and what people use it for? Very much so. Does this mean it shouldn't proliferate further and be used in legitimate settings? No. It just means that defending it by pointing at it "not necessarily being for piracy" is a hideously weak, laughably phony political position, that would not at all stand up to scrutiny in a sufficiently adversarial environment. Like come on...
A robust argument for private comms, encrypted comms, and E2EE comms, in my opinion, does 100% need to have a compelling explanation on how it hopes to mitigate issues like this. Because beyond the sob story of the person above, these are very real avenues of abuse, avenues that these technologies do uniquely support, and this does matter. And I'm yet to encounter such an explanation. So much so, that some individuals even flagrantly refuse to address it, like the person above. They'd rather spend their time moping, and pretending that it's only ever the government conspiring against the people, painting them as terrorists, gangsters, and pedophiles falsely, just to get their data decrypted and stolen. This can and does happen too, but also, they do indeed could absolutely be all that, and sometimes are. As per the example above.
If I was holding a position where I'm arguing for backdooring private, encrypted, or E2EE comms, I'd need to similarly have a compelling story on how to mitigate governmental abuse. I do not hold such a position however, exactly because I have no proposal in the way of that. I do recognize this at least, and am more than willing to acknowledge it. This is a complex matter, and I think it should be discussed accordingly. Not with tired self-victimizing brainwash like the person above.
> maybe write less of this winky-face bs and just say what you mean.
All the points you ran into issues with were delivered in very direct terms.
https://en.wikipedia.org/wiki/Shutdown_of_Sky_Global#Communi...
EDIT: Based on German law this certainly is not a lawful interception but one made by an intelligence agency.