Twitter joins the "forward secrecy" club for added resistance to surveillance

Filed Under: Cryptography, Featured, Twitter

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!

, , , , ,

You might like

4 Responses to Twitter joins the "forward secrecy" club for added resistance to surveillance

  1. Siva · 489 days ago

    Asymmetric cryptography is used in https only for sharing symmetric key (session key) which will be used for further encryption of data being transmitted.
    Seems I am little confused here,the above article mentions that for forward secrey one time key should be used.
    Can you please explain more about it.

    • Paul Ducklin · 489 days ago

      Perhaps oversimplified, instead of sharing a one-time secret (symmetric sesssion) key using a long-term public key, you share the one-time secret key using a once-off public key. Because the private key that goes with the once-off public key is destroyed after use, the session key can't later be decrypted, so neither can the session. That's the theory.

      • Siva · 488 days ago

        thanks understood.But still I don't think this is a viable solution.In that case the organization should have multiple certs singed by CA(each being charged) to have multiple public-private key which needs to provide authenticty at the same time.

        • Siva · 488 days ago

          or perhaps,they generate multiple public-private keys and get it digitally signed by the CA in a single Cert?

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog