7 ms·
Parallel Reconstruction of Lawful TLS Wiretapping
- TZubiri 4mo agoWhat LI vendors can break https?
- jerrythegerbil 4mo agoThe sloppy ones who want a huge headache and leave a publicly auditable trail a mile long that get analysis blogs written about their mistakes.
- perching_aix 4mo 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 4mo agoI 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.
- deleted 4mo ago[deleted]
- ls612 4mo agoI 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 4mo agoBasically, 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).
- perching_aix 4mo agoNothing, 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 4mo agoYeah 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.
- XorNot 4mo agoDo 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.
- edelbitter 4mo 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 4mo agoThat 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 4mo agoI'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
- aleksejs 4mo agoThe 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.
- ValdikSS 4mo agoThat'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.
- 8organicbits 4mo agoOne 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.
- aleksejs 4mo ago> This is imperfect, as CAA record validation is not mandatory yet. But by March 2027 all the CAs a supposed to have support. 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-requirements/documents/CA-Browser-Forum-TLS-BR-2.2.7.pdf https://cabforum.org/working-groups/server/baseline-requirem...
- mcpherrinm 4mo agoCAA 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.
- codedokode 4mo agoThis is a reminder why you should use E2EE messengers only.
- upofadown 4mo agoI 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.
- matheusmoreira 4mo agoOne 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.
- perching_aix 4mo agoSounds heartwrenching until you see a story like this: https://youtu.be/hKLIxxBrM-o https://youtu.be/hKLIxxBrM-o 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?
- nl 4mo agoThis isn't what parallel reconstruction means. This seems to be reverse engineering the attack.
- crystaln 4mo agoIndeed. 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 4mo agoParallel 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.
- jerrythegerbil 4mo agoParallel Construction is a term: https://en.wikipedia.org/wiki/Parallel_construction https://en.wikipedia.org/wiki/Parallel_construction 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 4mo agoThanks for explaining. It's an interesting turn of phrase. I don't see how it relates to parallel construction.
- 0xbadcafebee 4mo agoYes 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.
- mtucker502 4mo agoHow 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.
- janmo 4mo agoSo 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). https://en.wikipedia.org/wiki/Shutdown_of_Sky_Global#Communication_interception_and_decryption_by_law_enforcement 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.
- Peacefulz 4mo agoCan we get an RSS feed? Loved the post.
- ghostlyInc 4mo ago[dead]
- arowthway 4mo agoWe 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. https://rachelbythebay.com/w/2025/05/22/ssl/ https://rachelbythebay.com/w/2025/05/22/ssl/