Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #3292

Closed (moved)
Open
Opened May 26, 2011 by Roger Dingledine@arma

Let bridge users specify that they don't care if their bridge changes fingerprint

We have an increasing set of situations where the user configures a bridge address that isn't actually the address of the place running the Tor program.

In scenario 1, we have a bridge running at point X, but addresses A and B both route to it, and the user types either A or B into her Vidalia bridge list.

In scenario 2, there's a bridge at point X and another bridge at point Y, and addresses A and B point to one of these bridges and fallback to the other as needed.

That sounds great for robustness, but if you configure your bridge at address A, and it forwards traffic to the bridge at address X which has fingerprint X, and then later it starts forwarding its traffic to address Y which has fingerprint Y, your Tor client will scream murder and stop using the bridge you've configured as A.

What exactly are we protecting against by refusing to use the network when A's fingerprint changes? Is that something we want to keep allowing users to protect against, or can we just change Tor to ignore wrong fingerprints on its bridge?

As a bonus, relaxing our security requirements here would let us tolerate SSL cert replacement attacks at the firewall -- so long as the attacks still allow us to talk our Tor protocol underneath.

This topic is related to #2764 (moved).

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Tor: unspecified
Milestone
Tor: unspecified
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#3292