A part of SSL is broken, and that’s serious. Not being able to trust secure Web sites totally affects all of us, and I’d certainly be remiss if I didn’t make sure everyone understood what’s happening.
To begin with, it’s important to understand SSL certificates. If there’s any confusion, please refer to the following two articles that I wrote about SSL certificates: “SSL/TLS Certificates: What You Need to Know” and “SSL/TLS Certificates: Perspectives Helps Authentication.”
In the articles, I initially explain that untrusted certificates are insecure and ripe for phishing exploits. Simple because most of us just OK the untrusted certificate regardless of the warnings; we’re impatient and just want the Web page to be served up. That’s still a problem, but things just got a whole lot worse, and I’ll explain why in this article. A little background information first though.
Creating SSL certificates
I also mentioned in the articles that SSL certificates become trusted because they are provided by Certificate Authorities (CA) such as Verisign and Network Solutions. The logic behind all of this is quite simple. The CA authenticates the Web-site host so users can trust the secure Web sites provided by that particular hosting organization. People interested in cryptography call this a chain of trust The research team that discovered how to break SSL has an excellent definition of SSL certificates in their article “MD5 Considered Harmful Today“:
“A certificate is a document that contains both an identity and a public key, binding them together by a digital signature. This digital signature is created by an organization called a Certification Authority. This organization guarantees that upon creating the digital signature it has checked the identity of the public key owner (e.g. Web-site host) and it has checked that this public key owner is in possession of the corresponding private key.
Anybody in possession of the CA’s public key can verify the CA’s signature on the certificate. In this way the CA guarantees that the public key in the certificate belongs to the individual whose identity is in the same certificate.”
To avoid confusion, I wanted to clarify that SSL certificates are a subset of digital signatures. With that in mind, I’d like to continue using the term digital signature since the researchers do as well.
Why are digital signatures used?
I thought it might be a good idea to review why digital signatures are important to SSL. Digital signatures are used to create the chain of trust I mentioned earlier. The way digital signatures accomplish this is through the use of public-key cryptography. Public-key cryptography can be a whole discussion in itself, so please refer to the RSA article “What Is Public-Key Cryptography” for a helpful definition.
With public-key cryptography, we start to see how information from a CA if signed with its private key (something that only it has) is one method for the CA to prove its identity. This verification process consists of two parts — signature generation and signature confirmation:
- Digital signature generation is the result of hashing the message (consisting of the CA’s identity and the public key of the Web-site host) with the CA’s private key.
- Digital signature confirmation is accomplished by the Web browser during the HTTPS handshake between it and the secure Web site.
If everything is working properly, the Web browser will use the CA’s public key to decrypt the digital signature and verify the CA’s identity against the list of CA signature files (almost 300 to date) encoded in the Web-browser application.
Once the identity is confirmed the Web browser can initiate a SSL tunnel with the Web site using the public key sent in the CA’s digital signature. The following diagram depicts the normal HTTPS handshake (courtesy of the research team):
Trusted certificates are no longer a sure thing.
All is not well with the supposedly secure connections between Web browsers and Web sites using HTTPS. As is typical with IT security and especially cryptography, protocols and concepts that have been around for a long time slowly start to cause trouble. In this case the MD5 algorithm is one of those old timers.
The following is a brief outline of the attack taken from the article “MD5 Considered Harmful Today,” written by the team of cryptographers who discovered the potential exploit. The team consisted of Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger:
“Our attack scenario basically is as follows. We request a legitimate website certificate from a commercial Certification Authority trusted by all common browsers. Since the request is legitimate, the CA signs our certificate and returns it to us.
We have picked a CA that uses the MD5 hash function to generate the signature of the certificate, which is important because our certificate request has been crafted to result in an MD5 collision with a second certificate. This second certificate is not a website certificate, but an intermediary CA certificate that can be used to sign arbitrary other website certificates we want to issue.
Since the MD5 hashes of both the legitimate and the rogue certificates are the same, the digital signature obtained from the commercial CA can simply be copied into our rogue CA certificate and it will remain valid.”
Collisions are bad
As with many cryptographic concepts, encryption-based security relies on the fact that huge amounts of time and/or money are required to come up with a solution or in this case a collision. The term is actually appropriate, since a collision occurs when two different hashed entities like digital signatures end up being identical.
Since the strength of a digital signature is entirely based on the premise that it’s virtually impossible to have two identical digital signatures, collisions are a bad thing. Now guess what the researchers have been able to do. That’s right; they were able to figure out how to generate collisions for known hashes.
More importantly their approach doesn’t take that long and is definitely low budget. The research team used Arjen Lenstra’s Playstation lab at EPFL, which consists of 200 PS3s as shown in the image below (courtesy of Lenstra and EPFL):
I’d like to once again refer you to the article “MD5 Considered Harmful Today,” as the researchers do a much better job explaining the details of how they were able to reliably locate MD5 collisions.
What’s it all mean?
It means an attacker could mimic a secure Web site like Amazon.com, and there wouldn’t be any indication that the displayed Web pages weren’t from Amazon’s Web server. The URL would have https in it, the lock would shut, and the user would be none the wiser. Needless to say that sounds scary; still this exploit by itself is almost useless.
So what’s the problem? It becomes a huge concern when the MD5 collision exploit is used in concert with exploits that redirect traffic. Consider a blended attack that uses Kaminsky’s bug and the MD5 collision exploit. The attack could consist of redirecting a user to a malicious Web site that is mimicking the user’s bank portal.
Another attack vector could consist of two parts. First subvert a network by using the DNS Changer trojan. Ultimately service up fake DNS records, which happen to point a user’s Web browser to malicious Web sites, and well, you know the rest. The following diagram (courtesy of the research team) outlines the steps required to carry out a redirection/MD5 collision attack:
How to fix the problem?
That’s a good question. There’s woefully little that we as users can do to prevent these types of exploits. Just understanding what’s happening is our best defense at this time. So I wanted to make sure everyone knew where these digital signature files were located in the various Web browsers. Pay particular attention to the signature algorithm. That’s the private key algorithm CAs use to generate the digital signature file. The steps listed below show where the files are located in the Internet Explorer and FireFox browsers:
1. Start Internet Explorer.
2. Go to Tools and click on Internet Options.
3. Go to the Content tab and click the Certificates button.
4. Select the Trusted Root Certification Authorities tab.
5. Double-click a certificate of interest.
6. Select the Details tab and check the Signature algorithm.
1. Start FireFox.
2. Go to Tools and click on Options.
3. Go to Advanced and click on the Encryption tab.
4. Click on View Certificates and select the Authorities tab.
5. Highlight a certificate of interest and click View.
6. Choose the Details tab and check the Certificate Signature Algorithm.
If you notice, in the above examples I kept highlighting the Equifax certificate. This particular certificate was the one exploited by the researchers. As you can see, Equifax is using MD5 as the signature algorithm.
This is where users have an option. If the SSL certificate is signed by a CA that’s still using MD5, the collision exploit is entirely possible. If the CA uses SHA-1 for its signature algorithm, the SSL certificates are not affected by this exploit. At least as of yet, there is some concern as SHA-1 has a similar collision problem.
Whew, yet another major Internet issue that leaves users vulnerable to some potentially heavy-duty exploits. As with the DNS vulnerability, users are pretty much at the mercy of others as to when and how this gets fixed. Hopefully Certificate Authorities and Web hosts will stop using MD5 and even SHA-1, switching to SHA-2, which raises the bar and is recommended by the research team that found this flaw in SSL.
One thing I see in our favor is that on-line retailers will certainly drive these changes, because they certainly don’t want to lose our business.
Need help keeping systems connected and running at high efficiency? Delivered Monday and Wednesday, TechRepublic’s Network Administrator newsletter has the tips and tricks you need to better configure, support, and optimize your network. Automatically sign up today!