Firesheep: It's gonna cost you

With the release of Firesheep, end-users need to be more vigilant about forcing Secure HTTP connections, and clients, servers and network infrastructure will need to be upgraded to support the additional overhead.

Well that certainly took long enough.

I mean, it's not as if packet sniffing unencrypted web traffic is rocket science. After all, free programs for network and traffic analysis such as Wireshark have been available for years -- it simply required a bit of analysis skills to set the right filters to watch what was happening over TCP port 80.

The only thing missing was for some smart hacker to figure out how to tie the packet sniffing driver (WinPcap) to a simple, web-based GUI that allowed any non-technical person to hijack user web sessions over the network segment they were connected to.

And that's really all FireSheep is -- a way to hand a packet analysis tool to the masses and package it in a user-friendly wrapper that any 10 year old could use, simply by watching unencrypted user sessions and cleartext passwords pop up on the screen and clicking on their avatar icon to impersonate them.

If that scares the hell out of you, it damn well should. We just handed every mischievous child and criminal an electronic equivalent of a map of all the houses in your neighborhood that have their back door unlocked.

My ZDNet Networking colleague, Steven J. Vaughan-Nichols outlines a number of ways we can stop this sort of thing, cold. It's a good start, but it's not enough, because it doesn't factor in the actual cost of what would happen if we started encrypting all traffic from the device to the server over the Internet, end-to-end by default.

Also Read: Five Ways to Shear Firesheep (Networking)

Also Read: Firesheep's real lesson, take Wi-Fi security seriously (Networking)

Also Read: Learning the wrong lessons from Firesheep (Linux/OpenSource)

The last thing Steven mentions in his article is forcing the use of TLS and SSL. Right now, there are only a few programs that do this, such as HTTPS Everywhere and Force TLS.

Essentially, what these programs do is make your web browser connect via port 443 instead of port 80, and then force encrypted traffic via the Transport Layer Security (TLS) protocol provided the site supports it. Google's sites and FaceBook support these protocols already, as do a large number of other major web sites, such as Amazon.

Page 2: [Forcing HTTPS/TLS is only half the battle...]  »

A Secure HTTP connection to FaceBook forced by the HTTPS Everywhere and Force TLS extensions for Firefox.

Sounds great, and everyone should use them, immediately. In fact, it should be the default behavior for all web browsers. The problem is, these two extensions only currently support Firefox. So we need to get Microsoft to patch this into Internet Explorer versions 7 and 8 pronto, and build it into the upcoming version 9, and Apple needs to get this into Safari, stat. Google obviously needs to get this default behavior into Chromium and Chrome as soon as possible.

[UPDATE: A nice developer has recently released the"Use HTTPS" extension for Chrome. If you use Chrome, download and use this immediately.]

But PC web browsers are only half of the story. There's also all the smartphones (and now Tablets, like the iPad) out there running Apps that use Web APIs to communicate with social networking sites like FaceBook and Twitter and other web sites and web services that require authentication of some kind.

We also have desktop/smartphone Twitter/Social Networking clients which talk over Web APIs that need to start sending their traffic encrypted by default using best practices, as per FaceBook's OAuth docs and Twitter's OAuth's docs here.

So we just turn on HTTPS and TLS for all of these apps in the next over-the-air patch, right?

Well, no. The problem is that smartphone embedded processors, as they exist today, are completely unequipped to do end-to-end SSL and TLS encryption all of the time. They're just not powerful enough to do the constant integer math required to do all their web communication fully encrypted for every running app talking to the Internet, it would significantly bog down performance.

There are C libraries for doing this in software, such as Polar SSL, but doing this constantly will heat up your ARM Cortex processor up like an egg on a hotplate and chew your battery life down to nothing in short order.

So we're going to have to get SSL/TLS acceleration coprocessors into the next generation of smartphone hardware and SoCs for consumer electronics that communicate and authenticate over the web, like XBoxes, Playstations, Rokus and Apple TVs. As an intermediate solution, we could also put this technology into the routers and firewalls, and also at the carriers, but that's not end-to end.

All of the above only addresses the clients. The big issue is the websites themselves. FaceBook and Google and Amazon might support HTTPS, SSL and TLS, but all the others? They don't turn it on by default because if you have a lot of incoming sessions and they turned HTTPS and TLS encryption on for everything, their server performance would go straight to hell.

Why? Because HTTPS/TLS eats up a bunch of Integer processor time. That's why companies like Amazon which heavily rely on this form of encryption to complete business transactions with their customers use TLS/SSL acceleration boards and appliances, which use specialized co-processors that offload the vast amount of CPU overhead associated with this type of thing at the scale that's needed for a large e-commerce operation like that. And they are extremely expensive.

This is going to be a serious concern especially if we start using 2048-bit encryption that is currently being recommended for wide adoption by January 2011 by the National Institute of Standards (NIST) in place of the 128-bit and 1024-bit keys which are more commonplace.

In decoding a 2048-bit key (which are 2 to the 32nd power times more mathematically complex than 1024-bit keys) you should expect to see about a 4-8 times performance degradation in decryption speed, yielding approximately 20 percent of 1024-bit key performance.

In order to secure the future of the web, everything, and I mean everything, end-to end is going to have to be encrypted. That means integrating TLS/SSL acceleration into the server chip, blade chassis and/or the network interface to compensate for all that encryption/decryption overhead.

And what does that mean for the enterprise and the end-user? Well it means it's going to increase the cost of our network overhead, the cost of the server and network infrastructure, the cost of the smartphones and smart devices, and the cost of delivering services to you, the consumer. Part of which you'll have to pay for.

Did you like your cheap broadband Internet and smartphone? Enjoy it while it lasts. Talk Back and Let Me Know.