Breaking the Web's Cookie Jar

The Firefox add-in Firesheep caused quite an uproar a few weeks ago, and justifiably so. Here's how it works:


•Connect to a public, unencrypted WiFi network. In other words, a WiFi network that doesn't require a password before you can connect to it.
•Install Firefox and the Firesheep add-in.
•Wait. Maybe have a latte while you're waiting.
•Click on the user / website icons that appear over time in Firesheep to instantly log in as that user on that website.
Crazy! This guy who wrote Firesheep must be a world-class hacker, right?

Well, no. The work to package this up in a point-and-click way that is (sort of) accessible to power users is laudable, but what Firesheep actually does is far from magical. It's more of an art project and PR stunt than an actual hack of any kind. Still, I was oddly excited to see Firesheep get so much PR, because it highlights a fundamental issue with the architecture of the web.

The web is kind of a primitive medium. The only way websites know who you are is through tiny, uniquely identifiying strings your browser sends to the webserver on each and every click:
GET / HTTP/1.1
Host: diy.stackexchange.com
Connection: keep-alive
User-Agent: Chrome/7.0.517.44
Accept-Language: en-US,en;q=0.8
Cookie: diyuser=t=ZlQOG4kege&s=8VO9gjG7tU12s
If-Modified-Since: Tue, 09 Nov 2010 04:41:12 GMT

These are the typical sort of HTTP headers your browser sends to a website on every click. See that little cookie in bright red? To a website, that's your fingerprint, DNA, and social security number all rolled into one. Some part of the cookie contains a unique user ID that tells the website you are you.

And guess what? That cookie is always broadcast in plain text every single time you click a link on any website. Right out in the open where anyone -- well, technically, anyone who happens to be on the same network as you and is in a position to view your network packets -- can just grab it out of the ether and immediately impersonate you on any website you are a member of.

Now that you know how cookies work (and I'm not saying it's rocket surgery or anything), you also know that what Firesheep does is relatively straightforward:


1.Listen to all HTTP traffic.
2.Wait for HTTP headers from a known website.
3.Isolate the part of the cookie header that identifies the user.
4.Launch a new browser session with that cookie. Bam! As far as the target webserver is concerned, you are that user!
All Firesheep has to do, really, is listen. That's pretty much all there is to this "hack". Scary, right? Well, then you should be positively quaking in your boots, because this is the way the entire internet has worked since 1994, when cookies were invented.

So why wasn't this a problem in, say, 2003? Three reasons:


1.Commodity public wireless internet connections were not exactly common until a few years ago.
2.Average people have moved beyond mostly anonymous browsing and transferred significant parts of their identity online (aka the Facebook effect).
3.The tools required to listen in on a wireless network are slightly … less primitive now.
Firesheep came along at the exact inflection point of these three trends. And mind you, it is still not a sure thing -- Firesheep requires a particular set of wireless network chipsets that support promiscuous mode in the lower level WinPcap library that Firesheep relies on. But we can bet that the floodgates have been opened, and future tools similar to this one will become increasingly a one-click affair.

The other reason this wasn't a problem in 2003 is because any website that truly needed security switched to encrypted HTTP -- aka Secure HTTP -- long ago. HTTPS was invented in 1994, at the same time as the browser cookie. This was not a coincidence. The creators of the cookie knew from day one they needed a way to protect them from prying eyes. Even way, way back in the dark, primitive ages of 2003, any banking website or identity website worth a damn wouldn't even consider using plain vanilla HTTP. They'd be laughed off the internet!

The outpouring of concern over Firesheep is justified, because, well, the web's cookie jar has always been kind of broken -- and we ought to do something about it. But what?

Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution. I'd rather see a better, more secure identity protocol than ye olde HTTP cookies. I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret. But gee, I sure do care if they somehow sniff out my cookie and start running around doing stuff as me! Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.

I'm not holding my breath for that to happen any time soon, though. So here's what you can do to protect yourself, right now, today:


