MD5 insecure? Absolutely. SSL hacked? Sort of, but it's not broken. CA negligence? What do you think? Tom Olzak examines the roles of each of these players in the recent problems with SSL.
MD5, known for years to be vulnerable, was instrumental in allowing creation of a rogue SSL certificate last month. Although this is troublesome, it isn’t what really bothers me, even though some erroneously reported the untimely demise of SSL. The real problem seems to be MD5's continued use by CAs to sign certificates for years after problems were identified.
The MD5 story
The attacks discovered are indeed obscure. But completely theoretical? No. Even given what little data has been released – code implementing the attack isn’t even public yet – sufficient information has been released to piece together a rudimentary proof of concept tool that demonstrates, at minimum, that the selection of MD5 exposes new and potentially deeply undesirable functionality above and beyond what the one-way hash primitive specifies…
That being said, this paper is not a “smoking gun” indictment of MD5. I’ve taken great pains to include the caveats of each vulnerability, as it is far too easy to overestimate the risks described in this paper. It is for that reason I am not saying ”today”, or ”any day now”. The title states ”someday” for a reason. There are dots going back ten years as to the risk of MD5. Here are a few more, in the hopes that they will start to be connected.
Was there enough information available at the time to make everyone immediately jump to another hashing solution like SHA-1? Probably not. However, there should have been enough concern among certificate authorities (CAs) to protect one of the most valuable security tools on the Web—SSL.
Although the bigger CAs did begin using SHA-1 for their high-end certificates, those with fewer security guarantees (I guess to really need your lawyer read the fine print…) continued to be signed with MD5.
The 2008 "SSL" hack
The “someday” Kaminsky wrote about drew much, much closer last month with development and successful use of a proof-of-concept rogue certificate by security researchers Alexander Sotirov, Marc Stevens, Jacob Appelbaum, Arjen Lenstra, David Molnar, Dag Arne Osvik, and Benne de Weger. Figure 1 is a brief description of how a malicious certificate can be substituted for the real thing during purchase and acquisition. The process is enabled largely because a majority of DNS servers are still vulnerable to redirection attacks. For a more detailed description of how this works, see the original findings paper.
What this means
On the surface, this “event” proves that it’s possible for an attacker to insert himself into the certificate acquisition process, resulting in wrongful authentication of visited sites. However, SSL might not be in as much danger as originally reported.
Yes, there are many CAs still using MD5 for at least some certificate signing. In fact, the rogue certificate used in this exploit emulated a VeriSign RapidSSL cert. TC TrustCenter AG, RSA, and Thawte Inc. also still use the vulnerable hash function. But there are four significant mitigating factors.
- Most enterprise-class certificates, such as VeriSign’s Extended Validation SSL Certificates use the still secure SHA-1 hash function.
- Certificates already issued with MD5 signatures are not at risk. The exploit only affects new certificate acquisitions.
- CAs are quickly moving to replace MD5 with SHA-1. For example, VeriSign was planning to phase out MD5 by the end of January 2009. The date was pushed up due to the December proof of concept. On December 31, 2008, RapidSSL certificates shipped with SHA-1 digital signatures.
- The researchers did not release the under-the-hood specifics of how the exploit was executed.
Again, these are mitigating factors. It isn’t impossible for cybercriminals to come up with an attack on their own now that conceptual understanding of approach is public knowledge. But SSL is not broken. The only thing broken is a portion of the public key infrastructure (PKI) which underlies it, and the risk is manageable.
How to mitigate risk
First, fix DNS. Organizations which haven’t ensured their DNS services are secure should do so immediately. Second, take the plunge and filter business or home access to Web sites. (See Free Web content filtering puts safer browsing within reach for everyone and Websense.) This is far from perfect, but it helps users avoid known malicious sites as they appear on the radar. Finally, check new certificates before you purchase to see if the CA might be vulnerable and to ensure their validity. Also check SSL-secured sites you visit for the first time to ensure the cert is valid—at least for the near future.
Checking before you buy is easy. Use a reputable CA and check the signature hash function used. Checking other sites requires the right tool, like Site Check at Networking4All. To test, I entered the alternate URL for Gmail, as shown in Figure 2.
Since the certificate is actually for mail.google.com, this is a good way to see if Site Check accurately tags the cert as invalid. It did, as shown in Figure 3. Although this is a valuable test for common certificate issues, the MD5 exploit described in this post would likely pass. However, note that the results show the chain of trust as well as the hashing functions used. If the certificate is signed with MD5, and the certificate was obtained after the exploit was made public, you are armed with information necessary to possibly avoid the site or take additional steps to verify authenticity. If a business partner uses MD5 signed certificates, 'strongly encourage' them to replace them with certificates signed with SHA-1.
The final word
So is SSL broken? Not really. The problems with MD5 are certainly cause for concern, but the risk is not high enough to mourn the demise of secure sockets, especially if simple steps are taken to avoid high-risk behavior. Further, the problem is not with SSL itself.
Yes, MD5 is broken. Of that there is no doubt. So with years of advanced warning, were the CAs negligent for continuing to use MD5? Was the risk high enough to make the shift before release of a successful proof-of-concept hack? What do you think?