Today at the Chaos Computing Congress, a group of researchers (Alex Sotirov, Marc Stevens, Jake Appelbaum, Arjen Lenstra, Benne de Weger, and David Molnar) announced that they have found a way to forge website certificates that will be accepted as valid by most browsers. This means that they can successfully impersonate any website, even for secure connections.
Let me unpack that for non-experts.
One of the cornerstones of web security is the use of secure connections. When your browser makes a secure connection to (say) Amazon and gets a page to display, the browser displays in its address bar a URL like “https://www.amazon.com”. The “https” indicates that the secure (https) protocol was used, and the browser also displays a happy blue lock or key icon to tell you the connection was secured.
The browser cooperates with Amazon’s web server to secure the connection via a two-step process. First, the two computers negotiate a shared secret key that they can use to communicate privately, using crypto tricks that I won’t describe here. Second, your browser authenticates Amazon’s web server, that is, it assures itself that the party on the other end of the connection is the genuine Amazon.com server.
Amazon has a digital certificate that it sends to your browser, as part of proving its identity. The certificate is issued by a party called a certification authority or CA. Your browser comes pre-programmed with a list of CAs its trusts; you can change the list but hardly anyone does. If your browser makes an encrypted connection to “amazon.com”, and the party on the other end of the connection owns a certificate for the name “amazon.com”, and that certificate was issued by a CA that your browser trusts, then your browser will conclude that it has a secure connection to amazon.com.
Now we can understand what the researchers accomplished: they showed how to forge a certificate corresponding to any address on the Web. For example, they can forge a certificate that allows themselves, or you, or me, or anybody, to impersonate amazon.com, or freedom-to-tinker.com, or maybe even fbi.gov. That is supposed to be impossible, for obvious reasons.
The forged certificates will say they were issued by a CA called “Equifax Secure Global eBusiness”, which is trusted by the major browsers. The forged certificates will be perfectly valid; but they will have been made by forgers, not by the Equifax CA.
To do this, the researchers exploited a cryptographic weakness in one of the digital signature methods, “MD5 with RSA”, supported by the Equifax CA. The first step in this digital signature method is to compute the hash (strictly speaking, the cryptographic hash) of the certificate contents.
The hash is a short (128-bit) code that is supposed to be a kind of unique digest of the certificate contents. To be secure, the hash method has to have several properties, one of which is that it should be infeasible to find a collision, that is, to find two values A and B which have the same hash.
It was already known how to find collisions in MD5, but the researchers improved the existing collision-finding methods, so that they can now find two values R and F that have the same hash, where R is a “real” certificate that the CA will be willing to sign, and F is a forged certificate. This is deadly, because it means that a digital signature on R will also be a valid signature on F — so the attacker can ask the CA to sign the real certificate R, then copy the resulting signature onto F — putting a valid CA signature onto a certificate that the CA would never voluntarily sign.
To demonstrate this, the researchers created a forged certificate signed by the Equifax CA. For safety, they made the forged certificate expire in the past and point to a harmless site. But it’s clear from their description that they can forge a certificate for any site they want.
Whose fault is this? Partly it’s a consequence of problems with the MD5 hash method. It’s been known for a few years that MD5 is in the process of melting down, so prudent designers have been moving away from MD5, replacing it with newer, better hash methods. Similarly, prudent CAs should not be signing certificates that use MD5-based signature methods; instead they should insist on signature methods involving stronger hashes. The Equifax CA did not follow this precaution.
The problem can be fixed, for now, by having CAs refuse to create new MD5-based signatures. But this is a sobering reminder that the certification process that underlies web site authentication — a mechanism we all rely upon daily — is far from bulletproof.
Is this any worse than (the majority of) CAs who do insecure verification of domain ownership?
Some CAs simply send an unencrypted mail to the domain admin contact asking them to verify the cert request. The attack on that is left as an exercise for the reader.
SSL Certs are a weak form identity and largely a means of extracting money from the system.
So the obvious question – how do I configure my browser to be on guard for those MD5-using CAs?
I can go through the list one at a time, but there are several dozen CAs now.
I’ve deleted one offending Equifax CA (equifax – again?!) from my Browser’s list, but there
has to be more I can do.
It would be helpful to have a ‘test site’ to visit some my easily-perturbed Firefox 3 would barf over, now that I’ve nuked Equifax.
Hi,
It’s Chaos Communication Congress.
Organized by the Chaos Computer Club
How does this solve the problem? Surely the solution is to revoke the Equifax and other CA certificates that use MD5 and get this revocation information into every browser.
The problem doesn’t affect certificates that are already issued; it only affects certificates that a forger, by watching for predictable elements, causes to be issued. VeriSign has already posted on their SSL blog that they have stopped using MD5 with RapidSSL and confirmed all their remaining MD5-signed SSL/TLS certs from other parts of their large and disparate company aren’t subject to these prediction-based faults. They will stop using MD5 with SSL/TLS next month.
Perhaps I don’t understand the issue properly, but I thought the problem is that the forger can now forge a CA certificate that matches one of the CA certificates already trusted by the browsers. The forgers can then use this forged CA certificate to sign their own server certificate. This server certificate appears to be signed by the genuine CA.
It doesn’t matter what the Certificate Authorities do — the forger can make certificates that appear to have been signed by that CA. Not all CAs use MD5 sums, but as long as the browser accepts one CA that has uses MD5 sums the forgers can continue. Thus the problem is only solved by modifying what the browsers will accept.
This attack is yet another that relies on a lack of entropy: on the predictability of contents that, combined with another weakness, allows spoofing. Dan Kaminsky’s DNS attack relies on having sequential UDP ports coupled with the ability to spew huge numbers of responses. The WPA exploit (short packets using a WEP flaw that remained inside of the integrity protocol in TKIP) works because elements are predictable in certain kinds of packets, and the rest can be guessed due to other flaws.
If RapidSSL (the VeriSign division that issued the cert that was the basis of forgery) had a randomness about its datestamps and serial numbers, it would have been far more difficult or impossible to stick the wedge in for MD5 collisions (or so I understand).
So, we should replace MD5. With what? Anybody got any good links about who’s looking into this?
MD5 should have been replaced by SHA-1 or preferably SHA-2 by now. MD6 has been submitted in NSA’s competition fro SHA-3.
http://en.wikipedia.org/wiki/SHA_hash_functions
?????
?????
?????
Does anyone have the fingerprint of the affected CA? I realize there are many, many other RSA-MD5 CAs out there.
As far as I can tell, security.ssl3.rsa_rc4_128_md5 only affects selection of which ciphers to use, not which certificates to trust.
This isn’t limited to Equifax afaik.
Is setting all security.*_md5 to false enough to stop this attack in Firefox?
(the only one that was true on my installation was security.ssl3.rsa_rc4_128_md5)
It would be great if users could get their hands on browsers that throw a warning if a secure connection offers a certificate that used MD5 fingerprints – is it possible for a user to configure this on any browser?
I did this as well. I don’t allow md5 nor 128 bit certificates, just 256 aes, sha-1 or something else. Most websites are pushing me an aes-256 bit certificate now (except a few stragglers) so I think it’s probably better overall with these settings too.
…just be careful in the about:config. You can accidentally turn on things and open a gaping security hole.
(This is tangential to the original post’s main point.)
Ed Felten: “One of the cornerstones of web security is the use of secure connections.”
This is by far one of the less-important cornerstones. The following two references explain why far better than I ever could: Matthew Paul Thomas: Security Snake Oil Ian Grigg: What’s Your Threat Model?
The most important cornerstone is that whenever something of value (e.g. money) is exchanged, an audit trail is created. This allows miscreants to be identified and punished after the fact; this threat of punishment deters bad activities.
In summary, the Internet has not, in fact, changed human nature.
(sorry, had to go with the holiday theme)
MD5 already seemed dead to me once I played with some of the “evil twin” tools and created two different EXE’s that hashed the same. Something as small as a cert is a lot more troubling.
Browsers should not treat a cert signed with that algorithm as secure any more, period.