> because their `certbot` made it with 0 review of who you are or what the site does? How is this different at all?
I think it only makes sense if you view the whole HTTPS everywhere initiative as a counter against MITM attacks - and only that. Everything related to identity has effectively been delegated to domain registrars. TLS certs as envisioned by browsers are really only about proving that you have genuine control of a particular domain - they give no indication at all who you are, whether your intentions are good or whether or not you're trying to imitate a different domain.
In that sense, the UI redesign from "neutral/secure" to "insecure/neutral" in Chrome makes some sense: HTTPS is necessary but not sufficient to make a site trustworthy: A https site might still be a scammer, but a http site can always be intercepted and manipulated by MITM, so http sites can can never be trustworthy at all.
> Everything related to identity has effectively been delegated to domain registrars. TLS certs as envisioned by browsers are really only about proving that you have genuine control of a particular domain
Might as well just stick the certificate hash in a DNS record and forget about keeping a public consensus on universally trusted CAs.
It doesn't though. The attacker could simply present their own self-signed certificate - and there'd be no reliable way to determine which certificate is the right one.
You could mitigate this with some kind of (non-scary) trust-on-first-use UI. But even that doesn't help you if you're unlucky enough to encounter the attacker before the real site. (Which isn't even that unlikely if the attacker is e.g. an ISP proxying all connections by default)
What LE gives you is a signed statement saying in effect: "we've seen that the owner of this cert can make changes to the domain which are visible from multiple different network locations - so they are very likely the real owner of the domain and not a MITM".
That's valuable, even if it doesn't tell you anything about who that entity is.
What I absolutely would wish for is some mechanism to include a cert hash in the URL. Then you could e.g. distribute QR codes with the cert hash embedded and circumvent the trust problem that way. Then, I agree, there would be no reason not to use self-signed certificates with that technique.
I think it only makes sense if you view the whole HTTPS everywhere initiative as a counter against MITM attacks - and only that. Everything related to identity has effectively been delegated to domain registrars. TLS certs as envisioned by browsers are really only about proving that you have genuine control of a particular domain - they give no indication at all who you are, whether your intentions are good or whether or not you're trying to imitate a different domain.
In that sense, the UI redesign from "neutral/secure" to "insecure/neutral" in Chrome makes some sense: HTTPS is necessary but not sufficient to make a site trustworthy: A https site might still be a scammer, but a http site can always be intercepted and manipulated by MITM, so http sites can can never be trustworthy at all.