In only a few short weeks, Firesheep has captured the attention and interest of hundreds of thousands of people around the world, and has spurred a lot of great discussion. This is the third in a series of posts highlighting and responding to topics I found most interesting.

Previous post in series: Idiot Shepherds

This post was co-authored by Ian Gallagher.

The risks of insecure websites have been known for years, yet over the years little to nothing has been done about what has become an incredibly widespread problem. In the three weeks since Firesheep was released, there has been some encouraging news that companies are waking up to the reality that HTTP is dead, and that full end-to-end encryption (HTTPS/SSL) is no longer optional but rather a requirement of doing business online.

Fourteen years after launching, Hotmail has finally announced support for SSL. While this is a huge step forward, it is currently implemented as an opt-in feature, meaning all of Hotmail’s 300+ million users have to know to turn the feature on, which is unlikely. Hopefully users won’t have to wait another decade for Hotmail, other Microsoft services, and other websites to implement mandatory SSL everywhere. In January of this year the EFF commended Gmail for making all accounts use SSL by default, and urged other websites to do the same.

The list of website handlers included with Firesheep represents a variety of sites that we frequent including some that require unique processing to obtain session/user information. Of these sites, we’ve heard that GitHub, Slicehost, DropBox, and Pivitol Tracker have all taken steps to protect their users since Firesheep was released. Firesheep and any similar tools are no longer be able to identify newly issued sessions on these websites, but users of these services should clear their cookies to ensure that no insecure session is left behind that could be potentially sent out.

Although most of the media attention has been focused on this list of sites, especially Facebook, this remains an extremely widespread problem. Illustrating this point, numerous people have already posted handlers they’ve written for additional websites. Other tools such as Hamster don’t require site-specific code and are capable of hijacking any insecure website they spot. A generic handler for Firesheep could accomplish this too. If you’d like to write a new handler to test your own security on the sites you frequent, see here for basic information.

If you work for a company that recently adopted SSL, or know of another company that did, please let us know. We’d like to learn more about why companies choose not to be secure from the start and what problems are encountered while making the switch. The EFF just posted a great guide on How to Deploy HTTPS Correctly for anyone who is looking to do so.

If one of the websites you frequent isn’t secure, let them know that your privacy and security should be a priority. A campaign demanding that the world’s top 100 websites support HTTPS was recently launched by human rights organization Access. Sign their petition and help spread the word.

Firesheep is not the cause or source of this problem. The clock started ticking for companies to protect their users the day they launched, not the day Firesheep was released. Facebook is already going on 6 years of insecurity, and counting.