> Well yes, but is it self-signed (or otherwise "invalid" cert) because the user was MITM or because that's what the server handed over?
Is it HTTP because the user was MITM or because that's what the server handed over?
Again, why one rule for HTTP and another for self-signed. It is inconsistent. HTTPS sites being hacked and turned into HTTP is a real and common problem, yet where is HTTP's red bar of danger?
If you send an HTTPS request you can't get back HTTP. HTTP vs. HTTPS was chosen by the client. A MITM cannot downgrade HTTPS to HTTP.
And thus the difference in behaviors because of the difference in intent. If you initiate HTTPS you intend for it to be secure and failure to do that is a fail condition, big red warning, this request faild. If you initiate HTTP you did not intend for it to be secure.
Yes this is a problem of technicals vs. UX but it's not arbitrary or random.
Merely a wonder out loud. How does the average user respond to the site not loading?
Lets say for example I managed to break into a Facebook edge server and disable port 443 so users get a connection failed message. On average would they themselves switch to http (or just type facebook.com into the browser, which interprets as the HTTP version) and receive my spoofed login page?
Please disregard the fact it would be near impossible to get into Facebook's edge servers and that they'd probably hit a different one on the reload, etc, etc. Merely used Facebook as an example as it's hugely popular and arguably addictive site (users need their 'fix', damn the security!)
Is it HTTP because the user was MITM or because that's what the server handed over?
Again, why one rule for HTTP and another for self-signed. It is inconsistent. HTTPS sites being hacked and turned into HTTP is a real and common problem, yet where is HTTP's red bar of danger?