Create a new MAR signing key for ESR60

Due to the new signing related code coming with ESR60 (which we intend to use instead of our own patch(es)), we need a new MAR signing key we want to ship with the first ESR60-based alpha. (See: https://lists.torproject.org/pipermail/tbb-dev/2018-April/000837.html item 3)

added GeorgKoppen201806 TorBrowserTeam201806R component::applications/tor browser owner::tbb-team priority::very high resolution::fixed severity::normal status::closed tbb-no-uplift type::task labels

Trac:
Status: new to closed
Resolution: N/A to invalid

Trac:
Status: closed to reopened
Resolution: invalid to N/A

Adjusting prios of some tickets.

Trac:
Priority: High to Very High

Moving my tickets to June 2018.

Trac:
Keywords: GeorgKoppen201805 deleted, GeorgKoppen201806 added

Moving our tickets to June 2018

Trac:
Keywords: TorBrowserTeam201805 deleted, TorBrowserTeam201806 added

Okay, I tested quite a bit. Here is the scenarios I covered:

old=BZIP2 new=LZMA

1. Signing old and new MAR file based on latest esr60 tor browser code with currently used cert a) used esr60 nightly (just tested old MAR compression) ERROR: Unknown signature algorithm ID. ERROR: Unknown signature algorithm ID. b) used esr52 alpha i) old worked, updated to esr60 nightly ii) new did not work, did essentially nothing and gave no errors

2. Signing old and new MAR file based on latest esr60 tor browser code with new cert a) esr52 nightly (just tested with old MAR compression) ERROR: Unknown signature algorithm ID 2. ERROR: Unknown signature algorithm ID 2.

3. Taking the result from 1b)i a) applying old with old cert ERROR: Unknown signature algorithm ID. ERROR: Unknown signature algorithm ID. b) applying new with old cert ERROR: Unknown signature algorithm ID. ERROR: Unknown signature algorithm ID. c) applying old with new cert ERROR: Error verifying signature. ERROR: Error verifying signature. d) applying new with new cert ERROR: Error verifying signature. ERROR: Error verifying signature.

Everything looks good except in 3c) and 3d). I had expected that in 3c) nothing happens and in 3d) the update with the new cert works. I tried to debug that and came earlier to the conclusion that I need to replace the nightly certs with the new certs as well for testing purposes. That's already included.

Now, I wonder what is going on. If I use the new mar-tools and create a new nssdb importing the public part of the new cert into it using

certutil -A -d nssdb -n marsigner -t,, -i ../../tor-browser/toolkit/mozapps/update/updater/release_primary.der

and doing now a verification of the signature of the two MAR files used in 3c) and 3d) the check succeeds. I.e.:

signmar -d nssdb -n marsigner -v 8.0a10_nssdb6/tor-browser-linux64-tbb-nightly-new-nightly-cert-unsigned.mar

returns nothing while importing the second new cert and checking against that one fails (which is expected as the key behind the first one signed the MAR files).

So, this makes me feel optimistic. Still, it would be nice to understand why the update in 3d) failed and why there was a signature verification error in 3c).

Trac:
Cc: N/A to mcs, brade

Okay, one additional bit: I can't even apply the signed MAR file to the nightly which it is built from but it seems to me that should be possible. I get "ERROR: Error verifying signature." in this case as well.

The final bit for now: I am following https://wiki.mozilla.org/Software_Update:Manually_Installing_a_MAR_file as usual when I am testing update related things.

Trac:
MAR_logging.patch

signature verification logging patch

Kathy and I are out of time for now, but the extra logging contained in the patch that I just attached might reveal something.

Were you able to reproduce the problem?

Here is what I've got:

