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

[teor <teor2345@xxxxxxxxx>]

> On 2 Nov. 2016, at 13:38, teor <teor2345@xxxxxxxxx> wrote:
> 
>> 
>> On 2 Nov. 2016, at 12:23, David Fifield <david@xxxxxxxxxxxxxxx> 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.

Logged as #20528, with a WIP patch:
https://trac.torproject.org/projects/tor/ticket/20528

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



_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev