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

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

By AcostaGuest Author
Andrei RobachevskyFormer Senior Director, Technology Programmes

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.

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

Related Posts

Building Trust 21 February 2020

NDSS 2020: The Best in Security Research – For the Good of the Internet

On 23 February, the 27th consecutive Network and Distributed System Security Symposium (NDSS) kicks off in San Diego, CA....

Building Trust 11 February 2020

Every Day Should Be Safer Internet Day

Safer Internet Day is an opportunity for people and organizations around the world to join forces in a series...

Building Trust 28 January 2020

This Data Privacy Day It’s the Little Things That Count

Today we’re celebrating Data Privacy Day, which is all about empowering people and organizations to respect privacy, safeguard data,...