ArchiveReader::VerifySignature BEGIN
ArchiveReader::VerifySignature - checking against primaryCertData
VerifyLoadedCert BEGIN
mar_verify_signatures - count: 1
mar_verify_signatures - loading compiled-in cert 0 of length 1215
mar_extract_and_verify_signatures_fp - key count: 1
mar_extract_and_verify_signatures_fp - sig count: 1
mar_extract_and_verify_signatures_fp - checking signature 0
mar_extract_and_verify_signatures_fp - sig 0 has alg id 2
mar_extract_and_verify_signatures_fp - signature len: 512
mar_verify_signatures_for_fp - sig count: 1
mar_verify_signatures_for_fp - checking signature 0
libmar - NSS_VerifySignature BEGIN
libmar - NSS_VerifySignature VFY_EndWithSignature  failed: -8182 (Peer's certificate has an invalid signature.)
libmar - NSS_VerifySignature FAILED 
ERROR: Error verifying signature.
VerifyLoadedCert - mar_verify_signatures FAILED
ArchiveReader::VerifySignature - FAILURE

I double-checked the .der file and it says (amongst other things): "Signature Algorithm: sha384WithRSAEncryption".

So, we indeed seem to have a key we want.

Two additional bits of information that may help:

1. I essentially used the key generation command as specified in our KeyGeneration doc, just adjusted to the new hash length. I.e. certutil -d nssdb -S -x -g 4096 -Z SHA384 -n marsigner -s "CN=Tor Browser MAR signing key" -t,,

2. For signing I used the old script we had in the Gitian days, signmars.sh, changed to check for the new cert9.db and to make sure it is using the new mar-tools (i.e. those built with the esr60 nightly).

If you want to inspect the .der certs, I used bug_26045 in my public tor-browser repo for building.

I uploaded the signed MAR file to my people dir for further testing:

https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly-new-nightly-cert-signed-debug.mar https://people.torproject.org/~gk/testbuilds/tor-browser-linux64-tbb-nightly-new-nightly-cert-signed-debug.mar.asc

For completeness sake, the output for checking the signature against the second cert is basically identical, the diff is:

1,2c1
< ArchiveReader::VerifySignature BEGIN
< ArchiveReader::VerifySignature - checking against primaryCertData
---
> ArchiveReader::VerifySignature - checking against secondaryCertData
18a18
> ArchiveReader::VerifySignature - final result: FAILURE

It seems mcs and brade found the problem: when building the nightly not the nightly certificates are included into the build but dep1.der and dep2.der`. The code responsible for that is

if CONFIG['MOZ_UPDATE_CHANNEL'] in ('alpha', 'beta', 'release', 'esr'):
    primary_cert.inputs += ['release_primary.der']
    secondary_cert.inputs += ['release_secondary.der']
elif CONFIG['MOZ_UPDATE_CHANNEL'] in ('nightly', 'aurora', 'nightly-elm',
                                      'nightly-profiling', 'nightly-oak',
                                      'nightly-ux'):
    primary_cert.inputs += ['nightly_aurora_level3_primary.der']
    secondary_cert.inputs += ['nightly_aurora_level3_secondary.der']
else:
    primary_cert.inputs += ['dep1.der']
    secondary_cert.inputs += ['dep2.der']

and we set the update channel to default for nightlies (see the tor-browser-build repo projects/firefox/config). After copying the new certs over dep1.der and dep2.der scenario 3c) and 3d) in comment:6 behave as epxected: in the former nothing happens after the successful signature verification and in the latter the update works. Thus, we are good with the new key.

bug_26045_v2 (https://gitweb.torproject.org/user/gk/tor-browser.git/log/?h=bug_26045_v2) is up for review. It first reverts the commit that let us add our old keys and is then starting basically from scratch adding the new certificates.

Trac:
Status: reopened to needs_review
Keywords: TorBrowserTeam201806 deleted, TorBrowserTeam201806R added

r=mcs Looks good to me.

Thanks. Merged to tor-browser-60.0.1esr-8.0-1 as commits d77a0ec835e8ee8e4beab614722c02fa7fd96119 and 1f78032d48850e0197608ac1d9906a095e2a4c06.

Trac:
Resolution: N/A to fixed
Status: needs_review to closed

Trac:
Keywords: N/A deleted, tbb-no-uplift added

closed

moved to tpo/applications/tor-browser#26045 (closed)