
Broadening HSTS to secure more of the Web - el_duderino
https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html
======
Ajedi32
> 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.

~~~
snuxoll
Whe you control the TLD _AND_ the preload list what’s to stop you?

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

------
CydeWeys
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](https://news.ycombinator.com/item?id=15268701)
for what that was like.

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

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

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

Edit: [http://www.herongyang.com/PKI/Chrome-40-HTTPS-Certificate-
Ge...](http://www.herongyang.com/PKI/Chrome-40-HTTPS-Certificate-General.jpg)

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.

~~~
xg15
At least there is an active bug about this:
[https://bugs.chromium.org/p/chromium/issues/detail?id=663971](https://bugs.chromium.org/p/chromium/issues/detail?id=663971)

------
b3lvedere
[https://hstspreload.org/?domain=google.com](https://hstspreload.org/?domain=google.com)
[https://hstspreload.org/?domain=googleblog.com](https://hstspreload.org/?domain=googleblog.com)

~~~
CydeWeys
We're working on those. Our main customer-facing blog is
[https://blog.google](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.

~~~
b3lvedere
"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](https://hstspreload.org/?domain=blog.google).
It says No HSTS header is present on the response.

~~~
CydeWeys
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/...](https://chromium.googlesource.com/chromium/src/net/+/master/http/transport_security_state_static.json#258)

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](https://github.com/chromium/hstspreload/issues/85)

~~~
b3lvedere
Thanks for this awesome reply!

------
Bhilai
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 ?

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

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

~~~
geofft
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](https://cabforum.org/pipermail/public/2015-April/005488.html)

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

~~~
bhartzer
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](https://icannwiki.org/.dev)

About 1300 registrations for .soy
[https://icannwiki.org/.soy](https://icannwiki.org/.soy)

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

~~~
bhartzer
The data I’ve seen there is correct.

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

~~~
Ajedi32
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](https://security.stackexchange.com/q/41988/29865)

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

------
SimeVidas
Why does Google own .soy?

~~~
CydeWeys
Does this answer your question? [https://www.iam.soy/](https://www.iam.soy/)

