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