Parallel Reconstruction of Lawful TLS Wiretapping
jerrythegerbil
79 points
38 comments
May 30, 2026
Related Discussions
Found 5 related stories in 97.3ms across 8,961 title embeddings via pgvector HNSW
- Bad Connection: Global telecom exploitation by covert surveillance actors miohtama · 123 pts · May 03, 2026 · 50% similar
- Acoustic Eavesdropping with Telecom Fiber Optic Cables Chaucer · 23 pts · April 08, 2026 · 49% similar
- Building a peer-to-peer alternative to Cloudflare Tunnels with edge TLS certs miloschwartz · 13 pts · May 28, 2026 · 48% similar
- CrabTrap: An LLM-as-a-judge HTTP proxy to secure agents in production pedrofranceschi · 106 pts · April 21, 2026 · 48% similar
- WireGuard Is Two Things mlhpdx · 17 pts · March 12, 2026 · 47% similar
Discussion Highlights (8 comments)
TZubiri
What LI vendors can break https?
perching_aix
> 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
ls612
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?
edelbitter
>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.
aleksejs
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.
codedokode
This is a reminder why you should use E2EE messengers only.
nl
This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.
0xbadcafebee
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.