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

Tor Bug Tracker & Wiki torproject-admin at torproject.org
Fri Jan 21 21:00:42 UTC 2011


#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 rransom):

 Replying to [comment:10 dkg]:
 > I agree with Sebastian that simplifying and integrating into existing
 systems is the right way forward, not to make the verification process
 even more complex.
 >
 > At its core, it sounds like the problem you're facing here is that old
 packages have no expiration mechanism so users can realize that they
 should look for a newer version.

 This bug report is about the fact that a user cannot verify that the file
 he has downloaded is the package the download page described it as.

 See [http://www.freehaven.net/~arma/tuf-ccs2010.pdf] for the design of an
 automatic package updater which protects a user from 'repository-state
 freezing' and other attacks without requiring the user to manually verify
 that a package file is the one he intended to download.

 The way to make the verification process simpler is to incorporate the
 package-verification part of TUF as a standalone program that verifies a
 package's identity using a downloaded single-file bundle of certificates.

 > It seems to me that this is best achieved through a combination of
 system-specific cryptographic signatures with embedded expirations (for
 dealing package installation time), and run-time version-checking against
 some authoritative server that can declare (in a cryptographically-secure
 way) "this version should no longer be run".  I don't much like this kind
 of "phone home" approach, but as i understand it, tor already needs to
 check in with some authoritative servers to find its way into the network
 anyhow.  If that's the case, maybe those servers can be re-used for this
 purpose?

 The Tor network consensus already includes a list of 'recommended
 versions' of Tor (see [https://metrics.torproject.org/consensus-
 health.html the Tor Metrics consensus health page]).  We don't actually
 seem to use this to deprecate old versions -- the list of recommended
 versions currently includes ''many'' versions of Tor vulnerable to
 CVE-2011-0427.

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


More information about the tor-bugs mailing list