# 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
