The Firefox add-in Firesheep caused quite an uproar a few weeks ago, and justifiably so. Here's how it works:
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
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.
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? 
cheers!
@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
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.
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 
Thank you Jeff for this amazing email. We can actually can call it “Firesheep Anatomy” 
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
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
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.
… what about HTTP Digest Authentication?
@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.
Firefox users should probably consider installing HTTPS Everywhere: https://www.eff.org/https-everywhere
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.
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.
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.
Mikekelly85 is right, you should have mentioned HTTP Digest.