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 and finds that it is valid, Firefox remembers each of the certs in the chain. Thereafter, if it visits a misconfigured server, it may be able to fill in the missing cert from its store of previously received and validated CA certs. Taking certs from its own store is safe because it has previously validated those cert. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
