Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?

Question

Firesheep sniffs the network looking for session id's and makes it very easy for an attacker to hijack this authenticated session. It should be noted that Firesheep is nothing new ; it just makes this attack very easy. Many websites like Facebook (EDIT: Actually Facebook has patched this vulnerability) and Stack Overflow violate OWASP A9 - Insufficient Transport Layer Protection. A user can protect themselves by using a plugin like HTTPS Everywhere, but stackoverflow.com doesn't even have a valid certificate. Thus it is trivial to MITM https://stackoverflow.com and users have no way of protecting themselves.

Does the Stack Overflow team not understand the threat of OWASP A9? Do they not care enough to spend the $20 on a certificate to give users the option to protect themselves? Google has not experienced a significant increase in resource consumption by switching to HTTPS. At least give people the option to secure themselves.

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 10 KB of memory per connection and less than 2% of network overhead.

Source: VeriSign

Answer 1

I was going to post this as a comment, but ran out of space.

For @Kop and @Rook:

For a site the size of Stack Overflow/Server Fault/Super User as well as the Stack Exchange network, you CANNOT just slap a $20 certificate onto your web servers and call it a day. You would kill the performance of the websites as SSL processing is a network-overhead intensive operation. Even though it is not as CPU intensive as I once knew to be true, you still do need to account for CPU in your planning, and implementation - because it does add overhead and when you are dealing with 10MM Monthly uniques that can start adding up quick.

To do this properly we would need to implement a highly available SSL load balancer/proxy that could handle the inbound SSL connections and not choke. To handle the load of the Trilogy in Four parts alone that would probably require (and I'm guessing here because we haven't run the numbers for obvious reasons) at least 4-6 very beefy servers, at about 6-8k a piece, plus Kyle's and my time to design, implement and test the solution.

Running SSL on a large website is NOT a cheap $20 certificate, and you don't just go slapping SSL certs onto your web servers and call it a day. For the amount of traffic we receive it is a lot more expensive and involved to get SSL running properly without degrading the performance of the site.

EDIT: Just to clarify BUYING THE CERTIFICATE IS NOT THE ISSUE

Answer 2

We will be purchasing certificates for the network this week (dev is already in place), but there's still a lot left to do on the move to SSL. If you're curious about the details, you can read a recent blog post I wrote about it here.

It's far from a trivial task, but we're moving towards making SSL available and then the default. I'll continue to blog about the SSL implementation as we go (websockets may be interesting for example).

If there are current questions, I'm happy to answer them. As for this one: why aren't we doing anything? Well we are now... Why weren't we? Because it's complicated and wasn't even a possibility before now. Third party content (ads, MathJax, etc.) had to support it, and it didn't until very, very recently.

Update #1 Jun 20th, 2013: The setup/test procedures of the migration to SSL configs was much more involved when we saw how to do it safely on production. We will be testing our internal/virtual load balancers very early next week then prepping to deploy certs to production. The site code will take longer (making https:// the default, 301, canonical, etc.), but this will make SSL available soon as we can.

Notes: websockets are almost complete unknown on our intended setup, you may see intermittent connectivity with real-time as we figure out what fun times are involved with our setup and how SSL sockets will best work.

Update #2 May 22nd, 2017: We have rolled out HTTPS across the network. Next up is chat forcing https:// (even with mixed content) and then secure-only cookies. Look for both of these to happen soon.

Answer 3

Here's a setting I made for getting Stack Overflow cookies. Please note that I don't even know how to write "leet" and I made this by just looking at other settings in Firesheep, and asking on Stack Overflow about how to traverse the page HTML to get the user name. If I create an open Wi-Fi network at home, sign out of Stack Overflow on one computer (with Firesheep running) and then look at a Stack Overflow page on another computer (which is already signed in) I can get access without the login.

I don't think it's a huge deal for Stack Overflow. The worst you can do is impersonate a user and call other people names. Even deletes can be rolled back. It's much more serious for Gmail. That said, I'd like to be able to see what IP addresses have accessed my account.

Using this plugin, I've noticed that it's hard to use Google search on an open Wi-Fi without exposing your Google cookie. Even going to https://google.com redirects you to the insecure site. Worse, Google seems to ping home, exposing your Gmail account (even without visiting gmail, even if you have the "always use https" set in Gmail). If you want to search securely, you can use HTTPS anywhere, but I found it very buggy.

