Unless your site is nothing but a dumb billboard serving nothing but static assets (and maybe even then...), the inability to serve HTTPS traffic should be considered a breaking issue and you shouldn't be serving anything until your HTTPS is restored. "Reduced security" is not a valid fallback option.

That might not be something that a company's management team wants to hear, but indicating to your users that falling back to insecure HTTP is just something that happens sometimes and they should continue using your site is one of the worst things you can possibly do in terms of security.

Here's a real example of how HSTS can break a site: My personal, non-public wiki is secured by HTTPS with a certificate valid for 5 years. I thought it would be neat to enable HSTS for it because what could go wrong?

Well, just last week the HTTPS certificate expired in the middle of the day. I had about a half days' worth of work typed up into the browser's text field and when I clicked "submit", all of my work vanished and Firefox only showed a page stating that the certificate was invalid and that nothing could be done about it. I clicked the back button, same thing. Forward button, same thing. A half-days worth of work vanished into thin air.

Is this my fault for letting the certificate expire? Absolutely. Should I have used letsencrypt so I didn't have to worry about it. Sure. Should I be using a notes system that doesn't throw away my work when there's a problem saving it? Definitely. I don't deny that there's lots that I could have done to prevent this from being a problem and lots that I need to fix in the future.

But it does point out that if you use HSTS, you have to be _really_ sure that _all_ your ducks are in a row or it _will_ come back to bite you eventually.

Your ducks didn't come back to bite you. Your ducks did exactly what they were supposed to do (and furthermore, exactly what you want them to do).

Maybe you don't care about protecting whatever data you were entering into your wiki, but in most (if not all) cases of sending data to companies you interact with, you do not want your user-entered data being sent in the clear to the server, or even worse, being sent to the server of a malicious attacker performing a MITM attack. What you want is for your browser to stop sending the data entirely when it encounters a suspicious situation (such as an HTTPS->HTTP downgrade or an expired cert), which is exactly what happened.

Again, "reduced security" is not a valid failure state. It's like having a button on your front door that says "Lost your key? Just press this button and the door will unlock." At that point, why even have a door lock anyway?

See https://en.wikipedia.org/wiki/Downgrade_attack

Without HSTS how do you think your scenario plays out differently? Your expired cert still isn't good, and I assure you Firefox isn't going to say "Oh, there's an insecure HTTP site we could try, would you like me to send the HTTP POST there instead?". So I think this only works out "fine" in the scenario where lack of HSTS means you just never use any security at all. Which is a fairly different proposition.

Since the expired cert can't be distinguished from an attack my guess is that the text contents aren't lost when that transaction fails due to the expired cert (as then bad guys could throw your data away which isn't what we want) so I think you could just have paused work, got yourself a new valid certificate, and then carried on.

Now, of course, it may be that your web app breaks if you do that, the prior session you were typing into becomes invalid when you restart, and new certificates can't be installed without restarting, that sort of thing, but that would be specific to your setup.

Wouldn't the browser allow you to inspect the cert and choose to continue the connection? Then you can decide for yourself if you trust the cert.

> I had about a half days' worth of work typed up into the browser's text field and when I clicked "submit", all of my work vanished and Firefox only showed a page stating that the certificate was invalid and that nothing could be done about it.

that's not a valid argument against HSTS! the browser behaviour with regard to your data is outrageous, and shouldn't be tolerated. and i'm saying this as a longtime firefox user. the browser just sucks, big time.

"luckily", as a vim junkie, i can't stand the textarea at all, and do anything that requires more effort than, say, this comment, in vim, then copy/paste over when i'm done. still, we should have gotten $VISUAL embedding fifteen years ago: what's happened, Mozilla? lining up your Pockets the whole time?

Curious: Wouldn’t you be singing the same tune if the browser/system crashed? Or the database backend for the wiki went down? Or..

I thought the general way was to automatically save any progress in localstorage/etc ready to be retrieved if needed once the problem is fixed?

I learned in the days of DOS to keep the "Ctrl+S" hotkey close and use it frequently. Combined with backups, haven't had a big data loss since that time ((crosses fingers)).

For unreliable webforms, Ctrl-A, Ctrl-C is useful.

Very politely, I want to comment that the problem wasn't your HTTPS cert expiring unexpectedly, but how your application handled storing in progress work.

Firefox is especially good about keeping previously filled in form fields around for a bit, so once you fixed the SSL issue there's a good chance that you could retrieve your form post.

If you don't use HSTS, you have to be _really_ sure that _all_ your users fully understand the risks of using an unencrypted connection.

In the example you gave, wouldn't you have lost all your work anyway without HSTS? I don't think browsers supply an easy way to retry POST to the corresponding http: URL whether HSTS is set up or not.

Without HSTS, you can inspect the cert and click through the invalid certificate warning.

With HSTS, that button goes away in browsers.

This is exactly what should have happened.

HSTS worked perfectly, your poor maintenance of certificates and your site lost you half a days worth of work.

Some people need to touch the stove and feel the pain...if you blame someone else for you touching the stove that is just willful ignorance.

> the inability to serve HTTPS traffic should be considered a breaking issue

> "Reduced security" is not a valid fallback option.

Agreed! But if my HTTPS is broken, I might well want to replace my site with an HTTP page explaining that we'll be back soon. If that is impossible until the max_age expires, that can lead to an awkward explanation to the higher-ups.

> if my HTTPS is broken, I might well want to replace my site with an HTTP page explaining that we'll be back soon

1) You're not going to be able to do that for anyone who has bookmarked the site, or loads it from their history / address bar, with the https already included. Under what circumstances, other than someone hand-typing a URL, do you expect anyone to reach your site by HTTP? (And note that any such user can potentially get compromised, such as by ISPs.)

