Re: About the Cybertrust Educational CA certificate
On Wed, Sep 17, 2008 at 05:06:55PM -0700, Wan-Teh Chang wrote: On Wed, Sep 17, 2008 at 4:52 PM, Eddy Nigg [EMAIL PROTECTED] wrote: I've been banging my head against a wall here because of this FUD and about misinformation which is absolutely incorrect. Sad, because there are many FF users running into it. And it doesn't help to ignore the fact that web site admins don't install their certs correctly - it works in IE and that's it. It would be nice to contribute a patch for Apache/mod_ssl to validate its own certificate chain at startup. [catching up on some old e-mail!] This would be quite simple to do, but mod_ssl doesn't necessarily have access to a set of trusted CA certs against which to validate a server cert, so it couldn't be universally applied. It might be possible for mod_ssl to determine whether OpenSSL has in fact been configured with a set of default CAs (many Linux distributions do set this up), and perform validation only in that case. Regards, Joe ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Kyle, Kyle Hamilton wrote: There's another, more pressing issue: If there are buffer overflows in ASN.1 parsing (there have been in at the least OpenSSL and Microsoft's), anyone who can provide a certificate that points to an AIA that ultimately wouldn't be trusted could provide malicious data that could compromise the issue. We took care of such issues in our ASN.1 parsing years ago. It was a large effort and many problems were found, and resolved in NSS 3.9, in 2004. Currently, we run test cases of millions of malformed certs from NISCC against every nightly build of NSS, FYI, to make sure that the code in that area doesn't regress. I'm not saying there are no remaining bugs - some may be found eventually - but we take the code in our ASN.1 decoders/encoder very seriously. In addition, if there were an MD5-like hash collision in such a way that an attacker could forge an apparently-valid (the signature matches what was signed, though the data does not) CA:true certificate, then all hell breaks loose. Currently nothing of the sort has been shown to be possible, however. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Eddy, Eddy Nigg wrote: Julien, can we assume that by trying to construct a valid chain up to a trusted root - even by fetching intermediate CAs via the AIA CA Issuer extension - doesn't present a risk we can not take? During this discussion I've found that only a very minimal privacy concern exists - if at all. I'd very much like to see the arguments against the implementation of fetching intermediate CA certificates declared null and void. At least to the extend which would allow us for such an implementation. I'm only saying it's safe to try to decode anything you have in memory within the application with one of the NSS ASN.1 decoders, and it doesn't present a risk to the integrity risk of the rest of the process. Issues of privacy related to downloads having been performed are separate. I must say that I haven't been following that part of the discussion closely enough to have an opinion on that topic. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/20/2008 02:45 AM, Julien R Pierre - Sun Microsystems: We took care of such issues in our ASN.1 parsing years ago. It was a large effort and many problems were found, and resolved in NSS 3.9, in 2004. Currently, we run test cases of millions of malformed certs from NISCC against every nightly build of NSS, FYI, to make sure that the code in that area doesn't regress. I'm not saying there are no remaining bugs - some may be found eventually - but we take the code in our ASN.1 decoders/encoder very seriously. Julien, can we assume that by trying to construct a valid chain up to a trusted root - even by fetching intermediate CAs via the AIA CA Issuer extension - doesn't present a risk we can not take? During this discussion I've found that only a very minimal privacy concern exists - if at all. I'd very much like to see the arguments against the implementation of fetching intermediate CA certificates declared null and void. At least to the extend which would allow us for such an implementation. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Kyle, Kyle Hamilton wrote: Mary and Mallory may not be the same control. Mary has a site with a cert with AIA. Mallory can take control over that location for the AIA, without Mary being able to do a thing to stop it. If Mallory was able to replace Mary's cert with a fake one, then they effectively have control already, and they might as well save themselves the trouble and just download Mary's server log file. It will be much more discreet, and less trouble. The other case is an MITM . Mallory is intercepting Mary's incoming connections somehow, and sending their own fake cert (MITM) with an AIA, that phones back home. However in that case, why bother even phoning back home ? Mallory is in the middle, and already knows that Alice is trying to connect to Mary. It's a little hard to see what Mallory is gaining from using an AIA that they can't already get by other means. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/20/2008 03:45 AM, Julien R Pierre - Sun Microsystems: I'm only saying it's safe to try to decode anything you have in memory within the application with one of the NSS ASN.1 decoders, and it doesn't present a risk to the integrity risk of the rest of the process. Thank you! This was my understanding on this subject. Similar I believe that NSS can try to construct a valid chain by using different input sources including server supplied, AIA and local authority DB. This will result in either a failure or success, for both situation NSS has a defined process. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/20/2008 03:54 AM, Julien R Pierre - Sun Microsystems: It's a little hard to see what Mallory is gaining from using an AIA that they can't already get by other means. And besides that, there are precedents with OCSP URI, to which any of the mentioned scenarios would also apply. However as you mentioned, I believe that the argument isn't really of concern for the reason you outlined. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 07:22 AM, Nelson B Bolyard: In the case of AIA cert fetching, we have a cert for which we have no issuer cert. We cannot know that the the cert we are trying to validate was signed by a real trusted CA. But you trust the CA certificates the server send to you, do you? Even if its issuer name matches that of a known and trusted CA, it may be a cert crafted by an attacker Really? Please enlighten me how...I would like to see a real example! But in that case the server can send also such a specially crafted CA certificate which chains to a builtin root, right? There is no difference between relying on a server sending the missing chain or NSS fetching it. In the end it must in both case validate up to a known root. for the specific purpose of getting the program that is attempting to validate the cert to do a fetch from a URL that is entirely under the control of the attacker. Or from the server... So, the risk to a browser of doing AIA cert fetching is relatively small. There is no higher risk that relying on the CA chain the server sends. In moth cases the parties might be interesting in spoofing Are you sure? Yes It would be relatively trivial to construct an attack client like the one I described above using NSS. Please construct such an attack for me... Firefox 3 does something to compensate for misconfigured servers that is without risk. When it validates a server cert chain and finds that it is valid, Firefox remembers each of the certs in the chain. I'm aware of that, but it requires to have visited at least once a correctly installed certificate at a site. It's actually very good to lower the traffic when fetching via AIA would be working. It would very efficiently fetch those needed and not bother when it has it already in the store. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 01:43 PM, Eddy Nigg: Even if its issuer name matches that of a known and trusted CA, it may be a cert crafted by an attacker I wanted to add here, that if this were true, than this would apply for any certificate, including server certs, CA certs and anything in the path. I sincerely believe that creating such a certificate which would appear and understood by NSS as being issued by a CA root NSS trusts is nearly impossible. Otherwise we'll have to look into this more in detail as it would mean that NSS might be fooled by a specially crafted certificate. It would literally mean, that somebody could play CA... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 9/17/2008 4:52 PM, Eddy Nigg wrote: On 09/18/2008 02:05 AM, David E. Ross: Note that this is not a unique situation. See bug #390835 at https://bugzilla.mozilla.org/show_bug.cgi?id=390835. Unfortunately, Internet Explorer (IE) works around this situation by searching the Internet for missing intermediate certificates. I consider this a security vulnerability in IE. However, because of IE's behavior, many Web server hosts ignore this problem (e.g., Canon, per bug #390835). Please note that IE isn't searching the Internet for missing certs, but is using the AIA CA Issuers extension of the server certificate to download the missing certificates. If the fetched CA certificate doesn't chain to a CA root it will not use it. If there is no AIA extension IE will also report an error (as with FF). There is absolutely no security issue at all with following the AIA CA Issuer extension, otherwise FF could not use the same extension to find the OCSP responder URL either. Nevertheless NSS does exactly that...uses the OCSP URL listed in the AIA extension. I've been banging my head against a wall here because of this FUD and about misinformation which is absolutely incorrect. Sad, because there are many FF users running into it. And it doesn't help to ignore the fact that web site admins don't install their certs correctly - it works in IE and that's it. Similar tweaks and corrections were made for FF if major sites didn't play nicely with standards in order to make FF usable. With the new error reporting for invalid certificates, this issue should have been solved beforehand. :-( Okay, I chose the wrong words. The vulnerability arises because IE enables hosts to be sloppy in how they configure their Web servers. If they won't include the required intermediate certificates, what else are they not doing properly? Is the server host machine physically secure? Are databases with personal data about customers (e.g., entered through secure Web pages) encrypted? Just slap this site certificate into the server. Don't worry about what secure Web browsing really means. -- David E. Ross http://www.rossde.com/ Go to Mozdev at http://www.mozdev.org/ for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
There's another, more pressing issue: If there are buffer overflows in ASN.1 parsing (there have been in at the least OpenSSL and Microsoft's), anyone who can provide a certificate that points to an AIA that ultimately wouldn't be trusted could provide malicious data that could compromise the issue. In addition, if there were an MD5-like hash collision in such a way that an attacker could forge an apparently-valid (the signature matches what was signed, though the data does not) CA:true certificate, then all hell breaks loose. Do not trust input from the user (unless obtained through a secure means). Trust input from potential attackers even less (since you cannot obtain it through a secure means). Only once the trust protocol has been completed should the trust be extended. -Kyle H On Thu, Sep 18, 2008 at 3:43 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 09/18/2008 07:22 AM, Nelson B Bolyard: In the case of AIA cert fetching, we have a cert for which we have no issuer cert. We cannot know that the the cert we are trying to validate was signed by a real trusted CA. But you trust the CA certificates the server send to you, do you? Even if its issuer name matches that of a known and trusted CA, it may be a cert crafted by an attacker Really? Please enlighten me how...I would like to see a real example! But in that case the server can send also such a specially crafted CA certificate which chains to a builtin root, right? There is no difference between relying on a server sending the missing chain or NSS fetching it. In the end it must in both case validate up to a known root. for the specific purpose of getting the program that is attempting to validate the cert to do a fetch from a URL that is entirely under the control of the attacker. Or from the server... So, the risk to a browser of doing AIA cert fetching is relatively small. There is no higher risk that relying on the CA chain the server sends. In moth cases the parties might be interesting in spoofing Are you sure? Yes It would be relatively trivial to construct an attack client like the one I described above using NSS. Please construct such an attack for me... Firefox 3 does something to compensate for misconfigured servers that is without risk. When it validates a server cert chain and finds that it is valid, Firefox remembers each of the certs in the chain. I'm aware of that, but it requires to have visited at least once a correctly installed certificate at a site. It's actually very good to lower the traffic when fetching via AIA would be working. It would very efficiently fetch those needed and not bother when it has it already in the store. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 09:48 PM, Kyle Hamilton: There's another, more pressing issue: If there are buffer overflows in ASN.1 parsing (there have been in at the least OpenSSL and Microsoft's), anyone who can provide a certificate that points to an AIA that ultimately wouldn't be trusted could provide malicious data that could compromise the issue. Very interesting Kyle. So how do you propose to solve the problem? Any server can send a server certificate including the chain which could provide malicious data! This isn't unique to the AIA extension obviously. A rough server can do that as well? And perhaps gain EV status even? Shouldn't be a problem then...right? Do not trust input from the user (unless obtained through a secure means). Does that mean, do not trust a server (which is user input after all) and his certificate and supplied chain of CA certificates? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Eddy Nigg wrote, On 2008-09-18 03:43: On 09/18/2008 07:22 AM, Nelson B Bolyard: In the case of AIA cert fetching, we have a cert for which we have no issuer cert. We cannot know that the the cert we are trying to validate was signed by a real trusted CA. But you trust the CA certificates the server send to you, do you? After verifying that the signatures are valid in the chain, all the way to a trusted root, then yes. If the signatures don't pass the test, then no. The crucial difference is that when using certs from the SSL server, we can construct the chain, and validate all its signatures, without doing fetches from URLs in the certs first. But when trying to complete a chain by fetching certs from URLs in AIA extensions, we cannot validate the signature in the cert from which the URL is taken until after we've gone and attempted to fetch certs from the URL in the unvalidated cert, a URL supplied by the (potential) attacker. Even if its issuer name matches that of a known and trusted CA, it may be a cert crafted by an attacker Really? Please enlighten me how...I would like to see a real example! Isn't this obvious? Think about this. Using certutil, I can construct a certificate that has an issuer name that exactly matches (every bit) the subject name of one of your CA's CA certs, but that has an AIA extension containing a URL that does not go to the server your real AIA's use, but goes to a completely different server. The cert I create will not have a signature that can be validated with your real CA cert, but as an attacker, I don't care because the damage will be done before the relying party discovers that my cert was not really issued by your CA. I can provide a more detailed description, and even a live example, if necessary, but really, by now this should be obvious. But in that case the server can send also such a specially crafted CA certificate which chains to a builtin root, right? Not unless it has the private key of the builtin root. It can create a cert that has an issuer name that matches a built-in root, but the signature will not validate. The security or vulnerability is all controlled by which operation is done first, the signature verification of the chain, or the fetching or external data (certs, CRLs, OCSP) based on the contents of those certs. There is no difference between relying on a server sending the missing chain or NSS fetching it. Again the obvious difference is that in once case, the relying party goes out and fetches from URLs in a cert of unknown origin, and in the other case, it does not. In the end it must in both case validate up to a known root. [snip] There is no higher risk that relying on the CA chain the server sends. In moth cases the parties might be interesting in spoofing Let me try to clarify the nature of the vulnerability. The concern is NOT that the relying party will be fooled into accepting a bogus cert as legitimate. The concern is that, before the relying party determines that the cert is bogus, it will have acted as a proxy for the attacker by fetching from an attacker-supplied URL. Being able to be tricked into acting as such a proxy is a vulnerability. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Kyle Hamilton wrote, On 2008-09-18 11:48: There's another, more pressing issue: If there are buffer overflows in ASN.1 parsing (there have been in at the least OpenSSL and Microsoft's), anyone who can provide a certificate that points to an AIA that ultimately wouldn't be trusted could provide malicious data that could compromise the issue. About 5-6 years ago, NISCC, an office of the UK government, made available to software developers an enormous set of test data, over 1 million certs, each crafted to detect buffer potential buffer overflows. The set was produced at the University of Oulu (IIRC) for NISCC. There were also test cases for PKCS#7 and numerous other common BER/DER message/file formats. There were SSL server certs and client auth certs, IIRC. A major part of the work done for NSS 3.9.0 in late 2003 was that we devised test programs and test scripts to test with all those files of test data. I devised an SSL server and SSL client that would serve up a different one of those test certs in each full handshake. We enhanced certutil and our PKCS7 and SMIME test tools to facilitate this testing. We found a lot of bugs, and fixed them all. We now run the NISCC tests periodically (nightly or weekly, IIRC) to ensure no regressions there. Consequently, since the release of NSS 3.9.0, our confidence level in the bullet proof nature of our ASN.1 decoder, and the higher level decoders that use it (such as PKCS7) is very high. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 10:29 PM, Nelson B Bolyard: After verifying that the signatures are valid in the chain, all the way to a trusted root, then yes. And what exactly prevents you from verifying the signatures of the received chain (by whatever means you constructed the chain) all the way to a trusted root? What does it matter if you received the sub-ordinate CA certificate from: 1.) The Server 2.) The AIA CA Issuer URL 3.) Previously stored in authorities 4.) UI input box from the user 5.) International Space Station If the signatures don't pass the test, then no. Exactly! The crucial difference is that when using certs from the SSL server, we can construct the chain, and validate all its signatures, YES! without doing fetches from URLs in the certs first. What does that matter? Seriously! Who cares? But when trying to complete a chain by fetching certs from URLs in AIA extensions, we cannot validate the signature in the cert from which the URL is taken until after we've gone and attempted to fetch certs from the URL in the unvalidated cert Of course...so discharge the received invalid obtained CA certificate and proceed with the error. a URL supplied by the (potential) attacker. I call that nonsense! If you believe what you are saying you can't rely on any server sending a certificate chain, because every server can be a (potential) attacker! Isn't this obvious? No Think about this. Using certutil, I can construct a certificate that has an issuer name that exactly matches (every bit) the subject name of one of your CA's CA certs, So? Does it match the signature as well? but that has an AIA extension containing a URL that does not go to the server your real AIA's use, but goes to a completely different server. Of course...but it doesn't matter, the signature never matches. The cert I create will not have a signature that can be validated with your real CA cert Right but as an attacker, I don't care because the damage will be done before the relying party discovers that my cert was not really issued by your CA. More nonsense! If the signature doesn't match you can't construct a valid chain up to a trusted root and you return an error. The same error you return today when the certificate can't be validated up to a trusted root. EXACTLY the same thing! Not unless it has the private key of the builtin root. It can create a cert that has an issuer name that matches a built-in root, but the signature will not validate. EXACTLY! You are saying it yourself! The security or vulnerability is all controlled by which operation is done first, the signature verification of the chain, or the fetching or external data (certs, CRLs, OCSP) based on the contents of those certs. Fist you try to construct a valid chain - being it with the certificates the server supplied, by the AIA extensions or by looking at the local auth store... Again the obvious difference is that in once case, the relying party goes out and fetches from URLs in a cert of unknown origin, and in the other case, it does not. That's wrong! Not the relying party is doing it, but the software is doing it! The software fetches those missing certificates, tries to build the chain and validate this chain. The software returns the either the error and continues the process (of validating the CRL, OCSP etc). The relying party is absolutely passive at this stage, there is nothing to do at this stage then wait for the site to appear. The concern is NOT that the relying party will be fooled into accepting a bogus cert as legitimate. The concern is that, before the relying party determines that the cert is bogus, it will have acted as a proxy for the attacker by fetching from an attacker-supplied URL. WHAT? You are fetching most likely a certificate...but even if it's something else, the software can perform its usual checks as it should do with anything which is supplied - including the CA chain from the server. Being able to be tricked into acting as such a proxy is a vulnerability. Nonono...this proxy-thing has nothing to do with it. Where is this proxy? Where is the vulnerability exactly? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Attack scenario is an information-leakage vulnerability. Client Alice connects to server Mary. Mary sends a certificate with an AIA, no chain. Mary happens to be a honeypot. Alice looks up AIA, makes connection to Mallory to retrieve the certificate. Mallory is looking for people who are looking at Mary. Mallory knows, beyond a shadow of a doubt, that Alice is looking at Mary. -Kyle H On Thu, Sep 18, 2008 at 1:20 PM, Eddy Nigg [EMAIL PROTECTED] wrote: On 09/18/2008 10:29 PM, Nelson B Bolyard: After verifying that the signatures are valid in the chain, all the way to a trusted root, then yes. And what exactly prevents you from verifying the signatures of the received chain (by whatever means you constructed the chain) all the way to a trusted root? What does it matter if you received the sub-ordinate CA certificate from: 1.) The Server 2.) The AIA CA Issuer URL 3.) Previously stored in authorities 4.) UI input box from the user 5.) International Space Station If the signatures don't pass the test, then no. Exactly! The crucial difference is that when using certs from the SSL server, we can construct the chain, and validate all its signatures, YES! without doing fetches from URLs in the certs first. What does that matter? Seriously! Who cares? But when trying to complete a chain by fetching certs from URLs in AIA extensions, we cannot validate the signature in the cert from which the URL is taken until after we've gone and attempted to fetch certs from the URL in the unvalidated cert Of course...so discharge the received invalid obtained CA certificate and proceed with the error. a URL supplied by the (potential) attacker. I call that nonsense! If you believe what you are saying you can't rely on any server sending a certificate chain, because every server can be a (potential) attacker! Isn't this obvious? No Think about this. Using certutil, I can construct a certificate that has an issuer name that exactly matches (every bit) the subject name of one of your CA's CA certs, So? Does it match the signature as well? but that has an AIA extension containing a URL that does not go to the server your real AIA's use, but goes to a completely different server. Of course...but it doesn't matter, the signature never matches. The cert I create will not have a signature that can be validated with your real CA cert Right but as an attacker, I don't care because the damage will be done before the relying party discovers that my cert was not really issued by your CA. More nonsense! If the signature doesn't match you can't construct a valid chain up to a trusted root and you return an error. The same error you return today when the certificate can't be validated up to a trusted root. EXACTLY the same thing! Not unless it has the private key of the builtin root. It can create a cert that has an issuer name that matches a built-in root, but the signature will not validate. EXACTLY! You are saying it yourself! The security or vulnerability is all controlled by which operation is done first, the signature verification of the chain, or the fetching or external data (certs, CRLs, OCSP) based on the contents of those certs. Fist you try to construct a valid chain - being it with the certificates the server supplied, by the AIA extensions or by looking at the local auth store... Again the obvious difference is that in once case, the relying party goes out and fetches from URLs in a cert of unknown origin, and in the other case, it does not. That's wrong! Not the relying party is doing it, but the software is doing it! The software fetches those missing certificates, tries to build the chain and validate this chain. The software returns the either the error and continues the process (of validating the CRL, OCSP etc). The relying party is absolutely passive at this stage, there is nothing to do at this stage then wait for the site to appear. The concern is NOT that the relying party will be fooled into accepting a bogus cert as legitimate. The concern is that, before the relying party determines that the cert is bogus, it will have acted as a proxy for the attacker by fetching from an attacker-supplied URL. WHAT? You are fetching most likely a certificate...but even if it's something else, the software can perform its usual checks as it should do with anything which is supplied - including the CA chain from the server. Being able to be tricked into acting as such a proxy is a vulnerability. Nonono...this proxy-thing has nothing to do with it. Where is this proxy? Where is the vulnerability exactly? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 11:50 PM, Kyle Hamilton: Client Alice connects to server Mary. Mary sends a certificate with an AIA, no chain. Cute :-) Mary happens to be a honeypot. Alice looks up AIA, makes connection to Mallory to retrieve the certificate. Mallory is looking for people who are looking at Mary. Mallory knows, beyond a shadow of a doubt, that Alice is looking at Mary. Since Mary and Mallory are under the same control it doesn't matter. Whoever controls Mary knows that Alice is looking at Mary anyway...Even in the scenario of Mary being compromised doesn't matter anymore... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Mary and Mallory may not be the same control. Mary has a site with a cert with AIA. Mallory can take control over that location for the AIA, without Mary being able to do a thing to stop it. -Kyle H On Thu, Sep 18, 2008 at 2:02 PM, Eddy Nigg [EMAIL PROTECTED] wrote: On 09/18/2008 11:50 PM, Kyle Hamilton: Client Alice connects to server Mary. Mary sends a certificate with an AIA, no chain. Cute :-) Mary happens to be a honeypot. Alice looks up AIA, makes connection to Mallory to retrieve the certificate. Mallory is looking for people who are looking at Mary. Mallory knows, beyond a shadow of a doubt, that Alice is looking at Mary. Since Mary and Mallory are under the same control it doesn't matter. Whoever controls Mary knows that Alice is looking at Mary anyway...Even in the scenario of Mary being compromised doesn't matter anymore... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/17/2008 09:01 PM, Nelson Bolyard: I wouldn't call it a known issue with Mozilla based products. It's a requirement of the SSL/TLS specifications. That's correct. It's an issue with servers that are not configured to conform to those specifications. Right, but as I mentioned elsewhere, this educational exercise costs some of the CAs using chained CA certificates (as recommended by Mozilla) to loose customers (just watch for some promotional adds like issued directly from CA root and such stuff...some users just turn away and use a different CA instead because it doesn't work and shows not trusted) SSL Server Certificate Email Signer Certificate Email Recipient Certificate SSL Certificate Authority Status Responder Certificate That's what PSM shows for roots, Eddy. I imagine you're expecting it to say something like Email Certificate Authority and Object Signing Certificate Authority. I agree it should. But it's a PSM UI issue, I believe. I expect to see SSL Certificate Authority as then only purpose, the same which I see for the StartCom roots. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Yes, that's the right solution. It was, indeed. Testing it with other browser worked flawlessly, thus the misunderstanding. Thank you very much, -- Fabio ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Perhaps, Eddy, StartCom's roots were only approved for SSL Certificate Authority. Did you not include a request for Email or Software Development bits? -Kyle H On Wed, Sep 17, 2008 at 11:11 AM, Eddy Nigg [EMAIL PROTECTED] wrote: On 09/17/2008 09:01 PM, Nelson Bolyard: I wouldn't call it a known issue with Mozilla based products. It's a requirement of the SSL/TLS specifications. That's correct. It's an issue with servers that are not configured to conform to those specifications. Right, but as I mentioned elsewhere, this educational exercise costs some of the CAs using chained CA certificates (as recommended by Mozilla) to loose customers (just watch for some promotional adds like issued directly from CA root and such stuff...some users just turn away and use a different CA instead because it doesn't work and shows not trusted) SSL Server Certificate Email Signer Certificate Email Recipient Certificate SSL Certificate Authority Status Responder Certificate That's what PSM shows for roots, Eddy. I imagine you're expecting it to say something like Email Certificate Authority and Object Signing Certificate Authority. I agree it should. But it's a PSM UI issue, I believe. I expect to see SSL Certificate Authority as then only purpose, the same which I see for the StartCom roots. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On Wed, Sep 17, 2008 at 4:52 PM, Eddy Nigg [EMAIL PROTECTED] wrote: I've been banging my head against a wall here because of this FUD and about misinformation which is absolutely incorrect. Sad, because there are many FF users running into it. And it doesn't help to ignore the fact that web site admins don't install their certs correctly - it works in IE and that's it. It would be nice to contribute a patch for Apache/mod_ssl to validate its own certificate chain at startup. Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/18/2008 03:06 AM, Wan-Teh Chang: It would be nice to contribute a patch for Apache/mod_ssl to validate its own certificate chain at startup. Perhaps then you should also offer a patch for IIS ;-) Ironic as it may sound, but as a matter of fact, Windows servers serve more secured web sites than Apache (AFAIK). But all the finger-pointing doesn't help, FF hasn't got its act together on this very issue -refusal for the purpose of being on the right side... -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Eddy Nigg wrote, On 2008-09-17 16:52: There is absolutely no security issue at all with following the AIA CA Issuer extension, otherwise FF could not use the same extension to find the OCSP responder URL either. Nevertheless NSS does exactly that...uses the OCSP URL listed in the AIA extension. There's one very important difference between AIA cert fetching and AIA OCSP fetching that makes one a potential security risk and the other not. OCSP fetching is done only AFTER the entire chain has been validated to the extent that every cert in the chain has a valid signature, the chain goes up to a trusted root, and no certs are expired. At the point where the only question remaining is that of revocation, OCSP fetching is done. At that time, we have confidence that the URL in the AIA extension was issued by a CA that we trust by direct or inherited (transitive) trust. In the case of AIA cert fetching, we have a cert for which we have no issuer cert. We cannot know that the the cert we are trying to validate was signed by a real trusted CA. Even if its issuer name matches that of a known and trusted CA, it may be a cert crafted by an attacker, for the specific purpose of getting the program that is attempting to validate the cert to do a fetch from a URL that is entirely under the control of the attacker. Now, it has been pointed out that, for BROWSERS, this is a very tiny incremental threat. Browsers ROUTINELY go and fetch URLs that they received in a web page from some server, without knowing anything about where that URL is going. You don't need a cert's AIA extension to get a browser to go fetch some URL of your choosing. You just need an ordinary http web page. Attackers won't go to the bother of using a phony server cert's AIA extension when they can use the much easier and more effective ordinary http page. So, the risk to a browser of doing AIA cert fetching is relatively small. But that logic applies only to browsers. Very few other applications routinely go out and fetch URLs that come from outsiders. Most go to servers that have been explicitly configured into the application by the user or admin. Examples of this include email clients that are configured to know about certain specific POP, IMAP and SMTP servers, and never go off and visit other mail servers due to the content of something they receive. LDAPS clients are like that, too. For those other types of applications, the incremental risk is much higher (when seen as a percentage of total risk). The type of application that is most likely to be the target of an attack using phony certs with attacker-chosen AIA extensions is a server that requests client authentication. The server may be behind a firewall, and still be accessible by systems outside the firewall. Other corporate systems behind the firewall are accessible to that server but are not directly accessible to other systems outside of the firewall. The server in that position becomes an attack target because the attacker can get that server to act as the attacker's proxy, and probe other servers located behind that firewall. The attacker does that by connecting to the server, and when the server requests client authentication, the client sends a bogus certificate constructed to contain an AIA cert extension that contains a URL that might go to another server also behind the firewall. When the server fetches that URL, it is acting as a proxy for the attacker. It is probably best for all applications other than browsers to not honor AIA cert extensions for the purpose of fetching issuer certs. Servers can be even more efficient by disabling the automatic fetching of OCSP and CRLs based on the extensions in an incoming cert, and instead periodically preloading the CRLs from any and all CAs that they trust to issue client certs. I've been banging my head against a wall here because of this FUD and about misinformation which is absolutely incorrect. Are you sure? It would be relatively trivial to construct an attack client like the one I described above using NSS. Sad, because there are many FF users running into it. And it doesn't help to ignore the fact that web site admins don't install their certs correctly - it works in IE and that's it. I think it would be interesting to survey the web's misconfigured servers to see which CAs' certs are most commonly left uninstalled by admins. I suspect that we would find that some fairly large CAs are disproportionately low in those standings, that is, some large CAs' certs are rarely left out. It's not difficult to imagine why that might be. Similar tweaks and corrections were made for FF if major sites didn't play nicely with standards in order to make FF usable. With the new error reporting for invalid certificates, this issue should have been solved beforehand. :-( Firefox 3 does something to compensate for misconfigured servers that is without risk. When it validates a server cert chain
RE: About the Cybertrust Educational CA certificate
This might be helpful for you: http://www.mozilla.org/projects/security/certs/ I'm writing to kindly ask you to consider to insert the Cybertrust Educational certificate in the list of the trusted certificate authorities. ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
Fabio Spelta wrote, On 2008-09-16 07:12: I'm writing to kindly ask you to consider to insert the Cybertrust Educational certificate in the list of the trusted certificate authorities. Fabio, Mozilla doesn't add any CA certificates to Firefox unless and until the CA itself requests the addition of its own certificates. There is a procedure by which the CA makes a formal request and supplies a lot of information that Mozilla verifies and evaluates before deciding whether or not to include the CA. Only the CA (and its official representatives) may make this request. Requests are not accepted from other parties, such as subscribers who have gotten certificates from the CA. More information about the procedures for making application and supplying the necessary information may be found on the web pages listed below, and the pages to which they link. https://wiki.mozilla.org/CA:Overview http://www.mozilla.org/projects/security/certs/ ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/16/2008 05:12 PM, Fabio Spelta: Hello everybody and thanks for reading. Many educational institutions, among which there are various Italian universities, are using X.509 certificates issued by the Cybertrust Educational CA for their websites. In Italy such certificates are obtained mainly through the GARR Italian Academic Research Network, www.garr.it. The Cybertrust Educational certificate can be found at http://secure.globalsign.net/cacert/sureserverEDU.pem. That's in turn signed by the GTE CyberTrust Global Root certificate. Please refer to http://secure.globalsign.net/cacert/ct_root.pem. While certificates signed by that authority are trusted and seamlessly accepted by the default installations of Internet Explorer (since version 6) and now also by Google Chrome, Mozilla Firefox still doesn't trust them (not even the latest 3.1 alpha2). I'm writing to kindly ask you to consider to insert the Cybertrust Educational certificate in the list of the trusted certificate authorities. That would be very helpful to all the organizations which use such certificates for they websites, expecially in view of the growing user base of Firefox in Italy. Should you need further details, don' t hesitate to get in touch with me. The CA certificate you referred above is signed by a CA root which is included in NSS. Therefore the error you are seeing is a server side installation failure and the server doesn't send the complete chain. This has been a known issue with Mozilla based products and servers are required to send the chain up to the root. Please contact the administrator of the site and ask to correct this issue. By having a look at this root I realized that the purposes of the certificate show in in Firefox for: SSL Server Certificate Email Signer Certificate Email Recipient Certificate SSL Certificate Authority Status Responder Certificate This is a builtin root! Nelson...can you check out those usages? -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On Tue, Sep 16, 2008 at 11:46 AM, Eddy Nigg [EMAIL PROTECTED] wrote: By having a look at [GTE CyberTrust Global Root] I realized that the purposes of the certificate show in in Firefox for: SSL Server Certificate Email Signer Certificate Email Recipient Certificate SSL Certificate Authority Status Responder Certificate This is a builtin root! Nelson...can you check out those usages? I believe this is a variant of this PSM bug: https://bugzilla.mozilla.org/show_bug.cgi?id=289988 Wan-Teh ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
Re: About the Cybertrust Educational CA certificate
On 09/17/2008 12:03 AM, Wan-Teh Chang: On Tue, Sep 16, 2008 at 11:46 AM, Eddy Nigg[EMAIL PROTECTED] wrote: By having a look at [GTE CyberTrust Global Root] I realized that the purposes of the certificate show in in Firefox for: SSL Server Certificate Email Signer Certificate Email Recipient Certificate SSL Certificate Authority Status Responder Certificate This is a builtin root! Nelson...can you check out those usages? I believe this is a variant of this PSM bug: https://bugzilla.mozilla.org/show_bug.cgi?id=289988 Not sure. The root works as expected, but some of the key usages seem to be not appropriate for a CA certificate, at least NSS shouldn't know about them. -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org ___ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