1.We should be very careful how we browse on unencrypted wireless networks. This is the great gift of Firesheep to all of us. If nothing else, we should be thanking the author for this simple, stark warning. It's an unavoidable fact of life: if you must go wireless, seek out encrypted wireless networks. If you have no other choices except unencrypted wireless networks, browse anonymously -- quite possible if all you plan to do is casually surf the web and read a few articles -- and only log in to websites that support https. Anything else risks identity theft.
2.Get in the habit of accessing your web mail through HTTPS. Email is the de-facto skeleton key to your online identity. When your email is compromised, all is lost. If your webmail provider does not support secure http, they are idiots. Drop them like a hot potato and immediately switch to one that does. Heck, the smart webmail providers already switched to https by default!
3.Lobby the websites you use to offer HTTPS browsing. I think we're clearly past the point where only banks and finance sites should be expected to use secure HTTP. As more people shift more of their identities online, it makes sense to protect those identities by moving HTTPS from the domain of a massive bank vault door to just plain locking the door. SSL isn't as expensive as it used to be, in every dimension of the phrase, so this is not an unreasonable thing to ask your favorite website for.
This is very broad advice, and there are a whole host of technical caveats to the above. But it's a starting point toward evangelizing the risks and responsible use of open wireless networks. Firesheep may indeed have broken the web's cookie jar. But it was kind of an old, beat up, cracked cookie jar in the first place. I hope the powers that be will use Firesheep as incentive to build a better online identity solution than creaky old HTTP cookies.

Comments
> if you must go wireless, seek out encrypted wireless networks.

Is this enough?
I'm quite sure that with WEP or WPA or WPA2 without Radius-servers etc., where everyone uses a common password that is the same for every user, this does not help:

If someone knows that password and is inside the encrypted wireless network, he should be able to run Firesheep and capture the traffic of everyone else in the same network.


The only solution for using public wifi is to always use a VPN of a trusted entity, e.g. your company. Of course it must be setup to send all web surfing over the vpn

Bugmenot5 on November 14, 2010 12:01 AM
@Bugmenot5,

WPA generates a unique encryption key for every connection. The key you type is only used for the connection, after that everything is encrypted with a separate key. That's why free public networks are starting to use WPA2 with the key "free" (or something similar). This way nobody can sniff your traffic (except for the router), as the connection between your computer and the router is encrypted.

Mircea Chirea on November 14, 2010 12:06 AM
Nice article! There' s also another case in which unencrypted network are used to steal credentials: when somebody leaves the connection open and set up a proxy in order to pretend to be the server of interest, in which case even ssl wouldn' t save you because being the proxy the one that does the ssl handshake(instead of the original server), you get your credential stolen again. So it' s always better not to rely on free wifi networks, even when using ssl.
And btw, do you mind offering https browsing? :D
cheers!

Omissis on November 14, 2010 12:12 AM
@Mircea Chirea

Bugmenot5 is right. In a standard WPA2 setup, as long as the attacker is listening when you connect to the network, encryption is not sufficient.

WPA2 uses PTK for private transmission between the AP and each client, but in order to set up the PTK channel, it has to send the key to the client in the first case. This is done via the broadcast GTK, and any users who are already connected to the network (authorized users) can intercept the key that is sent. That is, if I am on the network when you connect, then I will see the key the AP sends you via GTK that you will use to encrypt your PTK messages, and thus I can trivially decrypt each one. Further, if I have the right tools, I can force you to disconnect and reconnect, so even if you connected before I did, it won't really matter that much (just an extra step).

Even in the case where the right tools are set up to prevent this attack (and doing so is far beyond the reach of most coffee shops), there are other proven man-in-the-middle attacks against WPA2. Assuming that WPA2 will protect you is not a good idea. Here's an example:
http://www.networkworld.com/newsletters/wireless/2010/072610wireless1.html

VPN is an excellent suggestion; if you have a host somewhere you trust that can serve as a proxy for all of your web traffic then using it through VPN, SSH tunnel, or otherwise, it is a great way to protect yourself.

TL;DR: wireshark can still snoop your traffic if it is on the network before you; wpa2 isn't good enough, but VPN is

Olpersonality on November 14, 2010 12:26 AM
For nitpickers, let me be more clear:
Vulnerable:
WEP
WPA/WPA2 Personal using Wireshark
WPA Enterprise using brute force
WPA2 Personal/Enterprise with TKIP using brute force

Harder but Vulnerable:
WPA2 Enterprise AES

Perfect:
...

For Wireshark's excellent "How To Decrypt 802.11" website:
http://wiki.wireshark.org/HowToDecrypt802.11

Do you trust your coffee shop to use the right wireless security settings? If not, the above advice - "be very careful how we browse on unencrypted wireless networks" - is insufficient. Be very careful how you browse on any network you don't trust, period, and if you're very worried about security, tunnel.

Olpersonality on November 14, 2010 12:58 AM
Another con with https is that nothing gets cached on the client, so every css, image, js etc has to be fetched on every page load.. Btw, doesnt everybody use 3g/4g these days? Free wlan feels so 2005 :P

