4 ms·

It's moving that direction. As it stands, any website can opt-in to this behavior for future visitors with HSTS[0], or even for first time visitors with HSTS pr

by f2n 9y ago

It's moving that direction. As it stands, any website can opt-in to this behavior for future visitors with HSTS[0], or even for first time visitors with HSTS preload[1]. And Google has been doing HSTS preload on their .google TLD for several years, and recently rolled it out to their .foo and .dev [2] TLDs [0] https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security [1] https://hstspreload.org/ https://hstspreload.org/ [2] https://security.googleblog.com/2017/09/broadening-hsts-to-secure-more-of-web.html https://security.googleblog.com/2017/09/broadening-hsts-to-s...

WorldMaker 9y ago
There were a lot of complaints about Google doing that with .dev given the number of other companies and developers that use .dev for random LAN things, but an HSTS Preload for random LAN things isn't a bad idea in that it can prevent some types of mistakes going to production like bad HTTPS->HTTP redirects in an application. Obviously, Google themselves thought it a good idea to test that in their development environments.
- f2n 9y ago
  The people doing random things with fake .dev domains were going to get bit in the ass one way or another. You can't just make up your own domain and hope no one ever does anything conflicting with it.
  - untog 9y ago
    > You can't just make up your own domain and hope no one ever does anything conflicting with it. Actually you can! You just need to use one reserved for that purpose: > In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System. https://en.wikipedia.org/wiki/.test https://en.wikipedia.org/wiki/.test
    - snuxoll 9y ago
      Sure, but you should NEVER use a domain that isn’t delegated to you or explicitly reserved by the IANA for local purposes. Plenty of people used .int as well which is now a gTLD, you can’t complain about a name you don’t own breaking down the line.
scott_karana 9y ago
I was excited until I realized that HSTS Preload is just a hardcoded list in the Chrome source!? Ugh, that's sort of disappointing :( Couldn't something like a TXT record also address this, but on a cross-client, scalable fashion? Like how SMTP with SPF or DKIM works right now. (And yes, I know DNS also has trust problems!) At the very worst, a central, programmatic source of truth, like DNSBL and company... just like how Google offers their "malware sites" hash table for all to use.
- pfg 9y ago
  Using a TXT record for this purpose would achieve nothing. Just like an SSLStrip attack would strip https:// https:// links and redirects, an attacker can simply block or spoof the DNS response. This doesn't add anything that you don't get with regular header-based HSTS. DNSSEC has no practical impact on this due to a lack of adoption both on the domain and end-user resolver side. (Not to mention that it's a terrible protocol.) Note that the HSTS preload list is not only used by Chrome, but practically all major browsers. For all intents and purposes it currently is the central source of truth. I imagine if the size ever becomes a problem, browsers will switch to a mechanism like Safe Browsing to distribute the list.
JepZ 9y ago
While I understand why HSTS makes sense I hate it and I think it comes from poorly tooling around it. Two examples: 1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list. 2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers... For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/ https://hstspreload.org/removal/

by f2n 9y ago

WorldMaker 9y ago

There were a lot of complaints about Google doing that with .dev given the number of other companies and developers that use .dev for random LAN things, but an HSTS Preload for random LAN things isn't a bad idea in that it can prevent some types of mistakes going to production like bad HTTPS->HTTP redirects in an application. Obviously, Google themselves thought it a good idea to test that in their development environments.

f2n 9y ago
The people doing random things with fake .dev domains were going to get bit in the ass one way or another. You can't just make up your own domain and hope no one ever does anything conflicting with it.
- untog 9y ago
  > You can't just make up your own domain and hope no one ever does anything conflicting with it. Actually you can! You just need to use one reserved for that purpose: > In 1999, the Internet Engineering Task Force reserved the DNS labels example, invalid, localhost, and test so that they may not be installed into the root zone of the Domain Name System. https://en.wikipedia.org/wiki/.test https://en.wikipedia.org/wiki/.test
  - snuxoll 9y ago
    Sure, but you should NEVER use a domain that isn’t delegated to you or explicitly reserved by the IANA for local purposes. Plenty of people used .int as well which is now a gTLD, you can’t complain about a name you don’t own breaking down the line.

scott_karana 9y ago

I was excited until I realized that HSTS Preload is just a hardcoded list in the Chrome source!? Ugh, that's sort of disappointing :( Couldn't something like a TXT record also address this, but on a cross-client, scalable fashion? Like how SMTP with SPF or DKIM works right now. (And yes, I know DNS also has trust problems!) At the very worst, a central, programmatic source of truth, like DNSBL and company... just like how Google offers their "malware sites" hash table for all to use.

pfg 9y ago
Using a TXT record for this purpose would achieve nothing. Just like an SSLStrip attack would strip https:// https:// links and redirects, an attacker can simply block or spoof the DNS response. This doesn't add anything that you don't get with regular header-based HSTS. DNSSEC has no practical impact on this due to a lack of adoption both on the domain and end-user resolver side. (Not to mention that it's a terrible protocol.) Note that the HSTS preload list is not only used by Chrome, but practically all major browsers. For all intents and purposes it currently is the central source of truth. I imagine if the size ever becomes a problem, browsers will switch to a mechanism like Safe Browsing to distribute the list.

JepZ 9y ago

While I understand why HSTS makes sense I hate it and I think it comes from poorly tooling around it. Two examples: 1. HSTS Preload: I am not 100% sure but, AFAIK your browser gets the list once during installation and then sticks with it until he receives another software update. I think the list should be dynamic (e.g. like adblock lists). That way even older browsers would have an up-to-date HSTS Preload list. 2. Like everything else HSTS records have a lifetime, but when you use your dev-tools to delete your browser cache it doesn't delete the HSTS information. So every time you want to delete them you have to go to some net-internals... browser configuration to explicitly delete a HSTS record for a specific domain. It's even easier to delete serviceworkers... For a long time I also didn't like that you could not easily remove your own domain from a preload list, but that fortunately changed and now there is a website where you can easily request to be deleted from the preload lists. The only hitch here is that as it takes a few month until every browser on this planet got a software update the new list will also have to wait for a while: https://hstspreload.org/removal/ https://hstspreload.org/removal/