by Ed Rose
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.
It appears that web browsers have become revocation unaware – the revocation system is broken. This was discovered after Heartbleed as many websites revoked their certificates and found that no warnings would appear to their users. Each browser handles revocation differently. It ranges from Firefox which has options for the most secure browsing, to android and iPhone browsers which performs no checks whatsoever for standard certifecates. The browser developers appear to have seen revocation as a nuisance and have subsequently ignored it when developing the browsers. http://revoked.grc.com is a web page specifically set up specifically to test this. The page is secured using a certificate that has purposefully been revoked but left on the server – visit this page on a revocation aware browser and you will get no warning that the certificate has been revoked. Try going to the link on an iPhone or android if you’re able, and you will see a web page explaining, in detail, the current issues with certificate revocation. The reason you can see this webpage on an iPhone is because an iPhone doesn’t check to see whether the certificate has been revoked. If you try it on a browser such as Firefox or Chrome, you will get a warning like the one below.
It appears that web browsers have become revocation unaware – the revocation system is broken. This was discovered after Heartbleed as many websites revoked their certificates and found that no warnings would appear to their users. Each browser handles revocation differently. It ranges from Firefox which has options for the most secure browsing, to android and iPhone browsers which performs no checks whatsoever for standard certifecates. The browser developers appear to have seen revocation as a nuisance and have subsequently ignored it when developing the browsers. http://revoked.grc.com is a web page specifically set up specifically to test this. The page is secured using a certificate that has purposefully been revoked but left on the server – visit this page on a revocation aware browser and you will get no warning that the certificate has been revoked. Try going to the link on an iPhone or android if you’re able, and you will see a web page explaining, in detail, the current issues with certificate revocation. The reason you can see this webpage on an iPhone is because an iPhone doesn’t check to see whether the certificate has been revoked. If you try it on a browser such as Firefox or Chrome, you will get a warning like the one below.
In fact, even though Chrome blocks this site, it doesn’t in any way make it secure. Chrome uses a home-grown method that will only recognise a small number of high-end revocations, compromising security for speed. If you’re interested in security then Firefox is the best way forward. See the links at the bottom for more information.
So how does all of this affect you? Well, it depends. The whole thing is a balance of risk – the risk that if someone had discovered Heartbleed in the two year window and if the certificate had been stolen and if they were then in a position to use it and if the certificate was either not revoked or you are using a revocation unaware browser, it then becomes a problem. If you bear in mind that ‘in a position to use it’ means that the attacker has to either be your ISP or be someone inside the local network you’re using (connected to your Wi-Fi or to your router with a cable), you’ll quickly realise that the risks are minimal to normal web users. Anyone who happens to have billions of pounds in a bank account that can be accessed will definitely want to change their passwords, otherwise make an informed choice about what passwords to change looking at the risks, bearing in mind that it has been advised to change all passwords.
Unfortunately, there is more for android users. Whilst Heartbleed allows a client to attack a server, it also allows a server to attack a client and certain versions of the android operating system (versions 4.1.0 and 4.1.1) are vulnerable. This creates another theoretical attack scenario where android users running version 4.1.0 or version 4.1.1 could have data stolen from them from an attacking server. This is highly theoretical and as far as I’m aware there aren’t any cases of this happening, but be on the safe side and upgrade your phone if you’re affected.
So what has happened in the two months since all of this came out? Well most of the web have been busy patching vulnerable software and many questions have been asked about revocation on browsers. For anyone still interested in the issue surrounding revocation check out the links below. This has been a massive wake up call for the internet community: nothing is 100% secure and this has proved it. We have to wait until 2017 for all of the certificates that could have potentially been stolen to expire, so until then make sure that your browser is secure enough for what you’re doing and avoid using mobile browsers for anything that needs to be kept ultra-secure.
Further Reading
Sources
Comments
Post a Comment