How does kinto know which certificates you yet need to download? On Fri, Mar 8, 2019, 3:29 PM J.C. Jones <j...@mozilla.com> wrote:
> # tl;dr # > > At the end of February I enabled Intermediate CA Preloading for all > desktop Nightly users to begin gathering telemetry. This means all > intermediate CAs disclosed to Mozilla will be pre-loaded into > profiles, so the common secure website misconfiguration of forgetting > this certificate won’t stop Firefox users. It has other benefits, too, > but for those read on. > > > > > In Bug 1404934 we've added support to download the Intermediate > Certificate Authorities that have been disclosed to the Mozilla CA > Root Program from Kinto in the background during normal Firefox > operation. I turned this on for all desktop nightly users a bit more > than a week ago, prompting Nightly users to download 100 intermediate > CA certs into their profile each day. I do not have a timeline at > present for this to ride the trains. > > > # What it does # > > Websites using encryption should provide two digital PKI certificates > [0] when connecting to clients: One for the website itself, and one > for the intermediate CA that produced the website's digital > certificate. Sometimes, websites are set up incorrectly. > > > When other browsers encounter this case, they use AIA-chasing, a > mechanism where the user's browser then, in the background, connects > to the CA and downloads the certificate during the TLS handshake. > > ## Performance benefit ## > > Preloading the intermediate CA data avoids the just-in-time network > fetch, which delays the connection. > > ## Privacy ## > > Avoiding the network fetch is also a privacy improvement, as it > doesn't disclose your browsing pattern to the certificate authority > that issued the misconfigured website's certificate. > > It's also helpful because it's possible to "fingerprint" a user by a > website carefully analyzing what other websites load or do not load > due to which intermediate CAs have been "seen" by a user [1]. > Preloading ensures that all users have "seen" all the same > intermediate CAs. > > ## Protection ## > > The Mozilla CA program requires all members to disclose unconstrained > intermediate CAs before using them, as a safety measure. However, > there is not currently a way to technically enforce that. Intermediate > Preloading could eventually be used to perform that enforcement, by > only trusting intermediate CAs which were disclosed already. This > protects against a scenario where a compromised CA is coerced into > producing an undisclosed secret intermediate CA, which is then used to > attack people on the Internet. > > > ## Future usefulness ## > > The experimental CRLite concept [2] (aiming to replace OCSP) requires > a mapping of Intermediate CAs to an “enrollment status” flag. Since we > need to enumerate the Intermediate CAs for that future functionality, > actually preloading their data is a rational extension. > > > # How it works # > > Intermediate Preloading fetches ~100 intermediate certificate > authorities' certificates once a day during the Kinto main update [3], > and loads them into your profile, as if you had visited a site that > used that intermediate. At 100 per day, summing to between 300-500 kB, > it will take approximately three weeks for a Firefox profile to > preload all intermediates [4]. We will likely increase the rate after > the initial experiments. > > The certificate data is loaded into the NSS Certificate Database, as > is done for normal web browsing. In the future, we will use the faster > Rust "rkv" database, in Bug 1530545. > > Currently preloading is only enabled for desktop users on Nightly. We > will want to (A) restrict the download to be only over WiFi and maybe > plugged in, and (B) switch to the faster database before enabling on > mobile. (Bug 1520297) > > > # What we expect # > > Intermediate Preloading should reduce the number of > SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which > is our most common secure connection error. It will also remove the > tracking vector (above, Privacy), and give us a path to enforce CA > disclosure. > > > # Things to keep in mind # > > Right now, these certificates go into the NSS Certificate Database, > and are visible in / totally overcrowding the Certificate Manager (Go > To about:preferences#privacy , View Certificates.., Authorities tab). > That’ll change when this moves to rkv. > > This is potentially a bunch of data, approximately 3 megabytes of > binary, but it’s data that changes only very slowly. > > > # Telemetry # > > Telemetry for Intermediate Preloading is available in the histograms: > > "INTERMEDIATE_PRELOADING_ERRORS" > "INTERMEDIATE_PRELOADING_UPDATE_TIME_MS" > > and the scalars: > > "security.intermediate_preloading_num_pending" > "security.intermediate_preloading_num_preloaded" > > ... which show how many of the ~2300 intermediates have been loaded, > per profile. > > # More info # > > Well, maybe. ;) There's a wiki page about this which can be used to > help explain the same things as are in this post. Otherwise, send your > questions to me, Mark Goodwin, or Dana Keeler. > > https://wiki.mozilla.org/Security/CryptoEngineering/Intermediate_Preloading > > :: Footnotes:: > > [0] The WebPKI generally has one root CA certificate, one intermediate > CA certificate, and then one end-entity (specific website) > certificate. Sometimes there can be more than one intermediate CA > certificate, potentially much more than one. Sometimes that’s because > of cross-certification CA certificates, sometimes it’s technical debt > someone hasn’t cleaned up yet. See https://signed.bad.horse for an > egregious (and untrusted) example. > ( > https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=188088012 > ) > > [1] > https://shiftordie.de/blog/2017/02/21/fingerprinting-firefox-users-with-cached-intermediate-ca-certificates-fiprinca/ > > [2] https://wiki.mozilla.org/CA/Revocation_Checking_in_Firefox#CRLite > > [3] 100/day is configurable by a pref, it is likely to change. See > > https://searchfox.org/mozilla-central/source/security/manager/ssl/security-prefs.js#166 > . > > [4] The data is loaded from Kinto here: > > https://settings.prod.mozaws.net/v1/buckets/security-state/collections/intermediates/records > . This data is exported from the Common CA Database maintained by the > Mozilla root program. > _______________________________________________ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
