Firesheep

HTTPS offers end-to-end security between the user agent and the web server. This works well with web sites that are offered uniformly over HTTPS. However, at the time of Firesheep's publication, many web sites employed HTTPS only during the login process, then reverted the user's session to unsecure HTTP.

This can be addressed in two intersecting fashions:

• First, the site can offer itself uniformly over HTTPS.[7][8]
  • As an adjunct to this, the site can advertise the HTTP Strict Transport Security (HSTS) policy, which will be honored by user agents implementing HSTS.[9]
• Second, the user can employ a browser extension, such as HTTPS Everywhere[10] which can help ensure uniform HTTPS access to certain websites (the list is extensive), whether or not the site offers itself uniformly over HTTPS by default or employs HSTS. Also, in Mozilla Firefox 4 (or later) as well as Google Chrome (version 4 and later) the user may natively hand-configure the browser to treat the site as HTTPS-only.[9]

The end-user may also employ a virtual private network to encrypt all the traffic transmitted by their computer over the public Wi-Fi link. Users can obtain a VPN through several approaches: their employer may provide one to access their corporate network, they may host a VPN (for example, OpenVPN) on a personal server, or they may purchase VPN services from a provider (see Comparison of virtual private network services).

However, one must then trust the VPN's operators not to capture the session cookies themselves. That is particularly a concern with the Tor network, for which anyone can set up an exit node and monitor traffic going to non-HTTPS websites.

Local Wi-Fi networks may be configured with varying levels of security enabled. Using a Wired Equivalent Privacy (WEP) password, the attacker running Firesheep must have the password, but once this has been achieved (a likely scenario if a coffee shop is asking all users for the same basic password) they are able to decrypt the cookies and continue their attack. In addition, the WEP protocol has been proven to have severe flaws which allow attackers to decrypt WEP traffic very quickly, even without the password.[11][12] However, using Wi-Fi Protected Access (WPA or WPA2) encryption offers individual user isolation, preventing the attacker from using Firesheep from decrypting cookies sent over the network even if the Firesheep user has logged into the network using the same password.[2] An attacker would be able to manually retrieve and decrypt another user's data on a WPA-PSK connection, if the key is known and the attacker was present at the time of the handshake, or if they send a spoofed de-authenticate packet to the router, causing the user to re-authenticate and allow the attacker to capture the handshake. This attack would not work on WPA-Enterprise networks as there is no single password (the 'Pre Shared Key' in PSK).[13]

On a WPA / WPA2 or Ethernet network, an attacker on the same network could still access session cookies of an unencrypted HTTP connection with a man-in-the-middle attack like ARP spoofing.