Home » Privacy & Security

Facebook HTTPS now works but forgot SSL authentication

By 4 February 2011 8 Comments

UPDATE 2/28/2011 - Facebook’s new feature now shows up and I’ve confirmed that it secures the cookies.  However, some of the applications still don’t function if SSL security is turned on.  The other problem is that the feature is still only on when a user opts in which is very unlikely for the vast majority of users.

Facebook’s new full SSL feature finally works three years after it became widely known that web pages were passing authentication cookies in the clear which could lead to hijacked user accounts, and 3 months after an easy to use tool called “Firesheep” made this hacking method easy enough for anyone to use.  Facebook users can now go to the Facebook Account Settings page and enable persistent HTTPS SSL protection for their Facebook sessions.  Unfortunately, their update still won’t fully protect Facebook users.

The new update makes it so that “sidejacking” with tools like Firesheep can no longer steal access to your Facebook account.  However, Facebook forgot one of the most important and basic components of web security which is to enable HTTPS when you’re logging into the system and not just while you’re surfing the website.  Facebook might argue that even without HTTPS on their login page, they’re still encrypting your username and password.  But the purpose of HTTPS has two purposes which is to encrypt data and to verify it’s authenticity to the user.  Without HTTPS on the Facebook login page, users have no idea if they’re visiting Facebook or if they’re visiting a fake Facebook login page set up by someone on a wireless network hoping to snare some Facebook user accounts.

Because Facebook forgot this fundamental step to protecting Facebook usernames and passwords, they still get an “F” on the updated report card below until they match this fundamental error.  The login page should automatically forward to an HTTPS page as soon as someone visits the site.

Online services security report card – Updated 2/4/2011

