Hacker News Reader

Comment by chunkyslink | Hacker News Reader

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#...

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

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.)

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.

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.

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.

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

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.

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.

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?

Reply on news.ycombinator.com