You can't assume protection, whereas with http you assume no protection.

So, if you can't trust certificate (not when it is invalid), just show same level of protection as http.

The problem is that a http: protocol specifier implies no protection; the moment you follow the link, you know that the connection is not secured. Whereas a self-signed https: connection could be due to someone MITM'ing a site that generally uses CA's, in which case "no warning message" implies that the site is secured. The browser message has to make it clear to the user that something possibly unexpected is going on.

Which CAs have never been subject to a National Security letter? Can't say cuz you can't know? Lets talk about that false sense of security indeed.

This is one of the threats addressed by https://www.certificate-transparency.org/ .

If a CA issues a rogue cert and _does_ add it to the CT log, it's discoverable, at least in retrospect.

If a CA issues a rogue cert and _doesn't_ add it to the log, some browsers will refuse the connection when presented with that cert. https://www.agwa.name/blog/post/how_will_certificate_transpa... has more details about Chrome's implementation.

Yep, for years when everyone was talking about NSL's and other corporate strong-arming by the gov, I started saying I suspect most major CA's are compromised. At least you know your threat model though, because only the nation states are going to have that.

CA's and DNS are two parts of the internet that have become way too centralized in my opinion.