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.
Anyone who cares about website performance comes to the quick realization that ads are a huge slow down. They are also the source of income for many websites. I somewhat casually mentioned back in December that Google was beta testing an async Google Analytics call. I found a bug in the early version but since updated it works extremely well and is non-blocking. It’s rather awesome.
<script/> it’s blocking. It would be nice if AdSense would have an asynchronous version that lets you specify an element where it could insert the ad when loaded by passing an element object or id. It could then be non-blocking and speed up a large number of websites thanks to its popularity.
I can’t find any reason this wouldn’t technically be possible. It would make setup slightly more complicated, but the payoff for those who choose this implementation would be a faster website. Perhaps Steve Souders could poke the AdSense folks for a faster solution.
I’m also still hoping for SSL support. Another place where Google Analytics is ahead.
Google’s implementation of AdSense never ceases to amaze me. AdSense has been a major source of revenue for many websites for a few years now and has allowed many businesses to succeed where previously they would have had little chance. It’s a great program and I appreciate how it allows websites to monetize content quickly and with little effort. That said, I’m still so confused by Google’s implementation. It just doesn’t make much sense.
Since July 2007 Google AdSense has had the ability to crawl login protected pages so that it can scan (and therefore provide relevant ads) to pages behind logins. This is great since many pages on sites, in particular social networks where the the majority of page views are post-login can now be monetized.
Despite this progress, Google still doesn’t provide an SSL version of AdSense, so while the page itself can be served over SSL, the ad isn’t. This is problematic since the browser will alert the user that the page is not entirely secure. I really don’t understand why this can’t be done. Google does appear to scan these pages as the ads are relevant, so I don’t think the crawler is the issue. They just don’t want to serve ads over SSL.
Come on Google, the web would be a much more secure place if AdSense supported SSL. It would remove a big reason for sites to not use SSL in places that they should.
For those who would argue that putting third party ads on an SSL page defeats the purpose, that’s only partially true. Yes in an ideal world there’s no third party content on an SSL page. In the real world, Google already supports using SSL with Google Analytics (as do virtually all other analytics services), and you can bet almost any SSL page you access has some analytics on it already. This is no worse. If anything it’s better since unlike Analytics, the nature of the service involves much less recording of user behavior.
By not supporting SSL it’s just encouraging sites to not use it in places where a users privacy and security would be better off with it.