Google: SSL alternative won't be added to Chrome
Path converges into security quagmire
Still smarting from a counterfeit secure sockets layer certificate that threatened at least 300,000 of its users in Iran, Google has no plans to fortify its Chrome browser with an experimental technology that bypasses the current system for validating websites.
In a blog post published Wednesday, Google security researcher Adam Langley said he didn't think the technology known as Convergence “is something we would add in Chrome.” Moxie Marlinspike, a researcher who has made a career out of exposing huge architectural cracks in the net's foundation of trust, designed the system to address security vulnerabilities and privacy weaknesses in the current SSL system.
In a nutshell, Convergence is a crowd-sourcing technology that allows endusers to query people or organizations they trust to vouch for the validity of certificates used to authenticate Gmail, eBay, or any other website that uses an https
suffix prefix. In its current incarnation, the system relies on a handful of “notaries,” including Marlinspike's organization and the the Electronic Frontier Foundation. It's capable of accommodating an unlimited number of notaries and would allow end users to query as many or as few as they want.
Convergence prevents certificate authorities from logging what trusted websites a given user accesses, and it also allows users to choose who they trust. For an in-depth description, see this video of Marlinspike's presentation at the Black Hat Security conference in August.
Google's Langley lauded the idea of “trust agility” behind Convergence, but said he didn't think the practical considerations made it a suitable addition to Chrome. Among other problems cited, he said “99.99% of Chrome users” would never change default Convergence settings designating which notaries should be queried. He continued:
Given that essentially the whole population of Chrome users would use the default notary settings, those notaries will get a large amount of traffic. Also, we have a very strong interest for the notaries to function, otherwise Chrome stops working. Combined, that means that Google would end up running the notaries. So the design boils down to Chrome phoning home for certificate validation. That has both unacceptable privacy implications and very high uptime requirements on the notary service.
Langley also said Convergence would do nothing to fix certain problems Marlinspike and others have identified in the current SSL system. They include the use of “captive portals” at Wi-Fi hotspots and elsewhere that require users to enter credit card numbers into a portal page before getting an internet connection. The lack of a link to the outside world makes it impossible for users to know they're giving their card number to a valid site, but they can't get an outside connection until they do, creating a Catch 22.
Langley also cited the problem of firewalled “internal servers,” in corporate networks that prevent notaries from seeing the sites an end user wants validated.
Langley's post comes nine days after the discovery of a fraudulent Google.com certificate that was issued in early July by DigiNotar, a Netherlands-based certificate authority whose trusted imprimatur was used to validate official websites of the Dutch government. More than 300,000 people, mostly located in Iran, were exposed to the certificate while trying to access Gmail.
A recent security audit documented weak passwords and other security lapses and the issuance of at least 531 bogus certificates at DigiNotar, which is a wholly owned subsidiary of Vasco Data Security, an Illinois-based provider of two-factor authentication services.
The incident highlighted one of the chief weaknesses of the SSL system, which is its reliance on far too many single points of trust. Users of the Convergence Firefox addon would have received warnings immediately after accessing any of the fraudulent certificates.
To be fair, a homegrown technology Google added to Chrome detected the fraudulent Google certificate, but it wouldn't have caught counterfeits for sites that aren't owned by the web giant.
For his part, Marlinspike said that Convergence is a beta that he's developed in his spare time, and that with additional work it has the potential to overcome whatever flaws it has now.
“I believe that all of the problems are very solvable, and that it is currently the best path we have out of this mess,” he wrote in an email. “I can only do so much as a lone developer without any commercial backing, however, and if the browser vendors are serious about driving innovation in this area, they're going to have to help.”
Here's hoping the developers at Google, Microsoft, Mozilla, and Opera get the memo. ®
X509 signing authorities!
Even just securely promulgating which CA is allowed to sign for your domain, or host, would be a very good idea.
One of the good ideas in Globus' security infrastructure was to put limits on what X509 certificate subjects a CA could sign for. This was fine for grid computing, because all the big labs had their own CAs in any case, so they signed certs for their own machines and users. Bit more of a drag for grid computing in Australia, where there were very few trusted CAs; and the big kicker was, the signing authority was part of the certificate for each CA that was included in the trusted CA bundle with a Globus installation.
No commercial CA will ever agree to such a measure, because they want to sell certificates to anyone, anywhere. Instead, this should be done by the people who *buy* SSL certificates, now that DNSSEC could allow this signing authority to be devolved back to the people who control a domain. Sure, include a trusted list of CAs in browsers, but then have a DNSSEC secured DNS record that states who is allowed to be the CA for a given domain or host. Then, your exposure to certificate fraud is only to whoever you choose to get your SSL certs from, not to the crappiest CA that managed to pass auditing and end up in your browser's trusted CA list.
Frankly, this default "we're so special that we deserve to be trusted to issue certs for every web site in the world" assertion from all the CAs is offensive. Google just sidesteps the whole issue by implementing a signing authority style policy for all their own sites within Chrome. Any rogue cert from a non-blessed CA for a Google web site will be detected straight away by Chrome.
This should actually become a fundamental requirement for all SSL implementations. They already use DNS names as part of the certificate subject - it wouldn't be a disaster for SSL/TLS to rely more explicitly on DNSSEC to retrieve signing authorities.
Spot the Straw Man.
Just Securing SSL
The proposal is intended to address the particular problem of securing SSL from man-in-the-middle attacks where the attacker has obtained a trusted certificate. For this limited but important purpose, it is an alternative to the conventional Public Key Infrastructure of hierarchical trust via certificates. The approach seems similar to the Perspectives add-on for Firefox which has been available for a year or more.