Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×

SSL Cert Revocation Lists? 59

Posted by Cliff from the respect-mah-authoritah dept.
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?
This discussion has been archived. No new comments can be posted.

SSL Cert Revocation Lists? More

SSL Cert Revocation Lists?

Comments Filter:
  • 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.

    • Two ideas:
      • Have Firefox automatically update from a set of known sites at a configurable interval. An indicator, like the update-now exclamation point of up2date, which if clicked upon would get and install the latest CRLs from all the available authorities;
      • A Firefox Extension should be created (anyone? anyone? Buhler?) that does this automatically at a configurable interval.

      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

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

    • Re:CRLs = blacklists (Score:3, Informative)

      by joebp ( 528430 )
      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.

      • Re:CRLs = blacklists (Score:3, Insightful)

        by jaseuk ( 217780 )
        Precisely. All SSL is really good for on the general internet is to prevent casual sniffing. You can sign up for a cert these days for $25 with very little clearance. The trust element has completely gone, if it was ever there at all?

  • This would be nice (Score:3, Insightful)

    by gcnaddict ( 841664 ) on Thursday June 01, 2006 @07:55PM (#15449814)
    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!
    • It would be great to see someone write a Firefox extension which merged the CRLs into Firefox

      Firefox will download CRLs repeatedly, once you have already done it manually once. Go to crl.verisign.com in Firefox, and click on one of the CRLs. Firefox will import it for you and offer to fetch it periodically.

      What Firefox is not doing - yet - is to look for a CRL Distribution Point URL in a certificate and then automatically download the CRL from that location.

  • Firefox supports OCSP (Score:5, Informative)

    by mysidia ( 191772 ) on Thursday June 01, 2006 @08:03PM (#15449884)

    Online Certificate Status Protocol.

    Tools > Options > Advanced > Security > Verification

    Verification that a certificate has not been revoked is not done in practice; however.

    • Extra time is taken for the request; or substantial disk space memory is used to download lists of revoked certificates -- slows down access to secure sites.
    • CRL lists can be out of date, if you importe an old list; a certificate you think invalid, may no longer be invalid -- CRLs allow a certificate to be blocked either temporarily (hold) or permanently (Revoke).
    • Online updates as to certificate status is something that would use a phenomenal amount of bandwidth, for any large CA; if all clients check status before allowing -- it would cut into CA profit margins if every web surfer insisted on downloading CRLs regularly for trusted CAs or before accepting a certificate. This would tend to discourage CAs from using CRLs, or justify even more extortionate rates to buy essential web server certificates.
    • 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.
    • ...that your browser basically hangs several times a week if you go to secure sites, becuase the OCSP server is either down/not-reachable/overloaded. I don't know anyone who has ever left it turned on more than a month.

      I suspect this is why it is off by default in the release of the browsers -- it makes browsing secure sites far too painful.

  • 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 [mozilla.org] 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 h

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

  • Moot point (Score:2, Interesting)

    by nagora ( 177841 )
    The first thing I do with a browser is delete all the certificates and tell it to ask me on a case-by-case basis. Since I don't trust Verisign/Thawte at all the whole system is fairly worthless.

    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

    • So what do you do instead? What advantage is there to having every HTTPS site interactively prompt you whether to accept the certificate or not?

      The only benefit I can see is if you telephone the administrator of every such site, have them read the certificate's fingerprint, and verify that the one you received in the browser matches.

      Since you don't do this, how do you know whether to accept or not?
      • What advantage is there to having every HTTPS site interactively prompt you whether to accept the certificate or not?

        Well, firstly "every" in this case amounts to about three sites per year so it's no big deal. But in general I think I'm a better judge as to whether the site I'm on is the real thing than some distant CA.

        As I said in my original post, I have no reason to trust or believe in Verisign's (or any other third party) ability to accurately judge who they are giving certificates to nor do they hav

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

      • 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?".

        I wouldn't say that's the only point... if you really trust the issuer, it's also supposed to give you some factual information, usually the company name, department name, phone number & address of whoever the cer
        • It doesn't need to be correct. The reason the certificate contains that information is so that you can vertify that it belongs to the site you are trying to connect to.

          I could issue an SSL certificate for a website claiming that my address was "On The Moon" - a totally invalid address. But if you through external means know from me that my address in the SSL certificate should say I live "On The Moom", then you know (or at least be that much more sure) it is me.

          An SSL certificate is nothing more than a type
      • 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?".

        Aah, but if you connect to www.paypa1.com, such a system would confirm that it legitimately has an SSL certificate for www.paypa1.com but you have no way of knowing who operates www.paypa1.com (assuming you noticed that

    • "Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"

      I don't get your sig. Are you implying that consulting Wikipedia is like asking a group of people at a bus stop? So if I wanted to know about Quantum Mechanics I'd be better off going to the library and reading books by people who know about it rather than asking some random folks. Is that what you're getting at?

      Perhaps Encyclopedia Galactica versus The Hitch Hikers Guide to the Galaxy would be a better analogy.
      • So if I wanted to know about Quantum Mechanics I'd be better off going to the library and reading books by people who know about it rather than asking some random folks. Is that what you're getting at?

        Yes.

        TWW

    • Re:Moot point (Score:3, Interesting)

      by Lord Ender ( 156273 )
      Instead of jumping right to the tinfoil hat response, I'll give you a real reason to trust Verisign: It is in their financial best interest verify that they are giving certs to the right people. If they make too many mistakes, Microsoft might stop including them with Windows (due to customer demands).

      Reputation is everything in the cert industry. They won't want to lose it.

  • Self-signed Certs (Score:1, Interesting)

    by Anonymous Coward
    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?
    • No problem at all, provided you make sure to memorize your key fingerprint. A self-signed cert can be used to encrypt just fine--you'll just need to tell your browser to trust it for however long you feel necessary. The problem comes when someone manages to hijack your DNS and *also* has a self-signed certificate with your site's name on it. The fingerprint being different is about the only warning you're going to get (because it will be trivial for them to tunnel the HTTP requests through their fake ser

    • Re:Self-signed Certs (Score:5, Informative)

      by Straker Skunk ( 16970 ) on Thursday June 01, 2006 @09:02PM (#15450260)
      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.
  • 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:

    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?, becaus
    • What if the URL is hijacked; via DNS poisoning, HOSTS, a BHO, site hacks, proxy hacks... a URL is unfortunetly, not 100% reliable.

      Presumably the hijacker wouldn't have a signed cert, which should raise red flags on your browser.

      Why should Verisign get special treatment?, because Microsoft used them as a CA?

      Verisign didn't get special treatment. Microsoft put out an update that put the revoked "Microsoft Corporation" certificates in the CRL. This is because IE can be told to always trust signed executables b
    • 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

      X.509 v3 certificates can contain an optional extension called CRL Distribution Point containing a URL to the specific CRL on which that certificate would appear.

      VeriSign do use this - take a look at crl.verisign.com in your browser and see how many different CRLs VeriSign have. Each issued certificate poi

    • What if the URL is hijacked; via DNS poisoning, HOSTS, a BHO, site hacks, proxy hacks... a URL is unfortunetly, not 100% reliable.

      If an attacker uses DNS poisoning or proxy hacks, the CN on the cert would not match the DNS hostname, which would cause an error, or the cert would have an unknown CA, which would also cause an error.

      An HTTPS URL is 100% reliable if the hostname matches the CN on the cert, and the cert was issued by a "trusted" CA. "Trusted" in this case means you have the CA's cert (kind of lik

  • Uhh... (Score:3, Informative)

    by WalterGR ( 106787 ) on Thursday June 01, 2006 @08:58PM (#15450234) Homepage

    From here [microsoft.com]:

    Internet Explorer 6 includes support for server certificate revocation, which verifies that an issuing CA has not revoked a server certificate...

    To enable server certificate revocation, in the Internet Options dialog box, click the Advanced tab, and then select the Check for server certificate revocation check box...

    Internet Explorer 6 includes support for publisher's certificate revocation, which verifies that an issuing CA has not revoked a publisher's certificate. To enable publisher's certificate revocation, in the Internet Options dialog box, click the Advanced tab, and then select the Check for publisher's certificate revocation check box.

    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 [microsoft.com]:

    Every certificate should provide a piece of data called the CRL Distribution Point (CDP) - this data indicates the location from which the CRL can be obtained. The problem is that VeriSign code-signing certificates don't provide CDP information. As a result, even though VeriSign has added these two certificates to its current CRL, it's not possible for systems to automatically download and check it. Our update compensates for this omission in the VeriSign certificates.

    • Grammar tip: "Effect" is a verb. "Affect" is a noun

      Grammar tip: you have it backwards.

      Formally, Effect and Affect are each both nouns and verbs. But the most common use of Effect is as a noun, and the most common use of Affect is as a verb.

      Common: The hurricane had a terrible effect on the New Orleans economy.
      Less common: Bush has effected a change in interpretation of privacy laws.
      Common: The hurricate affected the New Orleans economy terribly.
      Less common: Bush affected a strange indifference to

    • To enable server certificate revocation, in the Internet Options dialog box, click the Advanced tab, and then select the Check for server certificate revocation check box...

      And then REBOOT. *cough* How's that for good user interface design?

      The point is that it is off by default, and not trivial to enable.

      MSIE7+ on Windows Vista will have both OCSP and CRL functioning, and ON BY DEFAULT.

  • 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

  • How Root CA Trust Works (Score:3, Informative)

    by Anonymous Coward on Friday June 02, 2006 @12:45AM (#15451414)
    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

    • Well, somebody should mod this up as informative, for those of us reading this discussion to try to learn a little about what this is all about. However, the post is a little confusing in that some of the advice is for browser users (So, I hope that my explanation has shown why you are not better off automatically "not trusting" the root CA's, and deleting their certs), and some of it apaprently is for website owners (All you can do is pick a company known for security as your domain registar and use a STRO

      • certificates have a built in expiry date, the cynical would say this is part of a money grab, the less cynical would say its to stop certs with no longer acceptable encryption levels remaining in use and to reduce the lifetime of a stolen key.

        Either way if its just a community site or something i'd ignore it but if it was a merchant or worse a bank i'd be worrying about how well they are keeping thier house in order if they let thier SSL certs expire.
    • Thank you thank you thank you. Hundreds of ignorant comments are posted in every SSL thread. It's amazing how little people want to learn about this. Your explanation was right on the money, and I hope everyone reads it.

Slashdot Top Deals

Receiving a million dollars tax free will make you feel better than being flat broke and having a stomach ache. -- Dolph Sharp, "I'm O.K., You're Not So Hot"

Close