In part one of this series I discussed how security technology is now very close to enabling robust secure web communication, but only for those few who have enough time to spend on making it work correctly.
To appreciate how small that group is, we can look at the number of sites that currently use advanced security techniques, such as HTTP Strict Transport Security (HSTS). We track that number on monthly basis as part of SSL Pulse, our survey of the encryption used by the most popular websites in the world. In October 2013, an optimistic estimate puts the support for HSTS at only 0.5%.
If the biggest websites are not deploying the best possible security, then it's clear that whatever we are currently doing is not working. We need to rethink our approach.
Our first activity should be involving those who are currently deploying encryption, but are either not doing it correctly, or are not using all the possible protection mechanisms. This group constitutes the other 99.5% of the sites we track in SSL Pulse, for example. The main reason this group underachieves is that using encryption correctly today is difficult and requires a lot of time and effort. But, it's a fact of life that most organizations do not invest enough in security, and never will.
As a result of that lack of time, websites are often deployed using the default operating system settings, which are, for various reasons, inadequate. For example, more than a quarter of sites from SSL Pulse continue to support the insecure SSL 2 protocol, known to be insecure for 18 years now. This clearly demonstrates that education does not work. The answer is, then, to ensure the defaults are always secure and, whenever possible, remove support for insecure features altogether.
To illustrate my point, let's look at the migration of server private keys from 1024 bits (no longer considered secure) to 2048 bits. Today, 1024-bit keys are used on only 2.2% of the servers, but in April 2012 (when SSL Pulse started), that number was 16.7%. This process is clearly a success, but that's because we didn't try to explain to everyone why they should be moving to 2048-bit keys. Rather, we made it impossible to obtain new certificates with 1024-bit keys.
At this point we're left with the biggest group, the 90% that don't bother with encryption at all. Helping them achieve robust security is not possible, given that encryption as we use it today requires keys and certificates, which cannot be automatically generated. What then?
To understand what can be done, it helps to understand the threats. There are two main types of attack against communication channels: active and passive attacks. Active, or man-in-the-middle (MITM) attacks, typically require a lot of effort and specialized tools. Against properly secured sites, MITM attacks might be extremely difficult to carry out, and they are certainly impossible to execute at scale without anyone noticing.
Passive attacks, on the other hand, are easy and only require that the adversary gains access to the communication channel (e.g., to be on the same Wi-Fi network as the victim). More interestingly, perhaps, we now know that passive attacks are carried out on a massive scale, whereby all internet traffic is recorded at key exchanges and stored in a form that enables automated analysis and correlation.
On the web, in its current insecure form, passive attackers are very effective because they can automate their processes, and the recorded traffic can just sit there in case it is needed in the future.
It is at this point we realize that, even though we might not be able to defend everyone from active attackers, we can, with some changes to how things are done, defend everyone from passive attackers.
The concept is known as opportunistic encryption, and is rather simple conceptually: if Alice and Bob want to talk but are unable to use a properly secure channel, they use ad-hoc encryption with throw-away keys, which is not enough to defend against an active MITM, but it is good enough against a passive MITM.
The beauty of opportunistic encryption is in the fact that it does not require long-term keys. Thus, it can be built into our infrastructure to be deployed transparently for everyone. Those who care about and need security will continue to explicitly deploy it, but everyone else gets to be protected from passive attacks with no work at all.
As a purely technical challenge, opportunistic encryption is easy to deploy, because we already have all the required pieces – existing standards and tools can be extended to support it. A much bigger challenge is convincing the relevant parties to accept the concept. But if we manage, then after a few short years of waiting for the technology to spread, we will have arrived at a much safer web.
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.