When Is a Self-Signed SSL Certificate Acceptable? 627
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?"
Always. (Score:5, Informative)
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.
Trivial question - how about the math answer ? (Score:5, Informative)
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 (Score:5, Informative)
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 (Score:5, Informative)
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:hipotesis (Score:3, Informative)
I don't see why they can't apply for a "real" cert.
Quite a few CAs these days use only email to verify that you are entitled to the cert (usually obtained via whois records). Some of them do it for free (cacert.org, although the CA cert is not trusted by many browsers).
I'd be happy to trust a cacert.org CA certificate, but *not* some random CA who could then issue certificates for other sites.
Comment removed (Score:5, Informative)
Depends. (Score:2, Informative)
A symmetric cypher combined with a random key provides the encryption. The rest of the system is only there to ensure that the parties who have the key are actually the endpoints, and that necessarily includes the authentication of their identities. The possibility that the certificate owner may not have been sufficiently diligent with his secret key is a problem which all cryptographic systems share. Nevertheless, identity verification is important for protecting against trivial man-in-the-middle attacks and certificates or trust-webs are ways to perform that verification. They're not perfect, but they're the best we have for encryption between mutual strangers. If the other party cannot be trusted to properly handle cryptographic keys, you might almost just as well not encrypt at all.
If you store the public key, then a verifiable signature is still important when the web site's public key changes. (That includes the first connection when you change from no key to the current public key of the web site.) The alternative would be to establish a different trusted channel for key verification. That could be a phone call, if it's sufficiently unlikely that you'll end up talking to the same man-in-the-middle who tries to pass his key as the web site's key. Just reading the self-signed certificate and clicking OK? You could be talking to a third party and would only notice when they stop intercepting connections between you and the web site.
Re:Firefox 3 (Score:5, Informative)
Re:Firefox 3 (Score:2, Informative)
All of our internal websites have self-signed certs. Once I added the permanent exception once, I never got another popup - unlike on FFX2 which gave me a box every time....
Re:Requirement for a signed certificate SSL flaw (Score:2, Informative)
Isn't any encrypted communication without some form of identification susceptible to man in the middle attacks?
Key distribution (Score:4, Informative)
Using self-signed certificates inside an enterprise is fine so long as all the clients have the certificate authority's public certificate installed. Key distribution mechanisms like group policy make it simple.
Sadly Firefox makes it less secure because it uses its own key store rather than the host operating system's, so users must manually import the certificate before attempting to visit an SSL-secured website.
Re:Always. (Score:5, Informative)
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 [netcraft.com] and http://it.slashdot.org/article.pl?sid=06/02/13/2143251 [slashdot.org]
Re:Firefox 3 (Score:2, Informative)
Why don't you add the root certificate to you browser? In Firefox 3: Tools -> Options -> Advanced -> Encryption -> View Certificates, then add the root certificate to your list of authorities. If memory serves me well, that should do the trick.
Re:What Are You Getting? (Score:3, Informative)
You should get a proper certificate signed by a CA. With a proper certificate, the end user's web browser can verify that your certificate did actually come from your web server, and not some other random computer pretending to be your web server.
The reason why browsers complain about self-signed SSL certificates is not because they are self-signed, it is because they cannot be verified as coming from your web server. If you set up your own root certificate and install it into your user's web browsers, then it stops complaining.
If browsers stopped complaining about certificates they cannot verify, I'd definitely NEVER use the web for anything secure ever again.
Re:Always. (Score:3, Informative)
I think you've misunderstood it (or I've not read what you said close enough).
You are Alice. You want to talk to Bob's website: www.example.com
I'm Evel (Hi, I'm male, can't use Even then ;) - and I by chance control your upstream.
Alice -> home network -> ISP (Evel) -> Bob.
Now, you try to connect to www.example.com, and he has got a signed certificate. I don't care about that, and insert my own certificate generated nicely for www.example.com . You get a browser warning - and since you know that Bob has a signed certificate, you know something fishy is about. You will still be communicating through an encrypted channel, but you're going to MY box, with MY certificate, talking to ME. I on the other hand proxy (decrypt, reencrypt -proxy) the requests to Bob. For you, everything looks normal - but I am listening in on the conversation.
Now, say that we didn't have signed certificates. You would not get a browser warning. You've reinstalled your computer, and you don't have Bob's certificate laying around, nor his certificates fingerprint. You access his site, you don't get a warning, and heeey - you don't even have the opportunity to suspect that I'm listening in.
That's the man in the middle we're talking about. Somebody intercepting the traffic, giving you a fake certificate, and using a proxy like that. That's the only thing SSL Certificate Authorities are there to prevent. Nothing else. They've tried to create an additional revenue stream by having 'high class' certificates with extra checking and yaddi-yaddi - but that of course is a nice little scam on their part.
Mod parent DOWN, please (Score:3, Informative)
He is spreading misinformation. The Internet and its security mechanisms were never meant to verify real-world identity (whatever that means: photo, street address, SSN?) or good intentions. Yet SSL does, however, validate the site's Internet identity... it ensures that the domain name you see in your address bar represents the actual server(s) registered to that domain name. As others here already pointed out, this prevents MITM attacks.
Thus, when you conduct critical business on the Internet, it is important to get the service's URL right from the horse's mouth. Otherwise a slightly-misspelled domain could amount to an attack of a different kind.
Self-signed certs are OK if you have a decent way to distribute the certs to others. For instance, if you can get the cert's fingerprint listed on various other sites... people can then check the fingerprint through alternate channels of the cert they downloaded and imported into their browser/client. Distributing in-person among trusted individuals also works.
OTOH, having a domain name mismatch would make me doubt whether the link could stand up to MITM attacks or if the cert I received wasn't a fake. Perhaps verifying the fingerprint is enough to satisfy most people, but for me it raises doubts about the site's technical ability.
Re:Always. (Score:5, Informative)
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.
You are correct to point that out (Score:4, Informative)
However, that is why Https security has to stand on a 'tripod' from the users' point of view:
1) The lock icon appears in the address bar (while a picture of a lock on the page doesn't count).
2) The domain name in the address bar is spelled correctly (because the lock is saying that the cert 'matches' the domain).
3) No certificate warnings appear from your browser.
If any one of those 'legs' is missing, then assurance of link security falls down. Otherwise (barring your computer being infected/compromised, or having a massive bug) you can be sure the link is both solid and also not a phishing site.
Re:Always. (Score:2, Informative)
SEBanken in Sweden gave out hardtokens. Initially it worked like this. To log on or make a transaction they sent you two 4 digit numbers. You entered a PIN number into the hardtoken to prove to it that you were not an imposter. Then you entered the two numbers and it signed them to give you a four digit number which you then entered into the bank site to make the transation.
Recently they improved it. Rather than two four digit numbers they sent one number which was the amount you were transferring and one which was opaque. So now if a MIM site is intercepting things, they can't change the amount your transferring. And you have to initiate the transfer in the seb site.
Like you say, it's not perfect but it's pretty good.
Re:Always. (Score:4, Informative)
Well, as I understand it, each of these devices has a unique ID, which is seeded into the number generation algorithm. The criminal's device will be spewing out a different number sequence than mine.
Re:Always. (Score:4, Informative)
No they don't. We have a code signing cert. I got it by email - I'm not the owner of the company or anything.. I just looked up the company reg. number and sent them the registered address and they replied with the link to the certificate the same day.
I could have been *anyone* - there was absolutely no real verification.. I literally googled all the information as it was quicker than asking my boss. For this they wanted $200.
Re:Always. (Score:5, Informative)
Can you cite any examples of a case where a certificate has been subverted in this way?
As others I am sure have already said, the strength of the identity verification is solely based on how the verification is done.
Yes, a self-signed certificate is just a secure (Score:5, Informative)
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.
The Pirate Bay (Score:1, Informative)
In case you all haven't figured it out...he is referring to The Pirate Bay...
Re:hipotesis (Score:5, Informative)
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.
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.
Things are not as they appear (Score:3, Informative)
Just because the form PAGE is not HTTPS doesn't mean the form PUT isn't HTTPS, i.e. a form that doesn't show the little lock icon might still be perfectly secure, but without looking at the page source you won't know about it.
And, ironically, vice versa. I.e. you can have a HTTPS form that actually uses unencrypted HTTP to submit its' data. Your browser is supposed to warn you when you submit an HTTP ("insecure") form and when you go from HTTPS to HTTP within the same site, but after the first couple of times almost everybody turns that warning off.
How's that for security comedy?
(Duped because I neglected to sign in the first time)
Re:hipotesis (Score:2, Informative)
Interestingly, the cert is supposed to demonstrate that the IP traffic HASN'T been intercepted and re-directed. So, if I intercept and redirect BigCo's IP traffic through my router, I can then "prove" I'm BigCo so that I can get a cert that "certifies" that I am BigCo and not some hacker intercepting their traffic!
Actually I would say that a widely published Cert is BETTER than one that some CA has signed. When a CA signs a fraudulent cert it happens quietly. The legitimate entity will be blissfully unaware that they are being impersonated. If someone widely publishes a fraudulent cert there's a chance the legitimate entity will see that and counter-publish the real cert and claims of fraud. You can then use an alternative means of communication to validate one or the other.
Re:I wonder... (Score:3, Informative)
Furthermore, have a look at the CA list in your browser. (In Firefox: preferences->advanced->encryption->view certificates->authorities). Now, have any idea who those are? If not, then you're taking a stranger's word for another stranger's ID.
Re:Always. (Score:3, Informative)
It only guarantees that the domain of the site you've connected to matches the domain in your browser bar.
So I set up a company usesave. It doesn't really matter what the company was going to do.
I then get a cert from verisign for my usesave company.
I then setup www.usesave.co.uk, and maybe even phish people with "you must check your details" and wait for people to typo www.icesave.co.uk or click on links in the phishing email.
Of course, hopefully, the site will get shut down quickly, but it's unlikely to be quickly enough not to catch some people out. The steps above might have cost me a few hundred pounds. I can set it all up and then "disappear" before actually triggering the phish. During the setup time my website is displaying a "How to save the environment by reusing the stuff you throw away: Coming soon"
But instead, icesave could have had their own root cert. And despite being an online bank, you do still have some paperwork from them which could have included the fingerprint of their root cert.
Now I can explicitly allow icesave's root cert and it doesn't matter if someone sets up usesave. If I typo it I won't recognise their root cert so I'll be alerted to the typo.
Of course, browsers don't make this at all easy to do. And, of course, icesave could still give their fingerprint on their paperwork (they don't).
For less critical transactions it's less important. If I'm just buying something online then the verisign checks are probably fine. I'm not likely to have any good way of verifying the companies cert. But there's no loss of security by still having a self signed cert - it's actually impossible for me to tell if the people I'm talking to are crooks - and verisign confirming that yes, I've really connected to the crooks and the good guys haven't intercepted my connection really doesn't help me.
What certs really give is the potential to confirm that the person you're talking to today is the same as the person you were talking to yesterday. But that's not the way they're used at all.
Tim.
Re:hipotesis (Score:5, Informative)
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. :)
Re:hipotesis (Score:3, Informative)