Threat model for huge warnings on untrusted SSL certificates and no warnings for plain HTTP connections? [duplicate]

Question

Why do untrusted/expired SSL certificates get such a huge warning in modern browsers even with "DO NOT VISIT THIS SITE!" messages, whereas a regular HTTP connection, which is more prone to eavesdropping and MITM attacks, doesn't get even a single comparably visible warning? A lock versus a world in a tiny icon is certainly not comparable to huge don't enter here signs.

What's the threat model where huge warnings for untrusted SSL certificates and no warnings (or very small warnings) for plain HTTP are sound?

Answer 1

It is not a threat model, it is a business model. Web browsers cannot warn about plain HTTP because that would be warning about the whole Internet (not a bad warning, really, but one which users will quickly ignore). Web browsers do warn about certificate issues with SSL because successful phishing attempts are very bad publicity. Browser vendor must be able to show that they "do something about it", and that's the scary warnings.

The theoretical justification is that users are obviously trained and know that in the absence of the (in)famous "padlock icon" there is no security. So they don't need warnings for plain HTTP; the lack of padlock ought to be enough.

(It takes a bit of training to be able to say that without sniggering.)

Answer 2

I think it has to do with people's behaviour and how the Internet has evolved.

I do remember that there were modal warning boxes in IE and Netscape whenever there was the first submission of a form over a plain HTTP connection, and there was a check box saying 'do not warn me again'.

As Internet users have become accustomed to HTTPS, they are more concerned about protection from phishing, what these big RED warnings try to accomplish. A UK high-street retailer was the victim of a phishing scam, and the first warnings came from customers who saw something suspicious in the SSL - the 'lock' icon. This was just before the RED screen warnings - about 3 years ago.

So, the threat model is the same. How average Internet users (and shoppers) perceive and react to it is changing.

Answer 3

Although I think the other answers have a valid point with regards to the financial motives of the vendors, I still think there is valid reasons for displaying the "big scary warning" in the case of an untrusted SSL certificates.

Perhaps the most dangerous thing is not someone who expects no security (plain http connection, although it's arguable if the general public knows this), but the person who expects security - and isn't getting it.

Yes lots of times expired certificates may not be super dangerous, but these warnings can be indicators of a MitM attack in progress, so I certainly want a strong warning when it happens on say a banking website where I have an expectation of security.

Summary - Given things could be broken down into insecure (http) connections and secure (https) connections, I think it's reasonable to warn people to a higher degree when security you believe is in place isn't working as expected, as opposed to the (supposedly) knowledgable choice of using an insecure connection in the first place.

Answer 4

I am asking myself the same question. Let me start by summing up (and addressing) the reasons I found here and elsewhere, and then explain the only good reason that I found so far.

1. First off, self-signed certificates do not protect against man-in-the-middle attacks because they don't prove the identity of the website you are connecting to. That is, they are essentially pointless / only prove that you are talking to the same site every time.

   This is true, but in many scenarios, that kind of weak security is good enough. Not everyone is running an online banking site. I run a small forum community on a virtual server, and an ssl certificate would be a significant cost in relation to my other hosting expenses. Consequently I now use no encryption at all, and e.g. on a public WiFi anyone could just read the passwords or session cookies of my users when they log in.

   Using a self-signed cert here would allow a significant increase in security, but the browser warnings would scare people away.

   Sites where security is essential need trusted certificates. However, the weak security afforded by encryption would still be an improvement for sites with low security needs which now use no encryption at all.

2. Showing the user that a connection is encrypted without a warning will create a false sense of security. Phishing sites could use that to fake a "secure login page".

   Then don't show the user that the connection is encrypted. Show no apparent difference to an unencrypted connection. If the user queries the connection details somehow (e.g. clicking on the favicon in Chrome), show him that the connection is encrypted but warn that it is insecure, with the information that is currently presented in the warning screen.

3. But the user might still expect a secure connection simply from the https:// protocol prefix.

   This is the only good argument that I found so far, and it is actually hard to work around. Maybe we could create a new protocol prefix specifically for connections that are encrypted but not secure, like cttp (ciphertext transfer protocol). Maybe it would be good enough to strike-through the https and show the user some informative mouse-over message, like "Insecure connection. Do not enter confidential information." - but then we are back in warning-land.

I hope this is good enough for an answer since it describes why the warnings are needed, even though I mostly wrote it to think things through for myself. :)

Answer 5

If it is not using SSL, it is not designed to be secure.

Warnings indicate that the expected security is broken. A lack of security is not broken-security.

Perhaps the threat would be if you could detect that there is a need for TLS/SSL security, but the site does not offer it. E.g., you filter the DOM and detect a field named "username" and one named "password", but the page is not being presented in HTTPS. Then, you could alert the user "hey, you might not want to log into this site, they are going to transmit your password in plaintext". We could probably think of a few other scenarios like a field called "ssn" that requires 9 digit number or 16 digit number which is run through a local check digit verification.

That actually sounds like it might be a useful plugin, probably a few false positives here and there, but could potentially help protect people.