5 ms·

The error page is plain http, doesn't HSTS stop that?

by belltaco 4y ago

Unjg4gByHdjnyvp 4y ago
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.
        4y ago

The error page is plain http, doesn't HSTS stop that?

Unjg4gByHdjnyvp 4y ago

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