LWN: Comments on "The case of the fraudulent SSL certificates"

The case of the fraudulent SSL certificates

Simetrical — 2011-03-31T22:40:07+00:00

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

The case of the fraudulent SSL certificates

job — 2011-03-31T21:56:33+00:00

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

gerv — 2011-03-25T18:31:03+00:00

Mozilla has now posted a more detailed update here: http://blog.mozilla.com/security/2011/03/25/comodo-certif... .

Gerv

The case of the fraudulent SSL certificates

foom — 2011-03-25T13:59:08+00:00

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

pbonzini — 2011-03-25T08:48:58+00:00

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

Certificate Patrol

xanni — 2011-03-25T07:19:40+00:00

See also the "Perspectives" plugin, which uses "network notaries" to monitor certs and will also warn you if certs change unexpectedly:

https://addons.mozilla.org/en-us/firefox/addon/perspectives/

The case of the fraudulent SSL certificates

ras — 2011-03-25T01:11:26+00:00

Thanks for that. I was wondering how a fraudulent certificate could possibly be generated. I was initially surprised by this turn of events, but in hindsight it is obvious the PKI infrastructure would be attached and abused in this way.

An odd thought popped into my head. Israel: our hackers can infect a few computers and knock your nuclear plans off line. Iran: yeah, well ours can attack the PKI infrastructure so we can spy on what our unruly citizens are saying.

Security is become a serious business indeed.

The case of the fraudulent SSL certificates

Simetrical — 2011-03-24T21:58:44+00:00

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

jake — 2011-03-24T18:32:29+00:00

> It is untrue and inflammatory to say that "browsers are generally not
> checking the revocation status of certificates".

I don't know about "inflammatory", but it is certainly "untrue". That was my misunderstanding, and has now been corrected above.

jake

The case of the fraudulent SSL certificates

nybble41 — 2011-03-24T18:07:48+00:00

You try to connect to PayPal. The bad guy intercepts your connection and forwards the traffic to/from the real PayPal site. This is essentially the definition of MITM.

Normally, SSL/TLS would prevent the MITM from observing the cleartext of the traffic, since (a) the MITM needs the proper private key to decrypt what you're sending, and (b) the client verifies that the public key used to encrypt outgoing traffic corresponds to the domain name. The bad guy can only observe the unencrypted traffic by substituting a different certificate, one which would not be approved by a registered CA for use with that domain, thus giving away the MITM attack.

The existence of a fraudulent certificate nullifies (b), since the client will see a certificate certified for the right domain name, but (presumably) the bad guy has the corresponding private key and can thus decrypt the traffic (and re-encrypt it with the right certificate before forwarding it to PayPal, or visa-versa).

The case of the fraudulent SSL certificates

gerv — 2011-03-24T18:07:41+00:00

It is untrue and inflammatory to say that "browsers are generally not checking the revocation status of certificates". There are no browsers which don't check. The issue here is the possibility that a user might not be able to reach the URLs at which revocation information is found.

"In addition, many browsers do not keep track of the certificates that they have received and alert users when they change." This is true, but the entire point of the certificate model is that this is not necessary. And if it were done, users would be bombarded with cert change errors, because certs change regularly. They would just learn to ignore them.

The two test certificates for which Jacob could find no match in the CRLs were issued to Google and Mozilla to test their blacklisting code.

Gerv

The case of the fraudulent SSL certificates

giraffedata — 2011-03-24T17:53:19+00:00

How does a fraudulent certificate allow a man in the middle attack? Say I connect to a bad guy's wireless access point in an airport, then browse Paypal. How does the bad guy sniff my Paypal password?

I can see how the bad guy could connect me to his impostor Paypal site, but that's not man-in-the-middle.

Certificate Patrol

cesarb — 2011-03-24T15:53:17+00:00

I found on a slashdot comment a link to a Firefox extension which could help mitigate these kinds of incidents: Certificate Patrol (https://addons.mozilla.org/en-us/firefox/addon/certificat...).

The case of the fraudulent SSL certificates

jello — 2011-03-24T14:11:22+00:00

Comodo posted their report at http://www.comodo.com/Comodo-Fraud-Incident-2011-03-23.html

The case of the fraudulent SSL certificates

job — 2011-03-24T10:13:26+00:00

Certificate revocation has been broken from the beginning. Not only do you need to worry about careless CAs, but stealing certs is way too easy given the security state of web applications. Other important parts of SSL is also broken, such as the ability to delegate and trust a particular cert only on your subdomains.

I wish we could just use DNSSEC for this, but things move very slowly. While I understand the concern that DNS is not identity, I strongly believe that is not the common use case. I am much more often concerned that the certificate I am presented with is legitimate for "lwn.net", than that it belongs to "Eklektix Inc."

The case of the fraudulent SSL certificates

job — 2011-03-24T10:05:15+00:00

It's being actively discussed, but (much too) slowly.

See for example draft-schlyter-pkix-dns-02.

The case of the fraudulent SSL certificates

Thue — 2011-03-24T09:37:33+00:00

It is obviously the responsibility of the browser to reject any certificates for which it can't reach the revocation list. Which only Chrome get's partially right: http://www.imperialviolet.org/2011/03/18/revocation.html

The case of the fraudulent SSL certificates

Da_Blitz — 2011-03-24T08:57:24+00:00

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"

The case of the fraudulent SSL certificates

ribbo — 2011-03-24T02:52:08+00:00

I read somewhere that these certificates may have actually been used by a particular country. In the case of the using a CRL or OCSP there's then nothing to stop the MITM from either just redirecting them or blocking access to the service just as they are for the other component of the MITM.

The case of the fraudulent SSL certificates

skissane — 2011-03-24T01:49:36+00:00

Why not use DNS?
Create some new type of DNS record, or just reuse TXT.
It can indicate what types of SSL certs are valid for this domain.
e.g. only certs with these serial number, only certs from this CA, etc.
Browser would check the DNS record for the site, to look for any
constraints on the SSL cert, and error out if they were violated.

Without DNSSEC, this doesn't add that much -- attacker just has to MITM
DNS as well -- although it does make their work a bit harder. But with
DNSSEC, this could be a solution to the problem.