Mozilla shipping SSL root certificate, has no idea how it got there(groups.google.com)
groups.google.com
Mozilla shipping SSL root certificate, has no idea how it got there
http://groups.google.com/group/mozilla.dev.security.policy/browse_thread/thread/b6493a285ba79998/26fca75f9aeff1dc
13 コメント
[deleted]
It's more likely than not that there's a harmless explanation for this one, but with the rash of these stories lately I think it's past time to declare that the PKI trust model is broken.
What troubles me is that no one has tried actually looking for sites that use this cert. If any valid sites are signed using this cert, then it's a simple matter of asking them who they paid for certification.
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.
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.
Can anyone find the link to that recent article / guide on registering a likely-looking address at a webmail provider then scamming a root certificate for that domain?
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.
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.
+1
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
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
Could someone please explain to me what this means ?
As far as I understand it:
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 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#...
Just to be fair, one of those certificates is shipped with Internet Explorer too.
You mean the one that RSA clearly said it owns? Let's be clear: this is a question about one certificate, that seems to ship with a number of different browsers and systems. Internet Explorer, however, isn't one of them.
Firefox ships with a bunch of trusted root authority certificates. If I understand how certificates work correctly, essentially what this means is that any certificate that is signed by these root certificates is automatically trusted by your Firefox browser.
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.
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.
> The implication, and what makes this scary
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?
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?
Once you, the user, are removing root certificates from your browser, the trust system has failed. Especially since while you and I may understand the full implications of such an action, "you the user" in general can not. The entire point of the trust system was to remove the need for the generic end-user to make such decisions, and if it fails that, it fails everything.
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.)
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.)
One cannot be 100% sure a CA isn't compromised by a robot coming from the future. You don't have to 100% trust a CA, but you have to know how much trust you'll give to the whole system.
Right now, I won't trust it that much.
Right now, I won't trust it that much.
That's not the way in which the system is structured for 100% trust. The problem is that the system as a whole produces a binary answer: "Yes, this site has passed your trust chain" and "No, it has not." There's no room for dodgy certs, and certainly no room for dodgy root CAs.
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.
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.
Mozilla ships with a root certificate, and they don't know who has the private key portion. Therefore, some rogue could be signing SSL certificates, executing man-in-the-middle attacks, or something else. These rogue certificates would be trusted automatically by Mozilla browsers.
The current SSL security model assumes that certification authorities are thorough with the checks they perform on people applying for certificates, so that I -as an example- cannot pose as your bank and obtain your credentials by fraud.
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.
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.
Short and dirty version: example.com has a certificate that is verified by a certificate authority (CA). Since there are lots of CA's, your browser cannot verify them all. However, it can verify a CA's certificate using another CA's certificate. A root CA is one whose certificate is included with the browser and is considered a trusted and secure source of identity information. Needless to say that compromising root CA's certificates in browsers is a big deal. On the other hand this particular instance in all likelyhood is simply a matter of human error, not a malicious attack.
Longer version: http://en.wikipedia.org/wiki/Public_key_infrastructure and http://en.wikipedia.org/wiki/Root_certificate
Longer version: http://en.wikipedia.org/wiki/Public_key_infrastructure and http://en.wikipedia.org/wiki/Root_certificate
An over-simplification, but in order for crypto to work, there needs to be a secret that is shared before hand. For SSL the root certificates are that pre-shared secret.
One of those root certificates is of unknown origin.
One of those root certificates is of unknown origin.
How do you square that with public key cryptography?
It was an oversimplification, but still valid. With public/private keys you know something that no one else knows (your private key). But instead of needing a shared secret, you are sharing your public information. The big difference (IMO) in public/private crypto and traditional shared secret crypto is the decoupling of encryption and decryption.
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.
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.
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.
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.
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.
If someone (with a malicious background) owns a Root CA wich is embedded into the Mozilla Cert Storage he could sign SSL Certs sites as he wants to... and clearly the user won't be warned that the connection isn't secure because the Root CA is there.
Basically it's a Secure Connection to a malicious Site. Got it?
Basically it's a Secure Connection to a malicious Site. Got it?
My gut says that it is a RSA mistake. That they shipped a wrong certificate way back in 2002.
It seems that the problem is that the certificate file name does not match its contents.
http://www.mail-archive.com/[email protected]...
http://www.mail-archive.com/[email protected]...
Hmm, it looks like that bug's still open with no responses, 4 yrs later: http://bugs.debian.org/351745
Actually, that Debian bug is about a different CA file "RSA_Root_Certificate_1.pem" that is owned by Valicert but contains "RSA" in the filename, probably because it uses the RSA-SHA signature algorithm.
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!
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!
The associated bugzilla ticket was posted here on hacker news earlier today: http://news.ycombinator.com/item?id=1244164
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?
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?
> 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.
My copy of Chrome doesn't seem to have it.
As always, YMMV.
Browsers should provide a function that monitors certificates for changes and alerts the user if (if he wants to).
This introduces a decision your typical user is not competent to make ("should I enable this setting?") and yet another error message they will quickly learn to ignore.
I agree. But imho this is no reason to not include the suggested feature.
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.
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.
Yes, it should be similar to disabling cookies or javascript. Or tinkering with other options. A default for the "normals" but power to people who know what they are doing.
It looks like the certificate can easily be deleted manually: Preferences > Advanced > View Certificates.
yes this sould not be the core of the problem. its important to know _who_ owns the debatable CA.
This gives a great Mitm Vector if i'ts a malicious CA
This gives a great Mitm Vector if i'ts a malicious CA
Is it possible to do a web crawl scan of https and SSL certs and find out which certificates have this questionable one as their root?
[deleted]
Uh... thats not good... and our gov-CA is hanging in the cert approval proces since... about a year now. strange world
[deleted]
maybe what is needed is an additional mechanism that browsers can use to verify that a CA is the correct one for a particular domain name.
Whoops! So much for open source allowing for greater scrutiny and security.
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.
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.
> Whoops! So much for open source allowing for greater scrutiny and security.
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?
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?
If a public discussion on what could be a massive internet authentication breakdown does not constitute "greater scrutiny and security", I wonder what does.
> Whoops! So much for open source allowing for greater scrutiny and security.
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.
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.
The same RSA 1024 certificate is in Mac OS X. Perhaps they kept a record of where it came from.
'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.