Eddy Nigg wrote, On 2009-03-22 12:51: > On 03/22/2009 07:25 PM, Anders Rundgren:
>> Solution: One solution would be to define signature support as a >> browser component. Especially the component you've invented and have been trying to get Mozilla to adopt for some time, right? Anders? > Sounds interesting, lets hear more... Let's see a standard from W3C (or browser standards group de jour) first. >> ------------------------------------------------------------------------ >> FF issue: It seems that the AIA ca issuer extension is not supported. >> This complicates server-setups [or] alternatively requires the end-user >> to install [intermediate] CA certificates. Oh, those poor server admins! It's such a taxing burden on them that they must install intermediate CA certs! You'd think they'd rather DIE or sell their children into slavery than have to do that, the way it is complained about around here. Sheesh. > Even though I agree and have urged Nelson and others to implement AIA > fetching of CA certificates for all products It's in NSS 3.12.2. Has been for some time. FF may enable it whenever Mozilla wishes. > (specially TB is a real pain in this respect), Why is it more painful for TB? Is it because a higher percentage of mail server admins fail to correctly configure their servers with the required certs? > correctly configured servers don't need these to be present in the > browser. Bingo! > I think the only thing preventing AIA issuer certificate fetching is a > political one (privacy: the CA might know to which site you are browsing > as if the CA couldn't know that anyway through OCSP and CRL requests). No, that's not the issue at all. (Well, maybe it is for some people, but I agree that the legitimate CAs are going to find out through revocation checks, as you've suggested.) The concern is that, with AIA cert fetches, you must rely on information in the cert before you've verified that the cert came from a real CA and is not a forgery. This is quite different from the normal cert validation. In "normal" cert validation, you first verify that the entire chain is valid and chains up to a trusted root, which you do without any visits to the net, or reliance on any URLs in the certs. THEN, AFTER you've validated that the certs in the chain were issued by issuers whose signatures verify (from the top down), you check revocation on the certs, from the top down, checking revocation on the penultimate level (second highest, issued by the trusted root) CA first, then on each successive level until you at last check the revocation on the EE (server) cert. So, you're not relying on any URLs in any cert whose authenticity hasn't already been verified. (Without the double-negative, that's: You're only relying on URLs in certs whose authenticity has already been verified.) But with AIA, you get a cert, and you don't know if it's from a legit issuer or is a forgery or an outright bogus cert, but you're going to take a URL from it and go access that URL, as if it was trusted. An attacker can use this to vector all sorts of attacks. Let me give an example. Let's say that there is a server behind a corporate firewall that only honors requests coming from clients that are also behind that firewall on the "intranet". Further, the firewall prevents requests coming from outside to reach the servers behind the firewall. An attacker outside the firewall cannot directly send requests to that intranet server. How could he get a client behind the firewall to do so? He could put the URL of that intranet server into the AIA extension in a bogus cert, and then serve that cert to the client from a bogus MITM attack server. The client gets the bogus cert and, before it has validated the cert, goes and accesses the URL in the cert. Even if the client ultimately determines that the cert it got was bogus, it has already done the harmful deed and fetched the attacker's URL. Further, the server now probably has a record that the harmful request came from an inside user, and that user may get fired or disciplined. So it's a vulnerability to intranet servers and users alike. Yes, there are other ways an attacker could do this, such as an IMG tag in an ordinary http page. But https and PKI are supposed to prevent (or at least mitigate) such attacks, not be a vector for them, and they do that, except in the AIA case. That is the concern held by some browser people, as I understand it. It's purely a browser decision. NSS offers the capability, giving the application control of whether or not to use it. If FF wants to use it, FF must write some code to tell NSS to do so. (NSS generally does not enable new features by default, because of backwards compatibility issues.) -- dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
