The FireSheep Dilemma - Encrypt Everything?

Tuesday, November 09, 2010

Rafal Los

0a8cae998f9c51e3b3c0ccbaddf521aa

The super-hype around FireSheep has died down a little now, and I think it's time to write about some of the things that stay behind in the wake of such a revelation

If the release of FireSheep has done nothing else - it has certainly demonstrated to people that HTTPS (encryption) is necessary well beyond the login page. Sounds easy enough right? Just "SSL the whole site"?

Actually, no. It's not that simple. So to quote my favorite British show and Jeremy Clarkson, "but there's a problem".

Horsepower

You see, it's not just as simple as wrapping HTTPS around every single URL call. There are technical hurdles here.  Performance is a big obstacle here now. It's not like HTTPS or TLS will significantly bog down modern processor... or will it? 

An argument could be made that the processing overhead for encrypting everything is do-able... but I don't think we're there today. Most sites are built for capacity around current encryption models - encrypt the login page and absolutely necessary transactions... everything goes in the clear. 

Even with that philosophy I remember back from not more than 3 years ago getting complaints from web application owners that "this would significantly bog down the application, and cause additional project spend to keep up with capacity requirements". 

That's a problem that we can't just address right now

My educated guess is that if applications like Facebook went full encryption on everything all the way through the site their processing power requirements on the server-side would take a significant jump...and then the site either has to scale out in terms of additional hardware or deal with the slow-down of the site.

OK, so there's the bump in performance... and it'll cost more too.  But that's it, right?

No, there's more.  Think about all the platforms today that you view web sites on.  Your mobile handset, your laptop, the tablet device, your refrigerator?  Are those all equipped to handle end-to-end HTTP (or TLS)? 

I'm going to make another educated guess and say no again. This means that there may be an end-user issue as well!  Yikes, that's probably not too good either.

So now we're asking servers and clients to perform additional mathematical calculations (and let's face it, this isn't simple...) for every. single. transaction.  I'm fairly sure that my handset would get fairly hot if I was to do that right now...

Externalities

So let's ignore the horsepower requirements, because hardware is cheap and if the web site "really cares about security" then buying some extra capacity shouldn't be difficult, right?

What if your site is serving up more than just your content like, say, Google AdSense?  Then you're stuck with this issue - https://www.google.com/adsense/support/bin/answer.py?hl=en&answer=10528

So that means you have two choices: (1) stop using AdSense OR (2) prepare your customers for having to click "OK" a million times... I don't like either of those options - as a webmaster - do you?

Now consider that there are at least a few externalities like this for just about every site out there!

That's not simple to overcome... this starts to sound like the reasons that DNSSEC had a difficult time- it's everyone participates, or no one plays.  That's a very difficult battle.

If I'm Facebook, I have to make sure that every plug-in, every widget, and add-on now supports HTTP/TLS capabilities throughout the site, start to finish, login to logout.  That's a monumental task even on a good day.

The alternative is having to click through those messages that warn you about non-HTTPS content on an otherwise HTTPS page, and that's confusing for users!  Actually ... I would say it's more of an annoyance than anything since 9/10 users will just click-through this anyway ...right?

So now we have 2 hurdles, hardware capacity which needs to be ratcheted up, and the externalities that will require HTTP/TLS as well.

So let's agree that this sort of evolutionary step won't be happening overnight, and see what we can do from there. Well, there are options, luckily... but as with any relatively cutting edge security measure they're not for the average user.

Browsers... Today

There are of course options for FireFox users -the EFF's HTTPS-Everywhere is a great option, and one that every FireFox instance (except the 4.x betas, ugh!) I use has installed and turned on. 

There is also a Chrome plug-in called "Use-HTTPS"  that does the trick ...but I don't have a whole lot of experience in that yet... still testing.  Sadly, IE (in any of the many incantations) doesn't support this either natively or with any plug-ins that I've been able to find.

Here's the problem with these neat-o browser add-ons... they're add-ons.  The average user won't be running HTTPS-Everywhere, or Use-HTTPS... the average user still has trouble spelling HTTPS or just doesn't understand. 

So the problem comes back to browsers... but can you realistically expect a browser to force HTTPS/TLS encryption on an entire site right from install?  I would argue that this would be a poor decision.

All in All

I think we've got a problem (still).  FireSheep has demonstrated that the attacks against non-end-to-end encrypted sites are very real, and very easy - yet the solution is extremely complex and as always falls completely apart if every single little piece isn't just perfect.  This is the nature of encryption, after all...perfection of nothing!

