Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Parallel Reconstruction of Lawful TLS Wiretapping

remyhax.xyz

Post reply on HN
Print view View original

31–40 of 81 posts

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#31

Post by crystaln »

nl wrote: post #30

This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#32

Post by crystaln »

crystaln wrote: post #31
nl wrote: post #30

This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.

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.

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#33

Post by tptacek »

Hizonner wrote: post #28
j16sdiz wrote: post #26

Earlier quoted context omitted.

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

> It is too fragile (multiple point of failure). 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 certifica…

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#34

Post by jerrythegerbil »

nl wrote: post #30

This isn't what parallel reconstruction means. This seems to be reverse engineering the attack.

Parallel Construction is a term: 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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#35

Post by matheusmoreira »

codedokode wrote: post #21

This is a reminder why you should use E2EE messengers only.

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#36

Post by LelouBil »

wahern wrote: post #29
edelbitter wrote: post #11

>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.

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 proc…

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

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#37

Post by cobertos »

8organicbits wrote: post #22
aleksejs wrote: post #17

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.

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.

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.

[0]: https://developers.cloudflare.com/ssl/edge-certificates/caa-...

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#38

Post by mcpherrinm »

j16sdiz wrote: post #26
mcpherrinm wrote: post #25

Earlier quoted context omitted.

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.

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

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.

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: Parallel Reconstruction of Lawful TLS Wiretapping

#39

Post by 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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#40

Post by 0xbadcafebee »

ls612 wrote: post #4

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?

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).

Post reply on HN