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.

[jamesh]

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

And while you are on your soapbox, what is the alternative? By what other method do you suggest that I prove to my satisfaction that when I go to www.mybank.com.au that I am actually at mybank's website, and that a dns record somewhere hasn't been subverted and I am instead entering my login details to a phishing site made up to look exactly like my bank?

I'm pretty sure you are talking out of your arse. Unless you can cite some examples of a big name company (eg a major bank) having had their certificate subverted in this way, and not having said certificate revoked almost immediately, i'll stick with what works thanks.

Re:Always.

[jolyonr]

I totally agree - The internet would be FAR more secure if there was a way of using self-signed certificates without browser warnings.

But the certificate vendors have a licence to print money and abuse it horrifically.

For example, a certificate for a domain www.example.com costs a fraction of what a certificate for a wildcard *.example.com would cost. What extra work do they have to do for that extra money?

ALL sites would be more secure with a self-signed certificate than plain HTTP. But self-signed certificates scare the crap out of visitors with their alarmist warnings. If anything, the warnings should be shown on plain HTTP sites saying "Watch out! This isn't encrypted".

So. I say get rid of the self-signed warnings from all browsers, they do far more harm than good. Instead, make it clear on the browser with colouring, icons, whatever, whether the site has a verified certificate from a CA, or it does not (in the case of self-certs or HTTP).

Jolyon

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.

[bpkiwi]

My bank txts a one time authentication code to my phone for any transaction that involves money leaving my accounts (transfers, setting up direct debits, etc). I've always considered it an elegant solution, not foolproof, but few systems are.

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.

Requirement for a signed certificate SSL flaw

[Chrisq]

In my opinion SSL mixed two requirements, identification of site owner and secure communication.

This meant that many sites applied for SSL certificates just for secure communication. Some certificate authorities virtually issued certificates on request.

To get round they introduced extended validation certificates, which means we really, really validate this site.

They should have allowed secure communication without certificates, and had properly authorised certificates to start with. Since they didn't we have the situation where people have to self-sign

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.

Re:hipotesis

[Anonymous Coward]

It's not really a No No; it's just that, in order to be sure that the certificate is okay, you have to be able to ensure that you have the same level of security as a normal certificate. What is that exactly??

Well, a normal certificate is often verified simply by email. In order to get one you have to prove that you can respond to email for your domain. In other words you prove that you get IP packets that are destined to that domain (recieve the email you want). This is quite a bit harder than spoofing, but much easier than breaking an RSA key.

So, how can we get the same level of security? Well, if we connect to a web server then that web server has proven that it can get the packets for that domain. Any certificate it distributes has almost the same level of security as a normal web certificate. There is one difference. When you use a normal certificate they are proving that they can now recive your packets and they could at another time much earlier when they contacted the cerfificate authority. Minor seeming, but important difference. You can gain the equivalent security by checking that the certificate is the same as it was some time before and checking that you have the same certificate as other people world wide.

So a good way, would be for the web site you are posting about to post their certificate fingerprint on various public web sites and news groups known to be associated with them. That would be just as good as a normal web certificate. Or put another way, given the amount people pay for them and the security they advertise, normal certificates are indeed scams.

Please note, this discussion doesn't cover extended verification which is also a partial scam, but not as bad as normal certificates. Please note also, that there are some of the older certificates which also require more than just email verification. That is totally irrelevant since your browser interface doesn't differentiate between them and the hackers will always go for the weakest security.

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?

Re:Interesting

[locofungus]

"When is it acceptable to encourage users to accept a self-signed SSL cert?"

The answer is: Never.

What is the point of being sure that no one can intercept your communication all the way from your browser to the server if you don't know who you are talking to in the first place?

If someone knocked to your door and asked for your money would you give it to him because he has a bulletproof truck so the money will be safe all the way to whatever it is going to? Or would you trust the guy in the truck because he showed you a self-signed document saying: "I am authorised to do what I'm doing. Signed: me." Of course not!

But you'd be happy if you'd arranged with your bank for a truck to come and pick up the money, and when the truck arrived and you asked to see his documentation he said "Here it is, guaranteed by Fred Bloggs over there." And you have no relationship with Fred Bloggs (although you guess your bank does because the driver says so!) and no comeback against Fred Bloggs if he screws up even if he does have a relationship with your bank.

Quite frankly what I'd want is my bank having its own root cert that was self signed. I can confirm with my bank that I've got the right cert. And then when the driver turns up he can say "Here it is, guaranteed by your bank". And if the bank has screwed up and let some third party get hold of their root cert private key then I've got a relationship with the bank and I can sue them.

And when I communicate with my bank I should be able to give them my root cert and then they can check I'm who I say I am (they can use other methods as well if they don't think that is secure enough)

IIRC the hmrc website (UK TAX) allows you to use client side certificates to communicate with them but doesn't allow self signed ones. But why not? Is hmrc more confident that verisign can tell who I am than hmrc itself is? As a result I don't use a client side certificate.

Tim.

Re:I wonder...

[evilpenguin]

Certificate key signatures can prevent MITM attacks. Provided someone doesn't MITM the signature exchange...

CAs are good, but, as I point out in another comment, most of us treat them magically. We don't do anything to verify our trusted cert lists. Can you tell me right now *with certainty* where your trusted CA list came from and that it hans't been modified by someone hostile or by hostile code?

If you can't tell me that for sure, then you are *less* secure than someone using unsigned certs who has personally verified key signatures face-to-face.

Re:Interesting

[Znork]

The answer is: Never.

Actually, the answer is: Always.

if you don't know who you are talking to in the first place?

For most purposes it's sufficient to know I'm talking to the same guy I was last time.

Or would you trust the guy in the truck because he showed you a self-signed document

Instead I'm supposed to trust the guy in the truck because he shows me a document signed by the guy in the truck next to him?

The economic interest of a CA is diametrically opposed to their purpose. They maximize their profit margins by _not_ doing what they should be doing; hence I have no more reason for trusting Verisign (the guy in the truck next to him) than the guy himself.

In fact, I'd be better off establishing my trust once with the guy in the truck, then accepting that trust in the future; trusting the CA merely means I've opened myself up to being blindly tricked coercion of the CA. If the certificate of the person I've established trust with changes I know somethings up. If I'm subjected to a MITM attack signed by a trusted CA I wont even notice.

False sense of security

Funny, I'd say that the false sense of security is exactly what you get from CA signed certificates.

True Story

[BLKMGK]

While at DEFCON working the Wall of Sheep one year we discovered that someone had setup a WEB site on the network to bet on the outcomes of the hacking contest - they used a self signed SSL cert. Now some people, being paranoid on a VERY hostile network, turned down this certificate and promptly created\used the WEB site sans SSL - exposing their creds clear text. We promptly snarfed these and posted them on The Wall. 0wned!

All they had to do was accept the cert and they would have been protected. But I guess since seeing that pop-up was out of the ordinary and being on a network that was so nasty they thought they would play it safe and say NO, how stupid....

Re:hipotesis

[morgan_greywolf]

Or put another way, given the amount people pay for them and the security they advertise, normal certificates are indeed scams.

Commercially-signed certificates buy you one slight degree of security -- since the certificate is signed by a third party, it means, at least minimally, that someone else trusts the certificate. It's up to you to determine if you trust that someone.

Re:I wonder...

[OolimPhon]

False dichotomy. You present two options: ultra paranoid verify everything; and verify nothing. There is in fact a third option: trust MS to publish a list of well established and trusted vendors, and trust those vendors to vouch for a sites authority. That is a third option. And for most people it's the preferable option. If not, it would not be so. Yeah, well, you lost me at "trust MS".

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.