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 trawling through the IETF Internet Draft specification but you want to figure out how it works, here's a quick summary:
- 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. - 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.
- 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.
Thanks, been waiting for this natively in Firefox.
ReplyDeleteI use Internet Explorer. As this is a better browser than FireFox, I don't need to worry about this do I.
ReplyDelete@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.
ReplyDeleteHopefully 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
ReplyDelete@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.
ReplyDeleteMaybe repeating the same search on Shodan on port 443 (with HTTPS) would find more results?
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".
ReplyDeleteIsn't there a privacy concern?
ReplyDeleteFirefox 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/10:42 PM
ReplyDeleteThe 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.
If I'm doing such a MITM attack it's trivial to remove that header. I don't really see the point..
ReplyDelete@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.
ReplyDeleteIt'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.
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.
ReplyDeleteThis 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?
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.
ReplyDelete@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.
ReplyDelete@Anonymous/4:16pm: Yeah, there's a bug filed about that, and it should be fixed in the next release.
Ez jól hangzik .. várom szeretettel!
ReplyDeleteVery cool, I'll wait for Beta 6 then on my machine that is behind the proxy.
ReplyDeleteUnfortunately, Beta 6 does not provide any improvement on that side... hope Beta 7 will soon be there and correct this behaviour.
ReplyDelete@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.
ReplyDeleteQuestion...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.
ReplyDelete@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.
ReplyDeleteI 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?
ReplyDelete@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.
ReplyDeleteHow 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.
ReplyDelete@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.
ReplyDeleteWe 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.
I'm still adding more HTTPS data.
ReplyDeletei begin test. 'o'
สุดยอด
ReplyDeleteExcellent.
Thanks , I will test more.
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
ReplyDeleteWhy is HSTS needed? Does the browser fall back to plain http:// at any time when you/site states https://?
ReplyDeleteIf 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.
@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.
ReplyDeleteMore information: http://blog.sidstamm.com/2009/07/force-tls.html
Can I use .htaccess to force HSTS in a whole domain and its subdomains? The code would run like this
ReplyDeleteRewriteEngine 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
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".
ReplyDeletehttps://www.mozilla.org and https://www.google.com both send the strict-transport-security header. (It is in the HTTP layer, not in TLS).
ReplyDeletefor https is there a level to ensure privacy?
ReplyDeletefor example, we have to pay more to buy an SSL Certificate
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?
ReplyDeleteWhy is HSTS needed? Does the browser fall back to plain http:// at any time when you/site states https://?
ReplyDeleteFor a secure web (as W3C has proposed), most of the web must be secure. Http should be the exception, not the rule and not the default.
ReplyDeleteHSTS still allows an initial http connection, to read the HSTS header, and any http connection can result in MiTM attacks.
So the browser must never make an http connection to a site that supports https.
So HSTS can only work if secure sites are preloaded. But in the case where most of the web is secure, a central list of most domains is impractical. It is too large and hard to change. In other words, a list doesn't scale up well.
A solution is to use a distributed list. One such list that already exists is the authoritative DNS zones. A flag could be added to the zone records to indicate that a site supports https.
Then the browser has that information as soon as it does a DNS lookup.
A possible problem is that DNS lookups are insecure. But this is not a real problem since a mistake either way can only result at worst as the site being inaccessible. A solution it to make DNS nameservers secure.
Thanks, been waiting for this natively in Firefox.
ReplyDelete