[tor-bugs] #30472 [Circumvention/Pluggable transport]: Implement a mechanism for PT reachability testing

[Tor Bug Tracker & Wiki]

#30472: Implement a mechanism for PT reachability testing
-----------------------------------------------+---------------------------
 Reporter:  phw                                |          Owner:  phw
     Type:  project                            |         Status:
                                               |  needs_review
 Priority:  High                               |      Milestone:
Component:  Circumvention/Pluggable transport  |        Version:
 Severity:  Major                              |     Resolution:
 Keywords:  reachability                       |  Actual Points:
Parent ID:  #30471                             |         Points:
 Reviewer:                                     |        Sponsor:  Sponsor19
-----------------------------------------------+---------------------------

Comment (by phw):

 Replying to [comment:6 cohosh]:
 > - A nicer way to express the timeout
 [https://github.com/NullHypothesis/obfs4PortScan/blob/master/handlers.go#L43
 here] would be
 >  {{{ timeout := 3* time.Second }}}, but even better would be to set a
 commented constant at the beginning of the file.
 [[br]]
 Good point, fixed in the following branch:
 https://github.com/NullHypothesis/obfs4PortScan/tree/fix/30472
 [[br]]
 > - In `main()` you could have the certificate and key files passed in as
 specific arguments such as `--cert` or `--key` as the broker does
 [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/tree/broker/broker.go#n263 here]. The advantage
 of this is making sure they are passed in the correct order (which should
 be documented outside of the usage function).
 [[br]]
 Also fixed in the same branch.
 [[br]]
 > - Do you also want timestamps in your logs?
 [[br]]
 I would like to keep timestamps because they tell us how much (ab)use the
 service is seeing. Do you see any issues with timestamps?

 On a related note: I noticed that the http package can log error messages
 that include the client's IP address. I included snowflake's safe logger
 to prevent this from happening.
 [[br]]
 > As a more general note, is this meant to be used in an automated way for
 bridge operators to log and report to themselves when their port isn't
 reachable? Or as an occasional manual check? I know this is something
 temporary so maybe not a large consideration, but returning something
 other than a `200 OK` if the port is unreachable would make it easier to
 write a client-side go program that performs this check automatically.
 [[br]]
 At this point it's meant for occasional manual checks. I plan to add a
 link to the service to our
 [https://trac.torproject.org/projects/tor/wiki/doc/PluggableTransports/obfs4proxy
 obfs4proxy installation guide]. I originally intended this service to be
 used as an API (see the bottom paragraph of the ticket's description) but
 it's not clear if we want yet another service that deals with bridge data.
 The better way forward may be to improve BridgeDB.

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