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.
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.
http://bitsup.blogspot.com/2015/03/opportunistic-encryption-...