Mozilla shipping SSL root certificate, has no idea how it got there
groups.google.com
groups.google.com
'I have received email from official representatives of RSA confirming that RSA did indeed create the "RSA Security 1024 V3" root certificate that is currently included in NSS (Netscape/Mozilla) and also in Apple's root cert store.'
So sounds like there hasn't been some rogue root cert out there for the last 9 years. Good to see that root certs are rogue until proven valid, though.
The article gave the impression that some CA's are a bit too happy to issue root certs, and he mentioned he's been blogging about the whole SSL trust system being broken for quite a few years now.
I would apreciate this article too! issueing a root cert at mozilla isn't as easy as it looks... they changed a lot in the process i think
It's of course harder to prove that NO sites use this cert. If there's a way to craft a Google query that searches for sites signed by a particular cert, that could go some distance to indicating whether it's been used and where.
One of those root certificates is of unknown origin.
I'm sure I'll be corrected if I'm wrong, but my understanding is that public key cryptography is very processor intensive. Because of this, instead of using your private key to sign every bit of communication, you use the public/private key crypto to negotiate a shared secret for a different algorithm, such as AES.
So it still comes down to having a shared secret. Public/private keys just change the way that secret is shared.
Going back to the issue at hand, the question is where did you get the original public key from. This has always been the "problem" in public key systems. You have to trust the public key that you get in the first place.
It's more than just an issue of efficiency. Encrypting/signing nonrandom text with RSA exposes you to all kinds of nasty attacks. For example, if you directly sign a message whose blocks are composed of prime numbers (rather than hashing the message and signing the digest), then an attacker can afterward forge your signature on any message composed of a sequence of blocks which are known powers of those primes or their mod-N inverses.
The entire SSL-certificate system is trust-based. When presented with a certificate for a particular domain, you need to ask some trusted Certificate Authority, like Verisign, whether the credentials match up. If the credentials don't match then you can warn the user that something's up - the site might not be who it claims to be.
However, how do you know whether you can trust the computer identifying itself as Verisign? Well, various CA root certificates are built into browsers. It seems that Mozilla has been shipping with a potentially rogue root authority for a while now, so there's the potential that whoever owned that certificate / IP might have been abusing it -- all the while having that comforting green tick in your browser to say the certificate is valid.
http://www.rapidssl.com/ssl-certificate-support/ssl-faq.htm#...
The implication, and what makes this scary, is that if this were done with malevolent intentions, there could be a whole host of sites out there that had "bogus" certificates that Firefox would think were fine because they were signed by this trusted authority.
Just as an aside, you can always see the certificate chain in Firefox by clicking on the favicon area when a certificate is in use (i.e. when using https), clicking on "More Information", clicking "View Certificate", and going to the "Details" tab. You can then see the "Certificate Hierarchy". This shows you all the certificates in the chain, and who signed what. At the very top should be the "root authority"; this is usually someone like Verisign.
To bring this whole thing around, then, on some sites, you could see the root authority as the certificate mentioned in the post.
I guess, finally, I should point out, like others have, that this doesn't really mean anything bad is going on; the certificate could be perfectly valid. However, it is at least a little worrisome that they aren't sure where it came from.
You can always remove certificates from CAs you don't trust. If you don't trust Verisign, how can you tell Amazon is really Amazon?
Moreover, even as a sophisticated user, I have to observe that I actually do not trust a single root certificate in my browser the requisite 100% that is necessary for this whole system to work. I can not assign a 0% probability to any of them being compromised by a hostile force, especially when the hostile force isn't necessary a random hacker but may be a sovereign government.
So, while your point is totally correct, it should be pointed out it isn't really a defense of the current system. (Which you may not have intended it as, but I have seen others use it this way and it's worth pointing out.)
Right now, I won't trust it that much.
Further, there's no room for decreasing my trust in a cert based on the length of the chain, or who's on the chain, or anything like that.
The whole system is structured to produce a 100% certification of trust, or a 0% certification of trust. This has the consequence that when the system is compromised in the way that you talk about in your last paragraph, it doesn't degrade; it falls apart.
It's not that robots from the future might compromise a cert, and going to something so fantastic in the light of the real threat of sovereign governments and the proved threat of compromised root CA certs (proved as in "you could buy this device for real money and have it really delivered to you") is a rhetorical unkindness. It is that nobody can any longer claim with a straight face that the system is 100%, and unfortunately, with SSL that leaves only one alternative.
Compare with the semi-mythical "web of trust", which would have ways of dealing with this that doesn't violate the very mathematical foundations of the system.
Longer version: http://en.wikipedia.org/wiki/Public_key_infrastructure and http://en.wikipedia.org/wiki/Root_certificate
Furthermore browsers ought to be meticulous about which certification authorities they trust and include in their liste of trusted root-CAs. If you'd trust anyone certifying someone else's identity, what would be the point in the first place?
Now if someone managed to sneak in a rogue CAs public key into a major webbrowser (and it currently doesn't look like it's the case here) it would undermine the whole SSL security model because the entity controlling the CAs private key would be able to generate arbitrary certificates. These days they are not only used to authenticate webservers (or other kind of servers) but also to make sure that downloaded code is genuine. So indeed a CA that is trusted but about which no one really knows where it's coming from is indeed a big deal.
Basically it's a Secure Connection to a malicious Site. Got it?
http://www.mail-archive.com/debian-bugs-dist@lists.debian.or...
The Debian bug also refers to "RSA_Security_1024_v3.pem" which is the one Mozilla is discussing, and whose filename and contents refer to RSA Security, Inc. But the Debian bug offers that as an example of a good certificate!
Resuming the matter, the SSL system is broken, as it works today, one of the messages clearly states:
Both "RSA Security 1024 V3" and "RSA Security 2048 V3" are shown as valid in Apple's System Roots.
Microsoft's list includes "RSA Security 2048 V3", but not "RSA Security 1024 V3".
Has someone checked if they are included in Opera and Chrome as well?
My copy of Chrome doesn't seem to have it.
As always, YMMV.
There are so many settings and warnings that a common user does not understand. This new one would not scare any users away I guess. They will just ignore it.
I would be very happy to notice that my browser suddenly uses a different certificate to validate the certificate of one of my servers.
This gives a great Mitm Vector if i'ts a malicious CA
It mostly does, of course. But greater transparency also means you need excellent auditing and tracing procedures. This highlights the potential dangers, as well as the daftness of the current trust-based security model.
There are two certificates from the same CA. Microsoft ships one of them. Are you willing to vouch for every certificate Microsoft ships with Windows? Are you sure their process is flawless? Are you absolutely sure their code shows all certificates they trust and there is no sneaky unlisted CA in their whole HTTPS stack?
I think you're jumping to conclusions here. For one it did get detected, secondly the theory is that faults are detected earlier and fixed faster, not that they don't occur at all. So no matter how long this has been in the wild, the question is how long it would have been there if it had not been open source. My guess is in this particular case just as long, but there are many other cases besides this one.