SSL flaw revealed at Black Hat

Moxie Marlinspike presenting at Black Hat 2009 Yesterday at the Black Hat conference Moxie Marlinspikes and Dan Kaminsky presented different aspects of the same flaw in SSL, a flaw significant enough to undermine the authentication used in all e-commerce.

SSL, or secure sockets layer, is the encryption technology used to secure interactions with Web sites and other Internet applications. It is the most widely used public key infrastructure in the world, and the authentication it provides is meant to ensure that the sites you're using that look like Amazon, Gmail, or your bank's site really are those sites.

Every SSL implementation begins with a domain name. A site or server owner seeking to deploy SSL generates a complementary pair of cryptographic keys. One is kept private; the other is public and is tied firmly to its originating site by a certificate compliant with the X.509 standard issued by a third party known as a certification authority (CA). Site owners applying for a certificate must specify the domain it's for; the CA checks the domain's ownership in Whois and sends an email requesting confirmation to the listed contact email address. When the owner clicks on the supplied link to confirm, the certificate is issued. In theory, any user should be able to check the bona fides of any site by inspecting the certificate, but few users understand how to do this in practice.

The flaw both Marlinspikes and Kaminsky have identified is that adding a null character into the string supplied as the domain name will get the CA to issue a fake certificate that browsers will accept as genuine. Marlinspikes' example: www.paypal.com\0.thoughtcrime.org. "In most implementations of SSL," he told the Black Hat audience, "this certificate is completely valid for www.paypal.com." Implementations at risk include browsers, email clients, chat clients, and even SSL VPNs. A user will have no way of detecting a man-in-the-middle attack.

Marlinspikes and Kaminsky discovered this flaw independently of each other. Marlinspikes went on to explain how it could be used; he has written proof-of-concept software he intends to put online eventually. Auto updates, he notes, may be a particular problem, as many companies' products (though not Microsoft, which has its own internal CA) rely on SSL or its successor, TLS (for Transport Layer Security) to verify the source of downloaded updates.

Kaminsky noted also that SSL is vulnerable to other attacks, such as that found by Alexander Sotirov and Marc Stevens: it's possible to falsify certificates issued using MD5 hashes. Using known insecurities in MD5 hashes, it's possible to swap the certificate's actual content for malicious content as long as the hash stays the same.

"It turns out there's more where that came from," Kaminsky said. "X.509 is a remarkably fragile piece of work." One of Verisign's own self-signed certificates used MD2, known to be insecure since 1996.

Kaminsky said the good news is that several months of effort mean that the flaw is being dealt with. "Maybe for the first time," he said at the press conference after his presentation, "a lot of vendors came together to work with researchers." In the short term, CAs are being encouraged to examine their certificates for null terminators, and as of May 17, Verisign, the registry for .com, is signing all certificates with the SHA-1 hash. In the long term, browsers need to be fixed to eliminate their support for this flaw; they are already being worked on.

Kaminsky said "The bottom line point we're trying to make is – we have to fix authentication."

(Wendy Grossman)

(djwm)