This was certainly an interesting day. As I told TechCrunch:

I went back and forth trying to predict what the reaction might be. Initially before Firesheep was completed I thought there might be moderate interest, but then after doing more research found a lot of one-off articles discussing this same issue that were essentially ignored. I certainly never expected Firesheep to be the #10 trending search on Google in the US.

Most importantly, I certainly never expected there would be this much attention all at once, and within the first 24 hours.

I’ve received a ton of great messages from people who are happy that this issue has finally received widespread attention, so after day one I’m happy with the result.

Since being released just over a day ago, Firesheep has been downloaded over 129,000 times. Firesheep has consistently been one (if not more) of the “Top Tweets” on Twitter, on top of Hacker News, was at one point the #10 trending search on Google in the US, and is the second suggestion on Bing when you start typing “fire”. Firesheep has been mentioned on countless blogs and news sites in numerous languages, and has received almost universal praise.

The first bug reports have started rolling in:

• "Backend exited with error 1" — This happens on Windows when you stop capturing. This message doesn’t actually indicate a real problem and can be ignored. This was a known issue that I wasn’t able to get to before the ToorCon release.
• "Run --fix-permissions first" — This problem appears to affect only Mac OS X users who are using FileVault. The current release of Firesheep is unfortunately incompatible with FileVault.
• "Funky custom tool bar icon explosion." — This one is actually a bit amusing.

All of these issues will be fixed in the next release.

There have also been a few common problems:

• No results on some Windows systems — Some users have reported that they aren’t seeing any results even when on an open network that has known insecure traffic. This may be because the wrong interface is selected. Click the gear icon at the bottom of the Firesheep sidebar and choose Preferences. From here you’ll be able to change the interface Firesheep listens on.
• Sidebar not displayed — If you’ve installed Firesheep but don’t see it, click the View menu then select Sidebar then Firesheep.
• Install error claiming Firesheep is not compatible with your version of Firefox — Several people ran into this problem because they were unknowingly running out of date (and insecure) versions of Firefox. Apparently Mozilla’s auto-update system is leaving some people behind. Currently the latest version of Firefox is 3.6.11. Firesheep is not yet compatible with the 4.0 beta.
• Compile error on Linux — Firesheep is not currently supported on Linux and will not work. Patches/pull requests gladly accepted!

Keep an eye on this blog as well as my Twitter feed for updates on these issues and other new features.

The real story here is not the success of Firesheep but the fact that something like it is even possible. The same can be said for the recent news that Google Street View vehicles were collecting web traffic. It should not be possible for Google or anybody to collect this data, whether intentional or not. Going forward the metric of Firesheep’s success will quickly change from amount of attention it gains, to the number of sites that adopt proper security. True success will be when Firesheep no longer works at all.

An across-the-board improvement in website security will take time, but people are beginning to see the risks of using insecure websites right now. Unfortunately there has been a lot of misinformation about what people can do to protect themselves. The rest of this post is co-authored by my friend Ian Gallagher (@cdine) who presented Firesheep with me at ToorCon. Ian is a professional software security consultant with Security Innovation in Seattle. Below he explains many of the problems faced when trying to stay safe online, expanding on information that was included in our talk but not in my Firesheep announcement blog post.

Finally if you sent me an email, left me a voice mail, or posted a comment and haven’t received a response, please don’t take it personally. I’ve been sick, traveling, and overwhelmed, but will get back to everyone as soon as I can.

Background on HTTP Session Hijacking

HTTP Session hijacking, as a vulnerability, is nothing new in the year 2010. It is a security vulnerability that people have been aware of for quite some time, with notable tools and papers existing at least since 2004 on this exact subject. OWASP (The Open Web Application Security Project) categorizes the issues responsible for HTTP Session Hijacking in to one of it’s Top 10 Web Security Risks, “A3: Broken Authentication and Session Management”.

Firesheep is by no means the first tool to exploit this issue and raise controversy. "Ferret" and "Hamster" were a pair of tools released by Errata Security in 2007 which let users exploit Sidejacking attacks easily (well, easily for geeks, and undoubtably easy for attackers). In 2008, "Cookie Monster" was released by Mike Perry which lets you again do this same attack. Last year, (around May 2009) Azim Poonawala released the tool FBController which yet again exploited this same issue, though this time specifically targeting Facebook. Very little has changed after each of these tools were released. They got their media hype, and then people forgot or didn’t care. For the most part, the tools were only used by tech-savy people, hackers and geeks.

Firesheep

Firesheep is doing the exact same thing as these other tools, but with a simpler user interface. Firesheep is more generic than FBController, but it still needs to be aware of what sites to target.

