Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?

share|improve this question
2  
+1 It's curious: I faced the same question. –  dag729 Jul 9 '10 at 18:12

6 Answers 6

up vote 11 down vote accepted

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.
share|improve this answer
4  
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. –  MDMarra Jul 10 '10 at 0:14
    
I wouldn't say 'broken'. I think that the Firefox Certificate Patrol add-on is a lot closer to the correct implementation of certificates and managing trust than the default. Still, the default is better than ignoring trust networks entirely. –  Slartibartfast Jul 10 '10 at 0:18
3  
@MarkM - My feeling is that authentication should not be considered the main benefit of SSL. I don't have the data to back me up, but I think that far more security incidents result from data transferred over unencrypted connections (as an example, the Facebook security engineer who's password was stolen - they sniffed the password off of a wifi network, since facebook login is not encrypted) than through MitM or imposter attacks, which are relatively much more complicated to implement. The focus on authentication over encryption in SSL is, as I noted, precisely what creates this situation. –  jcrawfordor Jul 10 '10 at 4:07
1  
@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 Jul 10 '10 at 5:47
3  
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.) –  jcrawfordor Jul 12 '10 at 1:19

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.

share|improve this answer
    
Fair enough to me. –  dag729 Jul 9 '10 at 18:16
    
+1 - Short, simple and correct. –  MDMarra Jul 10 '10 at 0:16
    
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... –  sleske Oct 10 '10 at 21:08

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Many good reasons have been listed. Here's one more:

Think about cases where one secure web page embeds elements from another. An attacker could detect which requests are for the outer web page (say by looking at the timing, it has to come first) and which are for the inner elements. He could inject himself as a MITM in just the inner elements, use a self-signed certificate, and control parts of the page. Unless a warning was presented for the inner elements using SSL but not using a trusted certificate, the security of the outer page would be compromised.

Here's a realistic example. Say I'm a vendor, and I have a 'pay with PayPal' link. You click on that, and I know. I redirect you to PayPal, and let you get the legitimate, secure PayPal page. If I'm watching your network, I know that will be your first request from PayPal, and soon after that you'll submit your password. So I MITM the submit containing your email address and password, substituting my self-signed certificate for PayPal's.

You see how the security of the outer page is compromised by not warning if the certificate of the inner page is self-signed? So it must warn on self-signed certificates that come from links.

And, of course, if you enter https manually, it must warn you. Because you expect it to be secure.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.