Live data from Hacker News

Parallel Reconstruction of Lawful TLS Wiretapping

remyhax.xyz

61–70 of 81 posts

Re: Parallel Reconstruction of Lawful TLS Wiretapping

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

https://rachelbythebay.com/w/2025/05/22/ssl/

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#62
post #49

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

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

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

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#63

Earlier quoted context omitted.

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

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

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

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#64
post #49

Earlier quoted context omitted.

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

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

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#65
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?

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.

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#66
post #63

Earlier quoted context omitted.

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

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

https://googlechrome.github.io/CertificateTransparency/ct_po...

Re: Parallel Reconstruction of Lawful TLS Wiretapping

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

Thanks for explaining. It's an interesting turn of phrase. I don't see how it relates to parallel construction.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#68

Earlier quoted context omitted.

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

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

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

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#69
post #49

Earlier quoted context omitted.

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

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

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

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#70
post #64

Earlier quoted context omitted.

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

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.

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
Post reply on HN