When Is a Self-Signed SSL Certificate Acceptable?

UltraLoser writes "When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?"

Comments

Always.

[fyngyrz]

SSL certificates provide one thing, and one thing only: Encryption between the two ends using the certificate.

They do not, and never been able to, provide any verification of who is on either end. This is because literally one second after they are issued, regardless of the level of effort that goes into validating who is doing the buying, someone else can be in control of the certificate, legitimately or otherwise.

Now, I understand perfectly well that Verisign and its brethren have made a huge industry out of scamming consumers into thinking that identification is indeed something that a certificate provides; but that is marketing illusion and nothing more. Hokum and hand-waving.

Re:Always.

[squiggleslash]

SSL certificates perform two functions: they verify the credentials of the website you're connecting to, and they provide a secure key for communications between the webserver and you. The reason we combine the two into one certificate is to make man-in-the-middle attacks more difficult. As you suggest, there are ways to compromise the SSL system, however they require you attack in one of four specific places:

1. You compromise the web browser, providing a bogus list of authorities. Your web browser maker becomes liable in that instance.
2. You compromise the SSL certificate authority, creating a bogus certificate signed by the CA. In this instance, the authority is liable
3. You compromise the certificate holder, stealing the legitimate private certificate and redirecting traffic to and from their servers to your own (or hacking into their website to transfer the information to you.) In this case, the holder is liable
4. You compromise the user's PC, patching the web-browser to accept bogus credentials. In this case the user is at fault

At this point it should be obvious what the SSL certificate system provides you with, which is a clear chain of responsibility for breaches in security. Simply sticking a box between a client victim and server victim is not enough, you have to actively compromise one of the four groups above in order to spy on secured traffic. This creates incentives for each group to keep their part of the chain of accountability secure, and it ensures there's a starting point should there be a breach anyway.

Given the difficulty of sending legitimate certificates directly to participants on a mass scale, the CA system is about as secure as we're going to get, and while it's not perfect, that's not a legitimate reason to treat it equally with unsigned certificates. The chain of accountability makes a difference in terms of how you can recover from security breaches, and the likelihood of there being a breach in the first place.

Re:Always.

[the_womble]

I doubt that precise attack has been used, but:

1) SSL certificates do get issued to phishing sites
2) Some banks have login forms on un-encrypted pages

see: http://news.netcraft.com/archives/2005/12/28/more_than_450_phishing_attacks_used_ssl_in_2005.html and http://it.slashdot.org/article.pl?sid=06/02/13/2143251

Re:Always.

[fyngyrz]

You are Alice. You want to talk to Bob's website: www.example.com

I'm Evel - and I have hacked Alice's computer, compromising anything I need to, from her certificate collection to her browser to her hosts file or all of the above.

Alice ->[her browser hums a happy song] home network -> Evel [collects her CC info, etc., moves to island with hot chicks and rum drinks.] Mind you a keylogger would be enough, but just for fun...

Alice is not safe from attacks. Not with a certificate, and not without one. End of story.

However: If Alice talks to a legitimate merchant, and no one has hacked anything, then the conversation between her and the other end is very difficult to break into, moreso than her computer, I might add. Which is the same advantage you would have had with self-signed certificates. The ONLY time you're safe is when you've not been hacked. To say that because ONE hack has been deterred -- the MITM attack -- the user should feel safe... I'm not buying it. It is as meaningless as saying you're safe because one out of a thousand vulnerabilities in your browser have been patched. You're not safe until there are no vulnerabilities; consequently, you're not safe. Period.

Re:Always.

[hal9000(jr)]

Can you cite any examples of a case where a certificate has been subverted in this way?

Yes. Back in 2001, Verisign issued 3 code signing certificates to people impersonating Microsoft employees.

As others I am sure have already said, the strength of the identity verification is solely based on how the verification is done.

Trivial question - how about the math answer ?

[OeLeWaPpErKe]

Self-signed certificates are acceptable if you can spread the root public key *yourself* in a secure manner.

Simple, no ?

In any exchange between 2 known parties for example, it is *always* preferable to have self-signed certificates.

Tons of them

[evilpenguin]

I find a self-signed certificate is useful on many occasions. I use it for my own squirrelmail service. I have set them up for "extranet" applications for small business clients.

This is just fine. I give them a hard copy of the key signature and tell them to verify it before the accept it.

Someone above says the a CA adds nothing. I don't agree with that. They add identity verification *to the extent* that site visitors actually *read* the certificates and evaluate their level of trust in the CA.

Quick: Tell me right now how many CAs are in your browser's trusted certs list. Now tell me where that list came from. Tell me why you trust it.

