> In 2015 we created the first secure TLD when we added .google to the HSTS preload list, and we are now rolling out HSTS for a larger number of our TLDs, starting with .foo and .dev.
Interesting, I didn't realize you could add entire top-level domains to the HSTS preload list like that.
This seems like a really interesting potential migration path towards a future where HTTPS support is mandatory. On TLDs that preload HSTS, you might not even need to open port 80 or accept regular HTTP requests at all, since browsers would _always_ load the HTTPS version of the site.
Hey everyone, I'm the author of the linked blog post. I can hopefully answer any questions anyone might have. I wrote this post to clarify our overall strategy and intent in response to some of the confusion surrounding our addition of .dev and .foo to the HSTS preload list; see https://news.ycombinator.com/item?id=15268701 for what that was like.
I will try to see if I can go make something happen. Thanks for the link. I will say that one benefit of TLD-wide HSTS is that you don't have to worry about configuring these headers on a per-domain basis; you're already covered.
No idea. I'm not on the Chrome team. I will say that the best way to find out this info (and more) now is to hit F12/Cmd-Opt-I/whatever to open up the Developer console, and then go to the Security tab. You can see the SSL certificate in there along with lots of other useful security information that wasn't as easily findable from the previous method.
So if I had to guess, it's that they wanted to display more security-related information, which made sense in the developer console but not on the certificate screen. And that viewing the certificate was confusing non-technical web users.
The old screen showed the same information as in the "Security" tab. Right now a click on the "Secure" button in the URL bar doesn't even show the certificate issuer. It is useless this way.
We're working on those. Our main customer-facing blog is https://blog.google, which is on the .google TLD, which is HSTS-secured. google.com is complicated because there are some subdomains that would need carve-outs, which are not yet supported by all browsers.
"In 2014, we started encouraging other websites to use HTTPS by giving secure sites a ranking boost in Google Search."
"We're working on those ....google.com is complicated"
Having a top rank in Google results is a very serious business for a lot of companies. If this trend continues for HSTS i am a little worried.
I do understand Google likes to encourage the rest of the world to have an as secure possible internet infrastructure, but i'm not so sure if those same companies would accept a lower Google ranking just because their IT department will tell them "It's complicated".
It's not evil by far. But it's not really nice as well.
We're working on standardizing HSTS carve-outs across browsers, which should help improve this process tremendously. The specific parts of google.com that are problematic are related to PKI infrastructure for Chrome (CRLs and such) that cannot be served encrypted. Most companies won't have these requirements, fortunately. And we do have many individual subdomains of google.com added to the list individually in lieu of carve-outs: https://chromium.googlesource.com/chromium/src/net/+/master/...
As for blog.google, that's the beauty of TLD-wide HSTS. You don't need to do anything special on the individual websites, such as configuring headers, to get the benefit of HSTS. All you have to do is set up an SSL cert.
The hstspreload.org site does not yet correctly display results for when a parent has HSTS enabled, but your browser itself does do the right thing. As for fixing what hstspreload.org displays, that's something I might take a crack at: https://github.com/chromium/hstspreload/issues/85
Oh, and another thing. I don't know if inclusion on the HSTS preload list will ever will be a website quality signal for Search, but it seems to me like full browser support for HSTS carve-outs would be a necessary prerequisite. We didn't start using HTTPS as a quality signal until well after all of our sites were encrypted, for example.
I am not sure I understand, who is supposed to add the TLDs to HSTS preload list ? I don’t see TLDs like .com,.net,.io etc. ever being added so is this an option only for likes of Google who own TLDs ?
Yes, registry operators would be the ones to add TLDs to the HSTS preload list. And it's very hard to do so retroactively as you're effectively breaking any existing website that isn't available over HTTPS. So, practically speaking, it's mainly an option for new, unlaunched, and closed TLDs.
I'd wager this sort of aggressive and possibly effective mass nudging toward effective encryption will lead to China further isolating itself from the rest of the Internet.
Ideally, you should use HSTS preloads in combination with a 301 or 308 redirect.
HTTP redirects can be intercepted by anyone who is a MITM (man-in-the-middle) to your connection. (Such as a Wi-Fi hotspot owner, ISP, or someone attacking the network itself via DNS poisoning, ARP spoofing, etc.) So using _only_ HTTP redirects leaves you open to a [SSL Stripping attack][1].
A better option is to use a HSTS header. This ensures that once a user visits your site once over HTTPS, all subsequent visits will also happen over HTTPS. This makes SSL Stripping attacks harder, but still possible if the attacker is able to MITM your users on their first visit to your site.
The best option is to get your site on the list of HSTS preloads. This list ships with web browsers, which will then _always_ load your site over HTTPS. A site that uses HSTS preloads is nearly immune to SSL Stripping attacks, and that's what Google is using here.
Some browsers still don't support HSTS though, so you might not be able to rely entirely on HSTS preloads to redirect your users. For that reason, it's best to _also_ redirect users via 301 or 308 HTTP redirects, just in case.
> HTTP redirects can be intercepted by anyone who is a MITM (man-in-the-middle) to your connection. (Such as a Wi-Fi hotspot owner, ISP, or someone attacking the network itself via DNS poisoning, ARP spoofing, etc.)
Don't forget state actors. Billions of people live in countries that censor/track/edit/redirect Web connections.
If you're a network-level attacker it's basically trivial.
If you get requests over HTTP of course you should still redirect them, as there's nothing more secure you can do. However via HSTS and even more via HSTS preloading you can prevent them from happening in the first place.
Exactly as viable as any MitM against (unsecured) HTTP.
The recommended way is still a 3xx-class redirect (consult your SEO) to the HTTPS version, because it's better than nothing -- in other words:
- if an MitM already tampered with the response, they already have control and given the momentary circumstances there's nothing more anyone can do to save you;
- else, if no one tampered with the response, then hopefully the site was configured properly and you ended up at the HTTPS version, receiving any HSTS headers the site owner may have issued, at which point you're either safe for the current session, or depending on any received HSTS headers, longer than that.
Interesting, I didn't realize you could add entire top-level domains to the HSTS preload list like that.
This seems like a really interesting potential migration path towards a future where HTTPS support is mandatory. On TLDs that preload HSTS, you might not even need to open port 80 or accept regular HTTP requests at all, since browsers would _always_ load the HTTPS version of the site.