So... if you're the average user, what do you do?  Here are some recommendations I can give you...

  • IF you have the luxury of using FireFox (3.x) then for the love of all things good and pure, install the EFF HTTPS-Everywhere plug-in ...NOW.
  • If you're using Chrome, test out Use-HTTPS ...
  • If you can't use either of those two browsers, or can't install those plug-ins... hope for luck
  • Watch yourself on wireless networks (as a start) ...and use VPN tunneling to connect to safe networks that you can reasonably trust...

Barring that - we need to push on the industry to make the evolutionary jump to encrypting well beyond the login page. 

It is not reasonable, in my humble opinion, to expect every site to encrypt every page... that's lunacy... so where are the lines to be drawn?  We need an architectural standard for "what to encrypt"... maybe a risk-scoring system or some guidelines?

As you've probably guessed, I have some ideas... if you're willing to think this through with me... reply here or contact me.  There's work to be done.  NOW.

Cross-posted from Following the White Rabbit

Possibly Related Articles:
11279
Encryption HTTP Security SSL TLS firesheep
Post Rating I Like this!
4072c1d979190d2cd781f241908d3a73
Anthony Wrather Maybe I misunderstood the problem ? ... For FireSheep to be effective you have to be using an insecure (read unencrypted) wireless (or wired link if you can gain sufficient access). If so surely the cost effective solution is to encourage vendors (ISP's and hardware manufacturers) to provide cost effective encrypted links and to encourage HotSpot providers to do the same ? Also doesn't IPV6 potentially solve the problem as full packet encryption is either an option or mandated ? Sorry if I have missed point with FireSheep.
1289444858
0a8cae998f9c51e3b3c0ccbaddf521aa
Rafal Los Anthony - yes you are essentially correct. The problem is most hot-spots are necessarily open and unsecured - which is where I watch people flip open their laptops and jump onto FaceBook and Twitter all the time ...scary.
1289512547
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson The average person doesn't think about security implications of logging into a site from an Open WiFi at a Cafe, they only consider the convenience.

I have to give Google props for being the first major web mail service to go https all the way.

I had been using https encrypted web mail and SSL/TLS encrypted IMAP from my own personal domain for years. It was the main thing that made me move away from the big free webmail services... and the option of having HTTPS (and eventual default of HTTPS) on gmail is what made me feel comfortable using it for secondary accounts.

As to the question of what should we be pushing for to be encrypted, for starters, all e-mail services, then I'd say all logged in sessions at online stores.

I'd feel much mor comfortable shopping at an online store that only used unencrypted sessions to let you browse the catalog, but once you hit the login page it encrypts and STAYS encrypted as long as you are logged in.

They don't need 3rd party ads, they already have you ready to make a purchase from them. Ads would only detract from business at that point. They also don't need 3rd party tracking, they can set cookies and watch your every move through their store on their own.

I'd much prfer the store that encypts my session while I load up the shopping cart right through till I hit submit on the credit card screen over one that only encrypts login and credit card forms.

It would provide some privacy, and prevent man-in-the-middle attempts to alter the price, quantity, items, delivery location etc.

Facebook type sites would be a bonus to have encrypted, but as Rafal pointed out, there is a lot of work to be done there.

On the point of handhelds not being ready yet, I think that is up for debate. The blackberry when connected to BES encrypts all communication between it and the BES, including surfing intranet sites at your company... I think we are ready for it.
1289554499
4072c1d979190d2cd781f241908d3a73
Anthony Wrather I use WM6.1 and WM6.5 and they both can support SSL / VPN so can encrypt things both at the application and communication level.
I would be very interested to see some performance figures regarding the extra load placed on http/https, smtp/smtps and imap/imaps servers when scaling server clusters with and without mandatory encryption.
In my experience the biggest server cluster and network load tends to come from the actual content and the load / throughput difference between encrypted and the unencrypted links and services is marginal in comparison. But facts and a desire to change are what is needed.
This whole issue is very reminiscent of the WEP to WPA2, telnet to ssh, and default passwords on hardware type issues, it requires a gradual but consistent move to educate the general populous and also a change in hardware vendors behaviour.
All new tech should be encrypted by default.
Personally I was horrified by how easy it is to break default configurations after my first security course and I only use cafe/hotel/airport hotspots for things I don't mind the whole world knowing.
1289615783
314f19f082e69886c20e31c70fe6dceb
Rod MacPherson I have a Linux box at home, with OpenSSH open to the world.

When I am at a public hotspot with my laptop, I fire up SSH/putty and log in to my home system, using dynamic tunneling to create a socks proxy, and send all web traffic through the proxy. Then I know that at the very least someone on the same AP as me cannot read my traffic.

I still use SSL wherever I can, because I want to to be encrypted all the way to the server, but the SSH trick makes sure that even pages that cannot be forced into SSL mode are not broadcast in the clear to the whole coffee shop/hotel.

1290921344
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.