Donate
Fixing Heartbleed – It's The Culture, Not Just The Technology Thumbnail
‹ Back
Building Trust 14 April 2014

Fixing Heartbleed – It's The Culture, Not Just The Technology

Andrei Robachevsky
By Andrei RobachevskySenior Technology Programme Manager

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).

Collective Responsibility

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.

‹ Back

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

What Can App Developers Learn From Heartbleed?
Deploy36011 April 2014

What Can App Developers Learn From Heartbleed?

What lessons can application developers take from the Heartbleed bug?  How can we use this experience to make the Internet...

Heartbleed, LibreSSL, and the Importance of Implementation Diversity
Deploy3609 June 2014

Heartbleed, LibreSSL, and the Importance of Implementation Diversity

Unless you've been living in a cave for the past 3 months you have heard of the Heartbleed bug in...

Wired: It's Time To Encrypt The Entire Internet
Deploy36023 April 2014

Wired: It's Time To Encrypt The Entire Internet

Is it time to "dump the plain text Internet" and encrypt everything everywhere? That's the main thrust of an article...

Join the conversation with Internet Society members around the world