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