Secure Certificate Hack Doesn’t Imperil Users

A team of researchers has managed to do what was hoped to be impossible: forge a digital certificate used by Web browsers to validate the identity and integrity of a secure SSL/TLS connection with a Web site that looks entirely legitimate. Time to panic? Not quite. (Read TidBITS Security Editor Rich Mogull’s more technical explanation on his Securosis blog for the full details.)

A forged certificate is a dangerous thing because it tells a party that’s looking for trust – anyone from the average Internet user (if such a thing exists) all the way up to security guru Bruce Schneier – that the site in question should be believed to be what it says it is. If a certificate is invalid or has odd parameters, a browser warns you; a forged certificate created using this new discovery doesn’t set off any browser alarms because it’s identical to an actual legitimate certificate.

Combined with another attack, such as a virus that falsified DNS entries, or a DNS poisoning attack on a network with many users, such as an ISP or academic network, a forged certificate could be used for great mischief in harvesting user accounts and password data.

SSL/TLS is used by other Internet services, such as secured email and FTPS (FTP over SSL/TLS). For instance, plain POP for email retrieval doesn’t encrypt the password, which is why most ISPs started offering a secure flavor in which the entire POP transaction – including the password sent in the clear – is wrapped inside an SSL/TLS tunnel. An attacker who managed to use a forged certificate to spoof a secure email host and redirect traffic to that fake host could access numerous email passwords sent via POP. The same is true for FTPS and a number of other protocols in which SSL/TLS is the wrapper.

Digital certificates are a fundamental part of SSL/TLS. For secure connections, those with a URL that begins https instead of http, a browser requests the public part of the certificate from a Web server, and validates that certificate by examining a cryptographic signature from a third party, known as a certificate authority (CA).

As I noted recently in “Quicken for Mac Lacks Extended Validation Certificate Support” (2008-12-23), CAs provide the glue that binds trust between a browser and server. Browsers (and operating systems) are preloaded with certificates from major CAs. When a browser tries to validate a server’s certificate, it uses the preloaded data it has to confirm the signature. (You can read much more about SSL/TLS in Chris Pepper’s “Securing Communications with SSL/TLS: A High-Level Overview,” 2007-06-25.)

The research team, including independent and academic researchers from the United States, the Netherlands, and Switzerland, discovered that the use of a weak encryption algorithm by just a few CAs, coupled with flaws in how the CAs issued certificates, enabled them to create a valid forged entry. In this case, RapidSSL, a division of VeriSign, was targeted as researchers found in a representative sample that RapidSSL had signed 97 percent of the weakest form of SSL/TLS server certificates.

RapidSSL uses an outdated signature algorithm, known as MD5, and appears to be the highest-volume CA using it. The researchers used two weaknesses in the RapidSSL issuing process: sequential serial numbers, in which they could predict a range of numbers by buying a certificate during a slow period over a weekend, and a guessable date stamp. They combined that with techniques known to be able to spoof MD5 signatures that look correct to produce a valid, forged certificate. (Amusingly, the researchers employed 200 Sony PlayStation 3 gaming systems in parallel to generate the forged certificate – the PS3 has a powerful multi-core processor!)

The researchers revealed that a single CA with a weakness can endanger all browsers and operating systems that trust that CA. The current system of built-in signatures for CAs in browsers and operating systems doesn’t require additional checks beyond the included data to validate a CA or test its mettle.

Fortunately, nearly all other CAs use SHA-1, a newer and stronger signature algorithm (or hashing method), that itself has been theoretically broken, but is still considered secure for practical purposes. SHA-2 is already available, and a competition to design SHA-3 is under way. (Unfortunately, despite years of warnings, MD5 is still widely used for integrity checking in many pieces of software and for some software distribution.)

Because RapidSSL is one of the only CAs to use MD5, and because the company is now aware of the problem, it’s unlikely this particular crack can be replicated. VeriSign, RapidSSL’s owner, told the Washington Post that they had been gradually phasing out MD5 for all their certificate systems, and said that it planned that MD5 wouldn’t be used by any CA it operates after January 2009.

Later in the day, VeriSign’s Tim Callan, who writes about security, posted a blog entry stating that RapidSSL no longer uses MD5 signatures and that they confirmed that the few remaining parts of their operation that use MD5 for SSL/TLS certificates don’t have the flaws that RapidSSL did.

The researchers didn’t provide enough detail for the attack to be replicated, and CAs will likely be immediately checking their security procedures. The researchers estimated it might take a month of diligent work by people highly familiar with MD5 weaknesses to replicate what they did.

VeriSign wasn’t notified in advance of this paper, but the researchers did provide details to Web browser development teams under non-disclosure. The researchers claimed to be concerned that VeriSign could have slapped a gag order on the paper and prevented its release. VeriSign’s Callan said that the company works closely with ethical hackers, and would have no trouble with coordinating a response.

Mozilla and Microsoft separately issued security advisories: Mozilla is “working with affected certificate authorities to ensure that their issuing processes are updated to prevent this threat,” while Microsoft is “actively monitoring the situation and has worked with affected Certificate Authorities to keep customers informed.” I think it’s easy to read between the lines there: the two organizations are saying “shape up or ship out.” Mozilla, Microsoft (in Windows and in Internet Explorer), Apple (in Mac OS X and Safari), Opera, and Google (via its new
Chrome browser) could simply ship updates that disable CA support for any authority that’s not being sufficiently responsible.

The Extended Validation certificates that I wrote about in the Quicken article referenced earlier must be signed with SHA-1, and thus a “green bar” showing EV status can’t be forged using this technique.

Switching from MD5 to SHA-1 is likely a trivial matter on the programming side for any CA. More important, there’s a whole chain of security testing that a CA must perform to make sure they’re using SHA-1 in the correct manner. I expect this particular problem will disappear as a potential threat quickly.

In the long term, a reform of what “trust” means has to happen. The amount of implicit trust among many moving parts was revealed in this exploit. We know the answer to “Quis custodiet ipsos custodes?” (Who watches the watchers?): the certificate authorities.

However, this research makes it clear that we may need yet another level of custodianship in the web of trust: a way to validate that the watchers’ watchers are themselves being watched.