6 ms·

Broadening HSTS to secure more of the Web

86 points by el_duderino 9y ago

Ajedi32 9y ago
> 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 9y ago
  Whe you control the TLD AND the preload list what’s to stop you?
  - CydeWeys 9y ago
    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.
DrinkWater 9y ago
How viable is the interception a http-to-https redirect page? What is the recommended way to redirect users to https?
- schoen 9y ago
  > 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 https://www.youtube.com/watch?v=MFol6IMbZ7Y (This kind of attack is a primary motivation for the existence of HSTS.)
  - ktta 9y ago
    Relevant part starts here https://youtu.be/MFol6IMbZ7Y?t=23m17s https://youtu.be/MFol6IMbZ7Y?t=23m17s Although for anyone interested in HTTPS, I'd recommend watching the whole thing. Very entertaining.
- deleted 9y ago
  [deleted]
- hannob 9y ago
  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.
- niftich 9y ago
  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.
- Ajedi32 9y ago
  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 9y ago
    > 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.
d0ugie 9y ago
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 9y ago
  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 9y ago
I wonder when, how and for how much the dev and foo domains are going to be available...
- CydeWeys 9y ago
  Think bigger than that, is all I can say ;)
- bhartzer 9y ago
  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 9y ago
    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 9y ago
      The data I’ve seen there is correct.
b3lvedere 9y ago
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 9y ago
  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.
  - ehPReth 9y ago
    I recall the blog having a much cleaner URL (no redirects) of https://blog.google 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?
  - JoshTriplett 9y ago
    > 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 http://clients1.google.com/generate_204 needs that? (And yeah, that should always have been on a separate domain entirely, but, hindsight.)
  - b3lvedere 9y ago
    "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.
Bhilai 9y ago
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 9y ago
  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.
SimeVidas 9y ago
Why does Google own .soy?
- CydeWeys 9y ago
  Does this answer your question? https://www.iam.soy/ https://www.iam.soy/
- x0x0 9y ago
  half a billion spanish speakers maybe
CydeWeys 9y ago
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.
- numbsafari 9y ago
  Seeing progress on this ticket would be really helpful: https://issuetracker.google.com/issues/62051227 https://issuetracker.google.com/issues/62051227
  - CydeWeys 9y ago
    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.
- ikeboy 9y ago
  Why did Chrome make it take an extra step or two to look at the issuer of a certificate?
  - CydeWeys 9y ago
    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.
    - 9y ago

86 points by el_duderino 9y ago

> 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 9y ago
Whe you control the TLD AND the preload list what’s to stop you?
- CydeWeys 9y ago
  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.

DrinkWater 9y ago

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

schoen 9y ago
> 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 https://www.youtube.com/watch?v=MFol6IMbZ7Y (This kind of attack is a primary motivation for the existence of HSTS.)
- ktta 9y ago
  Relevant part starts here https://youtu.be/MFol6IMbZ7Y?t=23m17s https://youtu.be/MFol6IMbZ7Y?t=23m17s Although for anyone interested in HTTPS, I'd recommend watching the whole thing. Very entertaining.
deleted 9y ago
[deleted]
hannob 9y ago
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.
niftich 9y ago
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.
Ajedi32 9y ago
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 9y ago
  > 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.

d0ugie 9y ago

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 9y ago
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 9y ago

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

CydeWeys 9y ago
Think bigger than that, is all I can say ;)
bhartzer 9y ago
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 9y ago
  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 9y ago
    The data I’ve seen there is correct.

b3lvedere 9y ago

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 9y ago
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.
- ehPReth 9y ago
  I recall the blog having a much cleaner URL (no redirects) of https://blog.google 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?
- JoshTriplett 9y ago
  > 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 http://clients1.google.com/generate_204 needs that? (And yeah, that should always have been on a separate domain entirely, but, hindsight.)
- b3lvedere 9y ago
  "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.

Bhilai 9y ago

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 9y ago
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.

SimeVidas 9y ago

Why does Google own .soy?

CydeWeys 9y ago
Does this answer your question? https://www.iam.soy/ https://www.iam.soy/
x0x0 9y ago
half a billion spanish speakers maybe

CydeWeys 9y ago

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.

numbsafari 9y ago
Seeing progress on this ticket would be really helpful: https://issuetracker.google.com/issues/62051227 https://issuetracker.google.com/issues/62051227
- CydeWeys 9y ago
  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.
ikeboy 9y ago
Why did Chrome make it take an extra step or two to look at the issuer of a certificate?
- CydeWeys 9y ago
  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.
  - 9y ago