Opened 19 months ago

Last modified 11 months ago

#24020 new defect

Can authorities use multihop circuits rather than direct connections to detect running routers?

Reported by: nickm Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: durauth, bridge-bypass
Cc: catalyst Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


So, I had an item on the roadmap to "Ensure dirauths check for incoming authentication when verifying ORPorts, if easy".

Summary: It's not easy, but it's possible given effort.

So, it looks like dirauths don't check for incoming authentication at all when verifying ORPorts. All they do is look at the "last_reachable" or "last_reachable6" fields. Those fields are set from dirserv_orconn_tls_done(), which triggers when we complete an outgoing TLS handshake.

The reachability tests are launched with dirserv_single_reachability_test(), which only opens a channel -- it doesn't try to create a circuit at all.

If we want to do a test for _incoming_ authentication, it's possible, but we'd need to write some more machinery and think of a workaround for an issue (below). We would need to launch testing circuits through the targetted node, and notice whenever somebody authenticates to _us_ using the node's key. If the circuit succeeds but the node has performed no authentication to us, it must be a bridge. Such tests could be launched on a comparatively slow schedule.

There's one other problem with the make-an-incoming-circuit approach: I think that the authority will authenticate to the bridge with its outgoing connection, and so the bridge will already have an authority connection to the authority. I think that the bridge will, when asked to connect to the authority, use that connection instead of creating a new one. Two possible fixes: first, the bridge could stop asking for authentication on incoming connections. Second, the authority could stop providing authentication on outgoing testing connections that it launches for this purpose.

Child Tickets

Change History (5)

comment:1 Changed 19 months ago by arma

What's the goal? To be able to notice that a relay is acting like a bridge so we shouldn't list it?

Or to withhold the Running flag from relays that for whatever reason are failing to offer appropriate auth on tls conns that they initiate?

Or something else?

comment:2 Changed 19 months ago by nickm

What's the goal? To be able to notice that a relay is acting like a bridge so we shouldn't list it?

I think this was the original rationale here.

comment:3 Changed 19 months ago by nickm

Cc: catalyst added; asn removed

comment:4 Changed 11 months ago by teor

Parent ID: #20532

Un-parenting to close the parent ticket.

comment:5 Changed 11 months ago by teor

We can't rely on other relays to build circuits for authorities, unless the network has better load balancing. At the moment, high-weight relays fail a lot of circuits.

Note: See TracTickets for help on using tickets.