Tor should self-test reachability of TCP listeners exposed by PT's
It would be useful if Tor would do self-test of TCP port reachability for bridge listeners and not just the ORPort itself.
Currently when a bridge operator starts their Bridge Relay, Tor will test whether their ORPort is available from the internet, but we do not test the reachability of, for example, the obfs4 TCP port.
We believe that just testing for whether the port is available to the internet is better than to actually test if the port, for example, is able to speak the obfs4 protocol.
We should probably have a way to disable the warning that is emitted if a port is not reachable if, for example, the bridge is actually lying to Tor about its port, does not have a port, or the port is exposed via UDP instead of TCP.
Activity
changed milestone to %Tor: unspecified
Trac:
Parent Ticket: #31280 (moved)
Updating the parent to #30471 (moved) because our past parent, #30472 (moved), turned into a short-term solution that is now deployed.
Trac:
Parent: #30472 (moved) to #30471 (moved)See also #31874 (moved) on the anti-censorship side: self-testing is one of the options listed in that ticket.
-
Replying to 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.
This sounds great because it's consistent with how a bridge's vanilla port is tested and the sooner we can tell an operator that something's wrong, the better. The bonus step is helpful in some edge cases: we recently had a bridge with an open obfs4 port but obfs4 connections failed. It turned out that obfs4proxy was unable to talk to tor because a local security policy prevented obfs4proxy from connecting to the ExtORPort.
The only downside I see is that it won't work for a UDP-based transport – if we ever end up deploying one.
Ok, here's a summary of the steps to move forward:
- If a transport exposes a TCP port, connect to that TCP port via a Tor Exit
- Test the transport protocol by connecting directly to the address and port
Getting the PT to connect to itself via the Tor network might involve some really complex code. So let's just do the simplest tests we can.
-
Replying to teor:
Replying to nickm:
If a transport exposes a TCP port, connect to that TCP port via a Tor Exit.
Question: what if the attacker runs an exit in order find out where PT ports are?
Bridges already do reachability checks via a random relay's ORPort: so we have accepted a similar risk in the past.
It may be a good time to re-consider this risk now. Over at #31874 (moved), we're brainstorming a service that takes as input a bridge line and then tests the given bridge. We may want such a service instead of, or in addition to Tor self-testing its PT bridge. The downside of this service (which we could couple with BridgeDB) doing the testing is that it takes a while until the bridge operator learns if their bridge works.
Replying to 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. :)
Replying to arma:
Replying to 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.
...
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. :)
We haven't implemented bridge guards yet, so bridges also have another similar vulnerability: all the middle nodes chosen by bridge clients can learn that the previous hop is a bridge. (Client-Bridge-Middle has different timings and node selections than Client-Guard, OnionService-Guard and SingleOnionService-guard.)
-
Replying to teor:
We haven't implemented bridge guards yet, so bridges also have another similar vulnerability: all the middle nodes chosen by bridge clients can learn that the previous hop is a bridge. (Client-Bridge-Middle has different timings and node selections than Client-Guard, OnionService-Guard and SingleOnionService-guard.)
Good point. A bridge's current guard barely sees anything at all from it, other than fetching directory stuff.
Almost makes me want to propose that bridges should build their path to Serge and then extend from there back to themselves. :)
Trac:
Parent: #30471 (moved) to #31280 (moved)mentioned in issue #31874 (moved)
mentioned in issue #31280 (moved)
moved to tpo/core/tor#30477 (closed)
