[jackewiehose]

> it's wrong to insist as you do that there's no benefit without them.

Ok, that wasn't really my intention. I was stating that a false sense of security is worse than having (knowingly!) no security at all.

So yes I agree, you're generally better off even with untrusted encryption but that doesn't help in practical terms with our current situation of HTTPS in web-browsers. Maybe it would have been better if web-browsers would have just silently accepted self-signed certificates while still showing the big red warning about an insecure connection. I guess that will be solved with QUIC/HTTP3.

[trashfindhunter]

> a false sense of security is worse than having (knowingly!) no security at all.

Agreed. If you know that you are insecure you're less likely to pass sensitive information over the connection.

IMO the culprit is browser behavior. For instance, when visiting unencrypted HTTP sites in Chrome you may or may not notice an unobtrusive, greyed out "Not Secure" label in the URL bar. Visit your own self-signed certificate dev site though, and Chrome will give you an error wall with nothing to click, and you have to type "thisisunsafe" to pass (the page does not tell you that typing "thisisunsafe" will get you through).

Perhaps the reasoning is that if a site is served unencrypted it shouldn't be serving sensitive information, whereas an invalid certificate is an easy indicator of something amiss... but wow, talk about obtuse.

Your concern is definitely valid though, and I'm concerned about it too.

[tialaramex]

The brick wall (it's unfortunate that there have been overrides in Chrome under phrases including 'badidea' because they encourage people to use them, correct design here is to make the brick wall unpassable, that's why we built it in the first place) is only present if this site has HSTS or similar requiring HTTPS.

If the site doesn't seem to require HTTPS but you've gone there with HTTPS and there's no trustworthy certificate then the browser gives you a different interstitial which has a button labelled Advanced which reveals a link "Proceed to ... (unsafe)" that will switch off further interstitials for this site but retain the "Not Secure" labelling.

The HTTPS site (once you reach it) gets access to all modern features, an HTTP site, even if you ignore all the warnings, does not. As an example that's particularly unsubtle, calls to all the WebAuthn APIs just give back an error as if the user has thumped "Cancel".

Edited to add: Also the grey "Not secure" is changed to red if you seem to interact with a form, because that's probably a terrible idea on an HTTP site. Eventually I expect it will just always be red (the change to notice form interactions was in 2018 and this is part of a planned gradual shift by Chrome and other browser vendors).

[dtech]

Everything what you're saying is true, but it doesn't change the fact that HTTPS with self-signed certificate is more secure than HTTP.

It took Letsencrypt to make HTTPS accessible to the majority of the web because there was no cheap way before, because self-signed certs were punished by browsers while unencrypted connections were fine. We could have been full on moving from an encrypted (self-signed) web to a trusted (CA) web by now instead of moving from a plain-text to a trusted web.

Also, self-signed certs still prevent a MITM if you ever connected to the site before, similar to the trust-on-first-connection behavior of SSH. Given the widespread deployment and trust of SSH I'm suprised this people act so different with HTTPS.