I hope you don't think I'm being irresponsible for posting this. Don't forget, ANYONE CAN DO THIS. Look at how simple the code is. It took me very little time to create, and very little knowledge (copying the template from another setting, looking at cookie names in Firefox, some JavaScript help). I actually started thinking about this after seeing this question on Meta Stack Overflow and finding nothing under the Firesheep tag on Stack Overflow.

register({
  name: 'Stack Overflow',
  url: 'http://stackoverflow.com/',
  domains: [ 'stackoverflow.com' ],
  sessionCookieNames: [ 'usr', '__utmz', '__utma' , '__qca' ],

  identifyUser: function () {
    var resp = this.httpGet(this.siteUrl);
    this.userName = resp.body.querySelectorAll('a')[3].textContent;
  }
});

Answer 4

If you have a "man in the middle" then there are deeper problems, like, you're using a compromised network.

We do actually cycle part of the cookie every so often, so if someone has an old cookie of yours it probably won't work. That's assuming they stop listening, and you keep using the site.

Also, we don't think the risk of someone stealing your Stack Overflow account is very dangerous compared to, say, your online banking account, or your Gmail. (Remember email is the de-facto skeleton key for all online logins that I know of.)

Answer 5

For what it's worth, Jeff now appears to believe that "maybe encrypted connections should be the default for all web sites."

I know that Jeff is leaving Stack Overflow in March 2012, but this post of his may be one indication that full HTTPS support is not all that far off.

Answer 6

May I suggest a compromise?

I think that the information which is not available publicly should be served over secure connections. These can include:

• when a moderator visits a page which is only accessible to moderators
• when a user visits his/her own userpage
• when a user logs in using the log-in page

This shouldn't create a performance problem since the number of visits to these pages is limited. Also this is consistent with what large companies like Google used to do: user account setting pages were served over secure connection even when the https was not default for GMail.

Let me add that I think these pages should be served securely since they contain private information about users and SE should make sure that the information on these pages remains private.

Answer 7

I agree that you should fix this right, with TLS/SSL.

In the meantime, Ben Adida's proposal/code for "SessionLock Lite" offers an inexpensive interim approach that looks like it at least protects against persistent hijacks by passive attackers. Of course it offers no protection against eavesdropping. There is also a short and worrysome window of vulnerability to a tool like firesheep, which you should take other server-side approaches to mitigating. But it can reduce the exposure while you engineer your SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/

By the way - do you at least actually expire cookies on the server side when users log out?

Answer 8

My first guess is that advertising won't support HTTPS therefore making a mixed session and the user having to deal with the browser "do you want to continue" dialogs

More information: Google Ads doesn't support HTTPS. What alternatives are there?

Perhaps SO had a different way of dealing with advertisements.

Answer 9

Why doesn't the Stack Overflow team fix the Firesheep style cookie theft?

Because even the high-rep users have rate limits, so if the accounts are broken into, there's very little damage that can be done to Stack Overflow at all, and what damage is done is easy to remedy.

It's likely something that will be addressed more completely at a later date, but it would take a concerted effort to pull something like this off.

For instance, go to CES with a few friends and set up their notebooks to sniff and report the cookie information to a central server. That server then figures out which accounts it's gathered, and sets up a controller so that a single user can insta-close questions, post questions and insta-vote them up, etc. using several accounts.

However, Stack Overflow already has significant monitoring, rate limiting, and firewall blocking for abusers, and chances are good such a simple setup (as above) would be blocked with the current setup.

The biggest danger is if someone gets the cookie from a moderator, at which point they can do some damage that can't easily be rolled back.

Answer 10

There are ways to prevent cookie leaks without using SSL and that will add very little load.

When session is created, generate a random number (R) and associate it with the session. Pass this number back to the browser as part of the login process (so it's covered by SSL, and is therefore secret).

Then for each request over HTTP:

• browser generates random number Q.
• browser calculates S = SHA1(Q + R)

• browser includes Q and S in the request along with the session cookie

• server receives request, verifies SHA1(Q + R) = S and if so, session is valid.

Not hard to do, adds about 40 bytes per request header, and increased server load is negligable. Breaking this requires some sort of XSS flaw which reveals R, breaking SHA1 or guessing the random number sequence, none of which are going to be quick.