significant ESR60 updater changes
Recently, Kathy and I spent some time looking at the changes that have been made to the Firefox updater since ESR52. The purpose of this message is to highlight a few of the most important changes. It would be helpful for other people on the team to review and comment on our assumptions. 1. "Simplify the application update UI" https://bugzilla.mozilla.org/show_bug.cgi?id=893505 The user experience has been streamlined. The big ugly update dialog has been removed and doorhangers are instead used to prompt people to update. We will want to adjust some prefs that control how soon users are nagged to update (to reduce the time, as we did with the older update UI) but Kathy and I think the new experience should be okay for Tor Browser users. There is a work item for later this year to work with our UX team to improve the update experience, but first we will need to get the ESR60-based one working. 2. "LZMA support for updater" https://bugzilla.mozilla.org/show_bug.cgi?id=641212 Within the MAR files, each file or patch is compressed. Prior to Firefox 60, BZip2 compression was used. By switching to LZMA, file size is reduced by 10-20% in most cases. Some size comparisons that were done for Firefox are available here: https://bugzilla.mozilla.org/show_bug.cgi?id=641212#c250 Kathy and I think we want this change for Tor Browser, but it will mean that we must execute a "watershed" (two-step) update process wherein older browsers must first update to a Tor Browser based on ESR60 before they can update to a newer version. In other words, we will need to provide old-format MAR files to old browsers so they can be updated to a browser that understands the new LZMA-based format. We have never done a watershed update for Tor Browser, so it will be exciting to try. 3. "Support stronger hash algorithms than SHA1 for signing certificates" https://bugzilla.mozilla.org/show_bug.cgi?id=1105689 Mozilla switched from SHA1 hashes for MAR files to SHA384. We have been using SHA512 for Tor Browser from the beginning (via patches to the Mozilla code). The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks. I am not a crypto person, but it seems to Kathy and me that switching to SHA384 is a win because we can eliminate some of our patches. If we are doing a watershed (two-step) update process to get the LZMA support, we can handle the SHA512 -> SHA384 transition at the same time. Mozilla did this same thing, adopting both incompatible changes to the MAR format together in Firefox 56.0 timeframe. 4. "Remove hashFunction and hashValue attributes" https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values. As I mentioned above, your input is welcome. Thanks! -Mark
On 5 April 2018 at 09:39, Mark Smith <mcs@pearlcrescent.com> wrote:
The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks.
This decision was made without the crypto people at Mozilla being involved. We considered it unnecessary and SHA512 would have been fine; but whatever we're not going to change it again for vanity.
4. "Remove hashFunction and hashValue attributes" https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values.
SGTM. -tom
Tom Ritter:
On 5 April 2018 at 09:39, Mark Smith <mcs@pearlcrescent.com> wrote:
The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks.
This decision was made without the crypto people at Mozilla being involved. We considered it unnecessary and SHA512 would have been fine; but whatever we're not going to change it again for vanity.
Reading through the bug it seems crypto people were consulted, no? Either way, I wonder what https://bugzilla.mozilla.org/show_bug.cgi?id=1105689#c52 implies ("Keep in mind that the implementation design that was created with the security team for this required that we use the system provided crypto instead of NSS if at all possible.") because three years ago I said at least that we are using NSS on all platforms. Looking at the changes for SHA-348, though, it seems they don't change the game for us or am I missing anything? brade/mcs: please proceed as you see fit taking my two comments above into account. Having a smaller patch set for the updater related parts, especially for the crypto related ones, is pretty appealing...
4. "Remove hashFunction and hashValue attributes" https://bugzilla.mozilla.org/show_bug.cgi?id=1373267 Mozilla removed support for a hash check of the MAR files that has historically been implemented by including hash values in the update manifest (XML) file that is returned by the update server. Mozilla relies on MAR signatures to verify the integrity of the Firefox MAR files, but in the past we have talked about the value in requiring that two things need to be compromised: the update server as well as a MAR signing key. For that reason, Kathy and I believe we should back out these changes and continue to have our update server return hash values.
SGTM.
+1 Georg
On 12 April 2018 at 12:41, Georg Koppen <gk@torproject.org> wrote:
Tom Ritter:
On 5 April 2018 at 09:39, Mark Smith <mcs@pearlcrescent.com> wrote:
The reason Mozilla chose SHA384 over SHA512 is reduced vulnerability to length extension attacks.
This decision was made without the crypto people at Mozilla being involved. We considered it unnecessary and SHA512 would have been fine; but whatever we're not going to change it again for vanity.
Reading through the bug it seems crypto people were consulted, no?
Security people were consulted, but not cryptographers. :)
Either way, I wonder what https://bugzilla.mozilla.org/show_bug.cgi?id=1105689#c52 implies
("Keep in mind that the implementation design that was created with the security team for this required that we use the system provided crypto instead of NSS if at all possible.")
because three years ago I said at least that we are using NSS on all platforms. Looking at the changes for SHA-348, though, it seems they don't change the game for us or am I missing anything?
That is a bit confusing. I wonder if that comment refers to generating the keys as opposed to validating the signatures. Either way I'm not sure.. -tom
participants (3)
-
Georg Koppen -
Mark Smith -
Tom Ritter