What you are trusting, when you trust a CA, is that it will only issue a certificate for a domain to someone it has verified as the owner. A self-signed cert could be from a man in the middle attacker.

An active MITM is a relatively more exotic threat than a passive observer. In the days when certificates cost money, there was a legitimate argument that you shouldn't need the whole elaborate active-MITM defense just to get protection against passive snooping. But now that you can get both for free... just use Let's Encrypt.

Small nit, verification is only meant to prove control over the domain, not ownership.

The theory here is a self-signed cert could be from anyone (including the NSA) and you wouldn't know. Unless you explicitly trusted the certificate you were using, like enterprises do.

NSA can probably already issue certs from some of the widely-trusted roots. If someone as big as NSA wanted to MITM you, you wouldn't notice...

I feel like this is an oversight due to the path we took to arrive here. HTTP website: no warning, "insecure" mark in the URL bar. Trusted HTTPS website: no warning, "secure" mark in the URL bar. Untrusted HTTPS website: impossible to open in modern browsers by normal users. Really, a non-expired, otherwise-valid self-signed certificate should be treated the same as an HTTP website is. But since LetsEncrypt made self-signed certificates much less common, I doubt there's going to be energy put into improving the experience with them.

As well as the affirmatively "insecure" marking in the URL bar for unencrypted HTTP, it's not a Secure Context (except localhost) and so modern browsers don't offer any new features for this case.

If you're writing an HTML 4.0 web page that's no issue. If you were building a video chat, or you were going to add geolocation to your "Where's my closest store?" page or you want to send Notifications, or you've got a framework that needs Service Workers, those APIs are Secure Context only and won't exist.

The general rule of thumb is, if you could polyfill it, then it's available even without Secure Context, otherwise you need Secure Context to get the new feature. Some older features are being retrospectively given this treatment.

An MITM attack on an HTTPS connection looks exactly like an untrusted HTTPS connection, and the main purpose of HTTPS is to prevent a MITM. The browser should rightly scream louder here than it does for an unsecure HTTP connection.

The man-in-the-middle can self-sign their own certs and present it to you as the site's own self-signed cert. Unless you have some way to verify self-signed certs out-of-band, they're useless.

They’re not useless. They stop passive adversaries, like the Australian government. They just don’t stop active adversaries.

Browser security warnings imply https > http > self signed https. The correct order of should be https > self signed https > http.

We're getting there, HTTP is going to be marked as insecure in the future as well. It's just the massive amount of HTTP sites that couldn't get marked as insecure before, due to the then resulting warning fatigue in users.

Allowing untrusted certificates for https, and showing just a warning for them, would make it impossible for websites to ensure that their traffic is not intercepted

Interesting point. BTW I love your blog and your work on ShareJS :)