8 Comments »

  • Tweets that mention Digital Society » Blog Archive » Facebook HTTPS now works but forgot SSL authentication -- Topsy.com said:

    [...] This post was mentioned on Twitter by gossip boy, The Team, leah smith, Craig, Chris Wysopal and others. Chris Wysopal said: RT @GeorgeOu: http://bit.ly/f1KzBU What's it going to take to get Facebook to get their security right? They're failing basics, like HT … [...]

  • Christopher said:

    Thank you for the interesting article George. However I imagine that the lack of a redirect to HTTPS on the Facebook login page isn’t a forgetful omission on their part but rather a purposeful business decision.

    As you can see with the previous link, with Facebook if you manually specify HTTPS it will result in an entirely encrypted session. There is an impact associated with HTTPS including a small percentage of connectivity issues and a slight increase in latency. It is possible that Facebook decided the benefit wasn’t worth the tradeoff.

    It is also a common misnomer that redirecting to HTTPS on a login pages provides much benefit to security. Because the initial connection is sent over HTTP before the redirect an attacker performing a MitM attack could simply redirect to HTTP on the client site, while still connecting with HTTPS on the server side, which results in an unencrypted login even for sites that redirect to HTTPS for login pages. This attack is implemented in Moxie Marlinspike’s sslstrip tool.

    The more effective method to prevent this type of attack is implementation of HTTP Strict Transport Security (HSTS). However, HSTS has limited browser support and site HSTS support isn’t reflected in your chart.

    I am not sure that Facebook deserves an “F”, because they do support beginning to end https if manually specified by the user, and because HTTPS redirects don’t help much without HSTS. Perhaps the biggest reason I don’t think Facebook deserves an “F” is that it moves the burden on the attacker from a passive (traffic capture, sidejacking) attack to an active (MitM) one.

    - Christopher

  • George Ou (author) said:

    @Christopher

    “However I imagine that the lack of a redirect to HTTPS on the Facebook login page isn’t a forgetful omission on their part but rather a purposeful business decision.”

    You grossly overstate the performance impact of 100% HTTPS. It’s the same lame excuse the US banks used several years ago when I called them out at ZDNet. Unfortunately, they had listened to the bad arguments you’re making now.

    The fact that SSLStrip needs to be addressed is irrelevant to the discussion because if we went with that logic, nobody should bother with HTTPS and just give up, just throw their hands in the air. I’ve proposed solutions by having a browser list of SSL only sites, but that can only work if Facebook implements SSL correctly.

  • Christopher said:

    @George
    I think you may have missed my main point, which is this:
    Redirecting to HTTPS on http://www.facebook.com would only provide a little additional security over their current practice of delivering the page over HTTP that POSTs to HTTPS, because the redirect would be over HTTP and therefore vulnerable to the same attack regardless.

    If a user desires to use HTTPS for authentication of the site, they can manually enter https://www.facebook.com in the address bar, run an extension that redirects automatically, or click the login button without entering credentials to get to the HTTPS page. Users of the site that don’t know to do those things are not looking for the indicators of a secure site anyway.

    Further, I doubt the hundreds of developers and security folks at Facebook simply forgot to redirect http://www.facebook.com to HTTPS as you suggest. And while they obviously have not implemented HTTPS 100%, they obviously don’t deserve an “F” – I’d save that for sites that don’t offer HTTPS at all.

    “You grossly overstate the performance impact of 100% HTTPS.”

    Below are the results for http://www.facebook.com over both HTTP and HTTPS (including redirect) fetched ten times each and results averaged:
    HTTPS: 1.04 seconds
    HTTP: .48 seconds

    As you can see, 100% HTTPS would double the loading time for http://www.facebook.com. In this context I don’t see how what my writing “a slight increase in latency” could be considered a gross overstatement. This doesn’t even include round trip times for OCSP checking (which cURL doesn’t support), or the impact to more complex pages. The effect would also be magnified for mobile clients or users with poor connectivity.

    To be clear I am not advocating against the use of 100% HTTPS, only that there are legitimate reasons they may have had for deciding not to go there. Use of HTTPS is important to improve the security and privacy of users. From a performance standpoint, Google has started several initiatives to lower its impact. You can read more about it in the articles “Overclocking SSL” and “Changing HTTPS” on Adam Langley’s blog.

    “I’ve proposed solutions by having a browser list of SSL only sites, but that can only work if Facebook implements SSL correctly.”

    Fortunately what you have proposed is already implemented in the HTTPS Everywhere plugin by EFF for Firefox. The latest version of HTTPS Everywhere supports Facebook now that they have added HTTPS, although this support is still experimental and off by default.

    On a side note, I suggest you avoid ad hominem attacks against commentators on your site. Using terminology like “grossly overstate”, “lame excuse”, “bad arguments”, “irrelevant” will just discourage participation and drive contributors away.

    - Christopher

  • George Ou (author) said:

    I didn’t miss your point Chris. What I said was that website authentication pages should always redirect to an HTTPS page instead of remaining HTTP. The idea is that it shows people the lock and they’re supposed to check to see if it’s there.

    Since people don’t check to see if it’s there, the auto-redirect does provide a good indicator to the browser mechanism or some other plugin that they should always look for HTTPS in the future. So implementing the best practice of HTTPS for authentication is useful not only for people that manually check, but it’s also useful for automatic future checking.

    “Fortunately what you have proposed is already implemented in the HTTPS Everywhere plugin by EFF for Firefox.”

    1. I’m happy someone is either listening to my proposals, or independently arrived at the conclusion after me.
    2. Firefox isn’t used by everyone.

  • George Ou (author) said:

    “To be clear I am not advocating against the use of 100% HTTPS, only that there are legitimate reasons they may have had for deciding not to go there”

    There were legitimate reasons for avoiding full-time HTTPS 10 years ago when the compute power wasn’t there. Everyone kept repeating the myth that HTTPS was too expensive when in fact it’s the initial handshake that’s expensive (which you must do anyways) but keeping it on for bulk encryption was almost free. Google finally turned on full time HTTPS for Gmail and it proved that HTTPS cost very little and it wasn’t just because of those HTTPS optimization initiatives.

  • Digital Society » Blog Archive » Someone in DC cares about online security said:

    [...] like Facebook finally added a secure SSL mode earlier this month, but the feature is off by default until a user manually turns it on which is unlikely for most [...]

Leave your response!

Add your comment below, or trackback from your own site. You can also subscribe to these comments via RSS.

Be nice. Keep it clean. Stay on topic. No spam.

You can use these tags:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

This is a Gravatar-enabled weblog. To get your own globally-recognized-avatar, please register at Gravatar.