Use SHA-2 signature for Tor Browser setup executables
As tjr mentioned in #17870 (moved) we only use SHA-1 when signing our Windows setup executables and should switch to SHA-2 or, better, provide both SHA-1 for older systems and SHA-2 for newer ones. Mozilla tried to deal with it in https://bugzilla.mozilla.org/show_bug.cgi?id=1079858 which might be a good starting point for solving this bug.
Activity
This ticket is about SHA-2 digest algorithm in digital signature (not certificate). (Otherwise it's a misunderstanding, taken here from Mozilla) As noted there:
"Microsoft does not require these file hashes to be done using SHA-2. Windows will also not enforce policies on these hashes. If pre-image attacks on SHA-1 become feasible we will reevaluate how the system trusts signatures made with such file hashes."
There is no current need to implement it, except for additional security. But exactly for additional, so
provide both SHA-1 for older systems and SHA-2 for newer ones. (and exactly in this order, so SHA-1 would be the first in the list) This solution has as much compatibility as possible.
(Current TBB 6.5a2 uses: SHA-1 digest + SHA-2 certificate + SHA-1 timestamp) (Current Mozilla progress is in https://bugzilla.mozilla.org/show_bug.cgi?id=1245842)
Trac:
Reviewer: N/A to N/A
Status: new to assigned
Owner: erinn to tbb-team
Component: Applications/Tor bundles/installation to Applications/Tor Browser
Today a Windows users showed up on IRC and said they needed a 64bit Tor Browser because the stable 32bit one is not working on Windows 10 USN due to missing WoW64 ("The subsystem needed to support the image type is not present"). Furthermore, it turns out that the SHA1 signature we have on our .exe files is not valid on that system either: it wants a SHA2 one as SHA1 ones have been deprecated in Windows 10 USN and giving a unknown publisher yellow UAC error now.
I wonder what that USN version is about and whether we could skip the dual-signing dance with
osslsigncodeand just provide a SHA2 signature given that we switch soon away from supporting XP and Vista anyway.Trac:
Cc: N/A to tom
Keywords: N/A deleted, TorBrowserTeam201802 added-
Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1245842 it seems Mozilla is not dual-signing things either. Instead, if I understand it correctly (https://bugzilla.mozilla.org/show_bug.cgi?id=1245895), they are redirecting users with older systems to binaries signed with SHA1 while properly supported ones get SHA2 signed installers.
Replying to gk:
Today a Windows users showed up on IRC and said they needed a 64bit Tor Browser because the stable 32bit one is not working on Windows 10 USN due to missing WoW64 ("The subsystem needed to support the image type is not present"). WTF is "USN"? And, yes, 32-bit apps aren't working on Linux or Windows 64-bit without 32-bit subsystem. Furthermore, it turns out that the SHA1 signature we have on our .exe files is not valid on that system either: it wants a SHA2 one as SHA1 ones have been deprecated in Windows 10 USN and giving a unknown publisher yellow UAC error now. SHA-2 where? All Firefox .exes in https://www.mozilla.org/en-US/firefox/new/ have the same kind of signatures as TBB. I wonder what that USN version is about and whether we could skip the dual-signing dance with
osslsigncodeand just provide a SHA2 signature given that we switch soon away from supporting XP and Vista anyway. You've already switched to SHA-2 signatures as Firefox 44 and don't provide SHA-1 ones for outdated XP and Vista versions.Replying to gk:
Looking at https://bugzilla.mozilla.org/show_bug.cgi?id=1245842 it seems Mozilla is not dual-signing things either. Instead, if I understand it correctly (https://bugzilla.mozilla.org/show_bug.cgi?id=1245895), they are redirecting users with older systems to binaries signed with SHA1 while properly supported ones get SHA2 signed installers. This is for outdated pre-SP3 XP and pre-SP2 Vista. You shouldn't support Windows installations without the latest security updates.
Replying to gk:
#17870 (moved) So, we are doing the same as Mozilla right now: SHA-1 signature with a SHA-2 code signing certificate. But not in Win64 builds! You should reopen that ticket.
-
Okay, Mozilla is still using SHA-1 for signing the installer (with a SHA-2 cert) but I've amended our signing script so that we use SHA-256 from now on. We'll test that in the first ESR50-based alpha. The script to use for signing those .exe files is the *256.sh one.
Trac:
Resolution: N/A to fixed
Status: assigned to closed -
Oh, I forgot to add that the timestamping and deterministic signature stripping is still working as expected. Tested on a Windows 7 box and after downloading the installer from my people dir and acknowledging the usual warning dialog (which showed we have a valid signature) the bundle installed and worked properly.
-
Replying to cypherpunks:
Replying to gk:
Oh, I forgot to add that the timestamping and deterministic signature stripping is still working as expected. and using SHA-1, fwiw. (SHA-2 digest + SHA-2 certificate + SHA-1 timestamp)
Yes, that's solved in #29614 (moved).
mentioned in issue #18315 (moved)