Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Tor
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 325
    • Issues 325
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 30
    • Merge requests 30
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Core
  • TorTor
  • Issues
  • #1138
Closed
Open
Issue created Oct 26, 2009 by Roger Dingledine@armaReporter

If bridge authority is unreachable, client doesn't fallback to bridge

When a Tor client starts up using a bridge, and UpdateBridgesFromAuthority is set (which it is when Vidalia configures you to use a bridge), Tor will go to the authority first and look up the bridge by fingerprint.

If the bridge authority doesn't have the bridge, or Tor doesn't know the fingerprint, then Tor will fall back to asking the bridge directly.

If the bridge authority is filtered, though, then Tor will never notice that the bridge authority lookup failed. So it will never fall back. Fail.

Our workaround for now is to stop giving out fingerprints via bridgedb.

[Automatically added by flyspray2trac: Operating System: All]

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking