[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-bugs] #31874 [Circumvention]: Automatically test the PTs of bridges

#31874: Automatically test the PTs of bridges
---------------------------+--------------------------------
 Reporter:  phw            |          Owner:  (none)
     Type:  defect         |         Status:  new
 Priority:  Medium         |      Milestone:
Component:  Circumvention  |        Version:
 Severity:  Normal         |     Resolution:
 Keywords:  s30-o23a3      |  Actual Points:
Parent ID:  #31280         |         Points:  10
 Reviewer:                 |        Sponsor:  Sponsor30-must
---------------------------+--------------------------------

Comment (by phw):

 Here are some thoughts on building a new service that would allow both
 BridgeDB ''and'' bridge operators to test bridges:

 * The service should expose a web interface and an API: The web interface
 is meant for bridge operators who want to test their new bridges, and can
 replace our [https://bridges.torproject.org/scan/ obfs4 port scan tool].
 The API is meant for BridgeDB, allowing it to test the bridges it knows
 about. We need to be sure that there's no interference that would allow
 web interface users to learn what bridges were tested over the API, so we
 may want to run two instances of this service.

 * The API should be a simple JSON-based REST API. Requests should go to,
 say bridges.torproject.org/api/test, and have the following request body:
   {{{
 {bridge_line: "1.2.3.4:443"}
   }}}
   The service should then respond with something along the lines of:
   {{{
   {functional: true, error: null, time: 4.215}
   }}}
   (Note that these are mere examples.)

 * The web interface
 [https://trac.torproject.org/projects/tor/attachment/ticket/31874/bridge-
 test-web-ui.png can look like this].

 * The service can take as input bridge lines (vanilla or pluggable
 transports), spawns a Tor process with the given bridge line, and parses
 Tor's output to determine if the bridge bootstrapped correctly. This has
 the potential to be quite messy. What's a better design?

 * How should BridgeDB use this service? At the very least, it should
 periodically test all its bridges and log the ones that don't work, making
 it easy for BridgeDB's maintainers to contact the respective bridge
 operators.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/31874#comment:2>
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