Why is an unsigned SSL cert treated worse than no SSL cert?

Question

If I view a site that has a unsigned or self-signed SSL cert, my browser gives me a warning. Yet the same browser has no problem allowing credentials to be sent across unsecured pages.

Why is the self-signed cert treated worse than having no cert?

Solution 1

There are plenty of people that feel that this system is broken.

Here's the logic behind why your browser will give you such an alarming warning when an SSL cert is invalid:

One of the original design purposes of the SSL infrastructure was to provide authentication of web servers. Basically, if you go to www.bank.com, SSL allows the webserver that responds to prove that it does, in fact, belong to your bank. This stops an imposter from manipulating DNS or using another method to have a malicious server respond.

The "Trust" in SSL is provided by having a trusted third party (companies like VeriSign and Thawte Consulting) sign the certificate, indicating that they have verified that it is owned by who it says it is (in theory by visiting the IT administrator in person or another method that creates direct trust, although evidence shows that they're actually rather lax about it - all it takes to get a signed SSL cert is often an 800 number and a bit of acting skill).

So, if you connect to a web server that provides an SSL certificate, but it is not signed by a trusted third party, in theory this could mean that you are communicating with an imposter that is pretending to be a server belonging to a different organization.

---

In practice, a self-signed certificate generally just means that the organization that runs the server chose not to pay for a signed certificate (they can be quite expensive, depending on the features you want), or lacked the technical expertise to configure one (some small-business solutions offer a one-click mechanism for a self-signed cert, but getting a trusted cert requires more technical steps).

I personally believe that this system is broken, and that communicating with a server offering no encryption is much more dangerous than communicating with a server offering SSL with a self-signed certificate. there are three reasons browsers don't act like this is the case:

1. Unencrypted communications are the norm on the internet, so if browsers made you click through a warning to view websites not offering encryption, you'd quickly get annoyed and disable the warning.
2. Because of the dire warnings to clients, it's abnormal to see a self-signed cert on a production website. This establishes a self-perpetuating system: self-signed certs are suspicious because they're rare, they're rare because they're suspicious.
3. This is cynical sounding of me, but there are companies that stand to make a great deal of money off of signing SSL certificates (cough Verisign cough), so they use whitepapers (an IT term meaning "long and boring advertisement") and other publications to enforce the idea that unsigned certificates are dangerous.

Solution 2

Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST.If any post to unsecure page would trigger warning, users would be bombarded by pointless warnings.

Using secure channel indicates programmer intention to secure the transfer. In this case, using self-signed certificate warning is very right thing to do.

Solution 3

I can't comment, so I'll post this information that complements the correct information of user40350.

Yet the same browser has no problem allowing credentials to be sent across unsecured pages.

That is actually not even true. Most browsers will show a warning like you're about to submit data over an unsecured connection when you first try that, but you can turn it off so it never shows again, and I bet that is exactly what you have done...

Miro A wrote:

Sending credentials from page to page is basically doing HTTP POST. There is nothing special about sending credentials comparing to sending e.g. Search terms via POST

This is also incorrect, as password fields are special html tags for example. On top of that the labels like "username" and "password" also betray a lot of their sensitiviy. It would be perfectly feasible for browsers to take this kind of information into consideration.

Solution 4

Connections that are secured by the https:// protocol are indicated by the browser to be "secured". For example, a little Padlock is shown or parts of the URL are marked in green.

The user therefore is supposed to trust that the pages he is visiting are indeed from the URL he had entered and are not from someone else.

If he is using no https://, the user is supposed to know, that the data entered is not protected and the site he is surfing at might be imposted.

A self signed certificate does not make sure - againts expectation, that the page surfed to is not imposted, therefore it gives no extra security.

Solution 5

A distinction must be made between a trusted (signed by an authority you trust) and untrusted certificate. Otherwise someone could impersonate your bank (for example) by using a self-signed certificate with relative impunity.

An in-your-face warning is preferable to a subtle one in this case because the potential risk is relatively high. People might click on an https link and not even think that someone could be sitting in the middle monitoring the connection. If the indication that the certificate is untrusted is subtle (say a red instead of green icon, etc), then people could be easily fooled, removing the benefits of SSL.

View more solutions

Comments

[dag729]

Fair enough to me.

[MDMarra]

Without a chain of trust, which is what you get with a CA signed certificate and not a self-signed, there is no way to verify that the server you are connecting to is who is says it is. Self-signed certificates are dangerous in the sense that they do not provide any means for a user to verify that the data they are transmitting is reaching the destination that they say it is. People are beginning to learn to look for "https" when doing secure transactions, so having a big warning about an invalid or self-signed cert is 100% warranted, because they are losing one of the main benefits of SSL.

[nhinkle]

@MarkM, true, self-signed certs you don't have the chain of trust. However, it's not possible to verify that the data one is transmitting is reaching a particular destination over standard http, either. At least with self-signed https, you know that the connection to the server is encrypted, which is better than no encryption at all. People indeed do look for https now, but really it would be better if everything were https, and for sites needing extra verification, users might want to look for an EV cert, etc. instead. Security would still be better if the default were self-signed https.

[MDMarra]

@nhinkle - HTTPS has an extra overheard on a web server, first and foremost, which is why it will never be the standard, not to mention the load it would put on the CAs. Second of all, there is no implication of security in regular HTTP, where there is in HTTPS, which makes untrusted HTTPS configurations dangerous.

[MDMarra]

@jcrawford - Authentication is as much a benefit of SSL as the secure transport of data. The two go hand-in-hand in a public key infrastructure. I'm in no way saying that an unencrypted connection is safer than one made with a self-signed cert, but the unencrypted connection makes no claims of security. An SSL connection does. This is the exact reason why a warning MUST be shown when an SSL connection does not have a verifiable chain of trust to validate it. The fact the SSL exists ONLY for security means that if there is a possible issue with it, the only responsible thing to do is warn.

[nhinkle]

@MarkM - while there definitely is overhead, which is a legitimate concern, use of unsigned certs will not put any stress on CAs, specifically because a CA wouldn't be used for a self-signed cert. Also, for organizations with sufficient power, it's not a concern - consider that Google now defaults to https for gmail and some other services. I understand your point that without authentication, SSL's usefulness is degraded. The current model is not well designed. What we really need is a standard encrypted protocol, and an authenticated protocol for more secure uses.

[nhinkle]

Also, there is evidence to support that the current model is not as secure as we like to believe. There are so many trusted CAs that a determined attacker could probably find a CA somewhere willing to sign a bogus cert for them. There have been reports of misconduct at some CAs, and there is very little oversight. While it's more secure than having no CAs at all, the current authentication portion of SSL is broken, too.

[MDMarra]

@nhinkle - That exists, it's called SSL... Perhaps you and @jcrawfordor should read up on PKI and its X.509 implementation. Not to put either of you down at all, but I get the feeling there is a disconnect between our points based on the fact that neither of you seem to have a grasp of how SSL/TLS actually works.

[MDMarra]

@nhinkle - First of all, a CA has to be trusted by a web browser for its certificate to be valid. I can't create a random CA and sign certs and have them appear valid. I have to show that I am reputable to Mozilla, Microsoft, Apple, etc and they add my root cert to their browser's trusted list. Root CAs have their root certificate stripped from trusted lists if they are found doing anything shady. This means ALL certs issued from them will be invalid. This means the end of that company. A trusted CA fraudulently signing certs and jeopardizing their business would be an extremely rare case.

[jcrawfordor]

@MarkM The question point that NRHinkle brings up about the current system being insecure is a valid one. The truth is that there isn't strong enough oversight of CAs on the part of browser vendors to ensure that they are behaving reasonably, and there is increasing concern over corrupt CAs, as Internet Explorer recognizes over 100 CAs, many of which are very small businesses or small government agencies of dubious stability. There is evidence that law enforcement is already exploiting this fact to create forged SSL certs (goo.gl/JotS, goo.gl/ynwl).

[jcrawfordor]

The greater significance of my point, and NRHinkle directly said this, is that we need to start considering encryption and authentication to be separate goals, and allow them to be achieved separately. These are the fundamental flaws with the SSL system right now: 1) We see encryption and authentication as being inextricably attached - to achieve one, you must achieve the other. Providing only one is 'suspicious'. 2) Authentication must be obtained from a limited number of primarily for-profit CAs. In general, CAs are either very expensive (Verisign etc.) or very shady (NameCheap etc.)

[sleske]

As a matter of fact, I recall that at least old versions of Netscape Navigator did pop up a warning for every unencrypted POST. Of course, everyone disabled them after five minutes, so I guess that's why they took it out...

[Dmitry]

Isn't it easy to impersonate a bank anyway if you have the access to the user's computer and modify their certificates? If the user's computer is not altered, then the web browser would not be able to modify the URL of the webpage to claim that they are the bank; and if they get a very similar URL, they can still get a certificate for that website and the user won't care who the the webpage is signed by, they'll just see that it's https and hopefully notice that the URL is not the URL of their bank...

[Dmitry]

The benefit of SSL is not trust that the website is who you think they are(This is impossible since a 3rd party application can alter your certificates, or the bank can get hacked); but rather trust that the communication between you and whoever the site thinks it is, is only between you two and nobody else can make sense of that communication. Not having a certificate is worse than having a self signed one because it doesn't matter who you're talking to, what matters is that nobody else should be able to intercept what you're saying.

[Dmitry]

Besides as a user, do I really know who Verisign is and why I should trust them? Isn't their interest in selling certificates higher than holding certificate owners accountable for misusing information you send to them?