5 ms·

Google doesn't have HSTS (on google.com).

ocdtrekkie 4y ago
The irony. Google understands that HSTS negatively impacts availability massively, and shouldn't be used for production websites, but recommends it to others.
- Dylan16807 4y ago
  I don't care about the "availability" of an HTTP 500 page that much, to be honest.
- vanchor3 4y ago
  Don't forget enforcing it on certain TLDs, even for internal DNS records used for testing.
  - ocdtrekkie 4y ago
    Yes, but also I put a lot of the blame for this on ICANN's greed. They could've and should've refused to issue .dev, if they were doing a good and responsible job stewarding the domain space.
- josephcsible 4y ago
  But HSTS absolutely should be used for production websites.
  - ocdtrekkie 4y ago
    It really shouldn't. HSTS is a harmful specification which both robs user agency and prohibits good service uptime. In 100% of all cases HSTS is in play, it's pretty much a cert that expired yesterday (aka, not actually a security risk). In exchange for this problem, HSTS demands that browsers stop acting as user agents and refuse to operate, no matter what the user says. It allows the server to dictate what the browser is supposed to do, without any bypass. Finally, the number one person who ends up wasting a lot of time trying to bypass HSTS: The dude trying to fix the certificate. A hilarious number of poorly-considered services have admins administrate the certificate from the web interface... which it won't allow the admin to access because of HSTS. This ends up exacerbating a simple problem into a complex one, and adds significantly to downtime. HSTS should be considered hostile and not recommended until amended with the removal of the "no user agency" clause. Honestly, a real world practical improvement for the entire HTTPS stack would be a more gentle expiration curve (browsers loading sites with expired certs for a week or so with a yellow address bar or something seems like a good idea, it's not like sites publish their private keys the day a cert expires). Unfortunately, the authors of HSTS did not consider the real world when developing their spec, they considered a virtually non-existent security case they wanted to address, and built a solution to an imaginary problem with significant real world negative impact.
    - quickthrower2 4y ago
      Yellow address bar when getting near to expiration would also work, right without changes to what expiration means. Then people using SSL will renew earlier to avoid embarrassment.
      - ocdtrekkie 4y ago
        That's also arguably acceptable, yes, though the renewal timeline is already quite aggressive if you aren't able to use ACME for whatever particular reason. I have yet to see any example of a real security risk involving a barely expired certificate. It seems that we invented a way to make the web extremely fragile for... really no good reason.
        execveat 4y ago
        Without HSTS browser might fall back to HTTP which would disclose passwords and sessions leading to account compromise. I'm a penetration tester / red teamer and we do this all the time. DEFCON has been hosting a Wall of Sheep since forever. They capture and analyze traffic then publish the leaked credentials and other fun stuff. Apparently it's still going: https://www.youtube.com/watch?v=4ZabsNgMHCM https://www.youtube.com/watch?v=4ZabsNgMHCM . Here's your example.
        josephcsible 4y ago
        > if you aren't able to use ACME for whatever particular reason. What are some technical reasons you might not be able to do this? I've only ever seen stupid bureaucratic reasons firsthand.
        ocdtrekkie 4y ago
        So a lot of times you may be feeding a certificate into a bespoke enterprise application. Some of them just load it into IIS and off you go, but some of them end up being Java platform crud where you need weird incantations just to import them at all. (And sometimes it's those same weird applications that also decide to opt you into HSTS...)

The irony. Google understands that HSTS negatively impacts availability massively, and shouldn't be used for production websites, but recommends it to others.

Dylan16807 4y ago
I don't care about the "availability" of an HTTP 500 page that much, to be honest.
vanchor3 4y ago
Don't forget enforcing it on certain TLDs, even for internal DNS records used for testing.
- ocdtrekkie 4y ago
  Yes, but also I put a lot of the blame for this on ICANN's greed. They could've and should've refused to issue .dev, if they were doing a good and responsible job stewarding the domain space.
josephcsible 4y ago
But HSTS absolutely should be used for production websites.
- ocdtrekkie 4y ago
  It really shouldn't. HSTS is a harmful specification which both robs user agency and prohibits good service uptime. In 100% of all cases HSTS is in play, it's pretty much a cert that expired yesterday (aka, not actually a security risk). In exchange for this problem, HSTS demands that browsers stop acting as user agents and refuse to operate, no matter what the user says. It allows the server to dictate what the browser is supposed to do, without any bypass. Finally, the number one person who ends up wasting a lot of time trying to bypass HSTS: The dude trying to fix the certificate. A hilarious number of poorly-considered services have admins administrate the certificate from the web interface... which it won't allow the admin to access because of HSTS. This ends up exacerbating a simple problem into a complex one, and adds significantly to downtime. HSTS should be considered hostile and not recommended until amended with the removal of the "no user agency" clause. Honestly, a real world practical improvement for the entire HTTPS stack would be a more gentle expiration curve (browsers loading sites with expired certs for a week or so with a yellow address bar or something seems like a good idea, it's not like sites publish their private keys the day a cert expires). Unfortunately, the authors of HSTS did not consider the real world when developing their spec, they considered a virtually non-existent security case they wanted to address, and built a solution to an imaginary problem with significant real world negative impact.
  - quickthrower2 4y ago
    Yellow address bar when getting near to expiration would also work, right without changes to what expiration means. Then people using SSL will renew earlier to avoid embarrassment.
    - ocdtrekkie 4y ago
      That's also arguably acceptable, yes, though the renewal timeline is already quite aggressive if you aren't able to use ACME for whatever particular reason. I have yet to see any example of a real security risk involving a barely expired certificate. It seems that we invented a way to make the web extremely fragile for... really no good reason.
      - execveat 4y ago
        Without HSTS browser might fall back to HTTP which would disclose passwords and sessions leading to account compromise. I'm a penetration tester / red teamer and we do this all the time. DEFCON has been hosting a Wall of Sheep since forever. They capture and analyze traffic then publish the leaked credentials and other fun stuff. Apparently it's still going: https://www.youtube.com/watch?v=4ZabsNgMHCM https://www.youtube.com/watch?v=4ZabsNgMHCM . Here's your example.
      - josephcsible 4y ago
        > if you aren't able to use ACME for whatever particular reason. What are some technical reasons you might not be able to do this? I've only ever seen stupid bureaucratic reasons firsthand.
        ocdtrekkie 4y ago
        So a lot of times you may be feeding a certificate into a bespoke enterprise application. Some of them just load it into IIS and off you go, but some of them end up being Java platform crud where you need weird incantations just to import them at all. (And sometimes it's those same weird applications that also decide to opt you into HSTS...)