Sophos Cloud Optix
Good news on the social networking security front is that Twitter has finally got its act together to offer an Always use HTTPS option.
If you turn on this option, all of your personalised interaction with Twitter will be encrypted – not only while you are logging in, but also while you are posting tweets.
A lot of people fail to recognise the value of using HTTPS on Twitter. As long as your username and password are sent over HTTPS, so no-one can sniff them out of the ether, who cares if your tweets go over plain HTTP? After all, a tweet is meant to be public.
The problem is that once you have logged in, Twitter sends your browser a session cookie. This is a one-time secret. It is unique to your account and the current session.
Because your browser retransmits this session cookie in all future requests to the Twitter site, Twitter can see that it’s you coming back for more. So you don’t need to put in your username and password for every single tweet you send. You login once, and the session cookie identifies you for the rest of the current session.
Unfortunately, if you login to Twitter over unencrypted WiFi – e.g. at a coffee shop or an airport lounge – then anyone who can sniff your session cookie can pretend to be you. That means they can post tweets as you. And you don’t want that. (It happened to Mr Demi Moore, a.k.a. Ashton Kutcher, recently, no doubt to his considerable embarrassment.)
Turning on full-time Twitter HTTPS keeps your session cookie encrypted throughout your login session. This is definitely what you want.
Don’t forget that it’s not just experienced hackers who can sniff Twitter cookies and use them to impersonate you.
The infamous Firesheep plugin to Firefox automates this cookie-stealing process – known as “sidejacking” – so that anyone who can use a browser can do it.
To enable this new Twitter option, go to your Settings page.
At the bottom is the new Always use HTTPS option. Turn it on and click [Save], and then [Save changes].
Do it today.
(Note: as a commentator below points out, it’s not clear if, or how, non-web-browser Twitter clients will support this new option. If in doubt, please ask the vendor of your Twitter client, or follow the Simplicity Principle and stick to using your browser when tweeting.)
So far so good, if I were to exclusively use my web browser for Twitter. I checked that Always use HTTPS in my Twitter profile and then captured my wifi traffic on it's way to the Internet. I can see the official Twitter client for Android negotiating a TLSv1 session with api.twitter.com on port 443, but then I still see a lot of port 80 traffic in the clear going to and from api.twitter.com. Maybe someone that understands their api can better explain what is going on? I also wonder how third party Twitter clients are going to work.
I'm not sure, but maybe this feature only applies to regular use of the website (e.g. from a laptop or mobile phone directly accessing and using twitter through twitter.com). Perhaps they did not develop the feature to work in the actual Twitter mobile apps yet?
Good comment. I have updated the article to make your point.
If you stick to using your browser to access Twitter, it's visually obvious, if this option is set, that you switch to and stay with HTTPS after you've logged in.
Might be a good excuse for those full-screen/full-time Twitter users who use specialised "high tweet bandwidth" clients to try backing off from their addiction a bit. Load browser. Log in. Post something. Log out. Close browser. Then do other stuff for a while, possibly even in realspace 🙂
This is good. I'm happy to see Twitter taking initiative in security. Facebook semi-recently released the same feature, right? I actually haven't heard too much about people being victim to cookie theft, but I'm not surprised to hear that it happens.
Anyway, in the case of Ashton Kutcher, that meant someone was physically near him (or whoever was using his Twitter) sniffing packets, right?
I'm not sure exactly what happened in the Kutcher case. IIRC, his only "fake tweets" were an appeal for people to learn to use SSL, and happened whilst he was at an event with free WiFi.
In this case, it's reasonable to assume that he was sidejacked, rather than that his password was phished, keylogged, guessed or stolen. The circumstances, at least, point to sidejacking.
If you watch the video I prepared a while back on "how to defeat Firesheep with a proxy", you'll notice me using Firesheep briefly – on some of my own test accounts! – and you'll see just how obnoxiously quick and easy it is: http://nakedsecurity.sophos.com/2010/11/15/exting…
Thanks Paul. Great video.
I've just seen this Tweeted, is this something Twitter is aware of
If true seems like a poorly implemented HTTPS ?
"New Twitter HTTPS option fragile. delete secure_session cookie [sslstrip], make https req, _twitter_sess re-issued as not secure, owned."
I've just seen this Tweeted, is this something Twitter is aware of…
Assuming you've received my last message, I went to the tweeters feed and saw a solution that was suggested that would improve Twitters security
I understand about 30% of what they are on about, but does it mean that even a if a site is 100% HTTPS the cookie is stil the weak point? Obviously I know you can't display the below cut & paste but I'm intrigued at how social media can be secure with the inconsistent cookie handling between various browsers and browser versions?
I'm off to bed now, hope this contributes something to the discussion on privacy.
@cdine craSH
@moxie__ Wouldn't it be better to at least fail closed/not re-issue an insecure ses. cookie? No doubt, lots of sslstrip'able conditions.
@moxie__
@cdine Perhaps, but sslstrip is completely deadly against sites that are all SSL all the time, so it's a losing game for them wrt/ stripping
Can’t this still fail if you use SSLStrip + ARP Spoofing….
Errr…can’t almost anything 🙂
Mind you, I guess that the hassle of “access to the LAN” is trivialised for unencrypted WiFi.
Or, alternatively, never use the browser client.. Of course that leads me to wonder how secure the APIs/OAuth are with their access keys etc.
(Hmm, no OpenID login on here?)