A self-signed certificate for a site that I expect to be delivered via HTTPS (either because I typed "https://", or clicked a link that starts with "https://", or because I opened a bookmark that I know to be secure) is definitely more likely to indicate a MitM attack, yes.
If you're arguing for opportunistic encryption for "http://" links, I'm fine with that, but if I'm expecting HTTPS, I want either a trusted certificate or a big, red warning that's hard (or impossible) to bypass. I'm also not convinced that opportunistic encryption is worth the effort nowadays, given that the price of a certificate is zero in all but the most obscure of use-cases.
I think the argument here is that, say, somebody's random blog or forum for their local group or whatever doesn't really need to worry about well-equipped state actors or the mafia or whoever MITM-ing them (and wouldn't be able to defend that anyway if they really became a target).
They do care about someone casually sniffing the password to the blog's admin interface when they post from a coffeeshop, though. But for years -- it's only recently that viable zero-dollar browser-trusted certs became a possibility -- we told those people "screw you, you're so dangerous for wanting that, we have to produce the loudest, nastiest, most terror-inducing popup warnings we can come up with just to slap on your disgustingly evil site and shame you into paying hundreds of dollars to a corrupt cartel".
Which confuses the poor schmuck who just wants that little bit of security against that particular, but far more common than MITM, threat model. De-conflating the two concerns -- inability to eavesdrop, and inability to impersonate -- might not be such a bad idea for those people.
Right, but doing this for HTTPS URLs would change the semantics of those URLs. People expect HTTPS to mean you either have a trusted CA certificate or you see a big, red warning. Changing these semantics would be terrible for security.
You can argue for opportunistic encryption in HTTP, but I'd argue that it's cheaper and easier for most affected parties if browser vendors just help push the price of publicly-trusted certificates to zero, which is exactly what Mozilla and Chrome (among others) did. Rolling out a new protocol would've taken years as well, so I don't think we've lost much time choosing this approach.
People expect HTTPS to mean you either have a trusted CA certificate or you see a big, red warning. Changing these semantics would be terrible for security.
No. You and some other folks on HN expect that.
The general public does not know or care that HTTPS conflates multiple issues. Some random person who just wants to have a secure way to hit the login page of their blog does not know or care. There's room for a spectrum of things and ways to indicate where on that spectrum a particular site is, but HTTPS has been forced to be the one-size-fits-every-entity-in-the-universe solution and so has bundled in things that just aren't relevant to a lot of use cases and made it a binary "either you implement 100% of this 100% of the time or else" proposition when that makes no sense to do.
Hence the huge warning page in Chrome warning about certificate errors. In the corporation I work for it has stopped a number of very nasty sites from compromising our security.
