Opened 8 weeks ago

Last modified 6 days ago

#31874 assigned defect

Automatically test the PTs of bridges

Reported by: phw Owned by: phw
Priority: Medium Milestone:
Component: Circumvention Version:
Severity: Normal Keywords: s30-o23a3
Cc: cohosh, phw Actual Points:
Parent ID: #31280 Points: 10
Reviewer: Sponsor: Sponsor30-must

Description

When a new bridge is set up, our directory authority is testing its OR port and assigns it the Running flag if the OR port is reachable. Nothing however is testing a bridge's PT port(s). This resulted in several bridges having an unreachable obfs4 port, e.g., because the operator failed to whitelist the obfs4 port in their firewall. Let's fix this by testing a bridge's pluggable transport and alerting the operator if the PT is unreachable.

Obfs4proxy has client implementations for most of our currently-deployed PTs, so we could start by writing some glue code that takes as input a bridge line and makes obfs4proxy (and tor) connect to the given bridge.

Another question is where we should do the testing from. Our bridge authority and BridgeDB are the obvious candidates. Our bridge authority currently tests bridges' OR ports but we may not want it to also test PTs.

Finally, how should we let bridge operators know if their PTs are unreachable? We may want to send them an email (if they have contact information in their descriptor), and/or make their tor log a warning.

Child Tickets

Attachments (1)

bridge-test-web-ui.png (56.3 KB) - added by phw 5 weeks ago.
Web UI mockup.

Download all attachments as: .zip

Change History (7)

comment:1 Changed 8 weeks ago by teor

It wouldn't be that hard to teach Tor bridges to self-test their PT addresses via an Exit, like we already do with DirPorts. As a bonus step, we might even want to test that the port speaks the PT protocol. See #30477.

Changed 5 weeks ago by phw

Attachment: bridge-test-web-ui.png added

Web UI mockup.

comment:2 Changed 5 weeks ago 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 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 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.

comment:3 Changed 5 weeks ago by phw

Some additional feedback from dcf and cohosh after today's anti-censorship meeting:

  • There's potential for abuse. Exposing this service to the public means allowing anybody to use our machine to establish TLS connections (for vanilla Tor) and send garbage data (for obfs4) to arbitrary machines on the Internet. To prevent this, the service could first verify if the provided bridge is in BridgeDB, and only then proceed to test it.
  • If BridgeDB uses this service to test a bridge, and somehow propagates this information to CollecTor (so it can be listed on the bridge's status page), there may not be a need to expose it to the public.
  • BridgeDB should not hand out bridges that this service deems non-functional.

comment:4 Changed 4 weeks ago by phw

Status: newneeds_review

I pushed a work-in-progress version of my code to this repository: https://dip.torproject.org/phw/bridgestrap

Here's what remains to be done:

  • Add tests.
  • Clean up code and make it more robust.
  • Strip down the torrc (in tor.go) to its bare minimum.
  • Improve the way we're spawning tor and interacting with it.
  • Improve log messages.
  • Write BridgeDB code that interacts with this service.
  • Figure out what to do with the Web frontend, to prevent abuse.

It's still work-in-progress but I would appreciate a preliminary review of the code.

comment:5 Changed 7 days ago by cohosh

Just took a look, and it looks great so far. The code is well written and the design makes sense to me.

I'm still doubtful that we'd need or want to expose the API to the public. I can see some value in allowing operators to use the web interface as a self-check after they set up the bridge, but I'm curious about how much use it will get. Do you have any insights into this from setting up #30472 before the bridge campaign?

I think by far the most useful part of this is for bridgedb to auto detect that new bridges are unreachable or that existing bridges have gone offline.

comment:6 in reply to:  5 Changed 6 days ago by phw

Owner: set to phw
Status: needs_reviewassigned

Replying to cohosh:

Just took a look, and it looks great so far. The code is well written and the design makes sense to me.


Thanks for your review.

I'm still doubtful that we'd need or want to expose the API to the public. I can see some value in allowing operators to use the web interface as a self-check after they set up the bridge, but I'm curious about how much use it will get. Do you have any insights into this from setting up #30472 before the bridge campaign?


We don't have any numbers because our port test tool is run over systemd and nobody has figured out how systemd can take the tool's logs (which are written to stderr) and log it somewhere else.

I agree that the primary purpose of this tool is to assist BridgeDB. I'm not married to the idea of exposing it to bridge operators but there's a clear need for operators to know if their bridge works. If BridgeDB tests new bridges and somehow communicates the result to metrics, operators can consult our relay search tool to get their answer.

Note: See TracTickets for help on using tickets.