Firesheep - What you need to know.

So, what do you need to know about Firesheep?

What it does

Firesheep makes it trivial for any Firefox user ( Windows or Mac, Linux coming soon ) to do a "Sidejacking" attack on the browser session of anyone on the same non-protected* wifi network that the attacker is on. For example, Facebook is one of the sites that is vulnerable ( and by far the biggest name in terms of actual usage ). So, if you're at a coffee shop and someone has Firesheep installed, and you log into Facebook on your laptop, they get a notification on their laptop that you've just logged in, with your profile picture. They click on it and !Bingo! they can instantly do whatever they want, as you, to your Facebook account. That's it in a nutshell.

The developer's post on it is here: http://codebutler.com/firesheep

What sites are vulnerable?

The current list is here: http://github.com/codebutler/firesheep/tree/master/xpi/handlers/

The only notable exception is Google. Google has secured themselves from this vulnerability by locking up their services with SSL. More on this in a second.

What do you mean by that "*" in the first part?

It's easier actually to define what I don't mean. WPA2 ( The "2" is important ) wifi networks are NOT vulnerable. WPA, WEP, WEP2, and open networks ( and whatever other kind you might have that doesn't use WPA2 ) ARE vulnerable. Basically the entire point of WPA2 is to protect clients from other clients.

So, for example, there are 3 coffeehouses within a 3 minute drive of my house. One has a WPA2 network. The other two don't. Guess where I'm getting a Latte?

So, as a user, if you're WPA2, good to go.

What if I'm not on a WPA2 network?

Well, then you need to be careful. What do I mean by "careful"? Use Firefox with the SSL Anywhere Addon. Or a Tor network. Or if you have the means, VPN. More about some options here: http://news.cnet.com/8301-27080_3-20008217-245.html

Is this a lot of technical mumbo jumbo? Yes. Do you want a 15-yr-old hoodlum posting bestiality pictures on your profile the next time you want to surf over a mocha? Probably not.

At the end of the day, though, these are all just throwing a carpet patch over a wine stain in terms of the real behind-the-scenes problem. The only way to actually eliminate the risk is to secure all of a site's traffic with SSL encryption. Up till now the industry standard for when this was necessary was "If e-commerce is involved". That may be a thing of the past. More for site owners farther down the page.

Is someone doing "something™" about it?

Well. Perhaps. As I said, Google already did. I don't run Facebook. Maybe you could email Mark Zucherberg? I hear he's pretty busy these days. Basically we all just have to wait & see.

SSL is in truth not all that expensive. And if enough users make enough noise, yes "they" probably will do "something" about it.

I have a website. Can people use this to break into it?

Many of our client sites have Administrative panels to manage their site's content. If you take the same kind of precautions as you would for Facebook, you'll be fine regardless. However, the real question is - are you on the list of sites I linked above? No? You're not the next Google? Ok you're probably pretty much fine as far as Firesheep is concerned. Basics like making sure you have a strong password, using SSL Anywhere, regularly updating your Windows Anti-Virus software and running scans, etc. will probably keep you pretty secure in terms of your own website.

So what REALLY "fixes" it on my web site?

As mentioned before, it really is up to the site owner and administrator to provide the real fix for it. That fix is: *trumpets* S S L.

SSL ( Secure Socket Layers ) changes the address of your website from http://mysite to: https://mysite. It also encrypts all traffic between your site and the end user so that no one in the middle ( ex: Firesheep users at the coffee shop ) can decipher the conversation.

Honestly, SSL is peace of mind, and it's fairly inexpensive peace of mind. You'll spend less on it than you do on a couple months of car insurance. We can recommend that you do this, but it's really up to you.

Locally Caching Google Web Fonts

So recently amid all my hubbub of implementing CSS3 & HTML5 feature sets, I ran into a very annoying problem regarding Google Web Fonts ( Which I love, tremendously ). The problem, in a nutshell, is this: DoubleClick. I have hated this "technology" for as long as it's existed. Not for any paranoid tin-foil-hat-wearing concerns about my cat pictures being cached for all eternity. Rather because it's so painfully resource-intensive. When I'm trying to access web content and I see in my browser status bar, "Waiting for xyz.doubleclick....", a slow seething sort of anger starts to seep into me.

Well, it turns out that since Google now owns DoubleClick and they put it in pretty much everything, "everything" includes end user downloads of Web Fonts, which is otherwise an excellent and extremely game-changing solution for presentation design. As opposed to, say, sifr, which makes me want to run away and hide under Zeldman's seat cushion.

Also, as far as my personal anecdotal testing is concerned, these fonts do _not_ cache well. Maybe the actual font does, but the added HTTP overhead from DoubleClick pretty much negates any actual caching of the font data itself. So, how to fix? Well, pretty simply, really, as it turns out. I'll outline it here.

The current state of affairs:

If you include a Google Web Font in your HTML documents and have any sort of basic thimblefull of knowledge about HTML & CSS relationships, you'll notice that the basic relationship is just like any other CSS include <link> that you might create yourself. The difference is that the end document is not a flat CSS file, but rather "dynamically" calls for a specific font family & possible variant(s) to be pulled into your overall HTML document. Like this:

<link href="'http://fonts.googleapis.com/css?family=PT+Sans:regular,italic,bold,bolditalic&subset=latin' rel='stylesheet' type='text/css'>

Well, so that's fairly ok, right? Just for kicks, let's go & see what that page contains. It's just a URL after all. Click Here to see it:

http://fonts.googleapis.com/css?family=PT+Sans:regular,italic,bold,bolditalic&subset=latin

Again, fairly ok. Now, we have a whole new set of URL's, and some basic CSS to encapsulate them. Again, in this example I've selected all 4 variants of PT Sans. You might have more or fewer in your actual usage of a particular font.

Again, copy-paste one of those URL's into a browser tab ( you're using tabs, right? Ok, just checking... ). Ah, now here's NOT a normal text file ala CSS/HTML. It is in fact a ttf, or True Type Font, file. Again if you inspect the URL you can tell that it's being "dynamically" generated.

