> The vast majority of users cannot do the "making sure" bit suggested here. Of those who can, the vast majority (including myself here) don't.

Crucially, the browser is showing you historical information. This was the certificate for a transaction which already happened. Because this is about the past not the future you can't make decisions here, only have regrets.

Whereas for certificate name verification and all the other stuff your browser does, that is done by the browser in real time during the connection setup.

When you type the destination bank account, and amount to send, into a bank's "send money" form, and then decide to "check the certificate" the browser is not showing you a certificate for the HTTPS transaction you're about to perform, it can't. It's showing you the certificate associated with the form page, when you click "Submit" or "Send" or whatever, there may be a totally different certificate for the HTTP POST operation, it may result in a 30x redirect, which can result in yet another different certificate, you aren't shown these certificates before your form data is sent, the browser does all its checks because they're instant, but your dithering would be too slow.

I believe the flow allows you to view certificate information prior to accepting, and then only that certificate will be accepted for only that hostname.

Which browser do you think that's true for, and, have you tried it?

All desktop browsers I've tried. I don't have anything other than Chrome handy at the moment, but it definitely still works.

You just need to click on the "Not Secure" warning that's where the lock symbol would be, then on "Certificate is not valid".

> This can be solved with a proxy.

Only if your retro hardware understands some form of SSL/TLS (ie https:// scheme), otherwise you need to rewrite all https:// requests to http:// inline.

And (don't quote me on this though) more and more proxy software drops the old SSL/TLS protocol versions and ciphers.

One more thing which is usually overlooked, is what TLS (or any other encryption for that matter) indirectly helps with payload corruption in transit: unencrypted packet would be just silently corrupted and most of the time you would never even know it happened, a corrupted encrypted packet couldn't be unencrypted. Most of the time you can't do anything with it anyway, but at least it breaks the connection (or starts to slow down for the retries) so you know what something is wrong.

Rewriting all https URLs to http is fairly trivial in the vast majority of cases, and I would imagine it would be adequate for this use case.

In the case of retro computing especially, specially compiled software supporting legacy versions of SSL/TLS is reasonable.

1: You can always use a stronger encryption. You don't have to use decades-old encryption that has already been compromised.

2: So clearly in this case the route wasn't trusted. The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed.

3: Intranets are vulnerable only if there is untrusted devices in the network.

As I wrote, encryption is a good thing and improves security when used correctly, but all software must respect the user's choices. Nothing can fix stupidity and ignorance.

> but the users were ignorant and continued using the service even after the certificate suddenly changed.

Designing for a perfect user is going to end up in sadness. Users will make mistakes regardless of how experienced they are.

> Intranets are vulnerable only if there is untrusted devices in the network.

In practice that's "always" given large enough networks.

> You can always use a stronger encryption.

Which? As I said, I assumed you were talking about MPPE.

> So clearly in this case the route wasn't trusted.

Then trusted routes don't exist.

> Intranets are vulnerable only if there is untrusted devices in the network.

I don't think I would ever be willing to assert an intranet is free of untrusted devices.

> software must respect the user's choices

Software performing security functions generally should not give users (or even developers) choices where they are unlikely to understand the potential consequences. If someone can supply a "--insecure-tell-fvey-my-kinks" command line argument, fine, but otherwise no.

Any choice a user can freely make is one that they can be manipulated into making. Failing to protect them accordingly because of "stupidity and ignorance" is effectively social darwinism.

Please consider that most people don't have your level of technical sophistication, nor is it reasonable to expect them to.

> The encryption was however used correctly, but the users were ignorant and continued using the service even after the certificate suddenly changed.

When designing anything that's going to be used by the general public on the Internet, you have to keep in mind that's the entire public, including grandma and grandpa that don't even realize that their Facebook app is not Google and post their search queries as status updates.

For fuck's sake, we can't even get professional office workers to not fall for painfully obvious phishing campaigns, and now you want to try to teach them how to recognize a bad SSL certificate?

You're not living in reality.

I am living in reality. I don't want to limit the user's freedom. Sometimes people have to learn the hard way, but the other option (giving away your freedoms) is always worse.

> Sometimes people have to learn the hard way

This isn't reasonable or ethical - and it's telling you didn't respond to my other comment replying to you.

If someone experiences harm due to use of unencrypted HTTP because they didn't understand the implications of it, they're not going to be able to make a causal association. Without the causal association, there is no opportunity to learn.

The way to "preserve freedoms" in these sorts of situations is to require a "warranty voiding" action.

"Encrypt the whole call", but the l2tp interface between the modem bank and the POP is almost certainly not encrypted.