Thursday, August 26, 2010

HTTP Strict Transport Security has landed!

It was a year ago now that I first blogged about ForceTLS, and it's matured quite a bit since. I revised ForceTLS to be more robust, and began actually implementing it as HTTP-Strict-Transport-Security in Firefox. I'm excited to say that my patch has been reviewed and landed in mozilla-central.

What's that mean? Look for it in the next beta release of Firefox 4! If you can't wait, grab a nightly build, but when 4.0 is released, HTTP Strict-Transport-Security will be built-in and turned on by default.

Though the feature's core functionality is there, work on HSTS is not completely finished. There are still a few tweaks I'd like to make, mainly providing a decent UI so people can add/remove HSTS state for servers themselves -- but none of this is necessary to be specification compliant. As landed, HSTS is the behind-the-scenes implementation that listens to the HTTP Strict-Transport-Security header and follows those instructions.

In case you don't feel like trolling through the IETF Internet Draft specification but you want to figure out how it works, here's a quick summary:

  1. Over an HTTPS connection, the server provides the Strict-Transport-Security header indicating it wants to be an HSTS host. It looks something like this:
    Strict-Transport-Security: max-age=60000
    The header's presence indicates the server's desire to be an HSTS host, and the max-age states for how many seconds the browser should remember this.
  2. For an HSTS host (e.g., paypal.com), any subsequent requests assembled for an insecure connection to that host (http://paypal.com), will be rewritten to a secure request (https://paypal.com) before any network connection is opened.
  3. Optionally, the header can include a second includeSubdomains directive that tells the browser to additionally "upgrade" all subdomains of the serving host. That looks like this:
    Strict-Transport-Security: max-age=60000; includeSubdomains

If Firefox knows your host is an HSTS one, it will automatically establish a secure connection to your server without even trying an insecure one. This way, if I am surfing the 'net in my favorite cafe and a hacker is playing MITM with paypal.com (intercepting http requests for paypal.com and then forwarding them on to the real site), either I'll thwart the attacker by getting an encrypted connection to paypal.com immediately, or the attack will be detected by HSTS and the connection won't work at all.

There are more details in the specification, like some further restrictions on cert errors and the like, but this is the general setup, and I believe a pretty nice feature to increase your site's security.

Also: Jeff and Andy at Paypal are working hard at standardizing this.

29 comments:

Anonymous said...

Thanks, been waiting for this natively in Firefox.

Anonymous said...

I use Internet Explorer. As this is a better browser than FireFox, I don't need to worry about this do I.

Sid Stamm said...

@Anonymous/5:54am: As far as I know, Internet Explorer doesn't implement protections against those man-in-the-middle attacks that HTTPS Strict Transport Security thwarts. If you want to be protected from those attacks, you should use a browser that supports HSTS.

achillean said...

Hopefully HSTS will be adopted by more servers/ clients, at the moment there doesn't seem to be much support for it. Out of ~120k HTTPS banners in Shodan, none of them had "Strict-Transport-Security"; and there were 6 regular HTTP banners that had them: http://www.shodanhq.com/?q=%22Strict-Transport-Security%22+port%3A80

Sid Stamm said...

@achillean: The Strict-Transport-Security HTTP header is not honored by browsers when it's served over an insecure connection (e.g., port 80 without SSL). It's ignored for many reasons such as the fact the header via insecure connection can be used as a DoS on sites that don't support HTTPS.

Maybe repeating the same search on Shodan on port 443 (with HTTPS) would find more results?

achillean said...

I'm still adding more HTTPS data (searchable index is at ~120k hosts), but currently there are no HTTPS banners that contain "Strict-Transport-Security".

Anonymous said...

Isn't there a privacy concern?

Firefox allows one to delete the browsing history, but in order for HSTS to work, Firefox has to somehow store HSTS information for individual websites so that it knows where to enforce, correct?

As more websites are implementing this, HSTS would act as a browser history and people looking at one's computer would know what websites that person has been visiting.

This might not be a big deal for some people, but apparently many people do care, otherwise there wouldn't be an option to remove one's browsing history.

Any thoughts?

In addition, I'm assuming this won't work in private browsing mode?

Anonymous said...

@ Anonymous/10:42 PM

The Browser History removal was, in my opinion originally created so that any remaining downloaded websites files (ie website images) could be deleted to conserve hard disk drive space on lower end machines back when it was originally created.

However, we've been using it since than and continue to use it now as it is out of habit to constantly keep clean the PC(s) we own now.

Nagilum said...

If I'm doing such a MITM attack it's trivial to remove that header. I don't really see the point..

Sid Stamm said...

@Anonymous/10:42pm: Yes, there is a privacy concern, and we address that. (1) When using private browsing mode, HSTS won't record any new HSTS data. (2) When you choose "Clear Recent History" and select "Site Permissions", HSTS data will be erased from your profile.

It's important to let users control the data sites set on their computers, and we wouldn't implement HSTS without letting them purge or disable the HSTS data.

@Nagilum: The header must be encountered by the browser over a secure, non-intercepted connection only once--before your attack. The browser then remembers the HSTS state for that site for the *future*, so whether or not the header is present in future requests/responses, the connection is ensured secure. So yeah, you could remove the header, but HSTS would prevent the connection in the first place because as a MITM, you probably wouldn't have a legit certificate for the site you're intercepting.

The attack scenario is this: I usually visit my bank's site at home, but for those occasions when I take my laptop to a cafe (where you are playing MITM for my bank), HSTS will prevent me from connecting to your spoofed version of the site.

Aryeh Gregor said...

Great to see this land, it will be a big step forward. To fix the bootstrapping problem and make the privacy issue less of a problem, you'd want to pre-populate the list of STS sites, no? Have a bot that goes through a list of sites and does a HEAD request over HTTPS for each. If it receives a response with a legitimate STS header of long duration (e.g., a month or more) and the response is marked as public and cacheable, store the result. Then ship the resulting list with Firefox and update it automatically every so often, like with the list of bad sites.

This way attackers can't even get lucky and hijack the first request. Also, if users clear their browser settings, you can still fall back to the stock list, which will reveal no info about browsing habits. Are there any plans to do something like this?

Anonymous said...

This feature seems to break HTTPS sites when going through a proxy server. After updating I couldn't get to any HTTPS sites that I tried. Testing on a network without the proxy worked fine.

Sid Stamm said...

@Aryeh: We've definitely considered shipping a list of pre-set sites with the product. There's no set list defined right now, but it does seem like a good idea.

@Anonymous/4:16pm: Yeah, there's a bug filed about that, and it should be fixed in the next release.

Anonymous said...

Ez jól hangzik .. várom szeretettel!

Anonymous said...

Very cool, I'll wait for Beta 6 then on my machine that is behind the proxy.

Anonymous said...

Unfortunately, Beta 6 does not provide any improvement on that side... hope Beta 7 will soon be there and correct this behaviour.

Sid Stamm said...

@Anonymous/4:28pm: Yeah, beta 6 was a quick fix for a few other more critical things, but the proxy fix will be in the next beta.

Xorlev said...

Question...if one self-signs their own certificate, is that at all valid for HSTS? Or must one have a trusted cert from a higher-end CA for HSTS to work? I've added the header to my site and have not notice HSTS working in FF4b6.

Sid Stamm said...

@Xorlev: Self-signed certs are not honored by HSTS. For a connection's HSTS header to be honored, the connection must (1) have a valid certificate and (2) the certificate must chain up to a root in the browser.

Paul said...

I get a "The operation can not be completed because of an internal failure. A secure network communication has not been cleaned up correctly." message pop-up when I start-up Firefox 4 beta 6. Is this something to do with (or a bug in) this new HSTS feature?

Sid Stamm said...

@Paul: I don't think that error message is related to HSTS. I encountered the same thing; try quitting and re-launching Firefox. It should not reappear.

Anonymous said...

How about, rather than storing one bit of "strictness" and a count-down timer, store the certificate chain from this authentication and complain if it ever changes.

Sid Stamm said...

@Anonymous/7:06pm: While that's a nice idea it is out of scope for HSTS (not in the specification that I am not in charge of) and also a bit too strict, especially for CDNs or for sites that suddenly want to change the CA they use.

We have been talking about adding an extension to HSTS that allows the web sites to additionally opt in to that type of chain locking, but that's still in the discussion stage.

gootooyoo said...

I'm still adding more HTTPS data.
i begin test. 'o'

gootooyoo said...

สุดยอด
Excellent.
Thanks , I will test more.

Paul said...

welcome firefox 4, but internet explorer 9 with direct x10 does not install on windows xp but only windows vista and windows 7 Y think that the firefox is the best browser and y have installed on windows xp y use direct x9 but y prefer this os or linux, windows 7 is very heavy

Anonymous said...

Why is HSTS needed? Does the browser fall back to plain http:// at any time when you/site states https://?

If not, only thing I can see that this technically helps with is if the browser normally sends some secure cookie/request data (which was set with https) over http if pointed there. In that case this setting would prevent it.

Sid Stamm said...

@Anonymous/10:23am: The point is to stop an "oops, I meant https" from happening *ever*. Do you type "https://www.twitter.com" when you go to twitter? Most people just type "twitter" and let 'er rip. If twitter.com were an HSTS host, then the browser would automatically assume https is the default, if not, http.

More information: http://blog.sidstamm.com/2009/07/force-tls.html

Anonymous said...

Can I use .htaccess to force HSTS in a whole domain and its subdomains? The code would run like this

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

so the .htaccess file would be like this:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}

RewriteEngine On
RewriteCond %{SERVER_PORT} 80
RewriteRule ^(.*)$ https://wf.ucipass.eu/$1 [R,L]

#RewriteEngine on
#RewriteCond %{HTTP_HOST} ^wf.ucipass.eu$ [OR]
#RewriteCond %{HTTP_HOST} ^www.wf.ucipass.eu$
#RewriteRule ^/?$ "https\:\/\/www\.ucipass\.eu" [R=301,L]

Dont find any clues in Internet...thank you in advance for your help