For years, security folks — myself included — have warned about the risk of personalized web sites such as Google, Facebook, Twitter, etc. being served over plain HTTP, as opposed to the more secure HTTPS, especially given the proliferation of open wifi networks. But warnings from security freaks rarely get people’s attention. A demonstration is worth a lot more, and that’s exactly what Eric Butler did with FireSheep, a Firefox plugin that lets you instantly see who on your local network is surfing well-known sites, grab their unencrypted cookie, and “become” them on the given site. Nice work Eric!
(I must also point out Ben Laurie’s post on this topic and his always-hilarious take, “these are not the credentials you’re looking for!”)
Some folks are wondering if this will be a watershed event where major sites will suddenly shift to serving everything over SSL. I don’t think so. The performance implications of serving everything, including static content, over SSL, are staggering. While working on my secure voting system Helios, I noticed that I could easily serve a static image over HTTP about 1500 times per second on a medium-sized server. Add SSL to that, and squeezing out more than 50 images per second becomes a significant challenge. Now, I’m sure there are folks who can tweak SSL far better than I, but it’s still going to be a significant amount of overhead, not to mention that caching content over SSL typically doesn’t happen, which means every graphic, every JavaScript file, is reloaded every time the user navigates to a new page. At the end of the day, a web site served over SSL is a significant amount of extra server-side overhead and, even if you do it right, it just won’t be as snappy in the browser. Users will complain, and that makes SSL-everywhere very unlikely. I would be happy to be proven wrong, but I just don’t think SSL everywhere is happening anytime soon.
What sucks is that there is no in-between. It would be nice if a web page could mix and match SSL and non-SSL components, so that images and JavaScript could be loaded without the overhead of SSL. Of course, that’s not nearly as secure, but it would defend against a passive attacker like FireSheep. Active attackers would still be able to cause damage, but then again active attackers are quite a bit harder to achieve and to defend against, so maybe an in-between defense is good enough. Unfortunately, if you try to mix and match secure and insecure resources, you get some nasty warnings / broken locks on most browsers. For good reason, too, since the browsers are defending against active attackers, but still, too bad there’s no usable way to achieve in-between security.
It would also be nice if web developers could easily use a more secure approach to authentication, one that doesn’t simply send over a cookie. Something like HTTP Digest Auth, only of course *not* Digest Auth itself since that doesn’t fit in nicely with the way web sites like to manage their users’ sessions (timeouts, explicit logout, …)
SessionLock Lite
A couple of years ago, I proposed an in-between solution called SessionLock [PDF]. This approach uses a combination of JavaScript and message-passing via the URL fragment identifier to cause every link, every AJAX request, etc. to be signed. Think of this as a more powerful version of HTTP Digest Auth that allows web sites to fully control login/logout procedures. The content of the web sites you visit with SessionLock is not protected. If you look at what your friends are doing on Facebook, someone with FireSheep might be able to see that, too. But, crucially, they wouldn’t be able to post new status updates, add friends, view data you haven’t viewed yourself during that session, etc. Is that good enough? I’m not sure, but I do think it provides a much more intuitive level of protection: when you’re on a public wifi network, you should always assume someone is casually looking over your shoulder. But you shouldn’t have to worry that they’re completely taking over your keyboard (I mean, that’s just rude!)
Shockingly enough, SessionLock has not caught on, and I often cry myself to sleep at night wondering why… Maybe it was too complicated? So, for those web sites thinking about what to do to respond to FireSheep, I propose SessionLock Lite. It requires a modern browser, IE8+, FF3+, Safari 4+, or Chrome, and it doesn’t fully protect against FireSheep, but it makes FireSheep’s stolen sessions valid only for a very short period of time (a few seconds). Could this be a reasonable compromise?
The idea is this:
- the web site, say facebook.com, logs you in over SSL the way it currently does, and sets a secure session cookie that is only transmitted over SSL.
- when the site redirects you to the plain HTTP site, the way it currently does, the plain HTTP site opens up an invisible IFRAME onto the SSL-protected version of the site.
- the SSL IFRAME computes, every few seconds, a new token that is timestamped so it is valid for only a few seconds. This is likely done using HMAC and the secure cookie as the key. HMAC can be computed in JavaScript in a few milliseconds.
- the new token is communicated to the containing HTTP frame using postMessage(), which is the main reason you need a modern browser.
- the containing HTTP frame then uses this token as its unencrypted cookie.
Effectively, the SSL channel is used to refresh the session cookie very rapidly, all locally in the browser, without making SSL requests to the server other than the initial request to a very small file when the page loads. This is particularly optimized for AJAX-heavy sites like Facebook and Twitter, where the SSL IFRAME will live on for minutes or hours. While you’re using the site, someone on FireSheep can use it, too. But the moment you stop using it, they can no longer use it either.
This is not anywhere near a complete solution, but it’s a very cheap solution that costs almost nothing performance-wise, requires changing very little code, and certainly reduces the damage FireSheep-wielding attackers can cause.
Benlog 
Comments
18 responses to “keep your hands off my session cookies”
This idea isn’t too far off from how many pay-WiFi systems work, popping up a separate window via SSL so they can distinguish you from somebody who tries to jump on your session coattails with MAC cloning or something.
Stubblefield, Rubin, and I wrote a paper way back when on this, where we proposed that static content (those images) be served up in a digitally signed format, suitable for CDNs or whatnot, while dynamic content alone be served via traditional SSL web server. Again, surprise, it never took off.
In a ‘couple of seconds’, it is trivial to make you friends with any and all other sheep in the room, and remove your existing friends network, answering yes to each confirmation. You see, facebook has an API, and that depends on credentials.
SSL is the answer. learn to tweak it. Optimizations will be made. Relying on plain text through public networks is just plain wrong.
I don’t get it! Why promote something that turns non-hackers into hackers by enabling this extension to roam around.
I think I said very clearly that what I’m proposing is only a partial solution, one that makes it harder to do bad stuff, but certainly not impossible. I would prefer if SSL were doable everywhere, but I just don’t think it’s that easy, or Facebook and others would have done it a long time ago and touted it as a feature.
because the hackers are doing it, so this helps raise awareness of the issue and maybe push web sites to do something about it.
http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html
“On our [Gmail] 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.”
[…] Home « keep your hands off my session cookies […]
just in time for my next post 🙂
https://benlog.com/articles/2010/10/26/ok-lets-work-to-make-ssl-easier-for-everyone/
I think my problem with half-solutions at this point, is that history shows they don’t ever turn into full solutions.
Facebook didn’t do it a long time ago because their priorities don’t include security, and they only include privacy when pushed. Additionally, SSL is only a feature once everyone’s pants have been dropped, not before.
SessionLock sounds cool, but you never published the code at http://ben.adida.net/projects/sessionlock/
ah! You’re right! I’ll update that page, but in the meantime the code is here:
http://github.com/benadida/sessionlock
This spring I’ll be doing my bachelor’s thesis in which I’ll work on developing a framework for (most likely) PHP, and security is one of the main focus areas. While doing some research (for fun) I just stumbled onto this blog via your paper on SessionLock.
A few years back it might not have been feasible to do the kind of math that is required using Javascript. However, since the browser wars have shifted focus to Javascript speed, today it seems reasonable to implement the fully non-SSL solution to provide another layer of security to websites, even though it might not be as good as actually getting a SSL certificate. Also, you talked about using local storage and since then the HTML5 specification has become reality (more or less). I’m curious to what you would consider to be the main drawbacks of a JS-only implementation?
I like the idea. Instead of time-based tokens, though, wouldn’t it make more sense to generate a stream of one-time tokens? Then, by the time the attacker can intercept the token, it’s already too late for them to use it.
Tokens can be sent to the browser in batches in advance, using the SSL channel you already described.
That would be quite difficult to achieve, given how browsers request a whole bunch of resources in parallel, so I don’t know how one would set the cookie at precisely the right time. If one wants to use a token as part of every URL request, then that’s more like my initial SessionLock proposal, but it requires a lot more work on the server side.
a JS-only implementation of… SessionLock? I built one, so that’s not a problem at all. You could even layer symmetric encryption on top of that. One problem is that it requires JavaScript, of course. But maybe that’s okay. I look forward to your new work in this area.
Well, you don’t need to use cookies – you can send the tokens as a request parameter – and you don’t have to consume them in order.
The brief of the original SessionLock proposal (I haven’t read the whole paper yet) does seem a lot more useful, and sensible. I’m not quite sure why it would require more work from the server – in fact, I would’ve thought the opposite – but as I said, I haven’t read it all yet.
Well, you don’t need to use cookies – you can send the tokens as a request parameter – and you don’t have to consume them in order.
>the plain HTTP site opens up an invisible IFRAME onto the
>SSL-protected version of the site.
This is where you fall, if there is a MITM they can replace the iframe with an iframe to their own site that is connected to facebook and can therefore pass-through cookies so you won’t notice anything and they can also post whatever they want.