Slashdot Mirror

← Back to Stories (view on slashdot.org)

Twitter Turns On SSL Encryption For Some Users

Posted by timothy on from the 140-chars-of-nothin'-there dept.

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."

36 comments

  1. Re:Herp a derp! by Anonymous Coward · · Score: 0

    Rated PG-13

  2. Speed? by softWare3ngineer · · Score: 1

    Anyone know how much every twitter user using ssl would slow down the service? twitter has always been a little slow (not surprising given how many requests they receive). This effort has got to introduce a huge scaling problem right?

    1. Re:Speed? by Anonymous Coward · · Score: 0

      well, that's why they're starting small. if it does start to cause problems i doubt they're just going to enable ssl for everyone anyway - they'll take a step back and see how they can do it without much slowdown, which probably means more/better hardware.

    2. Re:Speed? by Eric+S.+Smith · · Score: 1

      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.

      --
      Mind the Gap
    3. Re:Speed? by Hatta · · Score: 2

      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.

      --
      Give me Classic Slashdot or give me death!
    4. Re:Speed? by GooberToo · · Score: 1

      Actually, its well known the primary reason its slow is that its written in Ruby - or at least it used to be.

  3. Re:Herp a derp! by Anonymous Coward · · Score: 0

    Hai gays I'm such a twat that I twitted on Twatter.

  4. AT&T, you're part of the problem... by kf4lhp · · 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.

    1. Re:AT&T, you're part of the problem... by afidel · · Score: 2

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

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    2. Re:AT&T, you're part of the problem... by dgatwood · · Score: 1

      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.

      --

      Check out my sci-fi/humor trilogy at PatriotsBooks.

    3. Re:AT&T, you're part of the problem... by Anonymous Coward · · Score: 0

      Just establish an SSH session to your own server with the "-D 1234" option. Then configure your browser to use localhost:1234 as a SOCKS proxy. Voila, secure browsing over unsecure wifi.

      If you use firefox, make sure you enable network.proxy.socks_remote_dns in about:config to avoid making DNS requests in the clear.

      http://embraceubuntu.com/2006/12/08/ssh-tunnel-socks-proxy-forwarding-secure-browsing/

    4. Re:AT&T, you're part of the problem... by yuhong · · Score: 1

      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).

    5. Re:AT&T, you're part of the problem... by kf4lhp · · 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.

  5. How does this work? by impaledsunset · · Score: 3, 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.

    1. Re:How does this work? by blueg3 · · Score: 3, 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/) 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.

    2. Re:How does this work? by Short+Circuit · · Score: 2

      "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"

      --
      tasks(723) drafts(105) languages(484) examples(29106)
    3. Re:How does this work? by Anonymous Coward · · Score: 0

      make sure that all links are a permanent redirect to the SSL version

      In addition to that there is an http header you can send to the client to let the client know that all future connections to this domain name must use SSL.

    4. Re:How does this work? by Anonymous Coward · · Score: 0

      Redirects are a bad idea in my honest AC opinion, There should be a splash page informing people to type in the https version themselves (or copy and paste a link - NOT click).

      It should also state a message to update their bookmarks.

      Redirects are a great exposure for MITM and Twitter / Facebook / Google are about the only websites that could get away with an annoying warning to users.

      Its the small sites that can't use them due to loss of click through. We as the web industry need these giants to do the right thing by everyone for once.

    5. Re:How does this work? by Firehed · · Score: 1

      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 authentication request is secure even if the subsequent session cookie is vulnerable to hijacking on public networks. At least until some jackass stores my password in plaintext in the session cookie for their "clever" auth system.

      After the user is authenticated the first time, you could set the HSTS header so that all subsequent requests (including ones typed directly into the URL bar) would automatically be transformed into https.

      No getting around that first request, unfortunately, so long as http continues to exist. Still, if I required that level of security, I'd just fire up my VPN.

      While I like the theory behind your approach, users don't care about security. At all. The ones that claim they do are either lying or developers (or ignorant; noting the strength of the password written on the sticky note by the keyboard). So if you want a secure site you have to do everything for them - merely encouraging good behavior is not going to help. 301'ing all http requests to https automatically is about the only thing you can do that users might actually notice - the rest is just following good development practices (secure-only session cookies, setting up your firewalls properly on your server, etc)

      --
      How are sites slashdotted when nobody reads TFAs?
    6. Re:How does this work? by lattyware · · Score: 1

      Copying and pasting a link from a website is not a secure act. It's quite possible to inject text into a copy-and-pasted link without even using Javascript.

      --
      -- Lattyware (www.lattyware.co.uk)
    7. Re:How does this work? by Anonymous Coward · · Score: 0

      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.

      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. 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. Even easier to MITM than HTTP, because SMTP isn't real time. You just send a mail, and it arrives at some point in the future. You can alter it manually, and nobody will notice. If you tried that with HTTP, the connection would time out.

      So, now we have an SSL sertificate, secured by unencrypted SMTP. When you assign trust, you assign the trust level of the weakest link. So this certifikate has the same trust level as unencrypted SMTP, just below HTTP.

      Every browser accepts this certifikate as secure. I.e., the weakest link in the browser trust model has the trust level of unencryptet SMTP. And thus, the trust level of the browser HTTPS implementation becomes the same as for unencryptet SMTP.

    8. Re:How does this work? by blueg3 · · Score: 1

      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 certificates and different qualities of CAs. These are well-known and addressable problems.

      Even easier to MITM than HTTP, because SMTP isn't real time. You just send a mail, and it arrives at some point in the future.

      Easier, yes, but the attack window is substantially smaller. Man-in-the-middle doesn't make a lot of sense, here. It's a more reasonable concern that someone is able to masquerade as the real domain owner to the CA.

  6. Widget SSL by watermark · · 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

  7. so this means.... by Anonymous Coward · · Score: 0

    So this means that everybody in the world can know/purchase/see all your private information *except* the people trying to snoop on your connection?

  8. Turning it on now? by Anonymous Coward · · Score: 0

    I haven't been using Twitter for long, just a few months, but all my connections to the site have been over SSL. Does this mean they turned it on a while ago and the story is just old? Or is it that they've supported SSL for a while now, but haven't been forcing people to use it?

  9. The real question here is... by Vrtigo1 · · Score: 1

    ...if Twitter's not been using SSL for authentication why has nobody called them out on it this whole time? After all, they're a major social network and they don't protect login credentials? WTF??

    1. Re:The real question here is... by Anonymous Coward · · Score: 0

      They always used SSL for login, but set a cookie that was passed in the clear. People couldn't snarf your password, but they could snag the cookie and steal your session. Google FireSheep for details.

  10. Encryption option is in ... by antdude · · Score: 1

    ... https://twitter.com/settings/account when you're logged in. :)

    --
    Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
  11. This feature could literally save lives... by Anonymous Coward · · Score: 0

    ..by protecting identities and communications of politcal bloggers from governments like Syria who use Internet surveillance to repress such activities. At worst, the users can get a warning (when presented with a fake certificate) that they're communications are being watched.

    I am surprised they didn't make https default already; Didn't they learn from the experiences of Facebook (in relation to spying by the Syrian government) and Google (in relation to the massive hacking done allegedly by the Chinese government).

  12. That's great, but what about other sites? by greenreaper · · Score: 1

    As I said to them a while ago, I'd be more impressed if they allowed the use of protocol-relative URIs in links (so users can maintain their HTTPS browsing when following links to my site, which supports both protocols).

    1. Re:That's great, but what about other sites? by Anonymous Coward · · Score: 0

      And what happens when that takes them to one of the majority of the sites on the internet that don't have an HTTPS version of their content?

  13. the thought being by nimbius · · Score: 1

    that it sure would be great for some customers in some countries to be free to extol the virtues of capitalist democracy without fear of censorship.
    conversely it sure would be great if American customers were free to extol personal information in a patriotastic manner to government agencies in a constant and warrantless manner.

    --
    Good people go to bed earlier.
  14. SSL configuration by Tomato42 · · Score: 1

    At least the SSL they have is configured properly https://www.ssllabs.com/ssldb/analyze.html?d=twitter.com

    Unlike some banks...

  15. Like every remotely technical site by m50d · · Score: 1

    right slashdot?

    --
    I am trolling
  16. SSL Everywhere. by lattyware · · Score: 1

    On a side note, if you want this functionality now, there is a firefox plugin called HTTPS Everywhere. It's a simple thing that pushes you onto SSL versions of sites (and now allows you to turn it off for individual sites quickly if it breaks something - as with google not allowing image searches over SSL).

    --
    -- Lattyware (www.lattyware.co.uk)