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

71–80 of 81 posts

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#71

Post by tptacek »

0xbadcafebee wrote: post #70
tptacek wrote: post #64

Earlier quoted context omitted.

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

Oh, I agree about their market power, just saying CAB is complicated.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#72

Post by nickf »

crote wrote: post #63
joxdosba wrote: post #42

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…

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#73

Post by leonidasrup »

cyphar wrote: post #49
0xbadcafebee wrote: post #39

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…

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.

https://en.wikipedia.org/wiki/Zookos_triangle

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#74

Post by account42 »

0xbadcafebee wrote: post #39

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

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#75

Post by account42 »

mtucker502 wrote: post #45
0xbadcafebee wrote: post #39

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

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.

DNSSEC is a thing you know. And not it doesn't allow a random Chinese agency sign records for my .de domain.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#76

Post by tialaramex »

cyphar wrote: post #69
tialaramex wrote: post #54

Earlier quoted context omitted.

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

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#77

Post by tptacek »

account42 wrote: post #75
mtucker502 wrote: post #45

Earlier quoted context omitted.

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.

DNSSEC is a thing you know. And not it doesn't allow a random Chinese agency sign records for my .de domain.

You mean until major DNS providers turn DNSSEC off for .DE to work around misconfigurations, which literally just happened.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#78

Post by account42 »

tptacek wrote: post #77
account42 wrote: post #75

Earlier quoted context omitted.

DNSSEC is a thing you know. And not it doesn't allow a random Chinese agency sign records for my .de domain.

You mean until major DNS providers turn DNSSEC off for .DE to work around misconfigurations, which literally just happened.

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.

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#79

Post by tptacek »

account42 wrote: post #78
tptacek wrote: post #77

Earlier quoted context omitted.

You mean until major DNS providers turn DNSSEC off for .DE to work around misconfigurations, which literally just happened.

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…

The "operators" you're referring to are the .DE TLD operators, right?

Re: Parallel Reconstruction of Lawful TLS Wiretapping

#80

Post by westurner »

mcpherrinm wrote: post #38
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

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

Is there a Transport-Secured-Only flag in a DNS spec? How to ensure that a CAA cert fingerprint is not retrieved over unsecured DNS?

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

Post reply on HN