[tor-bugs] #2340 [Tor bundles/installation]: GPG signatures do not authenticate filenames

[Tor Bug Tracker & Wiki]

#2340: GPG signatures do not authenticate filenames
--------------------------------------+-------------------------------------
 Reporter:  rransom                   |       Owner:  rransom     
     Type:  defect                    |      Status:  needs_review
 Priority:  critical                  |   Milestone:              
Component:  Tor bundles/installation  |     Version:              
 Keywords:                            |      Parent:              
--------------------------------------+-------------------------------------

Comment(by dkg):

 Replying to [ticket:2340 rransom]:

 > The GPG signatures only prove that a particular person associated with
 The Tor Project has signed a particular file; they do not authenticate the
 filename, thus they do not authenticate the package name or the package
 version, and they do not prove that a particular package file is the final
 build of a package version which we want to distribute to users.  This
 leaves our users vulnerable to version-rollback attacks and package-
 substitution attacks if they download packages from mirrors or over non-
 HTTPS connections.

 Isn't this still true if they download the proposed new file format over
 non-HTTPS connections?  as an attacker in this scenario, i can just point
 them to the set of different files, including the old .asc.

 Doesn't the tor installer package contain its version number internally?
 You mention an .exe, and i haven't worked on that platform in years, but i
 seem to recall that Windows executables could embed a version number that
 is visible in the one of the tabs in the File Properties dialog, which
 would presumably not change even if the file name changed.

 If you know you have a regular release schedule, say, every 6 months, then
 you could also add a [https://tools.ietf.org/html/rfc4880#section-5.2.3.10
 signature expiration subpacket] to your OpenPGP signature that is roughly
 in the time frame that you expect the next release to come around.  (see
 the `--ask-sig-expire` and `--default-sig-expire` options for gpg), to
 limit rollback attacks beyond that range.  Users who actually verify the
 download with OpenPGP-compliant software will be notified that the
 signature is expired.

 Another approach entirely could use the OS-native mechanism for signing
 distributed software:

  * [http://stackoverflow.com/questions/252226/signing-a-windows-exe-file
 windows appears to use signtool.exe] -- i don't know much about it,
 whether embedded version numbers are themselves signed, and/or whether the
 signatures can be made to expire.
  * debian and debian-derived operating systems use signed apt
 repositories.  Tools like [http://packages.qa.debian.org/r/reprepro.html
 reprepro] can create signed archives, and those signatures can themselves
 have expiration dates.
  * macOS -- it seems that
 [https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/packagemaker.1.html
 packagemaker] is capable of signing the files.  i also don't know about
 expiration or embedded version numbers here.

-- 
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/2340#comment:6>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online