This is all fine & well and not a huge concern, if you have even some basic access to your web stores, ala FTP.

The Fix:

What I've done can be pretty simply described. I've added a few flairs based on long-term considerations. Basic steps:

1. Copy-Paste the font ( or font family ) CSS file.


2. Put the resulting FLAT CSS file at a location & naming convention of your choosing, somewhere within your web app or a centralized known location that you can always get to.


3. Download each of the .ttf files, rename them according to some sensible convention, inclluding the actual ".ttf" file extension. The mime-type should be included in the binary of the file itself. ( This is a good theory. If any knows how to test it let me know. )


4. Place those, again, somewhere sensible that you can access. A "ttf/" directory in the directory that you placed that CSS file in step 2 seems pretty darn reasonable to me.


5. Edit the CSS to reflect the new URL's of those .ttf's instead of Google's "dynamicized" URL's.


6. Edit the original CSS include to reflect the new location of your flat CSS file.
7. Enjoy fast download times on Web Fonts.

That's pretty much it.

Some Considerations:

Naming conventions I used were pretty much according to my existing web development conventions. "PTSans.css" ( really complicated, right? ). "ttf/PTSansItalic.ttf" ( super creative, I know. ).

I also placed these on my own company domain, under a /_css/webFonts/ directory. That way I can "locally" store them just once and continually recycle the URL's for them.

If I'm going to use one of these, I'm just going to grab all variants from Google, do all this downloading once, and be done with it, rather than piece-mealing each variant. Small bit of extra time now, saving time later.

I used wget ( best command line tool E V E R ) to pull these to my web server. If you happen to be blessed with shell access, here's an example ( assuming you're cd'd to the directory you want the .ttf's in ):

# wget http://themes.googleusercontent.com/font?kit=F51BEgHuR0tYHxF0bD4vwvesZW2xOQ-xsNqO47m55DA -O PTSansBold.ttf

Hope that helps someone. This post is mostly just to document the fact that DoubleClick latency is EXTREMELY annoying, and that again, from my anecdotal testing definitely affects end-user experience if you're trying to use this overall technique.