2) Search engines will link to your site with the https pages they found when crawling. And if you stay down long enough for search engines to notice, you have a bigger problem and a much more awkward explanation to give.

3) Many kinds of failures will prevent anyone from reaching the whole domain, or the IP address the domain currently points to, or similar. Have an off-site status page, social media accounts, and similar.

Everything you said is true, but it does not provide any reasonable argument that HSTS as it is designed and implemented is a valid way to enforce this. The potential for malicious or accidental misuse to cause an effectively immediate and irreversible domain-wide DoS is simply too great. I am quite surprised that the feature made it through planning and implementation to begin with.

This is a silly and absolutist position to take on HTTP. Everything depends on context, and in many cases it is far better to serve things over open HTTP than go offline.

If you had reason to previously set up your site with HTTPS, you should never fallback to serving anything other than static assets (and even then, you better have a damn good reason) over HTTP from that same domain. Period.

Sorry, but sometimes security is absolute.

In what situation that you can conjure up is being forcibly reduced to HTTP distinguishable from being down?

Like, how does it happen, ever?

And what happens to your users' credentials if you do?

When you have publicly accessible resources that must be available to all, but you can't guarantee that the accessing systems are configured correctly to use HTTPS.

There are plenty of scenarios in which this happens online:

* Legacy systems (e.g. Aminet)

* Software distribution (e.g. apt mirrors)

* Anything involving FTP where a HTTP mirror would be useful (e.g. overcoming FW restrictions)

* Anything where permissionless access is a requirement (HTTPS is a permissioned system)

Not being able to serve HTTPS is not a real concern. It seems possible but in reality it simply won’t happen. If it ever does break, you fix it, you don’t change protocols.

Once you go HTTPS you’re all in regardless whether or not you’ve set HSTS headers. Let’s say your HTTPS certificate fails and you can’t get it replaced. So what, you’re going to temporarily move back to HTTP for a few days? Not going to happen! Everyone has already bookmarked/linked/shared/crawled your HTTPS URLs. There is no automated way to downgrade people to HTTP, so only the geeks who would even think to try removing the “s” will be able to visit. And most geeks won’t even do that because we’ve probably never encountered a situation where that has ever helped.

It happened to me. I served my site over TLS and used HSTS. Hosting got expensive, so I rebuilt my site on Github Pages and hosted there. It was another year and a half before they rolled out HTTPS for custom domains.

In that case, old visitors were rejected due to the policy. I wish I had set a lower duration.

> old visitors were rejected due to the policy

Also because their links and bookmarks would have all failed.

But HSTS also blocks the workaround of "just Google it and find the page again"

You can use the webmaster tools on Google to fix the indexing. It takes a few days, but worth the effort.

The issue is that the browser won't let you visit the insecure URL, regardless of how you get to it.

It won't work because the HSTS setting the visitor got months ago told it not to.

That is exactly what I am talking about.

In the webmaster tools, you want to get google to remove all references to the non https versions. Ensure https is up on all URL's, then use their tools to re-index everything and remove all references to http://

