1248557 - Investigate support of OneCRL in Thunderbird

Status: RESOLVED WORKSFORME

(Thunderbird :: Security, defect)

Description

[Jorg K (CEST = GMT+2)]

M-C implemented OneCRL in bug 1024809. In bug 1227956 further changes were made and in bug 1247662 TB had to add preferences to get tests going again.

One outcome from bug 1247662 is that we need to look at OneCRL in TB as per bug 1247662 comment #9.

We should see whether it actually works in TB and define the mentioned preference security.onecrl.maximum_staleness_in_seconds.

Also see:
https://dxr.mozilla.org/comm-central/source/mozilla/browser/app/profile/firefox.js#1430

Comment 1

[Jorg K (CEST = GMT+2)]

Hi Mark, thank you for your offer to help with testing whether OneCRL works in TB. How would be go about that? Frankly, I know close to nothing about security in TB, I'm the guy who worries about the mail composition window, occasionally also hacking on the M-C editor. So any help would be greatly appreciated.

Over in the other bug you said (quote):
Also, if you have security.onecrl.maximum_staleness_in_seconds set to a non-zero value (I'm not sure if this is set in TB), you might be bypassing revocation checks that you otherwise should be performing.

We don't have this set at all, of course we can add it. But looking at firefox.js, it's actually set to a "very" non-zero of 108000:
pref("security.onecrl.maximum_staleness_in_seconds", 108000);

So please let me know what the next steps could be. One such step could be to add the preference (which value?) and then compile a version on try for you to do testing with. I'd need to know which platform you prefer.

Thanking you in advance.

Comment 2

[aleth [:aleth]]

Friendly needinfo ping ;)

Comment 3

[rsx11m]

My understanding of how it's used in http://mxr.mozilla.org/comm-central/source/mozilla/security/manager/ssl/tests/unit/test_ev_certs.js#219 is that setting it to zero will /always/ perform a revocation check with OneCRL whereas 108000 will only perform it with the next request at least 30 hours after the last update of the revocation list. So, that looks basically like a performance trade-off to me.

Comment 4

[rsx11m]

(In reply to Kent James (:rkent)) 
> tracking-thunderbird_esr45: --- → ?

Bug 1259815 comm-central changeset 16b7ef1fb002 explicitly disables services.kinto.update_enabled for release builds, so this may not affect releases from comm-esr45 at all.

Comment 5

[rsx11m]

