[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