Monday, June 4, 2012

SSL certificate safety bolstered by standards that lessen dependence on CAs | Naked Security

2011 was a bad year for certificate authorities (CAs) and the privacy of internet users as multiple successful attacks against CAs resulted in a reduction in confidence of the basic structure of trust that SSL/TLS depend on.
Last summer Moxie Marlinspike proposed a new system calledConvergence that puts the decision about who to trust in the hands of users. There are some technical challenges with Marlinspike's approach and to date not many people have embraced the technology.
Within the last 6 months, two new proposals have come forward that look to make a more gradual, compatible transition away from the current model possible.
One proposed by Google engineers is called Public Key Pinning Extension for HTTP, while another similar idea backed by Marlinspike and Trevor Perrin is called Trust Assertions for Certificate Keys (TACK).
Some browsers like Google's Chrome have already implemented a similar approach called certificate pinning, but the implementation doesn't scale. Google Chrome ships with a set of pre-defined high-profile certificates installed for services like Gmail that are "pinned" and do not rely on CAs to validate.
This is how the DigiNotar CA breach was discovered. Users of Chrome and Gmail in Iran began getting warnings that their traffic was being intercepted by a man-in-the-middle attack through falsely signed certificates.
Hard coding certificates for more than a handful of sites is highly impractical though, and these new proposals address the scalability problem in an elegant way.
Initial contact to an HTTPS server will work the same as it does now, relying on CAs to verify you are talking to the right site. However for sites that would support these new extensions they could offer an extra digital signature of their certificate signed by the site owner.
Push pin courtesy of ShutterstockYour browser could keep a copy of this signature and "pin" it to identify a known public key that represents that site.
Subsequent visits would then check the signature of any certificates presented not only with the CAs, but also against the copy of the public key you pinned from a previous visit.
This means an attacker wishing to perform a man-in-the-middle attack would not only have to compromise a certificate authority, but also compromise the private key possessed by the web site operator.
Ultimately it lessens our dependence on the security of CAs by putting more power in the hands of web site operators and individuals.
This diversification of trust is a necessary step toward more independent verification of trust and potentially eliminating the need for CAs in the future.
Both proposals are in draft form with the IETF and there are many technical details not covered here. If you want to understand the differences and specifics, I recommend reading the proposals themselves as they are not terribly long.