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

[teor]

> On 2 Nov. 2016, at 12:23, David Fifield <david at 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.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. 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

-- 
Tim Wilson-Brown (teor)

teor2345 at gmail dot com
PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B
ricochet:ekmygaiu4rzgsk6n
xmpp: teor at torproject dot org
------------------------------------------------------------------------------