What you need to know about the Heartbleed bug – in layman’s terms

Any site doing anything important on the internet uses SSL certificates to both validate who they are and to encrypt data moving back and forth between customers and the servers (often through a HTTPS connection in a browser). However, early this week a flaw in a core piece of technology used in this process (OpenSSL) was discovered that allows people to access the memory of the presumed-secure server.

 

The flaw is related to OpenSSL’s heartbeat feature, and so has been nicknamed Heartbleed – its more formal name is CVE-2014-0160.

 

The memory that can be accessed contains information on what the server has recently been working on – which will include passwords, credit card details, or whatever other data the server is involved in processing at the time – including the private encryption secret of the SSL certificate itself. This data had been encrypted when sent *to* the server, but now that the server’s got it, it’s decrypted, and so all of these private details are publicly available to anyone with the technical know-how of exploiting this bug.

 

Essentially, it means that everyone’s passwords and other private credentials are compromised, for the vast majority of sites on the Internet. There’s no way to be sure whether sites that were vulnerable had data stolen from them – but it was certainly possible (and it’s recently become clear that unknown people were hunting for vulnerable servers as early as two weeks ago). Also, any SSL certificate that was being used on a site with the bug can no longer be trusted – the private details of that certificate may have been appropriated and others can then use those details in phishing sites.

 

This bug in OpenSSL hasn’t always existed, though. It was introduced in version 1.0.1 in December 2011, so systems using releases before that – or not using OpenSSL at all – have remained secure.

 

Startups, and any business that operates online, need to first identify whether their servers have a flawed version of OpenSSL installed, update it to 1.0.1g, and then get their SSL certificates re-issued (to change the encryption details). Once that’s done, future encrypted communication on their server becomes reliably secure.

 

Of course, if a flawed version of OpenSSL had been in place, existing passwords and other private details have been compromised, and you should alert your customers to this. Depending on how critical private data is on your site, you may want to force your customers to change their passwords.

 

A good starting point for further information is https://heartbleed.com.

 

Pat Allan is a freelance Ruby Developer

COMMENTS