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.
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.
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?
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.
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?
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?
For unreliable webforms, Ctrl-A, Ctrl-C is useful.
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.
With HSTS, that button goes away in browsers.
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.
> "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.
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.
Sorry, but sometimes security is absolute.
Like, how does it happen, ever?
And what happens to your users' credentials if you do?
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)