STE WILLIAMS

Twitter is the latest high-traffic social networking site to announce that it has added an extra layer of protection known as forward secrecy to its web servers.

“But wait,” you may be saying. “Didn’t Twitter implement an Always use HTTPS option back in 2011?”

Indeed it did, and that was important because it allowed you to ensure that all your traffic to and from Twitter enjoyed the protection of the padlock in your browser’s address bar.

It might seem slightly odd to be so fussy about encrypting every Tweet while it’s being uploaded, when most users’ intention is to have Twitter shout those selfsame Tweets as far, as wide and as soon as possible.

But secure HTTP, better known as HTTPS, is surprisingly important for any web service that lets you login up front and then stay logged in indefinitely.

That’s because your logged-in status is usually dealt with by a session cookie that is transmitted in the HTTP traffic.

A session cookie is a random string of data that a server sends to your browser as a sort of temporary ID, and that your browser sends back, in the headers of any future requests to that server, to assert that ID.

In short, the server uses the session cookie to recognise that’s it’s you coming back for more.

Without a session cookie, you’d need to login every time you loaded or refreshed a page from the relevant site, which would quickly become tiresome.

Your session cookie can’t be guessed by an attacker, because it consists of many bytes of random data generated uniquely for your session.

But without HTTPS to encrypt the cookie between your browser and the server, an attacker could sniff your traffic, extract the cookie and use it to masquerade as you.

So that’s why Twitter added Always use HTTPS.

→ Three years ago, a freely-available tool called Firesheep was published that allowed even completely non-technical users to sniff session cookies, for example at coffee shops with shared Wi-Fi connections, and use those stolen cookies to publish Tweets or Facebook postings in other people’s names.

Now, of course, there’s a new game in town, which goes a lot further than just sniffing your unencrypted session cookies in order to send embarrassing Tweets from your account.

As we now know, widespread surveillance and monitoring of what we do online means that third parties – from intelligence organisations and the private sector all the way to cybercrime gangs – are sniffing and keeping giant stashes of our internet traffic, just in case.

And although that traffic may be illegible now, thanks to HTTPS encryption, what about tomorrow, or next year, or even next decade?

What if the decryption keys fall into the wrong hands, through fair means or foul, such as: by coercion; due to a legal warrant; or because of a data breach?

Forward secrecy is a way of side-stepping that problem by using temporary encryption keys that are discarded after a short time, such as minutes, hours or days.

Incidentally, techniques for forward secrecy online were supported from the earliest days of HTTPS, but weren’t widely implemented because of extra processing load on the server.

Very greatly simplified, if not actually oversimplified, that’s because plain HTTPS only requires the server to send you a public key to which it has a matching private key, allowing the server to use the same public-private keypair over and over again.

HTTPS with forward secrecy, however, requires the server to send you a public key that is unique to your session, so that the corresponding private key can be destroyed after use.

Generating a keypair for every connection is much costlier that generating one for each server.

→ That’s how the forward secrecy is achieved: once the decryption keys from your session are destroyed, any copies of the encrypted data are effectively “nailed down” into an eternally-encrypted state, like a padlock to which you’ve lost the key.

If this sounds strangely familiar, that’s because it’s how the CryptoLocker ransomware claims to work: the crooks produce a one-off keypair for each victim, and warn you that if you haven’t paid after 72 hours, they delete your private key, and that’s that for your data.

(They’re lying. They practice forward dishonesty, and will sell you your key after more than 72 hours. For a lot more money.)

Of course, as the CryptoLocker private key shenanigans remind us, HTTPS forward secrecy depends on both ends doing the right thing.

It depends on your browser requesting the relevant cryptographic support in the first place; it depends on the server agreeing to provide that support; and it depends on the server doing the right thing by not retaining (or losing) the so-called “ephemeral” key.

But how you keep track of those possibilities is an article for another time!

Follow @duckblog

Article source: http://feedproxy.google.com/~r/nakedsecurity/~3/Et0SZ-ej9nY/