If they are going to show a green padlock, the connection needs to be reasonably secure, because the icon is supposed to indicate as such. With HTTP there are no icons being shown indicating you are secure, so there should be no expectation of security.
Chrome's security team is working on a proposal to show negative UI indicators to sites using HTTP:
That's always been a massive pet peeve of mine. HTTP gets a "free pass" (white/generic) but if you dare to self sign, BIG RED SCARY ALERT. Yet nobody thinks self-signed is less secure than HTTP, the worst you could claim is "equally as secure" (when the reality is it makes it subtly harder to eavesdrop, but provides no MITM protections at all).
They should just give HTTP and self-signed a red bar, and stop with the silly warning pages (unless the site previously had a CA signed certificate and HSTS). Just treat HTTPS self-signed the same as HTTP, that's all I ask.
Well one of the problems is that SSL does two things: Server Authentication and Encryption. Since there is nothing backing the identity of a self-signed certificate, it can easily masquerade as whatever it wants.
Yes, a CA-issued cert and a self-signed are equilvent when it comes to encryption. But with Server Authentication, its too easy for self-signed certificates to mislead people, and that is deserving of the red-X in my opinion.
Treating self-signed HTTPS as HTTP would be a behavior change with subtle implications that are hard to get right.
For instance, let's say that I log into https://example.com today, and it has a valid cert (but no HSTS). It sets a cookie with the "HTTPOnly" and "Secure" flags, indicating that it should only be sent over HTTPS, and not exposed to e.g. JS. I come back tomorrow, and https://example.com is now sporting a self-signed certificate.
There are now three possibilities for what's going on here. One is that this is an attack, so the browser should by default block the site. One is that the site downgraded to a self-signed certificate because they want to be treated as HTTP. One is that the site downgraded to a self-signed certificate because of misconfiguration, but you know out-of-band that it should be treated as HTTPS (the fingerprint matches what the support phone number tells you, or you're on a secure network, or something).
Those last two situations are different. In the former, that cookie should no longer get sent, just as it would not be sent to http://example.com. In the latter, it should be sent.
Right now, on the assumption that "intended to downgrade to HTTP with opportunistic encryption" is rare, the browser will put up a scary alert to make sure you're verifying the security of the connection out-of-band, and then send the cookie if you click through the warning. You'd have to somehow find a way for site owners to signal that they intend to do OE, and they don't want to be treated as HTTPS -- including not getting secure cookies, not getting features like web crypto or service workers, etc.
Mozilla is working on exposing opportunistic encryption via the http:// scheme, instead of the https:// one, which sidesteps all of this: if you happen to connect on https, you'll still get a cert warning. This approach is also consistent with OE being "equally as secure" against a slightly nontrivial attacker.
If it's using a self signed cert, it's as secure as HTTP, and should be treated a such.
That means your cookie shouldn't be sent. (And, optimally, the address bar becomes red.)
If you want to trust the self signed cert, you should be able to do so, and the optimal place for that is at an scary-looking icon on the same place the padlock would be.
Other features shouldn't depend only on the protocol used.
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? The former really does deserved a BIG RED SCARY ALERT, the later not so much. But distinguishing those two reliably is not feasible, so browsers fail-safe into assuming it's a potential MITM.
> 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!)
Chrome's security team is working on a proposal to show negative UI indicators to sites using HTTP:
https://www.chromium.org/Home/chromium-security/marking-http...