Slashdot Mirror
SSL Cert Revocation Lists?
DA-MAN asks: "Browsers ship with a ton of different certificate authorities that provide 'trust' for secure sites that we visit. With all of these certificate authorities comes a certificate revocation list, which is to flag bad certs. Firefox, IE and Safari do not have an automated way to pull updated lists from all of the different certificate authorities, so one must download each CRL manually and import them into the browser. It occurred to me the other day that the only time I've ever seen this feature in use was when Microsoft inserted the CRL for a certificate that was mistakenly issued by Verisign with the "Microsoft Corporation" name. All that said, I was just wondering if anyone cares about this? Do you actually import updated CRL's into your browser? Why can't the CRL be signed by the Cert Authority and automatically imported?" What other browsers support automatic CRL updates?
Online Certificate Status Protocol.
Tools > Options > Advanced > Security > Verification
Verification that a certificate has not been revoked is not done in practice; however.
And how do you know that the certificates "from websites I know and trust" are really from said websites? The simple fact is you don't, because you have no trust in the root certs that they present.
From here:
The VeriSign screw up was made worse because their certificate didn't indicate a CDP (CRL Distribution Point) from which IE could have automatically downloaded the updated CRL. From Microsoft's security bulletin:
The Online Slang Dictionary
Don't use self-signed certificates. Create a private CA, generate a real root certificate, and then distribute that to all the clients that need it.
That way, you don't get a warning dialog, and you get real protection from MitM attacks.
Also: If you find the openssl(1) tool annoying, try certtool(1) from GnuTLS. I've found it a lot easier to work with.
iSKUNK!
The fact this guy is modded so high scares me, because his post is startlingly idiodic.
The purpose of a certificate signed by Verigisn/Thawte is most certainly not to tell you that you should trust the site you are at with your data. And in no way do either of these companies make any claim to this.
The only point of a third-party signed SSL certificate is so that you can say "OK, I am trying to connect to www.myfavoirtestore.com. Is the data actually coming from there, or am I actually getting data from www.hackersite.com that intercepted the transmission/hijacked the DNS/whatever?".
Whether or not you actually trust www.myfavoritestore.com with your data is totally irrelevant, beside the point, and has absolutely nothing to do with Verisign, Thawte, or SSL certificates.
It's up to the consumer whether or not to trust where they shop. In this sense the web is absolutely no different than the B&M world. The only job of Thawte and Verisign is to ensure you are where you think you are because unlike in the B&M world, you can't just look at the sign on the front of the store and trust it.
I've seen quite a few posts here decrying the root certificate authority "chain of trust" model commonly in use today, with drastic suggestions such as --deleting all of the root certificates that ship with the browser-- being made. This shows a general lack of understanding of how the chain of trust model works, and so I'd like to try to clear things up a bit:
Your browser comes with a bunch of root certificates generated by high-level certificate authorities installed -- Companies like Verisign, Thawte, etc. These companies then use these certificates to sign SSL certs for websites that purchase them, allowing the visitors to that web site to enjoy some degree of verification that Versign, Thawte, or whoever says that "You are at the legitimate website for 'https://www.example.com'."
How does Verisign or Thawte or whoever know that they issued the certificate to the real owner of "https://www.example.com"? Well, different certification authorities verify identity in different ways, and some even do different levels of verification depending on the certificate package purchased, or depending on how big (and potentially a target for fraud) the website that the cert is being requested for is. Generally speaking, at a minimum, they will do a "domain" verification. That means they will look up "example.com" in the whois database, find out who the administrative contact is for the domain, and send that person an email asking if the certificate request from "Some Person" is legitimate. Additional verification techniques may include publicly looking up a company based on the requested certificate domain name, calling them up, and asking to speak with the person who requested the certification, or, in some cases, requiring a request in writing from a company official authorized to request certificates in the company's name.
So now, you may be thinking, "Well, why the hell should I trust that Verisign or Thawte or whoever properly verified the identity of 'example.com' before issuing a cert? How do I know that they are not just money hungry bastards that issue a cert to anyone that asks? How do I know that they didn't just get hacked, and someone signed their own cert using the root certificate authority's cert?" The simple answer is --- Because they are money hungry bastards! They are a business. They somehow managed to work out the necessary red tape to get their root certificates to ship with the major browsers. They make lots of money by selling and signing SSL certs. It is in their best interest as a business to do this right. These companies want to verify certificate requests right and protect their systems from hackers intensely because they want their root certs to stay in the browsers; they want people to keep buying certs from them. Think about it...If a company starts getting a reputation for issuing certs without proper verification, or if it gets public that their private signing key has been compromised, then their root cert will be pulled from the major browsers, no one will trust them anymore, and no one will buy certs from them anymore. They will quickly be gone. I know there have been a couple of high-profile fuck-ups that have happened with CA's issuing certs to fraudulent requestors -- But people will only tolerate so many of these until they simply don't trust that CA anymore, and their root cert gets pulled from browser packages.
So, while the "chain of trust" does not inherently PROVE that Verisign correctly validated "example.com", and that they have not been hacked, it is most likely that Verisign DID do everything correctly to maintain their reputation and business model. That's why it still has the word "trust" in it. You are still "trusting" some things, but that "trust" is built up by a company over time by not fucking things up. Is the system perfect? No, of course not, but it does work, and it scales beatifully. If more stringent verification is needed, you can always create your own CA cert, install it on the necessary computers, and then issue certs signed by that cer