Carlhoerberg on November 14, 2010 1:03 AM
Thank you Jeff for this amazing email. We can actually can call it "Firesheep Anatomy" :)

Ahmed Magdy on November 14, 2010 1:05 AM
For immediate purposes, its good to have BlackSheep installed to detect if any one is running Firesheep on your unsecured Wifi

http://research.zscaler.com/2010/11/blacksheep-tool-to-detect-firesheep.html

Swaroop on November 14, 2010 1:07 AM
Am I missing something or does this only work if a security system authenticates by only a cookie check? For example if you would have the auth system compare your HOST + IP + cookie + session_id everything would be fine? I thought it was more common to use sessions than cookies for authentication nowadays....

Oskar Schöldström on November 14, 2010 1:24 AM
@Swaroop,
BlackSheep does nothing interesting; it is, in fact, a DDoS against facebook.

Blog on November 14, 2010 1:31 AM
@Oskar Schöldström
I am quite sure that the session_id is what is stored in a cookie. If more parameters than the session id was required, i would guess you could just sniff them out of the HTTP header as well.

Andreas Vinter-hviid on November 14, 2010 2:01 AM
.. what about HTTP Digest Authentication?

Mikekelly85 on November 14, 2010 2:39 AM
@oskar: as @andreas already mentioned, no matter what session mechanism you use, there are only two ways to link a client-side user with a server-side session: via cookies or via a URL parameter. You can encrypt the session id all you want but if somebody simply steals it, they are you.

You are right though that you could perform additional checks on the server-side, for example by IP, hostname, user-agent, etc. That will help a bit. Another helpful strategy is to regularly regenerate the session id. These will reduce but not eliminate the fundamental issue of shared physical network access.

Fchristant on November 14, 2010 3:12 AM
Firefox users should probably consider installing HTTPS Everywhere: https://www.eff.org/https-everywhere

eetu on November 14, 2010 3:20 AM
IF you are using Chrome, I wrote an extension called Fidelio that will automatically rewrite requests to https for certain sites (Facebook and Twitter by default, but you can add more in options):

http://github.com/nikcub/fidelio

unlike other extensions, it will also rewrite all your cookies and set the secure flag, so that you session is not passed in the clear during the initial request before the plugin gets a chance to rewrite it. The cookies are set to secure as soon as you install the extension or add a site in options.

Nikcub on November 14, 2010 3:49 AM
Browsing anonymously is quite difficult. I, and I assume a lot of other people, tick the remember me box on most websites. Your browser will send the corresponding cookies without you having to explicitly indicate that you want to log in.

So the best option is to use a separate browser or browser profile when you have to browse over an unencrypted and untrusted network.

Johan on November 14, 2010 3:55 AM
Jeff, I think I remember you tweeting about having to deal with a popular OpenID provider that had an expired certificate.

Then there are web mail providers / rss reader providers that don't deal well (if at all) with mixed content.

Then there are sites with home grown ad networks that don't do well with mixed content and each ad wants to set a new cookie.

The point being, until people actually learn how to implement https correctly and how to interpret browser warnings, a lot of 'facebookers' are just going to use a link that doesn't present warnings.

We have "Don't drink and drive" , yet people do it.

We have "Don't smoke in bed" and it seems that people are finally waking up to the danger of that, but way after burning to death was the consequence at hand.

Barring the invention of a reverse multicast mind meld that works via osmosis, we aren't going to get the majority of people that use web browsers to follow good practices. HTTP was never, ever meant to do what it is doing.

And now, we won't rest until the majority of the developed world has some kind of wifi enabled 'pad' in their hands, ensuring that they have several more inches of screen real estate to utilize at their every convenience when screwing up.

Do not transmit information that you don't want anyone else to have over the public internet, period. Anything beyond that is a calculated gamble.

It's going to be years before the public at large starts 'calculating' prior to taking that gamble.

Tinkertim on November 14, 2010 4:31 AM
Yet codinghorror.com doesn't support HTTPS. Hypocrite.

bah on November 14, 2010 4:43 AM
Mikekelly85 is right, you should have mentioned HTTP Digest.

Adish876 on November 14, 2010 5:32 AM
I wrote a short post about this:

http://restafari.blogspot.com/2010/11/cookies-are-gross.html

Mikekelly85 on November 14, 2010 6:10 AM
Thats only when a service checks just for a valid cookie. One can make it secure for users by also considering the IP address while generating the cookie.

