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 > [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
