Networking

The new MD5/SSL exploit is NOT the end of civilization as we know it

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

In 2004, Dan Kaminsky described weaknesses in the MD5 cryptographic hash function.  He predicted future attacks against it could cause problems with digital signatures.  Kaminsky wrote,

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.

Certificate Attack Sequence

Figure 1  (http://www.win.tue.nl/hashclash/rogue-ca/#sec71)

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.

  1. Most enterprise-class certificates, such as VeriSign’s Extended Validation SSL Certificates use the still secure SHA-1 hash function.
  2. Certificates already issued with MD5 signatures are not at risk.  The exploit only affects new certificate acquisitions.
  3. 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.
  4. 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.

 Site Check URL entry

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.

 

Site Check results

Figure 3

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?

About

Tom is a security researcher for the InfoSec Institute and an IT professional with over 30 years of experience. He has written three books, Just Enough Security, Microsoft Virtualization, and Enterprise Security: A Practitioner's Guide (to be publish...

16 comments
cageandmo
cageandmo

CA's do not verify SSL owners true city, state, or country addresses. I had input a site check address, and the info that came back was that the SSL certificate info was validated. It showed the city as Anyplace, and state as Anyprovidence US. Then the certificates validation period was for 28 years (March 2008 -November 2036) can this be? cageandmo@juno.com

ahmad_mohamads
ahmad_mohamads

Hash algorithms and RSA Keys Policy in Certificates: As we know MD5 creates a 128 bit digest while SHA1 creates a 168 bit digest and SHA256 creates a 256 bit digest , the question arises is Why SHA is not in use instead of MD5 ?. AS we know if Keys used for encryption as well as Signature for the security of data communications ,It requires : 1- large sizes as 1024 ,2048 bits to prevent the process of breaking the key easily. 2- As we know Key needs managements and scalability of its distribution among the growing large number of communicators using public Internet, so it may be possible to generate new keys that may be generated before and be in use with some one. 3- As times goes and key is still in use ,we give chance to some body to discover our keys by analysis . 3- If we produce our Keys RSA , DSA , SSH RSA ,... , if we use them for One session then destroid after session completed ... isn't that better than keeping the key for along time and remove the need for all those head aches ?. 4- Since SSL certs uses public,private Keys for may be 6 months or even more to reduce management effort of a large number of Certs , isn't that risky too ?. Well SSL certificates is still alive , just needs replacing MD5 by SHA algorithm and change session Key Policies too if it would be better.

RJRM
RJRM

Maybe it's not the end of the world, but it appears worse than this article's explanation. A quote from the original paper's summary: 'As a result of this successfull attack, we are currently in possession of a rogue Certification Authority certificate. This certificate will be accepted as valid and trusted by all common browsers, because it appears to be signed by one of the root CAs that browsers trust by default. In turn, any website certificate signed by our rogue CA will be trusted as well. If an unsuspecting user is a victim of a man-in-the-middle attack using such a certificate, they will be assured that the connection is secure through all common security indicators: a "https://" url in the address bar, a closed padlock and messages such as "This certificate is OK" if they chose to inspect the certificate.' This tells me that if one forged CA certificate gets into the wild, it could be used to generate an unlimited number of PKI certificates. These certificates could be used for a "man-in-the-middle" attack for a website regardless of the root of the legitimate certificate for that site. This vulnerability will remain as long as browsers accept the root certificate of the forgery. Trusted CAs that use MD5 signitures (and sequential serial numbers) must change their procedures immediately -- before that one rogue CA certificate gets produced. If it does get produced, I bet it could be sold for a pretty penny.

noah
noah

People seem to forget the principles of security when things like this pop up. Can you jimmy an 82 nissan sentra in 30 seconds sure, do you sue the car manufacturer? No. Would you buy a car without door locks? No, you would probably sue the manufacturer then. Basics of security, an 85 yr old, 300lb, guard is better than nothing.

apotheon
apotheon

I was planning on writing an article about this myself -- but I saw you had it in the queue, and waited to see what it would say. I'm glad you handled the subject so well, Tom. Keep up the good work.

cliff
cliff

It isn't exactly the proverbial A-bomb, but it does indeed raise some concerns, the first being the lassaiz faire approach to security demonstrated by the CA's. I think we've been dealing with these issues long enough to understand that we need to be pro-active regarding security. The second is not being privy to the knowledge possessed by the black hats regarding this issue. Like it or not, it is generally the black hats who move security advancements down the road. They are the ones who usually, and quite naturally, discover vulnerabilities first. It would be interesting, if not disconcerting, to find out what they know about this security hole and to what extent it's been exploited.

MISDude-E
MISDude-E

What I'm more concerned about is other places that use MD5. For example like the secure "enable secret" in Cisco IOS. (Note I know of the hack tool for the simple encryption used in local passwords and the "enable password".) But up to this point it's always been advertised (by Cisco) that the enable secret is super secure because of MD5. If I use remote passwords I'd at least want the one local "enable secret" still secret even if someone found my archived config file.

controller
controller

We only know what the good guys know. We don't know what the bad guys know, or what their strategies or deployments are

seanferd
seanferd

Thanks for this fine article. I'm glad M. Kassner pointed me in this direction, or I may not have seen it for a couple of days. As to the poll, I voted "negligent", although it would reflect my opinion more accurately to say "kind of dumb" instead. Why not move to a better algorithm when it becomes available? Is it that CAs are waiting in hopes of not "using up" an algorithm too soon by waiting until the current one is really, really broken? I think this piques my curiosity the most. Does this break SSL? No. Moving to SHA1 or 2 "fixes" it. What really breaks SSL is poor implementation by websites, which is, apparently, fairly common. Even if the CAs had some magic unbreakable encryption, people will still flub the implementation and break SSL for themselves. This is more of a danger to secure transactions than the CAs persisting in using MD5.

apotheon
apotheon

1. It would be nice if they used key lengths over 200 bits. 2. This is only a problem with hash collisions -- which implies a flaw in the hashing algorithm. Of course, we already know that MD5 is subject to collisions, so the fact some CAs are still using them is just doubly negligent. 3. Technically true, where keys in question are "secret". SSL/TLS uses a public key cipher, however, to generate unique session keys. That's why it's called a "Public Key Infrastructure". Further, if even a secret key can be discovered by cryptanalysis, your encryption algorithm has been broken far more severely than MD5. The Other 3. Each encryption session has its own key in SSL/TLS. 4. What, exactly, is risky about it?

apotheon
apotheon

There are better "locks" for use with SSL/TLS now.

ndeyoung
ndeyoung

This is exactly what I'm thinking. I was beginning to think I was alone in the world. The premise of this article is based on what the good guys know without a clue of what the bad guys know. Based on what I know about the bad guys they are generally more advanced then the good guys. They also have a much higher profit incentive for their work then 'researchers' or 'bloggers'.

darpoke
darpoke

of the risk posed by the potential creation of rogue CA certificates. It seems to me that if a rogue certificate is generated by a malicious party, it can grant 'legitimate' (from the POV of a browser) certificates of any type - so a site certificate that is digitally signed and encrypted using SHA-1 for example is still potentially a spoof if that certificate itself was signed by an MD5 encrypted CA. Is this an accurate understanding of the risk? If so, is it necessary to ascertain that *none* of the certificates in the chain from site to root are signed using MD5 encryption? Just trying to get my head around the risk and develop a suitable avoidance strategy, thanks!

koen.bossaert
koen.bossaert

Since the bad guys are so heavily focussed on profit, this is exactly the reason why I don't think they have invested a lot in this area (maybe some evil goverment support espionage group yes, but not the phishers). Why? Simply because there are so many much easier ways to fool applications and users, there isn't a high incentive to invest heavily in this kind of research. Now that it's proven by the good guys it is feasible however ...

JCitizen
JCitizen

Here at TR. People forget that the bad guys have expenses too; they can't steal enough, quickly enough to cover all of their budget, of course.

Editor's Picks