Hacker News Reader

Comment by CKN23-ARIN | Hacker News Reader

Why is it that the CA can expect no tampering? It seems to me that it would not be hard for certain classes of attackers to MitM a CA.

View on HN

CAs should be able to afford to make the requests from multiple sources and compare the results.

Alternatively they can use secondary challenge-response auth which depends on some credentials being deployed to your server. Mitm-ing it wouldn't give the attacker anything interesting in that case.

CAs bet the farm on the idea that doing two separate DNS queries instead of one will keep them safe. This is a ridiculous assumption. Sophisticated attackers can often successfully attack multiple targets at once.

They can use a secondary challenge, but this being optional completely defeats the purpose. A MITM attack will allow an attacker to pretend to be the target during creation of a new cert, tricking a random CA into giving them a valid cert. You do not need to use the CA that the site owners use, so their use of an extra challenge is irrelevant.

Lots of assumptions which are ridiculous in theory are pretty good in practice. Having to MITM multiple servers just to get a cert (which will most likely be detected on the CT logs) is orders of magnitudes harder than just clicking a button on Firesheep or adding a few lines of code to a router malware.

Credit cards literally rely on every single merchant not leaking their info, yet as flawed as that is, there's no great pressure to replace them.

Credit cards have manual charge back as a fallback with human driven process. The equivalent fallback for certificates does not exist. You can only revoke.

They're not just doing two queries. Anybody on HN with a strong opinion about DNS and CAs and a bare minimum of programming ability could rig up a fairly sophisticated DNS validation service in under a week. Just think about how you would do it, given a pretty reasonable budget.

I'm not thinking about a sophisticated service. I'm thinking about the weakest link in the chain that I could possibly exploit to generate fake certs. Pick the least secure CA with the least secure validation method and you now have valid fake certs.

Even if DNS by itself was secure enough to validate, this is a single factor and there are many ways to exploit a single factor. Why a secondary mechanism/factor isn't required for critical infrastructure makes no sense.

I'm not making a point about the CA system as a whole, just about multi-perspective DNS verification.

I didn't say they do that. Just that it's one of the ways to avoid a single, targeted mitm. There are many other approaches and cab baseline requirements (3.2.2.4.) are not very specific on what's specifically expected.

> CAs should be able to afford to make the requests from multiple sources and compare the results.

Do they actually do that in practice? Are they required to do so? (How many sources and how far distinct?)

To test this, I just now acquired a Let's Encrypt cert using `certbot certonly` while tailing the logs. I received only a single request, from 64.78.149.164. The cert was issued. They did not appear to take a second measurement.

On your DNS or on your webserver? Did you use a fresh domain or a domain that has been previously seen in DNS?

On my webserver (http-01 challenge type). Fresh hostname. Fresh VM. Fresh certbot install.

That's not a DNS challenge.

HTTP challenges do not offer meaningfully increased resistance to MitM over DNS challenges, and require measurements from multiple vantage points just as much as DNS challenges do.

No, but it is a good example that CAs don't require DNS changes to assign a cert. One just needs to MITM an HTTP connection for a single request. (Or, depending on the CA, control one of the following email addresses: "admin@example.com, administrator@example.com, postmaster@example.com, webmaster@example.com, hostmaster@example.com")

Let's Encrypt seems to be working on validating from multiple vantage points, by doing or having done this in their staging environment: https://community.letsencrypt.org/t/validating-challenges-fr...

Can you elaborate this MITM attack? How would it work?

Local network tampering (ARP etc) at registrar end, routing attacks such as BGP hijack, below-IP attacks in transit (eg MPLS hijack, malicious transit router, QUANTUM INSERT, other fiber tap approaches, ...) DNS implementation bugs in UDP spoofing countermeasures, local network tampering at domain holder end, social engineering or extortion against transit or stakeholder sysadmins, etc. It's a long list of possibilities.

Right. Which ones of those leave the signatures on root zone, the .com zone and the cert unaffected and are transparent in any real sense of the word?

Reply on news.ycombinator.com