Opened 7 months ago

Last modified 8 weeks ago

#30477 new task

Tor should self-test reachability of TCP listeners exposed by PT's

Reported by: ahf Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version: Tor: unspecified
Severity: Normal Keywords: tor-pt, network-team-roadmap-november, s30-o23a3
Cc: phw Actual Points:
Parent ID: #30471 Points:
Reviewer: Sponsor: Sponsor30-must

Description

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.

Child Tickets

Change History (17)

comment:1 Changed 7 months ago by phw

Parent ID: #30472#30471

Updating the parent to #30471 because our past parent, #30472, turned into a short-term solution that is now deployed.

comment:2 Changed 6 months ago by gaba

Keywords: ex-sponsor19 added
Sponsor: Sponsor19

Remove sponsor 19 and add a keyword ex-sponsor19 to mark all the tickets that could have been in the scope of the sponsor.

comment:3 Changed 4 months ago by gaba

Sponsor: Sponsor28-must

comment:4 Changed 4 months ago by gaba

Keywords: network-team-roadmap-november added; ex-sponsor19 removed

comment:5 Changed 3 months ago by gaba

Sponsor: Sponsor28-mustSponsor30-must

This is really sponsor 30 and not 28.

comment:6 Changed 3 months ago by teor

See also #31874 on the anti-censorship side: self-testing is one of the options listed in that ticket.

comment:7 Changed 3 months 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.

comment:8 in reply to:  7 Changed 2 months ago by phw

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.

comment:9 Changed 2 months ago by teor

Ok, here's a summary of the steps to move forward:

  1. If a transport exposes a TCP port, connect to that TCP port via a Tor Exit
  2. 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.

comment:10 Changed 2 months ago by 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?

comment:11 Changed 2 months ago by gaba

Keywords: s30-o23a3 added

comment:12 in reply to:  10 ; Changed 2 months ago by 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.

comment:13 in reply to:  12 Changed 2 months ago by phw

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, 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.

comment:14 Changed 8 weeks ago by teor

Self-testing is really important: lots of relay operators have trouble with IPv6, because tor doesn't self-test IPv6 ORPorts.

comment:15 in reply to:  12 ; Changed 8 weeks ago by 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.

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. :)

comment:16 in reply to:  15 ; Changed 8 weeks ago by teor

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.)

comment:17 in reply to:  16 Changed 8 weeks ago by arma

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. :)

Note: See TracTickets for help on using tickets.