On 2 Nov. 2016, at 12:23, David Fifield david@bamsoftware.com wrote:

Someone on #tor-project IRC reported that you can bypass your pluggable transport if you use the fingerprint of an ordinary relay already known to Tor in your bridge line. I would file a ticket but I haven't been able to reproduce it.

The example the IRC user gave was this, meant to be pasted into Tor Browser as a custom bridge: Bridge meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com The fingerprint is the wrong one for this bridge. It should be B9E7141C594AF25699E0079C1F0146F409495296 for the bridge nicknamed TorLandMeek. It is instead for the relay nicknamed traffic70 at 188.138.1.166:9001.

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. I used this torrc file:

DataDirectory datadir UseBridges 1 Bridge meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com ClientTransportPlugin meek exec ./meek-client --log meek-client.log

First I tried with a cold cache, and got a fingerprint mismatch:

Nov 01 18:00:53.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Nov 01 18:00:54.000 [warn] Tried connecting to router at 0.0.2.0:2, but identity key was not as expected: wanted 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 but got B9E7141C594AF25699E0079C1F0146F409495296. Nov 01 18:00:54.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 at 0.0.2.0:2)

Then I commented out "UseBridges 1", let the bootstrap finish, and uncommented "Use Bridges 1" again. I got the same output:

Nov 01 18:05:06.000 [notice] Bootstrapped 10%: Finishing handshake with directory server Nov 01 18:05:09.000 [warn] Tried connecting to router at 0.0.2.0:2, but identity key was not as expected: wanted 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 but got B9E7141C594AF25699E0079C1F0146F409495296. Nov 01 18:05:09.000 [warn] Problem bootstrapping. Stuck at 10%: Finishing handshake with directory server. (Unexpected identity in router certificate; IDENTITY; count 1; recommendation warn; host 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 at 0.0.2.0:2)

I used tcpdump to check for connections to 188.138.1.166, and didn't see any.

I suspect this user might be on 0.2.7 or earlier. Or they are changing UseBridges over the control port using SETCONF.

In 0.2.8, we made all client connections use begindir, which causes the "unexpected identity" error. We also changed how node addresses are looked up, and how proxy / transport addresses are connected to. I think this mitigates this bug somewhat.

But it's certainly plausible, so we should reload the consensus (which resets nodes and guards) when bridges are reconfigured.

We should probably do the same when authorities or fallbacks are changed, too.

T

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