Slashdot Log In
When Is a Self-Signed SSL Certificate Acceptable?
Posted by
kdawson
on Wed Jun 25, 2008 04:53 AM
from the how-about-never-is-never-good-for-you dept.
from the how-about-never-is-never-good-for-you dept.
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?"
Related Stories
[+]
Ask Slashdot: Choosing an SSL Provider? 183 comments
An anonymous reader writes "I have recently been tasked with switching our SSL certificate provider and it's proving not to be easy. We use an internal authority for our own stuff and then we buy certificates to protect outward-facing sites (a lot of them). My question for this community is: How do you choose a certificate authority to use? There is price, service (why we're leaving our last vendor), warranty, and products offered as the only differentiators I can find. Is there any public resource that would show me actual customer reviews of CAs like Verisign, GeoTrust, Comodo, Trustwave, and DigiCert? Our last vendor did a really poor job with support and I would like to make a reasonably educated decision."
[+]
Ask Slashdot: What Would It Take To Have Open CA Authorities? 529 comments
trainman writes "With the release of Firefox 3, those who have been using self-signed certificates for SSL now face a huge issue — the big, scary warning FF3 issues which is very unintuitive for non-technical users. It seems Firefox is pushing more websites in to the monopolistic arms of companies such as Verisign. For smaller, especially non-profit groups, which will never have issues with domain typo scammers, this adds an extra and difficult-to-swallow cost. Does a service such as this need the same level of scrutiny and cost since all that is being done is verifying domain and certificate match? This extra hand holding adds a tremendous cost and allows monopolistic companies such as Verisign to thrive. Can organizations such as Mozilla not move towards a model that helps break this monopoly, helping establish a CA root authority that's cheap (free?) and only links the certificate to the domain, not actual verification of who owns the domain?"
[+]
Technology: Mozilla SSL Policy Considered Bad For the Web 897 comments
Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
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.
Re:Always. (Score:5, Insightful)
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.
Parent
Re:Always. (Score:4, Interesting)
I don't know of any instances of SSL certificates being subverted in the way described by the GP, but there are instances of phishing sites using correct-looking certificates, such as http://blog.washingtonpost.com/securityfix/2006/02/the_new_face_of_phishing_1.html [washingtonpost.com]
"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"
Not very easily, but you can use two factor authentication to make sure that even if scammers find out the static username, password, and whatever, it's useless without a second bit of information generated by an electronic device. So the device generates a pin number which is based on time, or generated in a sequence. I have used Cryptocards in the past - they can generate a 7 digit pin number which is valid for one time only - the server knows the order that the card should generate the pin and it can be easily tied into existing infrastructure using by authing using RADIUS. Some UK banks have sent out devices which you need to insert the debit card into in order to generate the code. It's far less likely that the scammer is going to have the debit card, *and* the electronic device, *and* the static username/password.
Parent
Re:Always. (Score:5, Interesting)
Parent
Re:Always. (Score:4, Insightful)
But there you're solving a completely different problem!
The SSL certificate scheme is there to assure your browser (you) that the bank is who they say they are.
The electronic pad and/or card are there to assure the bank that you are who you say you are.
Completely different problems. Without the first being solved (usually via SSL) then you have no idea who you're giving your username, password and one-time number to.
IMHO this is a MAJOR problem in security. Most people don't understand that there are multiple different issues of trust, secrecy and integrity to be solved in any given situation.
Parent
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.
Parent
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]
Parent
Re:Always. (Score:5, Interesting)
I figured that would probably happen, but i'd never actually seen it. I don't make a habit of deliberately visiting phishing sites though.
I've not seen a bank do it, but these guys [melbourneit.com.au] do, which I think is just insane, especially seeing as in all other respects (apart from price) they are an excellent domain registrar. Click the login link in the top left and you'll be presented with a non-https page with a username and password on it. I've emailed them about it but they just don't get it. Idiots.
I've stopped using MelbourneIT for new registrations on that basis. I suggest you do the same.
Parent
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 tim
Re:Always. (Score:5, Interesting)
Wachovia tells their users to enter their credentials on the unsecured front page, which then submits to a secure script processing said credentials.
What you might be forgetting: What if I set up interception on my shared WiFi (or somewhere at the backbone of the hypothetical ISP I might be working for) to grab all HTTP requests for / going to r3wec01.wachovia.com and add a tiny bit of JavaScript that, in addition to the page working as it usually does, posts all keypresses to a script of my choosing?
Without access to WB's certificate, I couldn't do that on a properly secured HTTPS site. Thanks to unencrypted HTTP, it's pretty [eff.org] trivial [wired.com].
Parent
Re: (Score:3, Insightful)
And yet they still have an unencrypted login on their home page. Submitting to an encrypted URL from an unencrypted URL is practically a phish in itself. Most banks do this, and I cringe every time I see it. It begs for a phish attacks, does a disservice to customers, and promotes bad computing habits. But hey, it doesn't really cost the bank anything if your username and password gets whacked.
Re:Always. (Score:5, Insightful)
no no no, really you don't understand. Since the login page is not encrypted, it may have been changed during transfer to your browser. You'll be sending your user credentials to the evil MITM.
See? since you can't trust the login page it doesn't matter that your username & password are sent using SSL, since you'd be sending them encrypted to the evil MITM.
Parent
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.
Parent
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.
Parent
Re:I wonder... (Score:5, Insightful)
Not nearly as much damage as would have been done if everyone used self-signed certs. Look up 'man in the middle' attack.
Parent
Re:I wonder... (Score:5, Insightful)
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.
Parent
Re:I wonder... (Score:4, Insightful)
Parent
Re:I wonder... (Score:5, Insightful)
Parent
Re: (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:5, Insightful)
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
Parent
Re: (Score:3, Interesting)
But that's nonsense. I have been robbed by the SSL certificate companies so that my shopping cart page would not flag any browser warnings. I paid my money and had the certificate the next day. They didn't contact me by phone or snail mail. The m
Re: (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
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.
Parent
Re: (Score:3, Insightful)
No.
The function of the KEY is encryption. The function of the certificate is authentication.
Big difference.
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.
Parent
Re:Always. (Score:4, Interesting)
Parent
Re:Always. (Score:5, Informative)
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:
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.
Parent
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 import
Re:hipotesis (Score:5, Insightful)
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.
Parent
Re:hipotesis (Score:5, Insightful)
Parent
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.
Parent
Re: (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.
Re: (Score:3, Insightful)
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. :)
Parent
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.
Requirement for a signed certificate SSL flaw (Score:5, Insightful)
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 [wikipedia.org], 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
Re: (Score:3)
However it's an order of magnitude at least more difficult to perform a man in the middle attack than to simply observe the data from the network.
(I was going to moderate this thread, but there's sufficient misinformation that I'll reply instead.) There are two sorts of attacks possible, either by snooping or by DNS poisoning (well, there are more, but those are the main two). Snooping is defeated by encrypting the channel. DNS poisoning (and other types of man-in-the-middle attacks) is defeated by ensuring that the person/server at the end is who you think it is. The best way to do that is if you already know the public key of the other party, but
It's at least as secure! (Score:3, Insightful)
IMO, self signed certificates can be more secure. And for the site in question there's a risk of governments strongarming the certificate authorities to provide signed certificates so the government can launch MITM attacks.
I have a https website on my home machine that occasionally I connect to from work.
Now I get a popup about how the certificate issuer isn't recognised etc.
If someone at work (who controls the browser, the proxy, the network etc) decided to sniff all SSL traffic - which they could do with a MITM attack because they control at least one of the allowed root certs in the browser - my popup would disappear (unless they were very careful)
Likewise, my mail servers all use self signed certificates. Again, someone trying to attack me by getting verisign (or whoever) to sign a certificate, will not work.
Self signed certificates don't prevent attacks but they do mean that the attack cannot easily be automated.
(Actually I have a single self signed root cert that I then use to sign all my other certs rather than each cert being self signed)
It's swings and roundabouts. Verisign et al have built a whole industry out of convincing people to trust them more than the person's own bank.
I'm surprised we don't already see spam attempting to get people to install new root certs. (Or maybe we do - almost all the spam I get gets stopped by greylisting or caught by spamassassin)
Tim.
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:Firefox 3 (Score:5, Informative)
Parent
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.
What Are You Getting? (Score:4, Insightful)
The cynic in me believes that Firefox and IE are giving you all sorts of 'helpful' warnings these days, not to protect a user's security, but to push website developers into buying certificates.
Using certificates is about one thing - encrypted communication between browser A and server B. That's it. Certificates have never given you any guarantee as to the integrity of the site that you're visiting, and it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here. To give a guarantee like that, further technology is needed.
As a rule of thumb, if you have a finite number of users logging into a system then a self-signed certificate is OK, and even preferable. If you have some kind of site where the users you can have can be anyone (shopping site for example), then it's preferable to buy a certificate - if nothing else, to keep people from getting infernal warnings popping up in their browser.
Re: (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
Re: (Score:3, Insightful)
Using certificates is about one thing - encrypted communication between browser A and server B. That's it.
That is not correct.
Certificates have never given you any guarantee as to the integrity of the site
Correct.
it gives no guarantee whatsoever of who you are talking to, as some people are stupidly claiming around here.
Actually, that is the ONLY reason certificates exist.
You do not need a certificate to encrypt communication.
Certificates are an identity authentication tool.
Obviously it cannot ensure that it is Fred on the other end of the line. It only ensures that it is a computer with Fred's key. It is up to Fred to keep people from stealing his key and impersonating him.
If you are considering using SSL on your new website I suggest you go and read up on it.
Trouble is, SSL does two things and users are dumb (Score:5, Insightful)
To compensate, browsers have ratcheted up the warnings given about self-signed certs to extreme levels, making them essentially useless for any site or service catering to the general public. This, then, creates a demand for cheap certs, which leads to shoddy verification, which defeats the purpose, which leads to E.V. certs, which are what certs are supposed to have been all along, only more expensive and with a snazzy green bar that nobody understands. Fan-Fricken-tastic.
What we really need is a clear distinction between "identity" certs and "stability" certs. Identity certs would essentially cover cases where trust in a given entity is a function of official verification; e.g. when I walk into a bank, my level of trust is based on the legal status of the bank, is it an FDIC member, where is it incorporated, are its financial data properly disclosed, etc. In this case, an assigned SSL cert is just one more official aspect of the entity.
The stability cert is different. It maps roughly onto the class of interactions that are based on reputation and patterns of behavior. You don't trust your best friend because you've checked his official ID, and you know that he is who he says he is, you trust him because you have been able to observe his behavior and interactions over a period of time. For this case, you don't need an SSL cert that is tied to a real world name, you need one that shows continuity over time. For example, knowing my real name would be of essentially no use in deciding whether or not to trust something I say in a post. Knowing that I am the same fuzzyfuzzyfungus who has posted in the past allows you to read my old posts and decide if I am reliable or not.
The solution to this need is not CAs in the classic sense, that verify identity then hand out a cert; but public repositories wherein people can deposit self-signed certs at a certain point in time and have that event on file, among a number of repositories, for anybody who asks. Then, if you go to my website, you can look at my cert and, rather then getting something useless like "certificate for foo-barr.org was issued to Mr. foo barr by Verisign", you can see "foo-barr.org has operated under the same entity's certificate for x years." From this, you could then judge the entity based on their last x years of activity.
The trouble with this notion is that it would require a subtler set of distinctions than the current setup, which people are, on the whole, already uselessly befuddled by. Oh well.
True Story (Score:5, Interesting)
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....
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.
Re:Interesting (Score:5, Insightful)
"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.
Parent
Re:Interesting (Score:5, Insightful)
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.
Parent