In the aftermath of discovering the Heartbleed bug, now it is useful to look at the bigger picture of security building blocks that the Internet – and all of us – relies on.
A Bit About Heartbleed
Heartbleed allows someone making a connection using TLS to read a random piece of server memory, which may contain important bits – private keys, fragments of cached files, etc. Make another connection, get another 64KB of data. Do this enough times and a bad actor may get enough useful information to do some damage – for instance a private key the server uses to authenticate itself and encrypt communication.
With the private key, an adversary can impersonate a server. If they can intercept traffic, they can also decrypt it. If the server is using crypto-suites that don’t support perfect forward secrecy (PFS), the adversary can also get at data collected in the past. And because it leaves no trace, we cannot be sure if the vulnerability has been exploited and to what extent.
This is pretty bad stuff.
Most prominent sites and services have been fixed (see Mashable’s summary of affected sites). Things are getting back to normal for most web services, although we will probably hear more about the impact of this bug as time goes on.
Building Blocks of Internet Security
So how resilient is the Internet to such vulnerabilities? Let’s begin with the fact that there is no absolute security or absolutely flawless software in real life. And what differentiates a resilient system from a fragile one is not necessarily the absence of flaws. It is the absence of a single (or double, or triple, depending on the requirements) point of failure. In information security jargon it is called “defense in depth” – securing one layer alone (say, an application) is not enough.
So what are other security technologies that can provide additional layers of protection?
DNSSEC. It is much more difficult to impersonate a server if its name is protected by DNSSEC and the client can validate it. I’ve heard people question the value of DNSSEC if a site already uses an X.509 certificate issued by a respected CA. Well, apart from some other flaws of the web PKI system, Heartbleed is a prominent example of why we need more DNSSEC deployment. Even if someone gets access to the secret key (essentially stealing the X.509 certificate) and sets up a fake site, DNSSEC, if used by the name owner and validated by the client, will reveal the deception.
DANE. DANE provides an easier way to replace compromised keys without relying on CRLs and OSCP (Online Certificate Status Protocol), which are not always enabled and working. A site owner creates a new certificate and publishes it in the DNS, protected by DNSSEC. It actually takes longer to get it done in the traditional way through the issuing CA.
PFS. PFS comes with some cost to the server operators, but it pays off in situations like Heartbleed. By using crypto-suites that support PFS, even in the case of a compromised private key, past communication cannot be decrypted.
Diversity. Flawless software is rare and the more complex the code is the greater probability of bugs creeping in. Bugs hurt, but are devastating when the same bug is pervasive, which happens when there is not enough diversity in protocol or technology implementation and deployment. Open standards documenting the design of protocols and technologies enable such diversity, but it also requires a conscious choice when these components are deployed.
Users. Internet users contribute to the overall resilience of the system, too, by keeping software up-to-date and using strong passwords that vary across sites. Changing passwords periodically has always been good practice, but now it is vital in response to the Heartbleed (check if the system is still vulnerable before doing this, though, at https://www.ssllabs.com/ssltest/index.html).
Looking at this specific, albeit unique, case we can see multiple paths toward improvement. Everyone has a role to play and an opportunity to contribute positively to the overall security and resilience of the Internet.
Security and resilience is ultimately not a technology. It is a culture.