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
Comments with names are more likely to be published.