Security/CryptoEngineering/Intermediate Preloading: Difference between revisions

From MozillaWiki
Jump to navigation Jump to search
(first draft)
 
(Reference it being online for all users.)
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
= Intermediate CA Preloading =
= Intermediate CA Preloading =
In Firefox users are benefiting from a new feature called Intermediate CA Preloading which reduces the number of secure connection errors that users run into when web servers forget to properly configure their TLS response.


In [https://bugzilla.mozilla.org/show_bug.cgi?id=1404934 Bug 1404934] we've added support to download the Intermediate Certificate Authorities that have been disclosed to the [[CA|Mozilla CA Root Program]] from [https://www.kinto-storage.org/ Kinto] in the background during normal Firefox operation.  
In [https://bugzilla.mozilla.org/show_bug.cgi?id=1404934 Bug 1404934] we've added support to download the Intermediate Certificate Authorities that have been disclosed to the [[CA|Mozilla CA Root Program]] from [https://www.kinto-storage.org/ Kinto] in the background during normal Firefox operation.  


This is currently only enabled for Nightly users on desktop platforms. (March 2019)
This mechanism shipped to release on desktop platforms in Firefox 75.
 
Follow-on work is being tracked by [https://bugzilla.mozilla.org/show_bug.cgi?id=1535662 Bug 1535662].


== What it does ==
== What it does ==


Websites using encryption should provide two digital PKI certificates 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.
Websites using encryption should provide two digital PKI certificates [1] 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 a mechanism where the user's browser then, in the background, connects to the CA and downloads the certificate just-in-time.
When other browsers encounter this case, they use a mechanism where the user's browser then, in the background, connects to the CA and downloads the certificate just-in-time, which delays the connection and reveals the website the user is connecting to.


=== Performance ===
=== Performance ===
Line 27: Line 31:
== How it works ==
== How it works ==


Intermediate Preloading fetches ~100 intermediate certificate authorities' certificates once a day during the Kinto main update [1], 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 [2]. We will likely increase the rate after the initial experiments.
Intermediate Preloading fetches all new or updated intermediate certificate authorities' certificates once a day during the Kinto main update [2], and loads them into your profile, as if you had visited a site that used that intermediate [3].


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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1530545 Bug 1530545].
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 [https://bugzilla.mozilla.org/show_bug.cgi?id=1530545 Bug 1530545].


Currently preloading is only enabled for desktop users on Nightly. We will want to restrict the download to be only over WiFi before enabling on mobile.  
Currently preloading is only enabled for desktop users. We will want to restrict the download to be only over WiFi before enabling on mobile.  


== Expected Results ==
== Expected Results ==


Intermediate Preloading should reduce the number of SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which is our most common error.  
Intermediate Preloading reduces the number of SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which is our most common error.  


Telemetry for Intermediate Preloading is available in the histograms:
Telemetry for Intermediate Preloading is available in the histograms:
Line 46: Line 50:
* "security.intermediate_preloading_num_preloaded"
* "security.intermediate_preloading_num_preloaded"


===== Footnotes =====
[1] 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. (https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=188088012)


[1] 100/day is configurable by a pref, is is likely to change. See https://searchfox.org/mozilla-central/source/security/manager/ssl/security-prefs.js#166 .
[2] It's 5000/day is configurable by a pref (security.remote_settings.intermediates.downloads_per_poll). See https://bugzilla.mozilla.org/show_bug.cgi?id=1667930 for the update to 5000.


[2] The data is loaded from Kinto here:
[3] 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 [https://ccadb.org/ Common CA Database] maintained by the Mozilla root program.
https://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/intermediates/records . This data is exported from the [https://ccadb.org/ Common CA Database] maintained by the Mozilla root program. The [https://github.com/mozilla/moz_crlite_query/ moz-crlite-query] Python tool downloads the Intermediate CA data and can be used as a quick reference.

Latest revision as of 03:54, 11 November 2020

Intermediate CA Preloading

In Firefox users are benefiting from a new feature called Intermediate CA Preloading which reduces the number of secure connection errors that users run into when web servers forget to properly configure their TLS response.

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.

This mechanism shipped to release on desktop platforms in Firefox 75.

Follow-on work is being tracked by Bug 1535662.

What it does

Websites using encryption should provide two digital PKI certificates [1] 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 a mechanism where the user's browser then, in the background, connects to the CA and downloads the certificate just-in-time, which delays the connection and reveals the website the user is connecting to.

Performance

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. Preloading ensures that all users have "seen" all the same intermediate CAs.

Protection

The Mozilla CA program requires all members to disclose intermediate CAs before using them, as a safety measure. However, there is not currently a way to technically enforce that. Intermediate Preloading can eventually 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 a secret intermediate CA, which is then used to attack people on the Internet.

How it works

Intermediate Preloading fetches all new or updated intermediate certificate authorities' certificates once a day during the Kinto main update [2], and loads them into your profile, as if you had visited a site that used that intermediate [3].

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. We will want to restrict the download to be only over WiFi before enabling on mobile.

Expected Results

Intermediate Preloading reduces the number of SEC_ERROR_UNKNOWN_ISSUER errors seen by Firefox users over time, which is our most common error.

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"
Footnotes

[1] 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. (https://tls-observatory.services.mozilla.com/static/certsplainer.html?id=188088012)

[2] It's 5000/day is configurable by a pref (security.remote_settings.intermediates.downloads_per_poll). See https://bugzilla.mozilla.org/show_bug.cgi?id=1667930 for the update to 5000.

[3] The data is loaded from Kinto here: https://firefox.settings.services.mozilla.com/v1/buckets/security-state/collections/intermediates/records . This data is exported from the Common CA Database maintained by the Mozilla root program. The moz-crlite-query Python tool downloads the Intermediate CA data and can be used as a quick reference.