the secure:channel

Click here to read more about SpamStopsHere, the e-mail security company that brings you this blog.

In case you weren’t aware, a vulnerability in the public key infrastructure (PKI) of Secure Sockets Layer (SSL) has been in the news recently. Is it a big deal? It’s definitely a problem highlighted by some important and great research in the field.

Wow, it’s been nearly a month since I have blogged. I’d like to apologize, and I have no excuses other than things are busy here at SpamStospHere with a new e-mail archiving and e-mail business continuity product. Additionally, I’m trying to get used to working a new shift and there were some holidays in there. I was mostly surprised at how much time had flown. In any case, there has been revealing SSL research, the findings of which were presented at the Chaos Computer Congress in Berlin.

SSL and the the Chain of Trust

Secure Sockets Layer, also known as SSL, is a public and private key encryption method. Additionally, public keys can be digitally signed by an entity, turning them into a certificate. This certificate then can be used to encrypt data, but the signing can also be used for identity purposes. This ensures that you’re not only encrypting your data, but you’re also sending it to the proper entity, for decryption.

At the top of the chain of trust is the certificate authority, also known as a CA. A CA certificate is used by a certificate authority to sign the certificate of another entity, showing in some way that the certificate authority trusts that entity’s certificate. By default, most web browsers and other applications that use SSL have a dozen or so locally trusted certificates, that recognize these certificate authorities as trusted. When establishing an SSL connection with a remote computer, if the remote computer is using a certificate that is signed by one of these trusted CAs, and as long as the hostname of the remote computer matches the name in the certficate, the remote computer is going to be trusted with accepting encrypted data without any warnings or security alarms going off.

In addition, if a CA certificate is signed by a trusted CA certificate, this establishes a longer chain of trust where certificates signed by the secondary CA would also be trusted by the browser or other SSL implementation.

The vulnerabilty

For many years, computer research has shown the weakness of using MD5 for hashing. The 128 bits used by MD5 hash lead to a high number of collisions. A collision is when two different sets of data are processed that result in the same hash. However, MD5 was superior to the 56 bits of Digitial Encryption Standard, also known as DES, which it had generally replaced. The MD5 hashing was also exportable outside the U.S., where DES was not. Additionally, MD5 was still very computationally fast for computers available at the time.

In 2005, some researchers at the Technische Universiteit Eindhoven (University of Technology) in the Netherlands, had published a paper on how MD5 collisions made it possible to have two certificates with the same signature, although the same owner name. In this case, the certificates are being signed with an MD5 hash function, which some CAs use to sign certificates.

In 2007, the same research team published a paper showing how an MD5 collision allowed two certificates with different common names and organization.The researchers used different sized keys for each of the two certificates, the only way to get the math to work out so that both certificates have the same signature.

In December of 2008, at the Chaos Computer Conference, the Technische Universiteit Eindhoven research team spoke on their latest research. Using new attack methods on the MD5 cryptographic hash function, the team was able to create a CA certificate that is signed by a CA that most Web browsers trust by default. This allows them to sign any certficate and have it trusted by web browsers. They did this by having a CA sign a non-CA certificate that had a collision with their rogue CA certificate. Once the non-CA certificate was signed, they then applied the signature to their rogue CA certificate.

Interestingly, the research team used a cluster of 200 Sony Playstation 3s to do the math computations. The PS3s did the hardest part of the math in only 18 hours.

The implications

In the past, you could be sure that you were actually providing your SSL encrypted data to the computer listed in the location bar in your Web browser, as long as you didn’t receive any warnings from your Web browser. Now, you can’t be sure. It’s as simple as that. Are you really connected to your bank’s Web site, or are you connected to a computer posing as your bank’s Web site? There’s no way to be sure.

Although not all CAs are still signing certificates with MD5 hashes, it was easy to target one that was. The research team said that they won’t release the more scientific information for a few months, in order to allow the affected certificate authorities to remedy the vulnerability. Like the DNS research from last year, it may not be long before many other researchers start reverse engineering the limited information and making fairly accurate guesses as how this might be accomplished. Surely exploits will be available in a few months after the more detailed paper is available.

Who is involved and how to solve?

RapidSSL, FreeSSL, TC TrustCenterAG, RSA Data Security, Thawte, and Verisign all had issued certificates in 2008 that had been signed with MD5. In theory, these CAs would need to revoke their certificates and issue new ones to resolve the issue, as well as offer resigning of all certificates previously signed. However, this problem will likely simply fall in the hands of the average user and the SSL implementation developer. Web browsers will likely simply stop trusting all certificates signed by MD5, requiring many web site owners to get their certificates resigned. Older browsers, like Internet Explorer 6, are unlikely to be patched.

This problem is similar to the DNS vulnerabilities researched last year, that had people unable to trust where they were sending their unencrypted data for several months. Due to the limited number of vulnerable recursive DNS servers, this possible nightmare was resolved rather quickly, and likely only cost hundreds of thousands of dollars and hundreds of thousands of man hours.

The damage caused by these CAs continuing to use a known insecure hashing functions will have people unable to trust where they’re sending their encrypted data for many years. The likely cost will be in the millions of dollars and it will take millions of man hours to make SSL secure again for the average computer user.