[tor-dev] Using fingerprint of cached relay bypasses bridge?

[Roger Dingledine]

On Tue, Nov 01, 2016 at 06:23:55PM -0700, David Fifield wrote:
> The claim is that if tor has already cached a descriptor with
> fingerprint 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554, then it will make
> a direct connection for the purpose of making a one-hop circuit. "it's
> about one hop tunnel when exit is entry" says the IRC user. They point
> to these parts of the source code:
> 
> https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c?id=tor-0.2.8.9#n2010
> 	r = node_get_by_nickname(conn->chosen_exit_name, 1);
> https://gitweb.torproject.org/tor.git/tree/src/or/circuituse.c?id=tor-0.2.8.9#n2015
> 	extend_info = extend_info_from_node(r, conn->want_onehop ? 1 : 0);
> 
> I wasn't able to reproduce it.

How about if you leave your Tor running, and it fetches a new consensus?
Then the routerstatus for that node gets updated, and it clobbers the
hack that rewrite_node_address_for_bridge() did on the node_t's address.

That is, when your Tor client fetches the descriptor for its bridge,
it calls rewrite_node_address_for_bridge() to rewrite what address it
thinks the bridge claims it's at -- that's how your client handles the
case where the bridge descriptor says one IP address, and the bridge
torrc line says a different one. We assume that you want to keep reaching
it at the address on your bridge torrc line, so every time we fetch the
descriptor, we reach in and pretend that the bridge just told you it's
on the address from your torrc line.

That hack is all fine and good except if the bridge happens to be a
public relay in the consensus, because then we have two competing ways
of updating info about it: first we have the descriptors you fetch from
it every hour or so as a bridge, and second we have the information
that you learn about it from each new consensus (every 2-4 hours). And
it seems plausible that there's a race condition where if the consensus
info is the more recent winner, then we'll accidentally use the address
in the consensus when reaching out to the bridge.

There are still some missing pieces to my theory though. The biggest one
is: how would your Tor client proceed past the fingerprint complaint?
That is, Tor will never get to actually fetching a bridge descriptor,
because the fingerprint of the bridge will be wrong so it will stop.
Maybe there is some edge case you can arrange where you had the right
fingerprint on the last run, so you have the descriptor already at boot?
Or maybe you do a setconf of the bridge line while your Tor is running?

Hm. I hope these further hints might be useful. :)

--Roger