Are you saying you can't set up https on some of your URL's?

The argument here is that enabling HSTS can be dangerous because if you enable it and then later become unable to serve HTTPS for some reason, you will have no way of turning it off. Even if you get your clients to manually edit their bookmarks to use HTTP again, their browsers will just rewrite the url to HTTPS anyway.

There's no issue with switching FROM HTTP to HTTPS: that's easy, just redirect them. The issue is if you have to switch back.

I completely understand. The bookmark scenario is even easier than the google links. You simply set up https and the cached HSTS entries will work.

The scenario is assuming you have a working HSTS setup but then become unable to serve HTTPS for some reason (e.g. cert expires and you can't acquire a new one, or the provider just drops support for SSL for some reason, or you are forced to change providers to one that doesn't support SSL)

HSTS can't be enabled on plain HTTP so it's not possible to create the problematic scenario if you never had SSL enabled to begin with. The problem is switching from SSL to non-SSL, not the other way around.

Even if you can't renew a cert you paid for, in most cases you should be able to get a temp cert from Lets Encrypt and renew it every couple of months. I have free wildcard certs for many of my domains. HSTS just requires HTTPS. It doesn't pin the cert to a particular CA. That is what CAA records are for.

Are you saying that you have applications that require HTTP port 80 only?

It's true that letsencrypt makes this less likely to be an issue. But there is still the possibility that maybe your hosting provider drops support for HTTPS or you are forced to switch to a provider that doesn't support HTTPS. The parent gave one example of this with their GitHub Pages situation.

Also: HSTS applies to all ports once applied, not just 80/443. That is another important thing to consider before turning it on.

It is a good point.

I would like to add that a lot of web-apps break if they aren't served over HTTPS regardless, due to the Secure flag being set on cookies. For example if we run ours in HTTP (even for development) it will successfully set the cookie (+Secure +HttpOnly) but cannot read the cookie back and you get stuck on the login page indefinitely.

So we just set ours to a year, and consider HTTPS to be a mission critical tier component. It goes down the site is simply "down."

HSTS is kind of the "secret sauce" that gives developers coverage to mandate Secure cookies only. Before then we'd get caught in "what if" bikeshedding[0].

[0] https://en.wiktionary.org/wiki/bikeshedding

The only risk is if you've served HTTPS traffic properly with HSTS headers to users, and then your server is later unable to correctly handle HTTPS traffic. Note that HSTS headers on a non-HTTPS response are ignored.

Whilst there's cases where you might fail to serve HTTPS traffic temporarily (i.e. if your cert expires and you don't handle it) almost all HTTPS problems are quick fixes, and are probably your #1 priority regardless of HSTS. If your HTTPS setup is broken and your application has any real security concerns at all then it's arguably better to be inaccessible, rather than quietly allow insecure traffic in the meantime, exposing all your users' traffic. I don't know many good reasons you'd suddenly want to go from HTTPS back to only supporting plain HTTP either. I just can't see any realistic scenarios where HSTS causes you extra problems.

I think it's a good point which is why I set the time low, even though many other resources set it to a week or longer. I just don't like very long cache times for anything that can break, so that site owners have a little more flexibility in case something goes wrong down the line.

Speaking of HSTS.. does anyone here know if Firebase Hosting (Google Cloud) plans to support custom HSTS headers with custom domains? I can’t add things like includesubdomains or preload at present unfortunately

> if for whatever reason you are no longer able to serve HTTPS traffic

Isn't that how it should work? Would you rather use Gmail over HTTP if its HTTPS stopped working? Besides, just supporting HTTP fallback means you're much more vulnerable to downgrade attacks -- it's the first thing attackers will attempt to use.

I set HSTS to 10 years. My infrastructure isn't even capable of serving HTTP other than for LetsEncrypt certs. An outage on HTTPS is a full outage. Most of my sites handle user data in some way, so HTTPS is mandatory anyway, as per my interpretation of the GDPR.

I don't get people who worry about _feature_ pinning like this.

I imagine them looking at a business continuity plan and being aghast - why are we spending money to manage the risk from a wildfire in California overwhelming our site there, yet we haven't spent ten times as much on a zombie werewolf defence grid or to protect against winged bears?

HSTS defends against a real problem that actually happens, like those Californian wildfires, whereas "whatever reason you are no longer able to serve HTTPS traffic" is a fantasy like the winged bears that you don't need to concern yourself with.