> On 2 Nov. 2016, at 13:38, teor <teor2...@gmail.com> wrote: > >> >> On 2 Nov. 2016, at 12:23, David Fifield <da...@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.
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@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
