Twitter Turns On SSL Encryption For Some Users 36
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."
Speed? (Score:2)
How does this work? (Score:4, Informative)
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? (Score:4, Informative)
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/ [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: (Score:2)
Just as hard with SSL. All you know is that it's being sent to someone who paid a CA for a certificate. And a CA is a business, they are in it to make money, and thus will sell a certificate to anyone.
It's enormously easier to MitM an HTTP session than it is to both MitM an HTTPS session and falsely obtain a certificate.
On top of that, simply trusting every CA out there is just the default stance of modern browsers. You can, however, choose only to trust particular CAs, implement a different or additional verification layer, run your own CA internally, et cetera. SSL gives you a lot of options with which to address the problem. HTTP gives you no tools.
When we got a certificate at work, the only check was that we could receive an e-mail. An e-mail sent over plain unencrypted SMTP.
Yes, there are different levels of validation for cer
Re: (Score:3)
"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"
Re: (Score:2)
Re: (Score:2)
The actual POST to the login page should always be going over https. And yes, it would be great if every website in the world was https all the time for anything requiring an active session, but there's no chance of that happening without at least the complete death of Windows XP (since no version of IE on XP supports SNI, and the millions of websites on shared hosting simply cannot use SSL without that because of IP reuse) or full IPv6 adoption. Still, I'd feel better knowing at the very least that my auth
Re: (Score:2)
I don't think that a "huge scaling problem" is necessarily implied -- Twitter is probably slow because it's querying your tweets out of its database, not because the front-end Web servers are CPU bound.
Re: (Score:3)
Anyone know how much every twitter user using ssl would slow down the service?
If Google's experience is any indicator, not much [imperialviolet.org]:
Re: (Score:2)
Actually, its well known the primary reason its slow is that its written in Ruby - or at least it used to be. [techcrunch.com]
AT&T, you're part of the problem... (Score:1)
I'm sure AT&T hates me for -not- using their free WiFi hotspots and continuing to suck data down over 3G... I just don't like wide open networks and so much stuff that you have to log in to still -not- using HTTPS.
Re: (Score:3)
Re: (Score:2)
If it requires several thousand dollars in custom hardware, it's not likely to be happening in very many places. By contrast, any jackass with a standard issue laptop can snoop open Wi-Fi.
So yeah, GSM might be sniffable, but it's still statistically a few orders of magnitude less likely to be sniffed than unencrypted Wi-Fi.
Re: (Score:2)
Not to mention they only apply to 2G connections, because 3G used strong 128-bit encryption from the beginning (GSM's A5/3 and GEA3 protocols uses the same encryption algorithm but with only 64-bit keys).
Re: (Score:1)
Didn't say 3G was safe, only that open WiFi is a lot less safe. I'm clear on the news from Blackhat.
Widget SSL (Score:2)
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 [twitter.com]
The real question here is... (Score:1)
Encryption option is in ... (Score:2)
... https://twitter.com/settings/account [twitter.com] when you're logged in. :)
That's great, but what about other sites? (Score:2)
Re: (Score:2)
SSL configuration (Score:1)
Unlike some banks...
Like every remotely technical site (Score:1)
SSL Everywhere. (Score:2)