On April 7th this year, it was revealed that a severe security bug in a widely used cryptographic software library, OpenSSL, had been discovered. It was estimated that around two thirds of the internet was using OpenSSL for day-to-day encryptions, and that the security flaw left around 17.5% (half a million) of internet webservers vulnerable to attack. This flaw was huge: it would allow a hacker to access private parts of a web server, stealing data and passwords whilst leaving no trace. What’s more, this vulnerability had been left undiscovered for two years, giving hackers a two-year window to exploit it. To understand the severity of this bug some base knowledge of the World Wide Web and how it functions is needed.The World Wide Web is the part of the internet that we all commonly associate with the word ‘internet’. While the internet carries everything on it from email to Skype calls to TV, the World Wide Web serves us webpages: documents linking to other documents allowing us to search for information, shop or even bank. It is what web browsers show us, and the communication protocol underneath it is HTTP – Hyper Text Transfer Protocol. The first thing worth mentioning is that HTTP is NOT secure by nature – the end user has no idea whether the web page that they are on is actually where they want to be; just typing in ‘www.pgs.org.uk’ into the address bar doesn’t mean that the page we receive is actually www.pgs.org.uk, but we generally trust that it is. This is because traffic on computer networks can be redirected – an attacker could redirect your request that was travelling to www.pgs.org.uk and send it to their own computer, returning you a webpage that looks exactly like www.pgs.org.uk, but is actually a copy and you wouldn’t even realise. This becomes problematic when, for example, you log into your email and a login form appears. You type in your email address and password, expecting and trusting that you are at ‘mail.google.com’ when you have just in fact sent your email address and password to someone pretending to be mail.google.com who has redirected your request. Furthermore, all of this data is sent in plain text – it’s unencrypted! You may as well have written down your password and given it to them. It’s for this reason that HTTPS was created – Hyper Text Transfer Protocol Secure.
The secure part of HTTPS does two things: firstly, it verifies the identity of the server, so you know that when you go to ‘mail.google.com’ you are actually at mail.google.com; and secondly, it encrypts all data between you and the web server with public key encryption, meaning that if anyone does try eavesdropping the data, all they will receive is garbage. This kind of encryption is currently unbreakable.The server’s identity is verified using certification. A Certificate vendor will independently verify a server’s identity, and then issue a certificate to the web server. This certificate is connected mathematically (and very complicatedly) to the certificate vendor’s certificate, meaning that the certificate can ONLY have come from the certificate vendor, and they are issued per domain – the web browser knows whether the certificate is intended for the server it has come from. We trust certificate vendors; this means that when our web browser receives a certificate from a server, it knows that the web server has been independently verified by a trusted certificate authority, and that the server you are connecting to is the one verified by the certificate authority. You get a padlock in the corner of your address bar and if you click on it, chrome will tell you very nicely that the server’s identity is verified. Secure, right?
Yes, but only as long as the certificate stays on the server. If the certificate is stolen or given away in any way, then this verification becomes useless. Someone could use the certificate to set up a “verified” copy of the server that we will trust, even if it is a copy. Furthermore, the certificate contains the server’s private key. This is what a web server uses to encrypt and decrypt all data travelling over HTTPS. If someone has the server’s private key, then they can decrypt all data. Clearly this becomes a major security issue should the certificate be compromised.
To solve this issue of compromised certificates, two systems were put in place. Firstly, certificates expire after about a year. This means that if a certificate is compromised it is only useful to the attacker before it expires. And secondly, certificates can be revoked by the certificate authority if the web server administrator believes that their certificate has been compromised. Once the certificate is revoked – cancelled – it is rendered useless to any attacker.
So how does this relate to Heartbleed? If you remember from the first paragraph, Heartbleed allows an attacker to access private parts of a server. An attacker using Heartbleed can steal a server’s certificate. What’s more, THE WEB SERVER WILL NEVER KNOW. This means that the web server’s administrator will have no reason to revoke the certificate and the certificate in all likelihood won’t have expired. Therefore the certificate could have been compromised and none of the security systems in place to protect it would work.
This is the reason Heartbleed was so huge. This is the reason the web community panicked: everything that we had built to protect ourselves from attacks, the systems that we trusted, could potentially have been bypassed in this two year window that the Heartbleed vulnerability existed. The fix for server administrators was simple enough; patch their version of OpenSSL, revoke their current certificate and then get a new certificate from a vendor whilst hoping and praying that no one had used Heartbleed against them in the previous two years.
However, a new problem was then discovered.