Eddy Nigg wrote, On 2008-07-23 14:30: > Nelson B Bolyard: >> Note that, when it sends the http get request to fetch the cert, it has >> not yet validated the cert from which it got the http URL, so it doesn't >> know if that URL is legitimate or from some hacker. It blindly fetches >> whatever the server at that URL sends it. Quite a few people view this >> as a security vulnerability and/or as a privacy vulnerability. That may >> well be a reason that FF3 doesn't use it. > > I don't think so, because if the CA certs it fetches doesn't chain up to > a trusted root and the EE certificate is in effect issued by the fetched > chain (there can be quite a few CA certs in a chain), the chain can't be > built and the EE cert remains effectively issued by an unknown root. > > Their might be an issue concerning privacy, however CAs are usually > bound to some privacy policy (and audited accordingly), so the privacy > issue is here somewhat under control.
Only if the server cert is from a CA that follows a reasonable CP/CPS. The case of concern is the server with a self-signed cert, or cert from an unknown CA, that has an AIA extension that points to a tracking host of some sort. The chain won't validate (the first time, without a "security exception"), but the fact that the user attempted to visit it has been recorded by the tracking host, whether the handshake to the original server succeeds or fails (when AIA cert fetching is used). And if the user creates a "security exception" for it, then each subsequent visit may also cause tracking. >> It's there in 3.12, and has been for quite a while. It gets tested >> continuously in NSS QA tests. > > What hinders its implementation? I'd say it's the staffing level for PSM. > This issue comes up every while. FF3 implemented the caching of > intermediate CA certificates once it gets them, which is a great step > forward, fixing this issue would be really cherry on top :-) I believe that, within the Mozilla developer community, there is a widely held misconception that NSS=PSM and the NSS team is the PSM team. But that's really not correct. Most of the NSS developers are paid to work on NSS but not on PSM. PSM could use more love, I think. > This and the fetching of CRLs (in case there is no OCSP responder or > OCSP validation is disabled). That feature is not yet present in NSS 3.12. It's a feature enhancement, and right now all resources are working on bugs, which generally take priority over enhancements. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
