Twitter Turns On SSL Encryption For Some Users

JohnBert writes with this news from ComputerWorld, which reports that "Twitter is slowly turning on automatic encryption on its website, a move following other major providers of web-based services to thwart account hijacking over wireless networks. Twitter has offered an option for users to turn on SSL (Secure Sockets Layer) encryption, but said on Tuesday that it will turn the feature on by default for some users. It did not indicate when the option would be turned on by default for all users."

Comments

How does this work?

[impaledsunset]

How do you enable SSL for "some users"? It means you have to send your credentials over an unsecured link until your secure connection kicks in, which is insecure. Even trying http before trying https is considered unsecure -- even if the cookies are correctly set to require require SSL, you reveal what site are you connecting to, possibly what URL from the site you're trying to access, etc. Verifying which user it is *before* enabling SSL sounds like a very bad idea.

Enable it for everyone, set the cookies to SSL only, make sure that all links are a permanent redirect to the SSL version, and encourage users to use https URLs when they send links, keep bookmarks or try to access twitter. Possibly issue a warning for a set of the possible URLs.

Re:How does this work?

[blueg3]

The exchange of credentials has always been over HTTPS. It's just that the later communication redirects to HTTP (and includes your session cookie, which can be then used for sidejacking). Of course, it's easy to turn it on for "some users", since your credential exchange is over HTTPS, and after that, you know who the user is and can have the later communication be HTTP/S as appropriate.

Having a login page (e.g., http://www.twitter.com/) transmitted over HTTP is unsafe, since it's hard to verify where the login data is actually being sent. That is, an attacker could modify the login page to send credentials to a third party with a legitimate certificate instead of to Twitter, and since the login page wasn't HTTPS-protected, you wouldn't detect this. But, that's another story.

HTTPS for session communication -- what they're talking about here -- has been available as a feature for a while now. They're just changing what the default is for some users.

Re:How does this work?

[Short Circuit]

"some users" can mean "users who happened to connect to a particular server bank" rather than "users who had a flag set in their profile"

Widget SSL

[watermark]

They are finally serving their "Tweet Button" widget via SSL. This has long been a thorn in my side.

https://platform.twitter.com/widgets.js

Re:AT&T, you're part of the problem...

[afidel]

Guess you weren't paying attention to the happenings at blackhat this year, your GSM/HSPA connection is NOT safe.

Re:Speed?

[Hatta]

Anyone know how much every twitter user using ssl would slow down the service?

If Google's experience is any indicator, not much:

In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.