Re: [tor-bugs] #30477 [Core Tor/Tor]: Tor should self-test reachability of TCP listeners exposed by PT's

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#30477: Tor should self-test reachability of TCP listeners exposed by PT's
-------------------------------------------------+-------------------------
 Reporter:  ahf                                  |          Owner:  (none)
     Type:  task                                 |         Status:  new
 Priority:  Medium                               |      Milestone:  Tor:
                                                 |  unspecified
Component:  Core Tor/Tor                         |        Version:  Tor:
                                                 |  unspecified
 Severity:  Normal                               |     Resolution:
 Keywords:  tor-pt, network-team-roadmap-        |  Actual Points:
  november, s30-o23a3                            |
Parent ID:  #30471                               |         Points:
 Reviewer:                                       |        Sponsor:
                                                 |  Sponsor30-must
-------------------------------------------------+-------------------------

Comment (by arma):

 Replying to [comment:12 teor]:
 > Bridges already do reachability checks via a random relay's ORPort: so
 we have accepted a similar risk in the past.

 Agreed, we already have that "enumeration by relays" risk with our current
 orport reachability testing.

 I'm ok with either choice here -- I think we need to get robust testing
 going of both PT ports and ipv6 ports, and whether we get it going first
 on the bridge side, or first on the bridgedb side, I'm ok with either
 choice.

 My first thought is that we eventually want to have the testing happen in
 both places -- on the bridge side for improved usability and quick
 feedback to the operator, and on the bridgedb side so we can control the
 quality of bridges we're giving out. That said, if we have to pick only
 one, I'd pick the bridgedb side, because that's the only logical place to
 do quality control that we can trust. And maybe given that, if we want to
 minimize exposure, it's worth exploring some way for bridgedb to do its
 first check really quickly, and get that feedback back to the bridge
 operator quickly, and then there's no need for the bridge to be doing its
 own checks?

 Speaking of bridges doing reachability checks via a random relay, thus
 letting relays enumerate bridges: a potential mitigation is for the bridge
 to ask its guard to extend to its ORPort. That way the guard learns that
 it's a bridge, but maybe it could have learned that anyway through timing
 or other characteristics, and nobody else in the network gets to see the
 reachability test. (I could have sworn I had already opened a ticket for
 this idea, but I can't find it. If you find it, please note it here. :)

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

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs