Is a Self Signed SSL Certificate a False Sense of Security?

Question

Is a Self Signed SSL certificate a false sense of security?

If you are being eavesdropped, the user will simply accept the certificate like he/she always does.

score 25 · Accepted Answer · edited Jun 13 '11 at 18:21

25

Interesting question, it depends on the use in my opinion. You're still protected in terms of the session is encrypted but you have no way of telling if it's the correct SSL cert presented to you unless you distribute your CA root cert to users/clients. For internal testing/dev projets this would work great, you generate a root CA certificate that you use distribute to your users (can be done via Group Policy in Windows and via openssl command line in Linux/BSD) and then use that root cert for signing your CSR's. Users will not see a warning or anything and you know the certificate is signed by your internal CA.

For external sites where you cannot assure this, I'd still say a self signed cert is better than no SSL at all if you are sending passwords or other sensitive information over the connection.

However, on the plus side there are plenty of very cheap "commercial" certificate issuers, GoDaddy being one of them. You can get a cert for about 40 euros per year. GoDaddy even offer free certs to OpenSource project web-sites.

edited Jun 13 '11 at 18:21

Callum Rogers

103
3

answered Jun 13 '11 at 07:05

HampusLi

3,398
15
14

This is exactly what we do. Be careful, though with the cheap certificates. Some of the have rather odd root CA's and not all of these are in the collection of root CA certificates that are shipped with all browsers. – wolfgangsz Jun 13 '11 at 08:08
4

+1 except "self signed cert is better than no SSL at all" - **iff** you verify that it's your certificate, and not one supplied by a MITM. Honestly, when was the last time a normal user did that? (I suspect the answer would involve blue moon and flying pigs) In other words, using a self-signed SSL cert without having distributed your CA certs to users, you're desensitizing users to the scary alert that they get - they'll learn to click through this, as "well, they told me to ignore the warning on mysite.example.com,so I can ignore it everywhere;look,a lock icon!" Voila,false sense of security! – Piskvor left the building Jun 13 '11 at 11:30
7

@Piskvor, actually that's the browsers' fault. First, browsers generally don't provide a way of "accepting permanently" previously unknown self-signed certificates so that user doesn't endanger himself upon every log-in. Second, the browsers don't discourage the use of old plain HTTP, also creating a false sense of security. So, HTTP is always worse than HTTPS, both in security and user awareness (at least they get the warning!). – Rotsor Jun 13 '11 at 12:48
1

@Rotsor: First, Opera has this feature you describe built-in, FF has Certificate Patrol (which at least warns of cert change). Note also that not everything on SSL is a browser (IMAPS etc.). Second, how is the existing plethora of HTTP only sites the browsers' fault? (and no, HTTPS-only browsers never caught on, precisely because there was a drastically smaller Net to browse with them). Third, "they get the warning" would be useful, *if only the users would read it* - and not blindly click "accept" to make it go away. "Clicking accept means understanding" is developers' shared delusion. – Piskvor left the building Jun 13 '11 at 12:57
1

@Piskvor, good to know some browsers do provide that feature. As for HTTP, I can't tell what has to be be done (disallowing HTTP is obviously not an option), but having more security-related warnings with self-signed SSL than without SSL at all is definitely wrong and is the browsers' fault! – Rotsor Jun 13 '11 at 15:01
@Rotsor: Okay, now I see what your point is. Perhaps an "insecure connection" warning would be in order on HTTP sites; note that ancient browsers of yore (e.g. IE6) used to do exactly what you suggest - and nobody ever noticed, as they were clicking through ten other *yes yes yes accept accept okay* alerts of "meaningless technobabble" when this was presented (e.g. on insecure (HTTP) form submit). I'd say this has been tried and failed. – Piskvor left the building Jun 13 '11 at 15:36
startssl cert's are free and work on every browser I've tried – Neil McGuigan Dec 13 '12 at 05:07

MadHatter · Answer 2 · 2011-06-13T15:10:39.373

I'm going to disagree, once on narrow technical grounds, and once on general grounds.

The narrow technical ground is that the OP asked about self-signed certificates, and several other answers refer to certificates signed by private CAs, which is a slightly different issue. But not very different, so that is really only a note in passing.

The major objection is that I think that as long as commercially-signed certificates are of more than trivial expense - and $40 a year is not a trivial expense for a lot of people on this planet - self-signed certificates have a major role to play in internet security, provided their limitations are recognised.

A self-signed certificate is like an ssh key from my known_hosts file. Without independent verification, it can't assure me that I'm talking to the system that I believe I am; but it can assure me that the system I am talking to now is the same system I talked to last time I thought I was having a conversation with it. We cache ssh keys all the time, and I've never yet met a system administrator that independently verified more than a fraction of the public keys in his/her known_hosts file.

Self-signed certificates (and, for that matter, certificates signed by not-generally-valid CAs) are much better than no SSL at all, as long as people realise that unless they verify them they only secure the communication to themselves, the server at the other end of the DNS record, and any men-in-the-middle currently on the line. If they independently verify the certificate, then the authentication and encryption are at least as strong as that provided by a certificate signed by a recognised CA.

Moreover, those wishing to present the use of certificates signed by a recognised CA as the one-and-only internet security panacea may need to think hard about issues such as the inclusion of the Chinese Government's signing CA in the standard Mozilla bundle, and the fraudulent SSL certificates signed by Comodo.

Alas, the "trusted CA" model is indeed broken (and has been for years); unfortunately, it isn't going away (and there isn't anything actually better to replace it). As always, SSL and trusted CAs are not magical security pixie dust; the user needs to actively maintain the security - which is, on the most part, a rather crazy assumption. — Piskvor left the building, Jun 13 '11 at 15:39
Are your users capable of making an educated evaluation of their confidence level in the integrity of their path to the current DNS server (incl the possibility of cache poisoning) and the device that they're hitting? Mine don't know what DNS is, much less being able to make educated security decisions about their connection to a server in another state, connected to another site via MPLS, which is connected to the user via a client VPN, which they're on via unencrypted coffee shop wifi. Avoid giving them that responsibility. — Shane Madden, Jun 13 '11 at 18:06
@Shane Madden: One area where this is possible is administration web frontends - e.g. phpMyAdmin (or, to a lesser degree, SVN over HTTPS). There's usually a limited number of users, *and they contain some significant fraction of a clue*. I wouldn't expect my great-grandfather to make heads or tails of a SSL certificate warning, but I definitely expect this of a fellow sysadmin, especially if it's a server under hir control. A garden variety user doesn't have a clue about `known_hosts` @MadHatter is referencing, either. — Piskvor left the building, Jun 13 '11 at 19:56

Piskvor left the building · Answer 3 · 2011-06-13T12:27:48.833

8

For external sites, where the users don't have your CA certificate installed (which is the most common case), yes, a self-signed certificate gives a false sense of security, and thus it's worse than useless:

First, without a pre-installed CA certificate, how does the user verify that the certificate indeed comes from you, and not from an attacker? By matching the certificate fields (CN, fingerprints, etc), of course - but against what? So now you need a side channel to verify the certificate - and in the few instances I've seen that, the support line operators (who should have served as the side channel for verification) have no clue what that is supposed to mean; also, operating such side channel is orders of magnitude more expensive than getting a trusted-CA-signed certificate, so the user must blindly trust you.
Second, the scary alert the user gets is scary for a good reason: since the user can't/won't verify the presented certificate, they might be securely transmitting data to the Elbonian Haxx0r D00dz.
Third, and worst of all, you are desensitizing the users: "well, they told me that I should ignore that warning on https://mysite.example.com/ , and an anvil didn't drop on my head, and my goldfish didn't die either; sooooo, that means that it's just another alert box without any actual meaning, so I can ignore this box whenever I encounter it - I get that nice lock icon thingy anyway, and that's important."

In other words, the level of protection is comparable to plain HTTP (except for on-the-wire sniffing: although the data are encrypted in transit, that is a rather anemic feature without endpoint verification), but the feeling of protection is unreasonably high. Bad car analogy: "I have ABS, so I can now drive safer in bad conditions" - except the ABS only exists in the car's sales brochure, without actually being present in the car.

Suggested reading: OWASP SSL Best practices

TL;DR: By using self-signed certificates on public-facing sites, you are making the Net a worse place, one clueless user at a time.

edited Jun 13 '11 at 12:27

answered Jun 13 '11 at 11:44

Piskvor left the building

2,093
1
17
17

2

@downvoter: I'd appreciate if you pointed out *where* my answer is factually incorrect ("incorrect" as opposed to "uncomfortable, inconvenient, and a bother to implement"). Security Is Hard, and going "la la la I can't hear you" does nothing to fix it. – Piskvor left the building Jun 13 '11 at 12:02
2

Although I didn't downvote your answer, the tooltip text on the down arrow indicates downvoting for no reason other than an answer not being useful. I think the false sense of security pendulum can swing in the other direction, too. The recent comodo RA breaches prove that it isn't all that difficult for a "villain" to procure a perfectly legitimate certificate either. – mahnsc Jun 13 '11 at 12:24
@mahnsc: Thank you for the reminder; I'm aware of that :-) "Is a Self Signed SSL certificate a false sense of security?" "Yes, for the following reasons..." sounds useful, no? So, I was curious why this wouldn't be the case: I could learn something from an opposing view; from a downvote, not so much. – Piskvor left the building Jun 13 '11 at 12:31
1

@mahnsc: Good point about compromised CAs. I'm not saying that the root CA list is set in stone and unhackable - perfect security doesn't exist; but it takes considerably more effort to break *that* than setting up a capturing SSL proxy on a network gateway. – Piskvor left the building Jun 13 '11 at 12:34
@Piskvor: I may be misunderstanding your most recent comment but if it is trivial to set up an intercepting ssl proxy and all one needs to hope is that the CA/RA cares more about the $49 than the verification process, self-signed vs. CA signed means very little. – mahnsc Jun 13 '11 at 13:08
1

@mahnsc: I meant that it is easier to set up a SSL proxy and hope that the user clicks through the warnings, than to set up a SSL proxy and hope that a bogus certificate request slips through the CA verification process. Either is possible, as we've seen, but the former is much easier to do (and harder to detect afterwards, as browser users usually don't keep audit trails). – Piskvor left the building Jun 13 '11 at 14:55

score 8 · Answer 4 · answered Jun 13 '11 at 14:47

Depends. If you think it makes you more secure then it increases your risk as you choose to do riskier things with your false sense of security. If you treat it functionally equivalent to HTTP, then I'd say you are slightly more secure.

Without SSL/HTTPS anyone with wireshark on your network (or the local network of anyone logging in) can trivially listen in and capture username / passwords sent as plain text.

With self-signed SSL they cannot simply listen in, but now must fake your site, potentially alter DNS to do a man it the middle (MITM) attack. This is still a threat, but significantly more difficult for them to accomplish.

The other problem with using self-signed SSL is that many browsers treat self-signed certificates as a major security threat and warn you before entering (e.g., chrome) with a giant red page. http://www.sslshopper.com/article-ssl-certificates-in-google-chrome.html This could be a major inconvenience.

So bottom line is: if you run something that doesn't need to be particularly secure (e.g., no credit card data, no social security #s) and can't afford a proper certificate, a self-signed certificate could make some sense (to say prevent other network users from easily sniffing their login information).

score 0 · Answer 5 · answered Jan 22 '15 at 23:17

It depends what you mean with "security", and which is the extent.

By example, your browser comes with a set of CA accepted by default. This means, any certificate issued by this CA is accepted by your browser (until it matches with the dns name) . Now, imagine some evil government owns a CA, or can force the CA to issue a certificate for the site you are visiting. Then, to do a MITM is very easy: they can proxy your connection, sending to your browser the certificate they have, and your browser will accept it, since it comes from a "trusted" CA. Until they are DNS-transparent (which is the base for MITM) this is ok.

So, the "list of accepted CA" is basically a big security hole, until one of this CA cooperate with some evil government. Having your own CA is much better.

Of course, you can do it in your company or in your home server, because you can install your own CA certificate into the client, which you control too. In a public server, you can't deal with any user, asking him to add an exception, or to add your certificate.

So, it depends what you mean for "security", and the scope. IF you own the clients, FOR SURE, the self signed is safer, until you install on the client itself the certificate of your own CA.

OF course, you can't do it on a public website since you don't own all clients. So you will get a jeopardy of different behaviours, which is not safe.

Is a Self Signed SSL Certificate a False Sense of Security?

5 Answers5

Linked