[smoppi]

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.

[viraptor]

> 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.

[ryan-c]

> 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.

[Sohcahtoa82]

> 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.

[smoppi]

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.

[ryan-c]

> 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.