Hacker News Reader

Comment by thayne | Hacker News Reader

There is one case where I think DNSSEC provides a lot of value: domain validation for the purpose of issuing a TLS certificate.

To get a DV certificate, the most common kind, you just have to prove you own the domain. If someone can MitM the DNS request to verify domain ownership, then they can issue a certificate for your domain. Transperency logs help protect against this, as long as you are watching them, and notice the bad cert issued before too much damage is done. Granted, there isn't a big risk of MitM between the nameserver and the CA, hopefully with multiple locations. But a state actor might be able to do it.

Still, I'm not sure that is worth the complexity of DNSSEC. Especially since you really only need signed records for specific records.

View on HN

On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare). By far the most common way people lose control of their domains (and their certificate identities) is by getting their registrar account phished.

Are they doing full chain TCP lookups?

Asking earnestly as I don't know. If they aren't, they absolutely should be.

You're probably correct in your assessment, but it does still happen.

https://medium.com/s2wblog/post-mortem-of-klayswap-incident-...

https://petsymposium.org/2017/papers/hotpets/bgp-bogus-tls.p...

I think it's quite telling that the examples here all involve BGP subversion, which DNSSEC doesn't coherently mitigate: universal DNSSEC deployment would change the exploit you'd deploy to exploit BGP, but it wouldn't break the vulnerability.

Out of curiosity—how does DNSSEC fail to address this specific vulnerability? Wouldn't it make it impossible to get an HTTPS/DNS record response for this zone, taking it from a "fail dangerous" MITM attack that could violate confidentiality to a simple "fail safe" DOS attack that only harms availability?

> On-the-ball CAs are already doing multi-perspective lookups from multiple global POPs to reduce the theoretical potential for this attack (which is probably extraordinarily rare).

It was certainly visible when a previous employer tasked me to go looking for it, in I'd guess 2018 or so. I have no details from that work because by convention I keep nothing, although by mistake I do still have a front door key to the office, which I really ought to get back to them one day.

IIRC the main targets were military and government entities in less important (so not G7) countries. We were focused on email at the time, but these days perhaps you would target other infrastructure and the shape of the attacks would look different. Since "Governments of poor countries" isn't an attractive sales target for a startup I don't think that work progressed beyond my investigation.

The Web PKI assumes the DNS is trustworthy, which in practice means DNSSEC or else just hoping. You are in team hope, and I think you ought to make that clear to people.

It is simply not true that the WebPKI relies on the continuous global trustworthiness of the DNS.

And a fact that you're not communicating to your audience here is that the ordinary way DNS is subverted to trick CAs is by phishing registrar accounts.

You can read more about multi-perspective validation here:

https://www.cs.princeton.edu/~jrex/papers/multiva20.pdf

State actors don't need to MitM the CA, they just order a CA they have leverage over to issue them a certificate.

... which is then logged in CT logs.

As it is if they MitM the CA.

I’m not sure how CT logs actually work, but is it impossible for the CA to issue a certificate that is not entered into the CT logs? If it’s possible, then governments would surely just require that, and then it would only be caught by interception of the actual certificate being used.

Browsers won't accept a certificate unless it comes with proof that it was submitted to a CT log.

So a government could MITM you but they'd have to burn a CA to do it, whether you personally noticed the attack or not, so it's a very high cost attack

The proof is an SCT, a signed document from the Log which says "I promise I logged this pre-certificate". [[ In some cases it'll be the actual certificate, but for most real world TLS certificates it's a pre-certificate with the same substantive details, if you think about it you will see why the SCT baked inside your certificate cannot mention the actual document it is baked inside ]]

Now, of course at the moment this document is created, there's no way to be sure this claim is true. The logs are a distributed system.

Twenty four hours later, (the Maximum Merge Delay, this is a global policy decision) the log should, if you interrogate it, be able to show you a log entry matching the SCT, which traces to the agreed Merkle Tree head for that log. If it cannot, in principle that log has failed and must be distrusted. This happens (to one of the dozens of public logs, somewhere) a few times per year on average.