In other words, the signed certificate system can provide excellent security, but most of us simply trust our browsers when they don't complain. That isn't security. You really should check certificates every time. View the details, check the signatures, verify the integrity of your trusted CA list. But who bothers?

So while I don't agree that CA signed certs "add nothing," I do agree that hardly any users (including me who theoretically knows better) do their due diligence that would make that system truly work.

Firefox 3

[Trogre]

I've noticed that Firefox 3 is much less forgiving of self-signed certs than other browsers. There's a lot more hoops that one has to jump through to get a page to load.

I've found it rather annoying, since all our internal web applications are served via SSL.

Re:Firefox 3

[Rovaani]

Can't you just generate your own root certificate, use it to sign all the web-app certs and then distribute your own root certificate to all the employees?

Yes, a self-signed certificate is just a secure

[hal9000(jr)]

The answer to you question is that you can use a self-signed certificate anywhere you can use one signed by a CA, public or not. However, to ensure that you are always talking to the web server and not through a MITM, you must distribute the self-signed certificate or the certificate thumbprint (and then verify it!) through some trusted means.

Using a public CA like Verisign buys you is that since their public CA certificates are already distributed in browsers, any certificate issued by them should just work. Oh, and make sure the host name matches the common name.

Re:hipotesis

[slim]

Infact, having a third party signing your certificate potentially reduces it's security, since they are now in possession of the certificate too, and have likely transmitted it to you via plain text email.

HUH?

There is nothing whatsoever that is confidential in an X.509 certificate.

It is a chunk of bytes that says "Public key P corresponds to identity I, according to authority A", and it contains a signature created using A's private key, which ANYONE can check using A's public key.

During the whole request and issue process, the secret bit -- I's private key, never leaves I's possession.

The certificate could be printed in the New York Times, with no loss of security.

Re:hipotesis

[Digital_Quartz]

The problem is that a self-signed certificate suffers from attacks at distribution time, whereas a CA signed certificate does not.

First, you have to understand what a certificate is. A certificate consists of two parts: a public key, and a subject. The public key has a matching private key, but only the owner of the certificate has the private key (no one else; not even the CA). The subject tells us who the cert belongs to, and it is signed with the private key (so we can use the public key to make sure the subject hasn't been altered).

If I connect to your server via SSL, and you provide me with a self signed certificate, then that certificate proves that you are you (because of the subject), and it provides a means for us to establish encrypted communication (because of the public key). All is well, right?

Well, not quite; this only works if you've provided me with your cert ahead of time via some other secure channel (not the web). Otherwise, this setup is vulnerable to the classic "man in the middle" attack. Someone who wants to intercept our communication pretends to be you, and gives me his own "fake" self signed cert. I establish communications with the attacker; the attacker's subject is signed with the attacker's public key, and the attacker has the private key so he can read the messages I send him. The attacker then establishes communications with you, and passes my messages on to you, and the attacker can now listen in on everything we say.

The attacker could also pretend to be you, again by providing me with a self signed cert that claims to be you.

The problem in both of these attacks is simply that I have no way to verify that this self signed cert is really your self signed cert. If you had given it to me ahead of time, I could have added it to my list of trusted certs, and then when the attacker presented me with a different cert, I'd know someone was up to something. (Although, how would I know it was really you when you give it to me "ahead of time"? And if we have some out of band secure channel, why aren't we using that instead?)

Now, why isn't this a problem with CA signed certs? The CA goes through varying levels of pains to verify that you really are you when you submit a signing request. So I get a cert from you, it's signed by the CA's cert's private key. I check the signature against the CA's cert, and I see that it is good. Since I trust the CA, I know that this certificate really is your certificate.

The man in the middle attack and the "pretending to be you" attack won't work here; if the attacker provides me with a different certificate, then the certificate's signature will either not match the certificate, or else won't have a signature. The attacker could simply grab your certificate (it is provided to anyone who asks for it by your web server - the certificate itself is public knowledge), and then the cert would pass the signature checks, but since the attacker does not have your certificate's private key (only you have that), the attacker would be unable to decrypt any communication I send to him using your certificate.

There's nothing wrong with self-signed certs in and of themselves. You will notice that the signing certificates belonging to the CAs are self signed. This only makes sense; the CA signed your cert with their cert, but who signed the CA cert? Even if someone did sign it (the uberCA), then who would sign that cert? It has to end somewhere, so it ends at the CA.

The thing about the CAs' signing certificates is that they are "well known". Everyone has a copy of them; they come with your operating system. If, for some reason, you distrust your OS distributor, you can go find multiple copies of them scattered about the internet. If you could convince OEMs to include your self signed cert, it would be just as good. :)