Broadening HSTS to secure more of the Web | Hacker News Reader

Broadening HSTS to secure more of the Web

security.googleblog.com

86 pointsel_duderino42 comments

> 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.

Whe you control the TLD AND the preload list what’s to stop you?

We encourage any other registry operators who want to add their TLDs to the HSTS preload list to contact us and we'll make it happen.

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.

Seeing progress on this ticket would be really helpful:

https://issuetracker.google.com/issues/62051227

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.

Why did Chrome make it take an extra step or two to look at the issuer of a certificate?

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.

Can you tell them to change it back? It's absolutely annoying.

Edit: http://www.herongyang.com/PKI/Chrome-40-HTTPS-Certificate-Ge...

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.

At least there is an active bug about this: https://bugs.chromium.org/p/chromium/issues/detail?id=663971

chrome://flags/#show-cert-link

Thanks

One of the requirements is that you have to actually add a chain redirect to the www subdomain if a dns record for that subdomain exists.

That’s actually not a very good practice. You’ll get http non-www to http www to HTTPs www,for example.

Why is this a requirement for the preload list?

See the following links:

https://github.com/chromium/hstspreload/issues/87

https://bugs.chromium.org/p/chromium/issues/detail?id=626180

https://hstspreload.org/?domain=google.com https://hstspreload.org/?domain=googleblog.com

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.

I recall the blog having a much cleaner URL (no redirects) of https://blog.google before..

I’m curious as to why the www. version was made the default after some time? Would you happen to know the story behind it?

> google.com is complicated because there are some subdomains that would need carve-outs, which are not yet supported by all browsers.

What other than http://clients1.google.com/generate_204 needs that?

(And yeah, that should always have been on a separate domain entirely, but, hindsight.)

"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.

By the way. Just checked https://hstspreload.org/?domain=blog.google. It says No HSTS header is present on the response.

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

Thanks for this awesome reply!

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.

Thank you very much for your replies. I appreciate the time and effort you made.

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.

This requires client buy-in, and (at least as of a couple years ago) 360 Secure Browser did not do interstitials on pages with invalid SSL:

https://cabforum.org/pipermail/public/2015-April/005488.html

I wonder when, how and for how much the dev and foo domains are going to be available...

Think bigger than that, is all I can say ;)

Calzone dot org has all the up to date dates of sunrise, trademark, pre-registration and general availability dates for all new TLDs.

GA is not available yet for .dev. See https://icannwiki.org/.dev

About 1300 registrations for .soy https://icannwiki.org/.soy

Some time about there was a discussion that the wiki you linked isn't really updated anymore.

I'm also skeptical if .dev will ever be open to registration.

The data I’ve seen there is correct.

How viable is the interception a http-to-https redirect page? What is the recommended way to redirect users to https?

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.

Rinse and repeat.

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.

[1]: https://security.stackexchange.com/q/41988/29865

> 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.

> How viable is the interception a http-to-https redirect page?

It can be very powerful if done maliciously:

https://www.youtube.com/watch?v=MFol6IMbZ7Y

(This kind of attack is a primary motivation for the existence of HSTS.)

Relevant part starts here

https://youtu.be/MFol6IMbZ7Y?t=23m17s

Although for anyone interested in HTTPS, I'd recommend watching the whole thing. Very entertaining.

Why does Google own .soy?

Does this answer your question? https://www.iam.soy/

half a billion spanish speakers maybe

Reply on news.ycombinator.com