The case of the fraudulent SSL certificates [LWN.net]

The case of the fraudulent SSL certificates

Posted Mar 24, 2011 8:57 UTC (Thu) by Da_Blitz (guest, #50583)
In reply to: The case of the fraudulent SSL certificates by skissane
Parent article: The case of the fraudulent SSL certificates

there has been some discussion about putting the ssl certs in DNS itself however for this to be secure you really need DNSSEC widely deployed in advance

this doesn't eliminate fraudulent ssl certificates, just reduces the possibility of them occurring by reducing the amount of parties involved (eg someone asks the ".com" provider to delegate the domain to them and they just mirror your records with slight modifications)

there could also be issues with caching, i have seen more than one ISP modify dns headers and change the TTL value to 3+ days which caused havoc with site migrations. munging of the TTL field could cause time delays with revoking certs

the anti malware guys really don't like it when you delay for any reason.

i already use the SSHFP record to indicate which ssh keys are valid for a host and it works well but in conjunction with my standard known hosts file (in revision control to make it easy to move out to new hosts and keep track of things)

personally i think the dns records combined with other methods eg a local list of certs watching for changes and checking with a distributed table of sites => certs is the best option. however i would hate to see the conflict resolution code should one and not all of these comes back with an "invalid cert"

to post comments

The case of the fraudulent SSL certificates

Posted Mar 24, 2011 21:58 UTC (Thu) by Simetrical (guest, #53439) [Link] (4 responses)

It doesn't eliminate fraudulent certificates, but it reduces a gazillion points of failure to one point of failure. Currently, compromising one CA allows you to forge any certificate you like -- and there are what, thousands of CAs? If we used DNSSEC instead, the only way to inject a forged certificate would be to compromise the DNS servers of the site itself, or the DNS servers of a higher-level domain. For a high-profile site, that reduces the attack surface to almost nothing. Instead of being able to forge google.com certificates by exploiting any CA on the planet, you suddenly have to exploit either .com TLD nameservers, or google.com nameservers . . . which is going to be close to impossible in either case.

A shorter-term and less complete solution would be to extend HTTP Strict Transport Security to say "ignore any certificates that aren't signed by this specific CA". That would also drastically reduce attack surface, and although in the long run it's probably inferior to DNSSEC, it would be much easier to deploy.

The case of the fraudulent SSL certificates

Posted Mar 25, 2011 8:48 UTC (Fri) by pbonzini (subscriber, #60935) [Link] (1 responses)

> Instead of being able to forge google.com certificates by exploiting any CA on the planet, you suddenly have to exploit either .com TLD nameservers, or google.com nameservers . . . which is going to be close to impossible in either case.

What about country TLDs? If a government wants to do a MITM attack, it can surely control the country-level nameserver.

The case of the fraudulent SSL certificates

Posted Mar 25, 2011 13:59 UTC (Fri) by foom (subscriber, #14868) [Link]

But at least then it's *only* that government for that TLD that can MITM the sites under their TLD, instead of the governments of every single country in the world...

The case of the fraudulent SSL certificates

Posted Mar 31, 2011 21:56 UTC (Thu) by job (guest, #670) [Link] (1 responses)

If you follow best practice compromise of a DNS server does not lead to compromise of DNSSEC for that zone, as the zones should be signed on a separate server. There should be no keys on the public DNS server.

The case of the fraudulent SSL certificates

Posted Mar 31, 2011 22:40 UTC (Thu) by Simetrical (guest, #53439) [Link]

Okay, granted. I should have said that you have to compromise Google's servers, not specifically its nameservers. The point is the same, that you have to target specific servers and don't get to pick the weakest out of a very large group, so your attack surface drops drastically. Of course, the signing servers aren't going to be Internet-accessible, so will probably be even harder to exploit than the nameservers. But exploiting the nameservers of a huge and well-run shop like Google would already be a pretty difficult feat for even a well-funded criminal hacker group (although maybe not for some governments).