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