While many pundits would agree the SSL and certificate authority (CA) trust model has some serious flaws, the ubiquitous protocol isn’t going anywhere anytime soon. As a result, various members of the security community have dreamed up a number of different solutions to "fix" SSL—primarily by making adjustments to how public keys and certificates are created and processed in order to better secure users’ Web experiences.

Some ideas look similar, others are mutually exclusive, and each has its own pros and cons. For those trying to keep all these proposals straight, the following round-up offers a quick cheat sheet to get a taste for the ideas and plans with the most momentum at this time.

1. Public Key Pinning
The idea behind key pinning is to give website operators more control over which certificate authorities can issue certificates for their servers.

“The one big problem is the fact that any one certificate authority can sign any certificate for any website in the world,” says Ivan Ristic, director of engineering at Qualys. “That's an obvious loophole.”

Ristic says he believes that public-key pinning can help close that loophole. Currently in revisions within the Web Security Working Group of the Internet Engineering Task Force (IETF), the Public Key Pinning Extension for HTTP puts power in the hands of domain holders.

“It’s a way for a website to choose three certificate authorities that you give permission to create certificates for your website,” Ristic says. “The idea is that rather than have any of the hundreds of certificate authorities create certificates, you say ‘I'm going to pick these three’ and then it sort of reduces the attack surface to a much smaller area.”

Currently, Google Chrome uses a pilot version of key pinning that pops up warnings when users visit some well-known domains (including Google) that are signed by non-pinned CAs. In fact, some credit this early use of key pinning for sussing out fraudulent certs that portended the DigiNotar blow-up last year.

2. DANE
Another idea currently making the rounds within the IETF is DNS-based Authentication of Named Entities (DANE). Piggybacking on the deployment of DNSSEC, the folks with the DANE Working Group are putting forth the proposal to do away with a central CA infrastructure and instead bundle the exchange of keys over a DNSSEC-validated communication channel.

“With DANE, a Web browser or other DANE-enabled client application can query the DNS to fetch initial key exchange material,” says Tom Daly, president and CTO at IaaS vendor Dyn. “By using DNSSEC validation, the validity of the key exchange material can be 100 percent validated against any form of man-in-the-middle attack.”

There are a number of issues standing in the way of DANE, however. First, DNSSEC will take some time to take root. Second, the CAs will likely not sit back blithely while their financial model is threatened with obsolescence. And, third, this model still depends on users and site operators trusting a third party.

"There are a number of people who see embedding certificate information into the DNS and signing it into DNSSEC as the magic bullet to solve this CA problem," says Jeff Schmidt, founder and CEO of JAS Global Advisors, a consulting firm specializing in IT, risk governance and strategic technology risk. "In fact, that's not true. You're just moving the problem around. The question then becomes, who do I trust? The domain name vendors or the CAs?"

3. Convergence and Perspectives Project
One movement gaining quite a bit of traction with some members of the security world is the one pushing a notary-based trust engine as put forth by the Perspectives Project from Carnegie Mellon University and Convergence, developed by noted SSL-researcher Moxie Marlinspike.

The idea behind both projects is to transfer the arbitration of trust from the browser vendors to the end users. An individual user would create a list of the notaries that he trusts and that the system would query whenever he visits an SSL-protected site. If the notaries confirm the validity of a site's certificate, then the user wouldn't be bothered. If one or more of the user’s trusted notaries were to flag a certificate as invalid, the system would alert the user, and he could choose whether to continue with the transaction.

"Ideally users would have a whole bucketful of notaries on their list and would query those notaries, which would in return respond back to what they have in terms of certificates for the site in question. So if you're under a man-in-the-middle attack, obviously what you're reporting as your certificate and what all of the other ones are reporting would be different," says Keith O'Brien, adjunct professor of network security at NYU and a distinguished engineer for Cisco. "So the idea being that you would distribute that trust around and as a user you can change your list to be whatever you want it to be."

Marlinspike built Convergence based on the Perspectives Project, but he also added the ability for users to anonymously query the notaries through a proxy to maintain privacy. Currently both projects are looking for uptake from browser vendors, with Convergence only available at the moment through a Firefox extension.

Some detractors wonder how well such a system would play out with the typical Internet user, however.

"My problem with Convergence is this: I was just looking at the New Yorker cartoon where God is looking down on the earth and asking his companion, ‘What if the meek don't want it?’” says Tim Moses, director of advance security at Entrust and chairman of the CA/Browser Forum.. “That’s the trouble; I don’t think the end user wants to be responsible for it. They don’t know what a CA is, they don’t know what a certificate is, and they’re just hoping someone is looking after them.”

4. CA Transparency
According to Adam Langley, a Google Chrome software engineer, while key pinning does show promise, he and others at Google don’t see it as a long-term solution for improving the certificate infrastructure. Which is why he worked together with his colleague Ben Laurie to devise the Certificate Authority Transparency Proposal, which would have site owners register certificates in a public audit log.

“Servers present proofs that their certificate is registered, along with the certificate itself. Clients check these proofs and domain owners monitor the logs,” Laurie says.

Moses says he is a fan of the proposal because it puts power in the hands of the certificate subscribers.

“Currently, the site operators are kind of powerless. Whereas the CA transparency proposal from Google gives site operators who care about this the opportunity to see what certificates are being issued in their name and to take steps to eliminate any that they haven't been actually approved,” Moses says. “I think the sites are a natural trusted party for end.”

If users have chosen to go to a site, then it is presumably because they believe it is well-operated and they want to do business with that entity.

“So it would seem to be natural to put the power back into their hands to police this whole infrastructure and eliminate this hole where rogue CAs can simply kick the legs out from underneath the whole infrastructure,” he says.

5. Sovereign Keys
In a similar vein as Convergence and Perspectives, the Electronic Freedom Foundation (EFF) Sovereign Keys project is designing a prototype method intended to decouple the trust infrastructure from third-party decision-makers, such as browser vendors. Site owners can sign CA-issued certificates with their own private keys, which are checked against timeline servers similar to the Convergence and Perspectives scheme. However, less input from the user will be required for this method to work.

“But the design also aims to do a couple of things that other proposals for fixing the problems with CA proliferation and domain validation do not,” writes Peter Eckersley, who is spearheading the experimental project at the EFF. “The biggest is to remove certificate warnings altogether, and to replace them with automatic circumvention of attacks.”

As long as users are able to easily click through certificate warnings, they’ll be easy prey for man-in-the-middle attacks. In the Sovereign Key design, that risk could be put to bed.

“The strongest way to do this is to compute a hash of the Sovereign Key, and use that as the .onion address of a Tor hidden service. It is also possible to use proxies or VPNs for weaker versions of this protection,” Eckersley says. “Because these methods may be slow, the user can be shown a message along the lines of ‘Experiencing difficulty establishing a secure connection to this site. Give us a moment while we try harder.’ If, after an attempt at circumventing attacks, the browser still cannot establish a verified connection to the server, it reports an error indicating that the server is unreachable.”

The EFF is very much in the initial phase of development. for the project, which was just announced in November 2011. The foundation is currently looking for donations for the Sovereign Keys project.

Have a comment on this story? Please click "Add Your Comment" below. If you'd like to contact Dark Reading's editors directly, send us a message.