e.g: An MD5 of the userid-IPaddress-SecretKey


Omtalk on November 14, 2010 6:11 AM
>> build a better online identity solution than creaky old HTTP cookies.

We did. 5o9 Inc.

Cheers,

Peter

Cranstone on November 14, 2010 7:29 AM
Just for fun, I turned on a unencrypted router at work (router was not connected to any network). Within minutes I had almost 100 connections. What this suggests to me is that the majority of people have no idea what WEP, WAP, HTTPS or TKIP is. Could this possibly why identity theft continues to rise. To me, education is the only solution. The problem is that only the people who know about Firesheep know about the dangers of unencrypted data.


App_Anarchy on November 14, 2010 7:29 AM
Github team also commented on this issue, and how they started dealing with it by setting secure flag and https for critical actions: https://github.com/blog/737-sidejack-prevention

Metaphysicaldeveloper.wordpress.com on November 14, 2010 7:40 AM
Considering that only you and the service provider (i.e. your bank) benefit from security, and that local hardware (WiFi router) is far more vulnerable to attacks than your/bank's hardware, HTTPS is the best option by far.

I think all web traffic should be encrypted, though we'd need to work on how browsers cache it etc. HTTPS is cheap enough to be used everywhere -- it shouldn't increase your CPU load by more than 1-2%.

I think that a great way to make people use encryption more would be to issue free SSL certificates with every new domain name sold.

Michał Tatarynowicz on November 14, 2010 8:16 AM
- SSL certs can be had for less than $10 these days. Cost is not an issue.
- Hardware impact is negligible.
- Browsers DO cache CSS and other resources, if the correct headers are sent. By default they are not written to disk.


obijan on November 14, 2010 9:05 AM
That's non-sequitur.

Better on-line identity will not solve problem of unencrypted traffic. Any identity solution will be vulnerable unless:


1.
Browser expects to get secure protocol and will refuse to fall back to an older one. Without this you can do MITM swapping new, secure protocol for old leaky one (e.g. replace Digest authentication with Basic auth).


2.Browser can verify identity of server using other/trusted communication channel (SSL does that by storing CA certificates offline). Without this you'll be securely sending your identity to an attacker spoofing a server.


1.All traffic has to be encrypted and tamper-proof. If you only protect identity, then attacker performing MITM can perform replay attack, change request parameters, steal data, etc. — you're still exposed to lot of risks.


kl on November 14, 2010 9:09 AM
It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?

Jo and Kang Su G. on November 14, 2010 9:49 AM
To all the comments that says that checking for the IP secure anything :

Firesheep is used with the attacker on the SAME network as the victim, and except if you use a full IPv6 setup to communicate to an IPv6 server they will have the same IP seen from outside the LAN.

Black Fox on November 14, 2010 9:54 AM
"build a better online identity solution than creaky old HTTP cookies. "

Yeah we already have that. It's called HTTPS cookies, supported by all browsers, secure and has negligible costs to implement.

HTTPS is our only practical solution. Even if this Unobtainable solution were to be invented today, have zero per user cost to implement, somehow magically be simpler than SSL, be universally accepted, we would still have to wait months if not years for it to supported well enough in every browser and web server.

We _have_ the solution, we know it _works_, we know _how_ to use it, all we have to do _is_ use it.

Warll Dressler on November 14, 2010 10:44 AM
"Lobby the websites you use to offer HTTPS browsing."

Jeff, have you ever tried:
https://stackoverflow.com/
?

It greets me with "The site's security certificate is not trusted!" and then further with Access Denied.

Isn't it ironic?

Dennis Gorelik on November 14, 2010 10:49 AM
HTTPS is not "overkill". In fact, given the somewhat broken certificate authority model that browsers impose, it's a bit underkill.

First of all, it's not too slow. See the links here - http://twitter.com/glyph/status/2958424706916352 - so there's no real reason to consider it 'overkill' if it's not taking up an unreasonable amount of resources.

Second of all, any "better" identity solution must necessarily involve crypto. So, why go to the massive amount of trouble to create a new cryptographic standard when the existing one is adequate? Keep in mind that if the stuff other than your "identity" isn't protected, your identity isn't really protected either. Active attacks aren't significantly harder than passive attacks on unencrypted traffic; if your authentication is encrypted but the commands you're performing aren't, an attacker could just as trivially capture your outgoing commands and modify them rather than modify your authentication.

Or, alternately, if you are concerned about people being able to masquerade as you, and you're using authenticated, encrypted connections, but the people reading your activity aren't, then the attackers can just spoof them instead of you.

So, turn on https on stackoverflow, please, and stop advocating for some mythical broken solution when a very real, working one already exists. The biggest problem here is that everyone thinks they understand the problem but very few people really do. So, while "Use HTTPS" is an oversimplification, it's the only message that is going to get through: if you say "Use HTTPS because there's nothing better but we should really come up with some better thing" then lots of people are going to take away "Oh, I should wait until there's a better thing, until then I'll just use HTTP and ignore the problem".

Glyph on November 14, 2010 12:15 PM
Several people have proposed combining and IP check with the cookie check. That doesn't work, however - many of these open WiFi routers are NATed, so the FireSheep connection will appear to come from the same IP that was issued the cookie. In fact, short of HTTPS or other similar encryption protocols, there is no solution. The required solution must be immune to forgery or to replay attacks; a give set of credentials must be unusable by anyone other than the sender and replaying a set of stolen credentials must not work. Given the stateless nature of HTTP, this is incredibly difficult to enforce, as the protocol doesn't provide a means to negotiate the necessary changes in magic numbers.

A solution could be approached using cryptographic signatures over some data including a timestamp and a nonce, but the current browsing technology doesn't make that a viable solution unless everything is done in JavaScript (thereby further breaking the Web).

Michael on November 14, 2010 12:31 PM
Hi Jeff,

Great post, thanks for clearly thinking this through and you no doubt understand most of the problem and what's happening to make it all possible.

Regarding your stance that Stack Overflow should not be SSL to protect the auth cookie, if there were some mechanism to somehow lock a browsing user to their session such that it couldn't be stolen/replayed/whatever by a passive attacker, what about active attacks? What about Man in the Middle attacks, where someone injects JS in to your page and performs actions as you by those means? This could happen on the local network, at your ISP, or by your government depending on what your personal threat model is. For protection against that, you need integrity and authentication, two things that SSL does very well. Add in privacy with symmetric crypto essentially for free (really, because you'd already be doing public-key operations to get authentication, and SSL/TLS session resumption make this quite fast after those operations are finished initially) - why not go with SSL for this?

Obviously I'm using Stack Overflow as an example here, not to poke and troll at you - I trust you can think about this idea as it applies to many other sites.

Do you have any thoughts on Google's SPDY (http://dev.chromium.org/spdy)? It stands to fix a lot of the problems with HTTP and streamline things. The security model there appears to just default to having everything be in an SSL channel, vs an option.

Thanks!

Ian Gallagher
Firesheep co-dev/co-presenter

Ian on November 14, 2010 12:58 PM
"If you have no other choices except unencrypted wireless networks, browse anonymously"

I think you need to be a little clearer about this statement. In the age of Facebook "Like" buttons on every damn page, if you browse with your regular browser that has the Facebook login saved, then you're sending Facebook cookies even as you browse other sites that are nothing to do with Facebook. To really browse anonymously you need to use an alternate browser with no saved credentials. Something like Opera is good because you can completely clear your saved data at the end of each session. (And even then, Flash cookies persist...)

Julian Melville on November 14, 2010 1:39 PM
I hardly think that all-encrypted traffic is 'boiling the seas'. As others write - it should be the bare minimum.

The second you tell everyday people that almost everything they read, write, click, view, etc are completely readable by anyone in the middle (governments included) they are noticeably, and understandably, upset.

Like most people, I don't have anything to hide, but that doesn't mean we don't value our privacy.

Maybe it doesn't matter to you if people know what products you like on Amazon, or how often you visit thinkgeek, or if you have a predilection for anime. Maybe you descend from the Dutch and never draw the blinds on your house. Good for you, but most people expect a modest amount of privacy and do not want someone else linking all their habits together (if they're lucky, it's just to sell them something).

Otherwise things become far too Orwellian for my liking. There's no need for 2-way tv's in them if you can glean all you need from someone's online life simply by capturing some of their traffic, or watching the websites they frequest.

SSL is cheap, and for a modestly-size site, SSL offloading firewalls are easy for an experienced sys admin.

Frank Black on November 14, 2010 1:55 PM
So, where do I go to lobby Stack Overflow and the other Stack Exchange sites to switch to https? While I'm only an infrequent user of the site, I can imagine other user's could be quite irked by the reputation hit that could be caused by someone hijacking their cookies - especially if they're using that reputation as part of their credentials/CV.