Because of its simplicity, Firesheep has already succeeded in demonstrating the risks of insecure websites to a much wider audience than any previous tool, in a single day.

Why is it hard to stay safe?

Websites that don’t have properly designed security architectures and implementations can make it very difficult for users to protect themselves. There’s a few levels of failure here that are worth noting.

• Complete absence of SSL/HTTPS — This is rare nowadays for popular sites, but it’s not unheard of by any means. Until recently, Foursquare fell into this category. Naturally, if you use such sites you’re exposing everything needed to identify your session with the site, potentially even your password. This is particularly bad when you consider many people use the same password for many different accounts. It’s terrifying to think that something as mundane as a Foursquare password could get you in to that person’s email, or even financial websites.
• Charging for SSL - GitHub and Evernote are some examples where you must pay to have full-session SSL. We have not confirmed if this is implemented properly once you pony up the cash but can confirm that on GitHub a free account that is associated with a paying organization leaves that entire company at risk. A basic expectation of privacy should not be a premium feature. UPDATE: GitHub contacted me with a correction: Until recently paid accounts/repositories had no additional protection over free accounts/repositories. Fortunately all GitHub accounts and repositories (paid and free) are now secure.
• Forced SSL/HTTPS for posting of Login/Password credentials only - Most big sites are in this bucket. Facebook, Twitter, Github, etc. Years back, people realized that sending usernames and passwords in plaintext was a bad idea, and so everyone started encrypting the transmission of those particular assets, and boasting how secure they were because they use SSL with 128-bit encryption or whatever it may be, and pictures of locks everywhere. These sites may serve other content over HTTPS if you explicitly request it, but they’ll rarely be opportunistic about serving content over HTTPS. These sites fail to protect you because after you’ve authenticated, you’re issued a cookie that identifies you throughout your browsing session, but if you think about it that’s just as good as your username/password for 99% of the time.
• Full HTTPS for everything — Some sites support full encryption everywhere, but don’t implement it properly by failing to set the “Secure” flag on authentication cookies, negating most of the benefits and leaving users at risk. What that means is that any time you type the URL (e.g. “manage.slicehost.com”) into your web browser (without explicitly typing https:// beforehand, which people rarely do) you will inadvertently leak your cookies with that first request, prior to being redirected to the HTTPS page. Slicehost and Dropbox are good examples of this mistake.

You can’t simply avoid visiting the sites that are being attacked here. There’s an enormous amount of mixed content on the web today, such as the Facebook “Like” button, Digg’s “Digg It” button, twitter widgets, and even embedded images that are hosted on Flickr or other photo sharing sites. Every time you access any web page that includes any of this content, your browser also sends any authentication cookies you have with the request to pull down the widget. TechCrunch is a great example of this, every article has lots of little widgets to share it on numerous social sites.

Even if you’re proactive and think to log yourself out of a website, this rarely does anything but delete the cookies from your web browser - meaning any stolen copies of them are still going to work for accessing the website. Twitter, Amazon, Foursquare, Github, Flickr, Yahoo, Windows Live (Hotmail) and many others do not properly delete your session from their severs when you use their “Logout” features. Facebook, while having other problems, does appear to properly delete sessions on their servers when you “Logout”.

People forget things. It’s easy to be logged in to many of these services, sleep your laptop, and wake it up somewhere where it will instantly associate with an open access point and start spewing your cookies over the air. Hackers even fall victim to this at hacker conferences where everyone knows they shouldn’t be doing anything on the wifi. The DEFCON Wall Of Sheep is a prime example of this.

Suggestions to help protect yourself right now

While companies are implementing fixes (described below) you can do a few things to increase your level of security, but there’s no silver bullet (aside from stopping use of the services which you don’t want hijacked.)

• HTTPS-Everywhere - This is a Firefox extension created by the Electronic Frontier Foundation which makes Firefox use only HTTPS connections for certain websites. Like Firesheep, it only works on a defined list of websites, so it won’t protect you if you use any websites that it doesn’t support. It does not appear to be immediately simple for users to add sites without some development experience. HTTPS-Everywhere is well respected for doing what it claims to do safely.
• Force-TLS - As mentioned earlier, some websites support SSL but don’t implement it properly, leaving you at risk. This Firefox extension is similar to HTTPS-Everywhere but allows you to specify your own list of domain names to force encryption on.
• VPN - In some situations a VPN (or something similar such as an SSH tunnel) can be great. All traffic sent through a VPN is likely secure from your computer to the VPN server. But be aware that this is not a silver bullet and there are potential problems. See below for our warnings on using a VPN.

Things NOT to do (debunking suggestions from other people/sites in response to Firesheep)

Stop using open WiFi

In response to Firesheep, lots of people are quick to say “Don’t use open wifi”. While open wifi is the prime proving ground for Firesheep, it’s not the problem. This isn’t a direct vulnerability in wifi, it’s the lack of security from the sites you’re using. Abundant, free, open wifi is great to have, it can be very useful. Low-risk activities like reading the news, looking up a nearby business or finding a bus route can be done without being logged in to such sites and risking loss of any important sessions, for example.

A password-protected (WPA2) wireless network or even a wired network just requires that attackers perform one more step to carry out this attack. This might be ARP poisoning or DNS spoofing, neither of which are difficult to carry out. Go and download Cain & Abel and try it out on your network, it’s not that much harder than using Firesheep, and it’s been around for nearly a decade. There are other tools that’ve been around longer.

Another problem is that anyone who has your wireless password could set up their own rogue access point. If they have the stronger signal than the “official” access point everyone in the room will automatically connect to it instead and begin sending all their traffic to the attacker. WPA2 Enterprise was designed to solve this problem by allowing clients to verify the authenticity of the access point they are connected to. Unfortunately in addition to being very difficult to configure, a flaw known as "Hole 196" was recently discovered allowing users on the same network to spy on each other.

For these reasons it’s not very helpful to just enable WPA2 and write the password on the wall. Doing so might actually give users a dangerously false sense of security.

Use Tor

Another very bad suggestion is to use Tor.

Tor is designed to protect the identity and location of you, or more specifically, the computer you happen to be using. It does not protect what you are actually saying. Think of a whistleblower: someone who doesn’t want their identity revealed for fear of retaliation but who has a message to spread. Tor is perfect for this scenario, and has likely played a huge role in the recent success of WikiLeaks. For the purpose of protecting free speech, we love tor.

Tor works by bouncing your data all over the world to make tracing it back to you unfeasible if not impossible. After the final bounce your traffic lands on an "exit node", which relays it out to the Internet. Exit nodes are a lot like an open wireless network in that they are often run by random people who decided they're willing to share their connections with strangers in order to help them out.

If the operator of an exit node were to run Firesheep or a similar tool, they would be able to compromise any Tor user who was accessing insecure websites through this exit node.

Use a VPN/SSH Tunnel (Without known risks)

While we metnioned that VPNs and SSH tunnels can be helpful just above this, we want to emphasize that it’s just pushing the problem to that VPN or SSH endpoint. Your traffic will then leave that server just as it would when it was leaving your laptop, so anyone running Firesheep or other tools could access your data in the same way. These are solutions that require at least some understanding of networking and risks at hand. A blind suggestion of “Use a VPN” doesn’t really solve the problem and may just provide a false sense of security.

Another problem with VPNs is that they don’t work all the time. Sometimes they just disconnect, and your traffic is all routed over your normal interface without any notice. The built in VPN clients on OSX, the iPhone, and iPad are particularly bad at this.

How do website operators fix the problem?

The only correct solution to this problem is true end-to-end security. On the web, this is called HTTPS or SSL/TLS. When SSL is used properly, all traffic is encrypted (unreadable by attackers) and integrity checked (can’t be modified by attackers) from your web browser all the way to the website’s datacenter (either their actual web servers, or specialized network equipment such as SSL accelerators/load balancers).

Designing with security as a requirement, rather than bolting it on after the fact, is also important. While it’s not fair to say this is always what happens, it’s not uncommon for sites to be quickly designed and developed while letting security slip by at a lower priority than other things. Design such that when you scale out, you can scale out securely. Adopt and adhere to a Secure Development Lifecycle process to ensure that security is considered at all points during a product/site’s lifecycle.

Reasons operators may say they can’t do the above

• Typically the response to implementing SSL for everything on your website has been that it’s a big performance hit. There’s an awful lot of debate about this, but there are a number of sites that require HTTPS for everything, most notably Google’s Gmail service went 100% SSL earlier this year. While it’s true Google has an amazing engineering team and impressive resources, they outline a system that should be approachable by many other sites.
• Lack of IP addresses for SSL hosts. In the past, an SSL service required a dedicated IP address. This isn’t true any more with the advent of Server Name Indication (RFC 3546) and improvements in TLS.
• Ignorance. Many people believe they are doing things correctly when they simply are not. Forcing HTTPS for everything but not marking cookies as secure is key example.

Many companies make a business, not technical, decision to not implement security due to either perceived or actual costs. It is our opinion that turning a blind eye to customer privacy and security is never good for business, and we hope the people making these decisions will begin to agree.

This post has been updated since it was originally posted.