> It's something else entirely though for a browser to unilaterally declare a site's security to be unacceptably weak (perhaps by choice or often by misconfiguration -- both of which we can agree need to be fixed) to the extent that the browser absolutely refuses to allow the user to connect, regardless of how crucial the situation and irrespective of the fully-informed expressed will of the user to connect in any case.<p>It's not unilateral at all. Sites have a choice if they offer connections over https, it's far from universal. By accepting http connections the site has indeed notified the browser that it wants to only allow secure connections. The problem is that a browser is refusing to connect to a server that has declared that it requires security but that it can't connect to because the browser has implemented it correctly and the server hasn't. It doesn't matter if that's temporary or not, the message of "I need a secure connection" has been understood.<p>Perhaps the browser should have a fall-back to http button, in which case the server's choice of how to redirect to https will be the deciding factor. I doubt many users routinely type <a href="https://" rel="nofollow">https://</a> to signify that it's <i>their</i> wish to only have a secure connection, so in this case it is certainly the server that's enforcing it.<p>We need to move to TLS by default with no unencrypted HTTP, that can allow old crypto and unverified certificates. That will turn http into kinda-secure http but not compromise on the security of sites that have specifically declared themselves as wanting to support only secure connections.