Don't forget enforcing it on certain TLDs, even for internal DNS records used for testing.

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.

I don't care about the "availability" of an HTTP 500 page that much, to be honest.

But HSTS absolutely should be used for production websites.

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.

> HSTS should be considered hostile and not recommended until amended with the removal of the "no user agency" clause.

Have you seen the new malicious websites with fake CAPTCHAs that say "click allow to this dialog box to prove you're human"? If you give nontechnical users an easy way to bypass a security check, the bad guys will just tell them to do so, and they'll listen. And remember that if a technical user really does need to bypass HSTS, they can, even if it means editing a SQLite database by hand.

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.

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.

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 . Here's your example.

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

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