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 [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
