With SSL, who can you really trust?
- 19 August, 2011 06:27
SSL, the encryption scheme that protects virtually all secure online transaction, requires that users rely on trusted third parties, but what if they can't be trusted?
Well, it turns out they can't be, as demonstrated earlier this year by the breach linked to trusted third party Comodo, but researchers are fashioning new trust models for SSL that they say are much less susceptible to being compromised.
One proposal, called Perspectives, is being vetted by a team at Carnegie Mellon University, and a second, called Convergence, is also being run through its paces by Moxie Marlinspike, a fellow at the Institute for Disruptive Studies, a lab devoted to privacy, anonymity and computer security.
Their schemes are similar and call for shifting the authentication of SSL-protected Web servers from browsers and certificate authorities to a new entity called a notary.
Traditionally, when a browser wants to set up an SSL session with a server, it asks for the server's SSL certificate. The browser verifies the authenticity of the certificate by checking whether it has been signed by a root certificate authority that the browser trusts. In practice, the browser may rely directly on other certificate authorities that are ultimately vouched for by the root authority.
This creates a chain of trust that branches off from a root authority to authorities it trusts to authorities they trust.
If any link in one of these chains of trust is compromised, attackers could acquire false certificates for sites. These invalid certificates could be used to trick browsers into trusting them, and that sets browser-to-server communications up for man-in-the-middle attacks.
That is the scenario in the Comodo breach, in which one of its trusted partners issued nine phony certificates.
With Perspectives and Convergence, rather than relying on certificate authorities and the root certificates that ship with browsers, trust is placed on a notary. Notaries are servers that routinely check and record what certificates Web servers present over time.
When a browser receives a certificate from a server, it doesn't seek confirmation that the certificate is linked to a root authority. Instead, it asks a notary whether it matches the certificate that the server has been regularly issuing over a period of time. If so, that is a good indication that it is a legitimate certificate for that site.
The upside is that this kind of trust model doesn't rely on a small static set of certificate authorities, says David Andersen, an assistant professor at Carnegie Mellon's computer science department, who heads up the Perspectives project. "You don't put all your eggs in one basket," he says. "We run all the Perspectives notaries, so you end up trusting us. We don't like that."
So he hopes that in a fully deployed architecture, major corporations -- Google, Microsoft, Yahoo, Verisign -- as well as smaller companies and individuals would set up notaries. Notaries could share the data they gather. "As long as they all agree, then that site is OK. You can trust the accumulated results," he says. Users get a statistical, probabilistic verification of a certificate's authenticity, he says.
Marlinspike says this architecture gives end users trust agility -- the ability to switch who they trust initially and to shift that trust to someone else at any time. Under the current system, trust is determined by what root certificates browsers support and that predetermined trust is irrevocably locked in between browsers and certificate authorities.
Marlinspike's Convergence architecture creates a notary relay that keeps any one notary from knowing both who is requesting authentication for a given certificate and what site that certificate is issued to.
That relay feature injects a level of privacy that Andersen appreciates. "Notary B sees only Notary A so it can't see what client is asking about what website," he says. Similarly, Notary A can only see the client making the request, not what website it is asking about.
At the moment Perspectives serves only 30,000 users, an insignificant percentage of users making SSL certificate checks on the Internet, Andersen says. To replace the current SSL authentication system would require a worldwide network of perhaps hundreds of notary servers akin to the network of DNS servers. But, he says, the tasks they would be asked to perform are simpler and fewer servers would be needed.
Taher Elgamal, CTO of Axway and one of the creators of SSL, acknowledges that authentication is a weakness in SSL deployments. At the time SSL was created, authentication wasn't the main focus, but he says he regards the notary system as an improvement over certificate authorities acting exclusively as trusted third parties.
"Something needs to change for the trust to be better," he says. "We need to build a community that says these are trustworthy or not."
Because the notary models would require worldwide deployment of infrastructure, an actual rollout could be done but it would be a major project. "It's bigger than it should be because it's 16 years late," Elgamal says.
Read more about wide area network in Network World's Wide Area Network section.