Stuart Jones on November 14, 2010 2:17 PM
SessionLock and SessionLock Lite (to a lesser extent) present a partial SSL solution: http://benlog.com/articles/2010/10/25/keep-your-hands-off-my-session-cookies/

George V. Reilly on November 14, 2010 4:54 PM
I assume then you never tried dsniff, which included a program (webspy) that did something very similar and has been around for a decade. It provided tools to sniff out sensitive data on a wired network.

As for a greater use of SSL for sensitive bits, if you want to make the web safer then push for better SNI (Server Name Indication) in servers and clients.

Joseph Scott on November 14, 2010 9:30 PM
Hey, does anyone else see the effects of bold text tag that didn't get closed properly in kl's comment? Or is it just me?

(I see it on latest firefox Ubuntu 10.10 and Windows XP, and I'm too lazy to inspect the html.)

http://i.imgur.com/4wAbm.png

David Czech on November 14, 2010 11:36 PM
Websites I've designed have used the technique Oskar describes to make a canonical string from data about the client, which is hashed to make a more individual session key. It works.

A hacker would need to fake a few details about a customer's active session to steal it. It's enough to not be the lowest hanging fruit.

HTTPS wouldn't be too much of a pain, except for maybe upgrading to a NIC that has full TCP IP and SSL chimney offload to accelerate it, and some possible problems with mixed HTTP/HTTPS content on the same page (ads), and that's probably the biggest barrier to wide-scale SSL adoption.

Luke

Lukepuplett on November 15, 2010 3:03 AM
Let's close this BOLD text first

Session ID's are saved through cookies, so if your security is based on sessions, it is based on cookies.

IP is pretty secure, but since the ip would come from the router / provider and not the computer, this adds nothing to prevent something like firesheep.
Also, people who use AOL have dynamic IP's, which can change at every request, breaking every site with IP-Based security.

User Agents are meh, it does add security, but not much.

Personaly I make sure that IF a session gets stolen, a person can't do TOO much damage, highly personal data (like credit-data) is only shown partialy and nothing personal can be changed without a password.

TL:DR
A website can't do much to prevent session theft so it is better to assume every session will be stolen and make sure nothing can go to hell if that happens.

JohanDam on November 15, 2010 5:12 AM
"That cookie is always broadcast in plain text every single time you click a link on any website. Right out in the open where anyone -- well, technically, anyone who happens to be on the same network as you and is in a position to view your network packets -- can just grab it out of the ether and immediately impersonate you on any website you are a member of."

(emphasis mine)

Very misleading. Jeff, i'm sure you understand how cookies really work, so i'll assume this is just poorly worded, but for the benefit of others reading: a single cookie will only ever be sent to a single domain, at most, and cannot be used to impersonate your identity on other websites.

Bobbykjack on November 15, 2010 6:53 AM

Hopefully that closes the bold. It does in the preview window.

@Jo and Kang Su G.
"It would seem this Firesheep would also work on wired connections within the same subnet. Is that not the case?"

It depends on the networking equipment. If it's a hub, then yes. If it's a switch or router, then no. Hubs fell out of favor years ago because Switches, for slightly more money, were considerably faster. Namely because a switch doesn't broadcast every packet to every computer, only to ones with matching addresses... or to the network gateway/router, which is responsible for sending the packet on to the next part of the network, or in home-use cases, to the public Internet.

Powerlord on November 15, 2010 8:28 AM
So does Yahoo mail simply not support HTTPS? I used Chrome + Use HTTPS (https://chrome.google.com/extensions/detail/kbkgnojednemejclpggpnhlhlhkmfidi) and when I logged in to mail.yahoo.com and provided credentials, I got this "The webpage at https://us.mc1103.mail.yahoo.com/mc/welcome?.gx=xxxxx might be temporarily down or it may have moved permanently to a new web address."

Hughdbrown on November 15, 2010 9:36 AM
What I'd be interested to know is how hardened the wired side of the typical coffee shop is. Encrypting the Wi-Fi traffic doesn't help you against that.

queisser on November 15, 2010 12:20 PM
@queisser: "how hardened the wired side of the typical coffee shop is." Considering most shops are not run by computer security experts I'd wager that the router is probably right next to the stereo controls for when they have to reset it.

Technically, I guess you would have to trust the coffee shop manager to not put a box in between the router and their internet connection in order to capture the traffic. But we have that problem everywhere already.

All of this reminds me of when I was giving a talk to some co-workers on network security. I fired up cain and able and showed them half the company's twitter, remote email, and facebook passwords within 5 minutes. The impact was everyone was a little bit frightened. BTW, the desktop machines were plugged into a router (not a switch/hub). The network guy had failed to do anything other than plug it in and it was defaulted to act like a basic hub (thanks Cisco). This was not a small company and they should have known better.

chris on November 15, 2010 12:45 PM
>a single cookie will only ever be sent to a single domain, at most,
>and cannot be used to impersonate your identity on other websites.

While that is technical true, most people don't understand how serious the lack of SSL is:

If I'm in such an open wifi (without you using VPN), I just have to intercept ANY http page you access and on the fly add some img-Tags into the unencrypted, unprotected html you download. That way I can make your browser send me many more cookies!

And another big big problem: Did you notice how IE sometimes warns you that secure and insecure traffic is mixed? Mostly because of horrible ad netwoks?
The attacker just has to modify that js that is loaded insecurely into a secure page and insert some javascript to steal the cookies and send them to me using GET-requests!

BTW: How about me offering you a cable with internet in my company and me saving all your network traffic and passwords to your extranet?

ALWAYS use VPN!


Bugmenot5 on November 15, 2010 1:05 PM
You could protect yourself online when using public WiFi networks by tunnelling your HTTP traffic through server over SSH.

See http://thinkhole.org/wp/2006/05/10/howto-secure-firefox-and-im-with-putty/ for how to set it up using putty + firefox

Grepmonster.wordpress.com on November 16, 2010 5:17 AM
Some websites won't do HTTPS for all traffic since they rely on Google Adwords for sponsorship. However Adwords won't allow HTTPS based advertisements.

Can someone convince Google to offer HTTPS? Otherwise they are encouraging bad paractices

Cmankowski on November 16, 2010 8:02 AM
What we really need is some way to encrypt just the cookie. I mean, seriously, I don't need my images, my css, my js or even my html encrypted, just the login.

Jeffrey Davis on November 16, 2010 9:28 AM
Before I get totally blasted off the internet, I suppose I should clarify that the the transmission of login/cookie needs to be encrypted, not just the cookie value itself. Encrypting the cookie value wouldn't really help. Still, it would be nice to be able to separate that process from the transmission of regular data, which often has no need to be encrypted.

Jeffrey Davis on November 16, 2010 9:37 AM
Now I'm quite ignorant about good http security but it seems to me that using different passwords for each website would help a little. Not much but at least only those websites that you visited from a given WiFi hotspot would be vulnerable.

I really like the open soruce KeePass utility as it will generate random passwords and I can use a hot key to fill in my userid and password.

One complaint though is websites that don't allow a 20 character password and don't ell you that it's too long. So you register with a 20 character password which is truncated and now you have to figure out what the length really is.

Of course folks reading this blog undersrant this issue. The masses have not a clue.

Tonytoews on November 16, 2010 2:11 PM
Does this "trick" apply if the cookie pertains to an SSL/TLS session? In other words, if I access my bank account - is the cookie still in the clear - not encrypted by SSL?

Mystagogue on November 16, 2010 10:16 PM
@Mystagogue:
No, SSL/TLS negotiation happens before most HTTP headers, including Cookie. TLS has a possible exception for the domain name (Host?) header, but support for that is not mandatory... Apache web server, I'm looking at you!

Also, the cookie specification allows you to specify that cookies are only sent if it is a secured transmission.

Powerlord on November 17, 2010 8:35 AM
@Jeffrey Davis - There's a number of issues with that:

Lets look at a http get request (using Fiddler2).

-------------
GET http://www.google.com/search?hl=en&q=cookie&btnI=I%27m+Feeling+Lucky HTTP/1.1
Accept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, */*
Referer: http://www.google.com/
Accept-Language: en-us
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;)
Accept-Encoding: gzip, deflate
Host: www.google.com
Connection: Keep-Alive
Cookie: PREF=asdf=1234&abc=123; NID=asdf=1234&abc=123
--------------

The important part in the request is the query string, and the cookies.

Without SSL, others can see everything.
With SSL, others only see 'www.google.com'

Cookies are, in reality, just another header in the list of http headers.

Further, most authentication cookies and/or cookies that hold identifying information should already be encrypted by the server and only decryptable by the server, and there's already a mechanism for cookies to only transmit the cookie when the connection is secure.

The authentication cookie for a typical web stack might look like:
745370B77DC347648F307DCFC800CD7BBF584A030D6477337ADD77670B77654222560F77A0DA36A4F5732D2AB867C828B22FC7777D05047B74AA08373FA70500DAFF2D2D0B7B7356BD22BAB0CA48DBF6D4D7872C5062DD8788B376F757B62D26D27F83AF777CD767B7427DDCA0DAFD82DD74DDA4

So if you can see the transmission in plain text, even with encrypted cookies, you can still become the person. The web's http protocol is stateless in the sense that between requests, a server has no ongoing connection with you. To achieve an illusion of state, the client holds the state, and cookies are a key ingredient to make it happen. Steal the state, become the person.

So maybe you're saying you want to open 2 sockets per request? The first socket is the encrypted channel for transmitting the headers and sensitive information, and the 2nd socket is unencrypted. The web server would then have to combine multiple incoming requests, do something, then split the result into sensitive and non-sensitive information. The client then recombines the two streams and presents something to the user.

I'm making a stab in the dark, but I recall the most expensive part of SSL is establishing the connection. So if you're already making an SSL connection, why wouldn't you just use that and avoid all the complicated and error prone splitting and recombining? Not to mention the re-architecture of every web server and every web client to support a new split protocol, and hoping that every web developer gets it right and never accidentally transmits sensitive information insensitively.

Right now it's easy for a web client to display the green bar/padlock icon.
if(All requests for content SSL) -> secure!
if(no SSL) -> not secure
if(partial SSL) -> not secure.

The beauty of SSL is that it encrypts everything*. Your web client can be sure it's talking to the correct web server, and nothing* in the middle can know what you're doing.

Frank Black on November 17, 2010 12:59 PM
| Yes, you can naively argue that every website should encrypt all their traffic all the time, but to me that's a "boil the sea" solution.

The sea should be boiled, because guess what, HTTPS is your mystical "more secure identity protocol than ye olde HTTP cookies"

| I don't actually care if anyone sees the rest of my public activity on Stack Overflow; it's hardly a secret.
Nobody is worried about the publicly accessible information being read.

| Encrypting everything just to protect that one lousy cookie header seems like a whole lot of overkill to me.

I don't want to be profiled in a database at my ISP or local neighborhood government cyber-spy agency of what websites I goto, what content I've read, or what my general habits are, that's between me and the website. The comment I've posted here, my ISP knows that I've done that. I don't have a problem with "Brian G. -- Content" being on this public website, but I don't want it to be hijacked along the way (from various nodes that carry the packet), nor do I want to get profiled.

Brian G. on November 18, 2010 8:34 AM
Don't forget about ARP spoof when connected to a switch/router, you can still intercept those packets if you arp poison.

David Czech on November 18, 2010 5:12 PM
Using SSL across an open network is simply not enough. Moxie Marlinspike has outlined a relatively easy way to hijack SSL sessions on an open network (http://www.thoughtcrime.org/software/sslstrip/) with his freely downloadable tool. Simply put: Don't trust open networks.

Kevin Scheetz on November 18, 2010 8:11 PM
Two things: a two-part authentication verification scheme is always preferable to a single-part scheme. Those suggesting IP as the second part above are on the right track: you want IP + HTTP-Forwarded-For value; this allows a user to access your site securely over a protocol-supporting proxy server.

Second, all the talk about SSL is protecting the cookie *in transit*, but not in rest. You are not protecting yourself from an XSS-initiated session hijack, nor from a disk-read or memory-read based session hijack. These are "harder" than the simple wire sniff attack, so SSL is a solid first step, but don't believe it gets you all the way there.

Overall, taking SSL + two-part identification gets you a whole lot closer to secure (based primarily on how well the user secures their end of the conversation), to the point that neglecting to do so should really be considered a security failure on your site.

From the user's end, never, ever, ever do anything on an open wireless connection (or any unknown network). Always use SSL where possible. Should go without saying, but obviously the world needs more education on the matter.

Tom Dibble on November 21, 2010 12:33 AM
Insightful article. Now we need an extension to show people how easy man-in-the-middle attacks against SSL over rouge wireless access points are :)

jagwio.blogspot.com on November 22, 2010 9:18 PM
Just use HTTPS-everywhere addon for Firefox and you will be fine. Almost all sites supported.

If you use any other browser, you are screwed :/

Anuj More on November 23, 2010 8:59 AM
Leo LaPorte has made a good suggestion. He suggests owners of hotspots use protected wifi so traffic is encrypted. Since a secure password is not just not needed but undesirable it should be included in the network name--for example: networkname(password=password).

spookie on November 25, 2010 12:32 PM Sphere: Related Content