Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
  • Tor Browser Tor Browser
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
  • Issues 834
    • Issues 834
    • List
    • Boards
    • Service Desk
    • Milestones
  • Merge requests 5
    • Merge requests 5
  • Deployments
    • Deployments
    • Releases
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • Repository
  • Wiki
    • Wiki
  • Activity
  • Graph
  • Create a new issue
  • Commits
  • Issue Boards
Collapse sidebar
  • The Tor Project
  • Applications
  • Tor BrowserTor Browser
  • Issues
  • #40242
Closed
Open
Issue created Nov 16, 2020 by Roger Dingledine@armaReporter

Tor Browser has two default bridges that share a fingerprint, and Tor ignores one

default_bridge.obfs4.13 has an ipv4 address and identity fingerprint C5B7CD6946FF10C5B3E89691A7D3F2C122D2117C, whereas default_bridge.obfs.14 has an ipv6 address and the same identity fingerprint C5B7CD6946FF10C5B3E89691A7D3F2C122D2117C.

One might think that Tor will then try both of these addresses and if only one works, it will use that one. But that is not so, because of Tor bug tpo/core/tor#40193 (closed).

I'm not sure what the best fix is from the Tor Browser side. The easy pick would be "we should remove one of those bridge lines for now, because we're clearly not getting the redundancy we hoped for." Maybe there are better plans than that, depending on when/whether/how the network team plans to address the tor-side bug.

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