122
edits
Security/CryptoEngineering/Intermediate Preloading: Difference between revisions
Jump to navigation
Jump to search
Security/CryptoEngineering/Intermediate Preloading (view source)
Revision as of 22:10, 4 March 2019
, 4 March 2019add another footnote
(→Expected Results: typo) |
(add another footnote) |
||
| Line 7: | Line 7: | ||
== 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. | ||
| Line 27: | Line 27: | ||
== How it works == | == How it works == | ||
Intermediate Preloading fetches ~100 intermediate certificate authorities' certificates once a day during the Kinto main update [ | Intermediate Preloading fetches ~100 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. At 100 per day, summing to between 300-500 kB, it will take approximately three weeks for a Firefox profile to preload all intermediates [3]. 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 [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]. | ||
| Line 46: | Line 46: | ||
* "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) | |||
[ | [2] 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 . | ||
[ | [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://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. | ||