Google researchers propose fix for ailing SSL system
Changes would overhaul net's foundation of trust
Security researchers from Google have proposed an overhaul to improve the security of the Secure Sockets Layer encryption protocol that millions of websites use to protect communications against eavesdropping and counterfeiting.
The changes are designed to fix a structural flaw that allows any one of the more than 600 bodies authorized to issue valid digital certificates to generate a website credential without the permission of the underlying domain name holder. The dire consequences of fraudulently issued certificates was underscored in late August when hackers pierced the defenses of Netherlands-based DigiNotar and minted bogus certificates for Google and other high-profile websites. One of the fraudulent credentials, for Google mail, was used to snoop on as many as 300,000 users, most of them from Iran.
Under changes proposed on Tuesday by Google security researchers Ben Laurie and Adam Langley (PDF here), all certificate authorities would be required to publish the cryptographic details of every website certificate to a publicly accessible log that's been cryptographically signed to guarantee its accuracy. The overhaul, they said, is designed to make it impossible – or at least much more difficult – for certificates to be issued without the knowledge of the domain name holder.
“We believe that this design will have a significant, positive impact on an important part of the internet security and that it's deployable,” Langley wrote in a blog post. “We also believe that any design that shares those two properties ends up looking a lot like it.” Some of the ideas overlap with recommendations recently published by the Electronic Frontier Foundation for improving the security of SSL.
While few disagree that SSL in its current form is hopelessly broken, finding agreement on a way to fix the fragile certificate authority infrastructure has proven to be elusive. Indeed, within hours of Laurie and Langley's plan going public, critics were already saying it was unworkable. Among the complaints was the critique that it would require the divulging of information considered to be proprietary in the fiercely competitive market for SSL certificates.
“I assume that CAs wouldn't agree to provide their entire customer data to the public (and competition),” Eddy Nigg, COO and CTO of StartCom, the Israeli-based operator of StartSSL, told The Register. He held out a voluntary set of baseline requirements recently adopted by the CA/Browser Forum as a more effective fix. Members of the forum hope to make the requirements mandatory for all CAs.
Nigg also said that Laurie and Langley's proposal could place significant technical burdens on website operators and browser makers. One or more authorities would have to be established to compile the lists around the clock and make them available to millions of users each time they access an SSL-protected page, and both activities would require considerable bandwidth and processing resources to be done properly.
“If browsers would have to ping this data upon every first connection per day per site, this would require lots of resources,” Nigg said. “This is something Google might be able to do, but not that many other entities will have those capabilities and interest.”
No more secret certs
Under the system Laurie and Langley propose, a web browser that accessed an SSL certificate for https://mail.google.com or any other domain would automatically check the credential against an accompanying audit proof that's cryptographically tied to the publicly accessible log of valid certificates. Credentials that don't come with a corresponding proof would be summarily rejected. In the event the official log added an entry for an unauthorized certificate, the affected domain holder would be alerted immediately and could take steps to revoke it.
The system would still be vulnerable to forgeries if one of the log's maintainers colluded with the CA that issued the bogus certificate. But the fraud would require additional work on the part of the attackers and would be easily detected using the cryptographic audit logs of other maintainers.
The Google researchers said they designed the system to be compatible with browsers that don't support it. They went on to concede that the challenge of maintaining, hosting, and monitoring the logs presented “major scaling issues,” but they said “there are many web services with at least as high an uptime requirement.” And besides, the ability to distribute multiple copies of the cryptographically signed logs across the internet could lower the burden on any one maintainer.
It was only two months ago that Langley said that Convergence, an experimental project designed to remove the blind trust that internet users are currently forced to place in CAs, was too unworkable to be integrated into Google's Chrome browser. Moxie Marlinspike, the security researcher who designed the SSL alternative, said the challenge to any fix is finding agreement among the affected browser makers, website operators, CAs, and end users – and that will be no different this time.
“With all of this stuff, it's easy to come up with new ideas, and the hard part is getting them done,” Marlinspike told The Register. “At first glance, it seems this is a major undertaking in terms of getting it done. It would require every CA being complicit in changing the way they operate, as well as every browser and every webserver.” ®