#30472: Implement a mechanism for PT reachability testing
-----------------------------------------------+--------------------------
Reporter: phw | Owner: phw
Type: project | Status: assigned
Priority: High | Milestone:
Component: Circumvention/Pluggable transport | Version:
Severity: Major | Resolution:
Keywords: reachability | Actual Points:
Parent ID: #30471 | Points:
Reviewer: | Sponsor:
-----------------------------------------------+--------------------------
Comment (by phw):
We had a short discussion on IRC and concluded the following:
* We don't want another central service that collects all the data.
* A bridge can self-test by having its tor client establish a TCP
connection with its obfs4 port (see #30477). Tor can then warn the
operator in its log file if the test fails. Unfortunately, this won't help
if we ever deploy a PT that speaks UDP.
* Some operators will ignore their log files, though, so we will still be
collecting unreachable obfs4 bridges. BridgeDB should therefore learn how
to test all of its bridges by speaking their respective transport
protocol. It should not hand out bridges that are unreachable or otherwise
broken.
We were left wondering what obfs4 operators should do in the short term,
before #30477 is done, to figure out if their bridge is reachable. One way
forward would be a simple web page, hosted by us, that asks for an IP
address, and a port as input. The service then tries to establish a TCP
connection to the given tuple, and lets the user know if it succeeded or
failed. The service doesn't need to log or remember anything, and we can
run it on polyanthum, the host that also runs BridgeDB.
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/30472#comment:2>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs
