I’ve coded my app to use https, but if a https transaction fails for any reason, I assume it’s because the server isn’t configured for https, and thereafter start all transactions with http. Seems like that’s a vulnerability. Likewise, a script kiddie using a proxy to intercept the traffic on his client hardware would be able to make all https transactions fail.
I’m told that if someone tries to MITM your app’s HTTPS request then the request should fail (invalid certificate) and your app should fail with an error, not fallback to HTTP. In a world where SSL is reliably available, sure, but maintaining valid SSL certs is a task in itself. For example, letsencrypt recently revoked some of their certificates and forced renewal of same because of some security problem. Aside from revocations, certs are short term and have to be renewed, and the renewal process involves a lot of stitchware, and can fail. If SSL goes down, I don’t want my site to go dark.
What is the best guidance for either:
More reliably maintaining certificates (such that if they do fail, the resulting downtime falls within the "five nines" SLA unavailability window) without it being such a manual headache, or
Allowing the site to continue to work if SSL has failed? Is it easy to allow most activity to proceed using http, but allow known-critical transactions to require https.
Note that no browsers are involved in the scenarios that concern me.