It’s been over two weeks since a security vulnerability concerning MD5 and SSL was announced, and Dyn is still receiving worried calls and emails from customers about their sites’ security, even though the flaw was patched within hours and existing certificates were never actually in danger.
Before we attempt to dispel some of the confusion surrounding the nature of this flaw, it’s important to make the following statement absolutely clear:
Your SSL certificates are safe! Yes, even certificates generated using MD5 are safe. Yes, SSL as a security method is safe. No, SSL certificates issued by DynDNS.com (a reseller of GeoTrust) were not in danger. Only a small handful of Certificate Authorities were vulnerable, and the affected CAs rectified the problem within hours of its revelation.
In the immortal words of Douglas Adams, “Don’t Panic!”
So What’s the Big Deal?
Rather than go into the gritty technical details of the flaw, a straightforward summary should suffice: Certain Certificate Authorities (such as RapidSSL) were using the known-vulnerable encryption algorithm MD5 to sign their root CA certificates (used in the generation of new certs). Researchers were able to trick RapidSSL into issuing them a “rogue” CA certificate, giving the researchers the ability to create forged certs which would look and validate just like a real cert issued by RapidSSL.
Armed with this “rogue” CA certificate, the researchers could issue certs for malicious servers masquerading as legitimate sites (e.g. your bank, Ebay, Amazon, etc.), and your browser would never know the difference because the certificates would be, for all intents and purposes, completely valid.
While the seriousness of this vulnerability can’t be denied, the hype and hysteria surrounding it are well out of proportion to the actual danger. As described above, no existing certificate was ever in danger of being compromised, since the flaw would have been used to create new, fake certs instead of affecting legitimate certs.
Further, the affected CAs were quick to change over to more secure algorithms such as SHA-1 and SHA-2, most of which performed the change within the same day the problem was announced. By the time most SSL certificate customers were aware that the problem existed, it had already been fixed!
What Does This Mean to Me?
Again, it bears repeating: No SSL certificate customer was directly impacted by the vulnerability, including customers of the affected CAs such as RapidSSL. The problem lay with the encryption used on their root certs; after regenerating the CA certificates using a more secure algorithm and changing some of their signing behaviors (like using sequential serial numbers), this particular flaw should no longer pose a threat.
As with all news in any media, it’s important to remember that complex topics often slough detail and fact and become soaked in sensationalism on their way to bite-sized, headline-friendly chunks. The panic-inducing doomsday scenarios suggested in some articles usually required multiple points of failure to work (poisoned DNS, malicious servers, etc.) and left out the fact that the problem had already been fixed even before they began writing the article!
If you’re interested in a more detailed explanation of the vulnerability, there are a few good articles about the problem, such as Beachballin’s excellent summary, RapidSSL’s FAQ about the vulnerability, and the researchers’ own highly-detailed and well-written explanation of precisely how they pulled it off.