Hacker News Reader

Comment by kragen | Hacker News Reader

a compromised root ca allows an attacker who already has dns or ip control (via bgp, arp spoofing, a captive portal, etc.) to leverage it into a working mitm attack on a tls site, but it can't revoke certs it didn't sign, and the attack is over as soon as the attacker loses dns or ip control

by contrast, the ca you chose to sign your cert can revoke it, or refuse to renew it, taking your website permanently offline with zero effort on their part, unless you can find another ca to sign a new cert for you

but if you could, let's encrypt wouldn't have had to exist in the first place

the dozens of companies you mentioned make that less of a threat, not more of one, though they do of course increase of mitm attacks as i described in the first paragraph of this comment

View on HN

> a compromised root ca allows an attacker who already has dns or ip control

DNS or host/IP control is not a requirement at all: a Trusted CA is already trusted to sign a certificate for any hostname (with exceptions): that's what Trust means, and it also means that we trust them not to issue certificates for domains/hostnames without doing at-least Domain Validation - and we have schemes like Certificate Transparency to help bolster that trust, but it still doesn't prevent an already-trusted CA from issuing its own certificate for, say, google.com or microsoft.com. This is why techniques like Certificate Pinning and co/counter-signing, and others exist - but they're only useful when the client isn't a human-operated web-browser ("smart clients", "IoT", etc). EV certificates were (amongst other things...) meant to help protect against small-time crooks but again, don't help when the CA itself is compromised.

if i type https://gmail.com/ into my browser, it usually doesn't matter if you have successfully gotten comodo or actalis to issue you a fake certificate for gmail.com, because my browser doesn't try to connect to your malicious server; it tries to connect to google's actual gmail server, and so you don't receive my packets, and your fake certificate does you no good

but, as i said, if you can feed me fake dns results so i connect to the wrong ip, or if you can arrange so that packets to gmail's legitimate ip go to your server instead (for example by having me connect to your wifi), then you can leverage the fake certificate into a successful mitm attack

but your explanation of the part of the basics of tls you understand, incomplete though it is, is irrelevant to the attack i was actually discussing, where someone doesn't like what you're saying (or the communication service you're providing) and gets your cert revoked to shut you up

because my browser doesn't try to connect to your malicious server

Unless a router is compromised along the route, which is a known thing, and part of why we use ssl everywhere now.

the paragraph immediately following the one you quoted from explains that, and did so nine hours before your comment

the grandparent comment https://news.ycombinator.com/item?id=34629050 also describes some more common ways that this can happen without routers being compromised

Noted.

If the browser enforced that the certificate had been issued in line with the domain's CAA record, such an attack might be less tractable without DNS control...

Reply on news.ycombinator.com