When, in 2010, I scanned about 90 million websites (all .com, .net, and .org domain names at that time) to determine their support for encrypted communication, I was dismayed to discover that only about 0.5% had the means to protect their data in transit. The vast majority made no attempt to encrypt anything. Among those that tried, many failed for one reason or another. Admittedly, among the popular websites, the situation is better; but, with only about 10% of such sites supporting encryption, not significantly better.
Websites fall roughly into three groups. In the first group are those that care about security and have the knowledge and the means to pursue it. The second group consists of those that might be aware of some security issues, but spend only a limited time on them. Finally, in the third group are those that do not care about security or are not aware of the security issues; as a result, they use no encryption whatsoever.
Given that our technology is still evolving rapidly, the security community has traditionally spent most of its effort helping those in the first group. In effect, it's been the security professionals trying to help themselves. Nearly 20 years since the first public version of SSL – the protocol that secures most of the internet – we are finally close to getting the technology right. In particular, two critical missing facilities are being implemented to address the remaining big chinks in the armor.
A big problem with web encryption, as it is implemented today, is that it’s optional. As a result, the deployments are very fragile. For example, if you type a domain name into the URL bar, your browser will attempt to access the website without encryption. That alone is enough for an active man-in-the-middle attacker (e.g., anyone on the same Wi-Fi network as you) to hijack all your communication, even if the website itself is encrypted. This problem can be avoided in practice if everyone remembers to always type "https" when needed, or bookmark their secure locations. But, of course, most people will not do that.
Fortunately, a new standard called HTTP Strict Transport Security (HSTS), released in 2012, addresses this problem by enabling websites to force all communication with them to be encrypted. At this time, the support for HSTS is not widespread, with only Chrome, Firefox, and Opera supporting it; we're still waiting on Internet Explorer and Safari. It's not ideal, but it's better than nothing.
The second big problem for the secure web is that it relies on third parties – certificate authorities (CAs) – to provide some guarantees to users that they are seeing the correct website. And, while CAs will ask you to prove domain name ownership before they issue a certificate, they currently do not need your consent: any CA can issue a certificate for any website in the world. This is fundamentally wrong. Given that there are certainly more than 100 CAs worldwide, not only is the security of the entire system as weak as the weakest link, but there is also no protection against rogue CAs.
This problem can be addressed with a technique called public key pinning, which enables websites to regain control over what certificates can be used with them. Google, which maintains its own browser, has been successful in protecting itself using this approach. It is via its built-in pinning that we learned about the compromise of the DigiNotar CA, and, later, a rogue subordinate CA certificate issued by Turktrust.
Google has been generous by allowing other high-value websites to use the same technique, but such a manual and centralized approach does not scale. For that reason, two new competing standards are being developed. One, called HTTP Public Key Pinning (HPKP), configures pinning via HTTP response headers, and thus applies only to websites. The other, called TACK, operates on the TLS protocol layer, and can be used with any protocol that relies on TLS for security.
Browser support for public key pinning will be limited for some time, but we're finally seeing the light at end of the tunnel, approaching the time when it will actually be possible to deploy TLS that effectively deals with a wide range of threats.
The bottom line is this: if you care about security, the two most important things you can do today are 1) deploy HSTS and 2) prepare to deploy public key pinning. What we can do about the other two groups – those that don’t have time to address or don’t care about security – is the subject of another article entirely.
Ivan Ristic, Director of Application Security Research at Qualys, has spent the last several years researching SSL/TLS and PKI technologies, focusing on large-scale assessment and user education. He maintains SSL Labs and SSL Pulse, where his research and tools are published. He's currently working on a new book called Bulletproof SSL/TLS and PKI.