Awesome, thanks Ryan. This cements my opinion on their fate. These are not just old and crufty, they are actively harmful. They can't be removed soon enough.
I'm not fundamentally opposed to the notion of having some sort of site control of client authentication in general, and maybe even TLS client authentication specifically, but this feature[7] cannot continue to exist as part of the web platform. [7] By which I mean the certificate download and install part, keygen seems to be more on the cruft side based on what I've seen. On Fri, Sep 11, 2015 at 9:42 PM, Ryan Sleevi <rsle...@chromium.org> wrote: > [No idea if these will show up on the lists since I'm not subscribed] > > On Fri, Sep 11, 2015 at 9:30 PM, Martin Thomson <m...@mozilla.com> wrote: > >> I have some questions, to which I was unable to find answers for in >> the (numerous and long) threads on this subject. >> >> 1. When we download and install a client cert, what checking do we do? >> Do we insist upon it meeting the same algorithm requirements we have >> for servers with respect to use of things like short RSA keys and weak >> hashes (MD5/SHA-1)? >> > > No. These are client certs (generally for internal systems), for which > there are no imposed policies on (CA/B Forum or otherwise). > > The only checking re: algorithms are those which NSS itself has not > disabled globally (MD5, minimum keysizes, etc), but only if they present as > parse errors - not as signature validation errors. > > If it comes in as application/x-x509-user-cert (vs, say, > application/x-x509-ca-cert, which can be used to quickly add a root > certificate), > http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#849 > is what first parses/interprets the byte stream. > > The validation requires: > 1) That the user has an existing private key (from any source, <keygen> or > otherwise - so you can use this as an existence proof of whether or not a > user has a matching key). That's line 886 > 2) That it's syntactically valid for one of the forms Mozilla accepts - or > one of the ones it can munge into something it accepts (a liberal decoder) > - that's line 875 > > If so, it'll toast the user (via > http://mxr.mozilla.org/mozilla-central/source/security/manager/ssl/nsNSSCertificateDB.cpp#810 > ) to let them know a certificate was installed (after the fact) > > It'll then parse the rest of the bundle, and if they are certificates that > chain to a CA the user trusts, they'll also be imported (that's line 924) > > > This behaviour, however, is different than Chrome's in several ways > (primarily related to the parsing of the bundle and handling the additional > certificates). Chrome also explored a number of strict checks (is it a > valid client certificate from a known CA), but those had to be relaxed for > compatability with Firefox and the existing use cases. > > We also explored not committing the generated key to the persistent > keystore until it'd been "confirmed" (via installation of a certificate), > except that broke nearly every <keygen> use case outside of WebID. In > particular, if you closed Chrome, we'd destroy the key - so that didn't > work for situations where you'd do a <keygen> enrollment, close Chrome, a > day later getting an email with a link from your CA w/ the certificate. So > you'd need some form of semi-persistent, origin-scoped storage if you went > that way. > > >> >> 2. What is the potential scope of use for a client certificate? >> Global? The origin that provided it? Something in-between like >> domain or domain plus subdomains? >> > > Global - all domains, all applications. A common pattern, as seen on the > CA/Browser Forum list, is to use this method to configure S/MIME > certificates for Thunderbird, which uses the same NSS database. > > Any other domain could do an existence test to see if a user has such a > certificate, by using <keygen> to create a key (which may or may not > involve prompting; various criteria there), using > application/x-x509-user-cert to deliver the user's cert that matches a > chosen ("attacker") issuer string, and then doing a TLS handshake that > requests a client certificate with the ca_names set to the attacker's > unique fingerprint. > > The timing difference between the handshakes - whether or not the user has > a matching certificate and private key - can reveal to any domain who knows > the ca_names whether or not the user matches, at the cost of potentially > prompting the user (if they do match). > _______________________________________________ > dev-security mailing list > dev-secur...@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
