HTTPS (webpages that start with https://) is often touted as a secure means to access web pages, and is consequently used by almost all websites that demand a high level of security, including banks, online shopping sites and webmail sites. Unfortunately there is a big (and well known to security professionals) flaw in the way that HTTPS works, which can make it easy for the likes of the NSA to not only monitor your current communications, but to also unlock any backlogs they have ‘captured’ in the past.
As most even vaguely tech-savvy people know, all modern browsers have built-in support for SSL and TLS (the encryption protocols on which HTTPS is built). When you go to a ‘secure’ website a padlock will show on the taskbar to let you know that you are accessing it using an encrypted connection.
For the system to work, your computer and the server agree to a shared encryption key, which is different for each computer that connects to the server, and is different each time your computer connects to the server. All well and good.
However (and this is the problem), shared encryption keys are sent to the server using the server’s public encryption key, which it then decrypts using its private encryption key. If the private encryption key remains secure then there is no problem, but if someone can obtain this private encryption key then all data communications protected by keys derived from it can then be easily decrypted.
Unfortunately it is has become common practice (because it’s easy), for companies to use just one private encryption key, meaning that if this key is compromised then the attacker can access to all communications encrypted with it.
In short, the private encryption key is ‘master key’ that can be used to ‘unlock’ all data encrypted by a given company.
Where NSA spying fits in
The NSA has been doing its level best over the last few years to hoover up every scrap of data transmitted on the internet. Most data is briefly examined and, if determined harmless, discarded (at least if it originates in the US, no such rules apply for other data, although sheer practically suggests this must also be the case with non-US data).
However, when it encounters encrypted data (which is at present impossible or at least too arduous to break), it stores it for an indefinite period of time until it can decrypt it (details of NSA procedures relating to data collection can be found here).
What this is means is that all the NSA has to do to decrypt every email ever sent through Hotmail (for example), is to discover Hotmail’s private encryption key, which will give it access to every Hotmail email it has stored.
To put it another way, the NSA stores all encrypted information until it can ‘unlock’ it. The standard way that HTTPS works means there is a ‘master key’ (much like a single password for everything), which once discovered will let the NSA easily all the data it has stored from a particular service.
Perfect Forward Secrecy (PFS, also referred to a Forwards Secrecy as ‘perfect’ is regarded as controversial in this context) is system whereby a new and unique (with no additional keys derived from it) private encryption key is generated for each session.
It is a simple idea (even if the Diffie-Hellman exchange maths is complex), and means that each session with an HTTPS service has its own set of keys (i.e. no ‘master key’).
Brilliant! So who uses Perfect Forward Secrecy?
Unfortunately almost nobody except (and this is a big except) Google. Adam Langley from Google’s security team highlighted the problem thusly:
‘Most major sites supporting HTTPS operate in a non-forward secret fashion, which runs the risk of retrospective decryption. In other words, an encrypted, unreadable email could be recorded while being delivered to your computer today. In ten years time, when computers are much faster, an adversary could break the server private key and retrospectively decrypt today’s email traffic … An adversary that breaks a single key will no longer be able to decrypt months’ worth of connections; in fact, not even the server operator will be able to retroactively decrypt HTTPS sessions.’
Google has become a champion for the PFS cause, and not only enables it by default for its own services, but has built the ability to verify that PFA is being used into its Chrome browser. In Chrome, simply click on the HTTPS padlock icon and select the ‘Connection’ tab:
Although only Chrome lets you verify that PFS is being used, PFS works with all up-to-date versions of Internet Explorer (but not on Windows XP) and Firefox. To check whether ECDHE (as used by Google) or DHE works with your browser, go here.
So why doesn’t everyone use PFS?
Given the clear security advantages offered by Perfect Forward Secrecy, the obvious question is why do more services not use it? The answer is not entirely clear, although it probably boils down to one (or a combination) of 3 things:
1. Not everyone is aware of it. This might be true in some cases, but if the security experts at Amazon, PayPal or Apple do not know of it, we would be very surprised.
2. It is deliberately not used so that organisations such as the NSA can readily access the data. One for conspiracy theorists this, although in the light of recent revelation perhaps not so far fetched.
3. It uses more processing power. The full Diffie-Hellman key exchange (EDH or DHE) can use between 15 per cent and 27 per cent more computing horsepower. While this is probably the main reason that many companies have been slow adopt PFS, this overhead can be reduced be ‘resuming’ the TLS handshake (rather than performing the full exchange).
The NSA is storing all encrypted data it encounters until such time as it can readily decrypt it, and way that HHTPS usually works is pretty much set up to make this easy for them.
Perfect Forward Secrecy makes each HTTPS session discrete, requiring the cypher be separately decrypted each time.
Given its advantages, the slowness with which companies are adopting PFS demonstrates a laziness or sloppiness bordering on the sinister. Fortunately, in the wake of the NSA scandal interest is growing in PFS, and a couple of high profile articles on the subject have appeared on The Register and Netcraft websites, and SSL Labs have released a tool for assessing whether a given server supports PFS (explanatory article here).
We hope that the technical staff of popular web services take note, and commend Google for leading the way (at least in this regard).