In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use.

It's probably fine, but without ever completing the system as designed, it does have flaws.

> In principle, everybody who sees the log could agree that they see the same Merkle Tree head, thus the certificate really is logged. In practice the mechanisms to ensure this works, a Gossip protocol, do not exist and have never been deployed in practical use.

It has been - the commercial instance of Cert Spotter gossips STHs with Chrome's SCT auditing infrastructure.

Edit: here's the gossip feed of STHs observed by Chrome's SCT auditing infrastructure: https://www.gstatic.com/ct/gossip/ct/v1/sth-pollination

And here's the gossip feed of STHs observed by Cert Spotter: https://certspotter.com/.well-known/ct/v1/sth-pollination

Ooh interesting, when did that start?

2017, but it only started having real value once SCT auditing rolled out in 2022.

This is theoretically true but not really true in practice right now.

If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt.

But if a CA misissued such a cert for a single specific target, without a CT SCT, neither Chrome nor Safari will report that (currently, CAs are explicitly allowed to issue non-CT-logged certs; the check on that is that Chrome and Safari won't honor that certificate --- a reason, by the way, to reconsider Firefox). If Google found out that you'd misissued a non-logged Google Mail certificate, you'd get nuked. But there's nothing currently in place to make Google find that out.

It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration. But that kind of surveillance isn't really a thing right now.

I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago. Now they just don't accept certs unless they're logged, and that's that.

> If a CA misissues a cert for something major, like Facebook or Google Mail, and Google or Mozilla find out, my current belief is that they'd be in for a world of hurt.

It doesn't even need to be major. Misissuing for example.com and test.com were major factors in the distrust of Symantec and Certinomis, respectively.

> It's clear what tweaks to the system would need to occur to make this work that way it would "ideally" work, and the problems are mostly not technical; you'd just have Chrome (or Safari, or Firefox) report certs without SCTs in its default configuration.

This would require a pretty big paradigm shift which is hard to see happening. But as long as clients require SCTs (Firefox needs to hurry up already) this is not really necessary.

> I've been cagey about this in past discussions because my understanding was that the Chrome team did do some of this kind of surveillance informally. And I believe they did --- but I'm told that stopped being a thing years ago.

I'm pretty sure this has never been the case. I think at one point Chrome may have reported certificates for Google domains that were not issued by a Google CA, but this was unrelated to CT.

Or maybe you're thinking of the Googlebot, which logs the certificates it sees while crawling the web.

I may have misconstrued things I was told by team members, or you might have, but either way it doesn't matter, because it's not happening now. You were right to call this out on the last DNSSEC thread, and I want to make sure I'm not endorsing a WebPKI security feature that doesn't currently exist. :)

Many major browsers expect CT, and won't accept a certificate from a default CA without it being in CT. Therefore it matters a little less whether such a certificate can be issued, but rather whether it can be accepted by a browser (which many popular ones won't). And therefore it will become relatively noisy and detectable if such a certificate is deployed at any sense of scale.

Chrome - https://chromestatus.com/feature/6244547273687040

Safari - https://support.apple.com/en-gb/HT205280

Firefox doesn't support it yet though - https://bugzilla.mozilla.org/show_bug.cgi?id=1281469

In essence, a cryptographic proof that the certificate was sent to CT providers needs to be enclosed along with the certificate. That can come via an OSCP staple, or a TLS extension.

More info - https://developer.mozilla.org/en-US/docs/Web/Security/Certif...

But what about clients that aren't browsers?

What about them? It's not like any of this technology requires a Javascript implementation to run.

But how prevalent is it that other clients verify a cert is in a CT log?

That's not how CT works! You don't have to go check if a cert is in a log!

(How many client/embedded systems do fully recursive DNSSEC verification? Zero!)

You have to check that a cert includes a signature that it was logged, or you risk accepting a certificate that wasn't logged.

