Slashdot Mirror
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?"
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.
I've fallen off your lawn, and I can't get up.
"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"
So it exists for the distribution of copyrighted material, right? Just like, say, Amazon? Or like SourceForge? So what's the problem of the CA knowing their personal information? After all, the domain registrar already knows the correct data, right?
Or are you saying that they exist for the distribution of copyrighted material illegally, in which case we all couldn't really care less what their problems are, and you should report them to the appropriate authorities instead of helping them break the law?
Now, back to your main question:
"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!
Self-signed certificates are pointless, because you are confident than no one is listening but you have no idea who are you talking to. It means the possibility of a man-in-the middle attack and many more problems that should be obvious to any self-respecting, computer-literate, intelligent person.
But what is even more important is the problem of getting people used to trusting incorrect, i.e. "self-signed" certificates. When they later are victims of phishing attacks everyone on Slashdot is saying to blame the victims because they have entered the fake bank website with an incorrect SSL certificate, while at the same time forcing equally incorrect certificates down their throats and saying that it is ok to trust it, because it is "self-signed" (which means that it is signed by itself, for those not familiar with the SSL lingo).
And these are the most important problems caused by self-signed certificates. False sense of security, and getting used to the browser complaining about incorrect certificates and ignoring it later.
Karma: Positive (probably because of superiour intellect)
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.
I'm a software developer and will often create my own certificates for testing purposes, and in my test lab people will trust them, however out in the wild there is no excuse for not getting a proper certificate signed by a proper authority.
Not only is this coming across as the company trying to do things on the cheap it has the possiblity of unraveling the trust of SSL for places you actually care about. If this becomes wide spread just think of the phishers create a copy of A Bank's site make their own SSL and put a note on the login screen "Dont worry you have to do some work to trust this certificate everything is alright honest guv."
Personally I normally trust self signed SSL certificates for sites I visit if they have them as i know the risks, but to potentially undermine for general users is just mad.
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
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.
God said, "div D = rho, div B = 0, curl E = -@B/@t, curl H = J + @D/@t," and there was light.
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.
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.
Accepting a certificate ultimately comes down to trust. For example, most people trust Verisign. Therefore, if a certificate is signed by them, most people will think: "Here is a legitimate site with identifiable credentials accepted by Verisign."
A self-signed certificate encrypts your data just as well as any other. However, you need to trust the website you are at (and hence the signing authority). The reason people trust sites like Verisign, is that it is often difficult to know how legitimate/secure/etc a particular website is. Also, a website could be faked.
I'd trust a self-signed certificate from my bank. But I wouldn't necessary trust that the site I am at is actually my banking website (instead of a cleverly copied phishing scam).
Also, even if I trust a site, I wouldn't necessarily trust the people they trust. What I mean is that if a certificate is signed by an external CA, or with a mismatched domain, I would have to know and trust that CA or other domain before I would accept that certificate.
Considering that most people just click "OK" when something pops on their screen, I would say that Verisign and the like are useful for now. But I have nothing against self-signed certificates in principle.
Unity in Diversity
Not nearly as much damage as would have been done if everyone used self-signed certs. Look up 'man in the middle' attack.
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.
"Nine times out of ten, starting a fire is not the best way to solve the problem." - my wife
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.
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.
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.
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 he's saying is that it is not necessary for all websites that would like SSL security to have to have a proper commercially signed certificate. For something that is less-risk than a bank they should be allowed to self-sign.
signature is pants
This is timely, as I'm looking at implementing SSL for a web system at the moment, and I'm seriously pondering using self-signed certificates. Paying for a certificate from an authority is, quite frankly, a rip-off. The companies don't need to do anything for that money, and the notion that they provide some service where you can trust the site for the issued certificate is laughable. The only reason for doing so is so that peoples' browsers don't complain when they come across a certificate they don't recognise.
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.
The problem with SSL, and the tension between ID verification and simple encryption, is not so much a technical issue as it is a "people, on average, cannot be trusted for anything more complex than tying shoelaces". With depressing regularity, studies show people with no clear idea of what the "lock icon" means, no understanding of the fact that a picture of a lock displayed on a website and a lock icon in a browser are two vastly different things, and no real idea of how certificates work, or what a Certificate Authority actually is.
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.
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....
Build it, Drive it, Improve it! Hybridz.org
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.
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.
My blog
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.
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.
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.
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)
There's no reason to continue to use self-certificates today as you can easily get your certificate signed for free by http://startssl.org/
Their certificate authority is included by default with Firefox (you can add it manually with IE)
You can get a certificate recognized by default by the majority of browsers for a few bucks anyway.
Just make sure you have OSCP checking turned on on your browser (because it's so easy to sign a certificate that it has to be revocable easily)
Please also stop to use pre-computed certificates (ie localhost with a private key on a cdrom that everybody can get...) or reuse the same on different servers (in some cases, Firefox 3 now refuses to load them...)
http://en.wikipedia.org/wiki/Certificate_signing_request/
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.
Applied Security Technology will always meet the expectations of experience.
http://en.wikipedia.org/wiki/Pretty_Good_Privacy
http://en.wikipedia.org/wiki/OpenPGP#OpenPGP
http://en.wikipedia.org/wiki/Public_key_infrastructure
http://en.wikipedia.org/wiki/Certificate_authority
http://en.wikipedia.org/wiki/Philip_Zimmermann
http://en.wikipedia.org/wiki/Secure_Sockets_Layer
http://en.wikipedia.org/wiki/Secure_Sockets_Layer#TLS_handshake_in_detail
http://en.wikipedia.org/wiki/Hardware_token
http://en.wikipedia.org/wiki/Biometric_authentication
https://www2.sans.org/reading_room/
http://www.giac.org/certified_professionals/practicals/gsec/4993.php
http://www.giac.org/certified_professionals/
http://www.linkmatrix.de/index.php?education=home
http://www.linkmatrix.de/tutorials.php?q=PGP
Those that can DO, read. Those who can read, but not DO, preach.
Readers, fakers, and test-takers always manage to fail.
Hands-On experience and continuous-learners always work for tale (or is that rep).
To many PGP/PKI/CA/TSL... comments are cross-BS technology application comments. Only in politics does mixed pieces of BS function properly or as expected.
In technology as in science it either does, or it don't do. There is working properly or working poorly (with a problem) until troubleshot and fixed. If it never worked or ain't working at all (cannot be made to function fully and consistently as expected) then someone fycked-up bad (miss-applied technology application) perhaps the brown-nose wannabe manager that can only read made a decision.
Unaccountable leaders are masters, and unrepresented people are slaves. How do US and EU fare?
Not really. A phishing site could get its own SSL cert for whatever domain it's using. For example, a bad guy could get a cert for paypa1.com and https://paypa1.com/ would work just fine with a proper secure connection.
The idea is that Verisign or whatever CA granted the certificate should have checked them out, and only give them a cert if they're "good". However, their idea of "good" is completely up to them. You're trusting that whatever they say is good, is good to you also. But what if my name is Bob Paypa and I want to have an SSL cert for my personal domain, paypa1.com? I would hope Verisign wouldn't allow an obvious phisher to get an SSL cert for paypa1.com, but I also think they shouldn't flat-out reject SSL cert requests just because the domain name resembles another business' name.
Personally, I've never trusted the CA verification system. I see an SSL cert as something that guarantees my connection to that server is encrypted, nothing else. As others have said, if you trust a server enough to connect to it, then you might as well trust a self-signed cert from that server. Would I give them all my bank account info just because they have a cert? No. Would I do regular website stuff via HTTPS using their self-signed cert? Sure.
Self-signed certificates work great, provided you require users to install your CA certificate as one of the trusted certs in their browser.
We make our CA certificate available at a simple url (https://www.example.org/ca/) that uses a commercial certificate signed by a "real" CA, and provides an explanation and instructions on how to install our cert. Installation is straightforward in IE and Firefox, a little trickier in Safari.
Once our CA certificate is in the browser's trusted list, all of the other certs are trusted as well. The only thing to watch out for at that point is name mismatch issues caused by domain aliases and the like.
We considered publishing our certificate thumbprints, too, but that just seemed too paranoid.
>personally verified key signatures face-to-face.
Over the phone is probably adequate. You already know your bank's phone number. Incidents of phone numbers being rerouted are rare, though there are rumors of escort services in Las Vegas redirecting traffic meant for their competitors, and Florida's probation department once had their phone number remapped to a phone sex service in New York.
Over the phone, you'd just have the website operator read you the thumbprint for their cert. You could check it against the value shown in your browser.
Someone more mischievous than me should call up a bank and say "I'd like to verify the SHA1 hash of your X.509 certificate" and report on the results.
A realistic compromise is to note the thumbprint the first time you visit a site, hope it wasn't taken over at that instant, and then make sure it's the same next month when you visit again.
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. :)
Here is the problem though. Why should I trust a signed certificate? If I go to a website and am prompted by an un-signed certificate, I need to determine if I trust that that web site.
If I go to a web site and their certificate is signed so no prompt but I have just blindly put my trust in the web site and in the nameless CA.
Personally, I don't trust the CA's any more than I trust some random website.