Hopefully it's about to catch on. Google Chrome has supported HSTS for a while now, and Firefox support is imminent.
The stated benefits of HSTS include:
- Defenses against sslstrip-like attacks. The initial navigation to blah.com is automatically upgraded to HTTPS.
- Zero tolerance for certification problems. The user is not permitted to "click through" anything such as a self-signed cert.
HSTS also comes with some less obvious benefits and security boosts, which it's worth noting:
- Mixed-content defense. For same domain mixed-content situations, the fetches are automatically upgraded to HTTPS. This can sometimes sidestep nasty bugs.
- Secure cookie defense. It's a pretty egregious bug for an HTTPS-only site to fail to mark its cookies "Secure", but HSTS can defend against the cookie value being sent out plaintext.
- Cookie forcing defense. Cookie forcing is a pretty nasty MITM attack that I was playing with back in 2008. As long as HSTS is used in "includeSubDomains" mode, it can provide a defense against this subtle attack.
- Latency win. User who navigate to or bookmark the plain HTTP blah.com are automatically bounced straight to HTTPS, without having to go via an HTTP redirect
In the future, I'm hopeful HSTS can be extended to provide defenses against possibly rogue CAs.
5 comments:
I'm totally with you on including for instance an optional flag "rememberRootCA"
This would mean we could have headers such as:
Strict-Transport-Security: max-age=15768000 ; includeSubDomains ; rememberRootCA
The new flag would instruct the browser to either point out the domain's root CA in its trusted CAs list, or save the fingerprint of the root CA certificate used to sign the server cert. This would effectively rule out subsequent man-in-the-middle attacks with rouge server certs signed by any of the 150-250 default root CAs trusted by the user's operating system or browser.
Defenses against sslstrip-like attacks. The initial navigation to blah.com is automatically upgraded to HTTPS.
-> not really, you assume you already have marked the site as a HSTS one.
Zero tolerance for certification problems.
-> I would not put all my money on that.
Mixed-content defense. For same domain mixed-content situations, the fetches are automatically upgraded to HTTPS.
-> perhaps or perhaps not, depends from where it loads the pages and how the "same domain"(exmaple.net and www.example.net may be the "same domain") was marked as an HSTS site(the HSTS vs canonical redirects issues).
I'm hopeful HSTS can be extended to provide defenses against possibly rogue CAs.
-> there is a proposed extension, lockCA. but things are not so simple though.
I wrote a HSTS post with HSTS currently (main) known issues:
http://www.carbonwind.net/blog/post/Random-SSLTLS-101-HTTP-Strict-Transport-Security.aspx
Cheers!
Adrian
@adrian: the first and most significant problem (first http:// navigation not HSTS protected) is tackled via HSTS lists built in to the browser.
Maybe I'm missing something, but couldn't HSTS be arranged like the following for safe autonegotiation of HSTS?
1) If the HSTS policy is explicitly defined in the browser settings for a particular domain (ON or OFF), honor that.
2) But if (a) the client-side policy isn't defined for a domain, and (b) the user-agent attempts to initiate contact without TLS to a particular domain, first have the browser immediately try to get the HSTS policy over 443 TLS before doing anything else.
If the HSTS policy isn't available over 443 TLS, then the browser can operate without HSTS.
The big concern would be TLS handshake penalties. But if there's only one handshake penalty per domain for the duration of the browser window being open or if there's a notion of TTL for an HSTS policy (or both) it doesn't much matter.
To make this the default on most browsers, browser vendors could have the following message display after browser install or upgrade:
===
When you type in a web server name do you want to always try to connect securely?
(*) Yes ( ) No
===
This is very good news, I hope HSTS will become a standard.
Post a Comment