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.

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?

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.

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

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

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.

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.