(In reply to Jorg K (GMT+2) from comment #1)
> pref("security.onecrl.maximum_staleness_in_seconds", 108000);

FWIW, we have set this preference with that suggested value for SeaMonkey in bug 1259947 now, it nevertheless would be good to know what the actual dependencies among those prefs are.

Here the comment added with bug 1016555 in firefox.js:

>+// OneCRL freshness checking depends on this value, so if you change it,
>+// please also update security.onecrl.maximum_staleness_in_seconds.
> pref("extensions.blocklist.interval", 86400);

So, somehow extensions.blocklist.interval and security.onecrl.maximum_staleness_in_seconds are related to each other as far as the timing is concerned (why the factor of 1.25x? ... no clue).

Comment 6

[aleth [:aleth]]

Mathieu, maybe you could advise on comment 1 (how to check things are set up correctly for TB)?

Comment 7

[Mathieu Leplatre [:leplatrem]]

(In reply to aleth [:aleth] from comment #6)
> Mathieu, maybe you could advise on comment 1 (how to check things are set up
> correctly for TB)?

OneCRL is a mechanism to enable fast revocation checks on certificates used in TLS connections. Thunderbird, in theory, should be able to make use of this. I can't comment on specific issues you're encountering at the moment (I've pinged mgoodwin to respond in the original bug), however, I can explain a bit the roadmap for a potential transition towards the new system:

Currently the blocklist system relies on a big XML file that is downloaded every day. It contains block entries for certificates to be revoked, addons and plugins to be disabled, and gfx environments that cause problems or crashes. Everything is managed via the Addons server.
The client (derivatives like TB) downloads it on an URL like https://blocklist.addons.mozilla.org/blocklist/3/%7Bec8030f7-c20a-464f-9b0e-13a3a9e97384%7D/44.0a1/

We want to replace this with a remote JSON storage that allows diff-based synchronization and content signature [0].
Each blocklist will be stored in a separate collection of JSON records.

Using the same XPCOM notification mechanism, the remote server will be polled for changes [1].
If changes are available, the local copy will be updated and content signature verified (Bug 1263602). [2]

In phase 1, this will be a no-op. Both mecanisms will run in parallel but only the legacy one will be used. We'll keep both mainly because the current download of the XML is used to count active daily users. Once we are ok with the statistics, we'll go to phase 2.

In phase 2, we'll change the source of truth of block entries on the server side. The data from the Addons server won't be used anymore. That means the server will produce the same XML file but using the data stored in the new service. 

In phase 3, the blocking mecanism will rely on the data managed via JSON, and the old XML client will be decommissioned. In this phase we'll probably have to remain in contact to make sure entries dedicated to derivatives are well taken into account.

I hope it will help to have a better understanding of the changes being submitted in the last few weeks. Don't hesitate to ping us on mozilla#storage or freenode#kinto if you need more details.

As I said in https://bugzilla.mozilla.org/show_bug.cgi?id=1266794#c14, we started to write some specs here https://wiki.mozilla.org/Firefox/Kinto

Thanks for your patience if you read all this ;)

[0] http://kinto.readthedocs.io
[1] https://dxr.mozilla.org/mozilla-central/rev/fc15477ce628599519cb0055f52cc195d640dc94/toolkit/mozapps/extensions/nsBlocklistService.js#632-642
[2] https://dxr.mozilla.org/mozilla-central/rev/fc15477ce628599519cb0055f52cc195d640dc94/services/common/KintoBlocklist.js#78-105

Comment 8

[aleth [:aleth]]

(In reply to Mathieu Leplatre (:leplatrem) from comment #7)
> OneCRL is a mechanism to enable fast revocation checks on certificates used
> in TLS connections. Thunderbird, in theory, should be able to make use of
> this. I can't comment on specific issues you're encountering at the moment
> (I've pinged mgoodwin to respond in the original bug), however, I can
> explain a bit the roadmap for a potential transition towards the new system:

Thanks for your detailed explanation!

I think the main concern here is whether TB can assume this new mechanism is working properly as long as the associated tests in toolkit/ pass, or whether additional tests (possibly just by hand) are warranted. It can sometimes be hard to tell whether all the required ingredients have been ported/packaged for TB. If it's just a matter of setting the prefs, things should be fine once they move to all.js. If e.g. some initialization code is required, there may be more to do.

Comment 9

[Mark Goodwin [:mgoodwin]]

(In reply to aleth [:aleth] from comment #8)
> I think the main concern here is whether TB can assume this new mechanism is
> working properly as long as the associated tests in toolkit/ pass, or
> whether additional tests (possibly just by hand) are warranted. It can
> sometimes be hard to tell whether all the required ingredients have been
> ported/packaged for TB. If it's just a matter of setting the prefs, things
> should be fine once they move to all.js. If e.g. some initialization code is
> required, there may be more to do.

If the tests are passing properly and all of the relevant preferences are set, this should work fine.  The good news is that this shouldn't be too hard to verify. I'll be working with QA to create test documentation that will outline how to test the various parts of this - including ensuring that the prefs are set appropriately.

Comment 10

[J.C. Jones [:jcj] (he/him)]

I believe we've proven, experimentally, that OneCRL works in Thunderbird -- too well, actually. We've opened Bug 1312827 to reduce the scope of OneCRL to only affect TLS loads, as currently placing a certificate in OneCRL will also affect email trust bits.

I'm going to close this as WORKSFORME.