Firesheep Demonstrates The Need For SSL

There’s been a storm of discussion over the past 72 hours about Eric Butler’s Firefox extension Firesheep. To summarize, it’s a Firefox extension that facilitates session hijacking by packet sniffing for data from certain websites. As far as software goes, it’s more evolutionary than revolutionary, at its core it’s a packet sniffer. The evolution is the pretty UI which makes it trivial to hijack someone’s session (he really did do a good job on the UI, it’s so easy a child could use it).

It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure. Anyone can read what’s going across the wire (that includes WiFi) when it is sent unencrypted. If your browser can interpret and use the information to let you browse Facebook, Twitter, etc. so can any browser, on any computer. It’s that simple. Firesheep only supports a handful of sites, but adding support for more sites isn’t difficult. If your favorite website hasn’t been done yet, I expect it will be soon enough.

How Do You Protect Yourself?

The best way to protect yourself is to demand that websites that hold private information use HTTPS from the moment you log in until you log out. Short of that, the best you can do is use a Firefox extension like EFF’s HTTPS Everywhere to force your browser to use HTTPS. This won’t work everywhere as not every web server even has HTTPS working, but many secretly do. They sometimes use HTTPS for certain things like login, then use insecure HTTP for the rest of your visit. That’s so your password isn’t transmitted in plain text. Protecting a password is important, but if the session is insecure anyone can intercept what you do. HTTPS Everywhere works by rewriting all requests to many popular sites to use HTTPS ensuring your privacy and security through the length of your visit. Some websites will have minor issues. For example Facebook Chat is impossible to support right now due to it not working via HTTPS. The rest of Facebook however works.

For more advanced users, HTTPS Everywhere lets you write your own rulesets for sites it doesn’t support.

How Do Websites Protect Their Users?

It’s very simple. Use HTTPS for the period a user is logged in, not just when authenticating and submitting sensitive data. Sure it’s a little slower and requires more hardware, but scaling HTTPS these days isn’t nearly as difficult as it was just 5 years ago. In 2 years it will be even easier. Google went as far as forcing HTTPS upon all of Gmail users. Binding a session to an IP address is fussy and largely ineffective due to NAT, WiFi hotspots and mobile services that can cause an IP to just change with little/no notice. It’s not effective security. It’s better than nothing, but it’s not a fix.

Google could make a huge difference by supporting SSL in Google AdSense, something I’ve called for since 2008. Google has supported SSL with Google Analytics for some time, but they have lagged with rolling out support in other services. Lots of websites monetize with AdSense and this is just another reason websites put off supporting SSL. Other ad networks should do the same. Google AdSense has the least barrier to entry since they serve their text ads off of their own infrastructure, vs. creatives hosted by other parties like some smaller ad networks. One could argue having third-party code inserted on a page mitigates security but it would still be a major improvement over the current state of affairs and would prevent simple session jacking.

9 thoughts on “Firesheep Demonstrates The Need For SSL

  1. Excuse me? Encryption != identity, and web developers cannot afford SSL certs and all the hoops they have to jump through to prove a worthless identity just in order to have encryption on their site. The CAs are to blame, not the web developers. They have a business model where HTTPS means money and the HTTPS login problem is *never* going to go away until encryption is offered for free, and by default on servers and browsers alike (like Google’s SPDY protocol).

    Perhaps Mozilla should be looking at itself for how it rectify this problem by supporting SPDY, some other initiative, or getting rid of SSL cert errors (which have never saved anybody, anywhere from fraud).

    Do you know what I have to do to use SSL with my web host? Direct all my users to (example) h++ps://web00.secure-secure.co.uk/mywebsite.com/ because of the stupid “identity” needing to be shared between customers when all I bloody want is encryption, not a verified identity.

    Don’t be pointing your finger at us web developers until you’ve acknowledged the broken system we have to work with. I don’t have the money Google has to afford SSL everywhere. I just want encryption for free, and that’s partly your responsibility to solve Mozilla.

  2. At worst encryption without proof of identity, is a small increase in security. The reliance on the SSL cert model has slowed the use of encryption on the web to a crawl.

    A new model for web encryption is needed. Something similar to SSH is a good start.

    And remember: #SelfSignedCertsAreNotEvil

  3. @Kroc Camen: I won’t disagree with you. I’ve argued that several times before on this blog. However at $10/year for a basic validation cert (I bought one from namecheap.com over the weekend), it’s hardly a burden for almost anyone who can afford hosting. Heck this blog has it’s own cert. Check the contact page.

  4. @Robert: Good find! I have not seen prices that cheep before.

    There was a fight to get the “padlock” removed from Firefox (replaced by Larry), because encryption is not the same as trust. There needs to be an equal push to keep the S in https for verified identity, but encryption to run over normal HTTP. And it needs to happen soon, if Firesheep is anything to go by. My host still hasn’t upgraded to PHP 5.3. If we have to have a new protocol and updates to server software, it’s going to be 2015 before we get encryption-by-default on the web.

  5. Ah, spoke too soon. The $9.95 offer is only for root. In my case, I need an SSL for subdomains too. Then we’re talking $125.88. That is not what I class as acceptable for me, or the average Joe who wants to throw up a PHPBB of his own.

  6. @Kroc: Another option is StartCom which is free. Do note every hostname with an SSL certificate requires its own IP address, which ISP’s generally charge $1-2/month for (don’t be shocked if that goes up when the IPv4 pool dries up). That’s $12-24 right there.

    That’s why most smaller sites that use SSL consolidate subdomains to one or two and just make good clean of paths. It saves money. I’ve got several things tucked away on my domains with SSL certificates.

  7. Encryption without authentication is basically useless, things might change with Quantum gidley-fiddly but apart from that I see no reason to underetimate MITM possibilities.

  8. >It’s actually surprising to me that so many people are shocked by what this demonstrates. Even those who claim to be technically literate seem taken back. Insecure sites by definition are insecure.

    Among people, I have read, it was not about the fact it was insecure, but more about the “contrat social” game changer. It’s not really about security but about contextual security. I’m surprised by the reactions of people too, but more because they thought there was an unwritten contrat social in any situations. Being at a friend’s house and respecting privacy of each other is one thing, being in a cafe or a conference is another thing. Not the same level of security and impacts.

Leave a Reply

Your email address will not be published. Required fields are marked *

Connect with Facebook

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>