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?
I see these things popup sometimes and I shrug and click `whatever`. Who cares? It's not like you can't popup a fake one anyway, and the average user doesn't understand it all anyway. Either this sort of thing works invisibly in the background, or just forget about it.
I do it the other way: delete all these default browser certs from companies I've never heard of, then only allow ones from websites I know and trust.
It would be great to see someone write a Firefox extension which merged the CRLs into Firefox, though I'm not sure how to pull that off in the first place :(
Still, I'd love to see someone do it!
Viable Slashdot alternatives: https://pipedot.org/ and http://soylentnews.org/
Online Certificate Status Protocol.
Tools > Options > Advanced > Security > Verification
Verification that a certificate has not been revoked is not done in practice; however.
A large majority of people don't understand what a Cert is, what it does and why it's necessary. Most still just click through without checking the credentials of the cert in fact for those who use Hotmail, many times you will note that - that site's cert has expired. Mozilla seems to have halted things as of 2003 so I wonder if only financial companies and companies making financial transactions are the only ones constantly pursuing certs. Who knows... I used to use a cert for a security/political site I had as a means of encrypting content on the wire. I don't think many are altogether concerned with who signed what...
Infiltrated dot Net
I believe CRLs have been superseded by OCSP (Online Certificate Status Protocol) for just the reasons you noted. OCSP doesn't require local storage of revocation lists and the synchronization issues that go along with it.
At the end of the day, what has Verisign or anyone else ever done to deserve unquestioning trust from me, a person with no legal recourse to challenge their decisions about who to issue certificates to?
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
It's somewhat off topic, but I have a related question. If all you want to do is encrypt traffic, and don't really care about the extra warning dialog, is there any disadvantage to using self-signed certificates?
Two ideas:
This would seem to solve this security hole nicely with minimal fuss. Normal users don't worry, they have a clear thing to do when the indicator changes, be it an extension or built into Firefox.
Unitarian Church: Freethinkers Congregate!
It's my understanding that there is a mechanism to automatically get CRL's in IE, but not all CA's use the optional item in the relevant RFC. Verisign used a specific 'well known' URL to host their CRL; I've seen rants that Microsoft should have used that URL to get CRL's, however that seems like a bad idea to me for many reasons:
.xxx...
What if the URL is hijacked; via DNS poisoning, HOSTS, a BHO, site hacks, proxy hacks... a URL is unfortunetly, not 100% reliable.
Why should Verisign get special treatment?, because Microsoft used them as a CA? I recall recently a huge stink was made about Windows treating special URLs differently... what about the CA's used by Firefox, Opera, AOL... shouldn't those CA's get equal special treatment? (all URL's are equal, but some are more equal than others)
Isn't it a bad idea to hard-code strings into software? does that same CRL URL apply world-wide and forever? imagine if between 2000 and 2007 Verisign went bankrupt, got bought by AOL/Time/Warner, or decided to change it's name to 'SuperAwesomeSign.com'? What if the nature of internet addressing chages? Unicode, IPv6,
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
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 never said the system was foolproof, and indeed, the root authorities are fallable and have mad ehuge mistakes in the past. I was only trying to accuratly describe at least the idea behind certificates. The GP poster was implying a totally different idea, that somehow Thawte/Veresign are somehow responsible for the content of the sites to which they issue SSL certificates. Nothing could be further from the truth. Any Joe/Dick/Harry can get an SSL certificate for any domain they can dream up. If you aren't trusting the root cert. authorities, then having SSL certificates *at all* is totally pointless. SSL certificates have nothing to do with the encryption cipher being used - they don't make the data secure. They just try to provide authority of the data. If you don't trust the root authorities then you might as well just call any company you want to connect to securely and rattle off the public key being used so they can confirm it, because that is basically what you are doing if you accept the untrusted SSL connection.
My favorite line about SSL Cert revocation came from a security presentation where a guy went through about thirty slides covering about 4 or 5 different ways people actually tried to make cert revocation work. At the end he said "and if you find a way that actually works 100%, see me after class."
I think the point is: don't ever get caught in a situation in which you need to revoke certificates, because it's likely you'll never completely be able to revoke them for everyone. (i.e., protect your SSL cert backups)
Also, people who are posting stuff about individually trusting new server certs are kind of missing the point; sometimes an issuer wants to revoke a cert you may have already individually trusted too.
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
MSIE7+ on Windows Vista will have OCSP too, and it will be enabled by default. Most likely Firefox will turn it on by default at some point too if they are satisfied it will not "break the internet".
If a CA's OCSP responder goes down, ALL sites using their certificates will be instantly knocked off the web as the browsers will refuse to connect to them.
I suspect this is why it is off by default in the release of the browsers -- it makes browsing secure sites far too painful.
- "History shows again and again how nature points out the folly of men" -- Blue Oyster Cult, 'Godzilla'
Yeah, I agree. Ironically, short cert expirations tend to cheese off the "I must individually trust every cert for security purposes" people more than anyone else (because it's inconvenient for them). I wish more people read this thread...