Call for stronger webappsec – enable HTTPS by default

June 16, 2009

In an open letter to Google, some familiar names in security call for Google, and other web-based application providers by proxy, to strengthen security by doing one simple thing – enable HTTPS by default.

If you haven’t read the letter, go back an do so [PDF link].  Please.  I’ll wait.  Lots of people don’t get the importance of a complete HTTPS session (not just when logging in) and hopefully this will help.  Cliff Notes version:

1. Once you have logged in, your session (often via a cookie but not always) is your “token” to that account.  Steal it, or inadvertently disclose it (via HTTP), and the person who has that token can effectively become logged in without knowing the credentials or having to going through the authentication process(1).  If you don’t know what that means, look here for an example.
2. On a mixed HTTP/HTTPS session, an attacker can do some funky things that can break the cross-domain protections and then once again it’s game over – you can’t trust the screen you are seeing and the attacker has control over the browser (session token stealing again, malicious code injection, DOM manipulation, browser flaws, etc, etc).
3. You would assume that in most cases even without account takeover or other injection issues that the information going over the wire you don’t want to broadcast to anyone that’s listening.  Many people’s personal lives are run via web-based email setups and it’s been said many times – gaining someone’s webmail account effectively mean you can gain access to lots of other accounts belonging to that person via password reset functionality.  Webmail is the de-facto master password of the net.

So, there’s very good reason to go HTTPS only.  However, there’s downsides to this.   First one is pretty obvious, second one no so much.

1. Performance.  Many companies assume that having everything go over HTTPS will have a huge performance impact.  There’s no doubt that there’s some performance impact, but the major cost is the HTTPS handshake in the browser and server agreeing on a cipher.  Once that is done, modern browsers can cache that agreement and not have to go through it again.  In some cases it makes sense to keep the connection open.  I should really do my own experiments, but it seems the even an old comparison showed very little degradation of performance on old(er) servers/browsers and without SSL concentrators.  A newer paper [PDF link] with lot more detail certainly shows degradation, but only at high throughputs – something certainly Google or a large/popular service would be concerned about.
2. Injections.  Not the kind of injections we don’t want (2), but injecting ads into HTTPS pages is a lot harder.  If it’s being done cross-site you get those horrible popup “mixed content” warning messages, and if it’s “force injected” (which no-one seems to be doing now, but ISP’s had some fun trying it.  With Google’s main revenue being ads, I can see how that might be an issue.

So, first props for Google mentioning it and of all the main providers of web-based apps out there are doing the right thing, even if not by default.  Second, I’m sure that it would have been done already if there wasn’t concerns, and I’m certain that Google (being Google) are crunching the number to see what impact it will have.  I’m not going to hold my breath, but at least it’s “out there” and I hope more people enable SSL by default.

My belief is that we’re relying on the web so much now that we’re going to have to consider encrypted communication to be the default.  Whether that’s VPNs, SSL concentrators, HTTPS-by-default, I’m not sure – it would be really interesting to see some recent stats of a) the amount of HTTP vs HTTPS traffic out there and b) the impact of HTTPS on a well-designed infrastructure setup to handle it.  If anyone has that info please get in touch while I go about looking for it myself and update here if I find anything interesting.  HTTPS/SSL isn’t the great panacea/silver bullet, but as the story goes, it does provide something and from there we can worry about all the other issues in webapps.

(1) There are ways of further protecting the session token if it is disclosed through tying it to an IP address, browser version, etc, etc, but it’s not foolproof.

(2) I still would rather not have ads injected into any of my pages, but understand the model.  I don’t mind paying for services that I use, but it seems I’m in the minority.

Posted in Uncategorized