There is not currently a good story for non-browser clients. Generally, non-browser clients don't enforce CT, and those that do are at risk of breaking if they don't stay on the ball with changes to the CT ecosystem. Browser makers can stay on the ball because they are well-resourced and competently staffed; non-browser apps, not so much.

Case in point: earlier this year a bunch of CT-enforcing Android apps were suddenly unable to establish any TLS connections because Google stopped publishing a JSON file which these apps should never have been consuming in the first place. There was plenty of warning that this would happen, but the author of the Android CT library was not on the ball, and app developers were not keeping their dependencies up-to-date: https://groups.google.com/g/certificate-transparency/c/38Lr9...

I hope this will get better with time and we will find a way to safely extend the benefits of CT to non-browser apps. I think we're more likely to find success with CT than with DNSSEC, but there is no free lunch.

If I read it correctly, it's in Chrome since the middle of 2018:

https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer...

In that context, reading the already mentioned Firefox bugzilla communication is even more interesting:

https://www.ssl2buy.com/wiki/google-will-start-enforcing-cer...

It seems Firefox implementing it or not doesn't change much, in this case, due to its low matket share.

There is no way to prove that every cert from every CA gets logged in CT. How can I know for certain some CA out there is not creating certs and not logging them?

CAs can issue certificates without logging them, but such certificates will lack receipts (SCTs) from CT logs, and will be rejected by major browsers.

Where it's just one out of hundreds of Let's Encrypt certificates.

Two simple things are missing to make any of this infrastructure useful at all:

- A system as easy as ACME for domain holders to revoke any certificate. A few months ago, Cloudflare started issuing certificates for domains where they're only dns hosts. They issued these certificates through the Google CA, without informing the domain owners. I only found out through a CT alert. The response when I contacted both Google and Cloudflare was a shrug and a runaround, and the certificates were never revoked.

- A monitoring system that will only alert me on new certificates in the CT logs that it can't find on my infrastructure. Alternatively, an external system that will alert me if it sees a new certificate for foo.example.org that it can't see being used at foo.example.org - the low number of false positives should still make it worth it.

> A system as easy as ACME for domain holders to revoke any certificate.

ACME in fact supports this, and I expect at some point CAs will be required to support it.

In the meantime, I'm working on a tool that will take a certificate, identify the true issuer, look up the CA's problem reporting email address, and provide an email template with the right words to make the CA care. If the CA supports revocation over ACME the tool will take care of revocation automatically (although you'll still have to demonstrate control over the domain).

(Note however that your example is flawed because the certificate was actually authorized by virtue of making Cloudflare your DNS provider. If you don't like that, your recourse is to pick a different DNS provider which is more respectful of their customers.)

> A monitoring system that will only alert me on new certificates in the CT logs that it can't find on my infrastructure.

Commercial CT monitors, like Cert Spotter (my product) or Hardenize support integration with your certificate issuance infrastructure so you're only notified if the certificate is unknown. I only get CT alerts for my domains if I actually need to care.

The open source version of Cert Spotter can execute a script when it discovers a certificate, and I know of users that use this to cross-check against their inventory and only send an alert if the certificate is unknown.

> ACME in fact supports this, and I expect at some point CAs will be required to support it.

If you use ACME to get a certificate from CA1, then you can use ACME to revoke the same certificate from CA1.

But if the cert was issued from CA2 (via ACME or otherwise), there is nothing you can do about it. And even if the 'rogue' cert was also issued from CA1 as well (but under a different account), unless you have the private there is nothing you can do to revoke it; only perhaps get a completely new cert that 'supersedes' it.

No, ACME allows you to revoke a certificate if you can successfully complete a challenge for every domain in the certificate (see https://www.rfc-editor.org/rfc/rfc8555#section-7.6 "an account that holds authorizations for all of the identifiers in the certificate"). The certificate need not be issued from the same account.

Once root programs require all CAs to support ACME, then all you need for automatic revocation is a mapping from CA to ACME directory URL (this could perhaps be disclosed through the CCADB).

Reply on news.ycombinator.com