Make sure directory_initiate_request handles pluggable transports correctly

When a relay is configured as a bridge, a user reports this can lead to direct connections being made to the relay/bridge, even when a pluggable transport is configured. We have been unable to confirm this.

​https://lists.torproject.org/pipermail/tor-dev/2016-November/011618.html

We should check directory_initiate_command_rend (the linked connection case), and connection_or_connect to make sure it is not possible for a connection to go directly to a configured bridge when a transport is set up.

changed milestone to %Tor: 0.3.2.x-final

added 031-backport bridge-bypass bridge-client component::core tor/tor milestone::Tor: 0.3.2.x-final owner::catalyst points::2 priority::high resolution::fixed severity::normal sponsor::M status::closed type::defect labels

We have been unable to confirm this

So you need to close ticket as invalid or not a bug.

Assigning this to 0.3.0 since a bridge bypass is important to fix.

(Also seems like #20528 (moved) and #20531 (moved) are related tickets)

Trac:
Milestone: Tor: 0.2.??? to Tor: 0.3.0.x-final

A further update from irc:

consensus updates rs
and client using infor from ri
it's about ipv6
not about generic conflict
...
it is when you paste meek bridge line and using plain tor relay
...
start tcpdump and watch for ip.addr == 188.138.1.166
then with green onion menu
chose tor network setting, choose to use bridge, custom
and paster
meek 0.0.2.0:2 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554 url=https://d2zfqthxsdq309.cloudfront.net/ front=a0.awsstatic.com
it's fp for it
it should to fail sometime during connections
tor using this p to get extend info for desc fetching
*fp
if knows such relay it using relay addr
insead of pt

188.138.1.166 is the direct address of the relay 3C3A6134E4B5B7D1C18AD4E86EE23FAC63866554, not the transport address of https://d2zfqthxsdq309.cloudfront.net/

(asn has confirmed this on irc)

Triaged out on December 2016 from 030 to 031.

Trac:
Milestone: Tor: 0.3.0.x-final to Tor: 0.3.1.x-final
Keywords: N/A deleted, triage-out-030-201612 added

Trac:
Priority: Medium to High
Points: N/A to 2

So hrm, that function name doesn't exists anymore so renaming to the new one.

Trac:
Summary: Make sure directory_initiate_command_rend handles pluggable transports correctly to Make sure directory_initiate_request handles pluggable transports correctly

Can somebody summarize what the issue is? Maybe asn can, since he confirmed it?

(I agree, on first glance #20531 (moved) is worth checking.)

Trac:
Keywords: triage-out-030-201612 deleted, N/A added

Trac:
Status: new to accepted
Owner: N/A to catalyst

Reproduced roughly as follows:

• Start Tor Browser 7.5a1 with default config
• Load a page
• Find a vanilla relay in cached-microdesc-consensus
• Convert its fingerprint to hexadecimal
• Start tcpdump matching on that relay's IP address
• Go to about:config and copy the meek-amazon config value
• Go to Tor Network Settings and paste that as a custom bridge, but replace its fingerprint with the hexadecimal fingerprint of the vanilla relay as converted above
• Select New Tor Circuit for this Site
• Watch as tcpdump shows inappropriate traffic flows to the vanilla relay

Trac:
Cc: N/A to asn

Based on IRC discussion, #22739 (moved) is probably the correct long-term solution. #16564 (moved) is also relevant.

Can somebody try to reproduce this using the steps that catalyst lists above?

I can confirm this behavior using catalyst's steps exactly. I chose to target an exit I run and thus ended up with the following bridge line

meek 0.0.2.0:2 09fa8b4f665ad65d2c2a49870f1aa3ba8811e449 url=https://d2cly7j4zqgua7.cloudfront.net/ front=a0.awsstatic.com

The page was able to load. The circuit viewer under the onion button reports I'm using a meek bridge, but I'm obviously not as tcpdump host 216.218.222.12 outputs.

Trac:
Sponsor: N/A to SponsorM

Patch for 0.3.1 at https://oniongit.eu/catalyst/tor/merge_requests/13 and it looks like it should merge cleanly with anything newer.

Patches for the other stable releases are on the branches bug20532_030, bug20532_029, and bug20532_025.

Trac:
Status: accepted to needs_review

Looks plausible! Is this tested? If so, I say we merge it to 0.3.2, and (barring misadventure) backport it in the next 0.3.1 release (not the one from tomorrow).

Merging to 0.3.2 and forward; marking for potential backport.

Trac:
Status: needs_review to merge_ready

I tested this manually on 0.3.1 and 0.3.0. I can't seem to reproduce the original bug on 0.2.9, but I'm not sure that means the bug doesn't exist there. Notably, 0.2.9 predates some large changes in the guard subsystem.

I think we're willing to consider the hypothesis that the guard work in 0.3.0 caused this bug to surface so we probably don't need to backport it to 0.2.9.

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.0.x-final

Replying to catalyst:

I think we're willing to consider the hypothesis that the guard work in 0.3.0 caused this bug to surface so we probably don't need to backport it to 0.2.9.

#23975 (moved) will address another root cause, by only checking routerinfo addresses for configured bridges.

Move all still-open 0.3.0 tickets to 0.2.9

Trac:
Milestone: Tor: 0.3.0.x-final to N/A

Trac:
Milestone: N/A to Tor: 0.2.9.x-final

Trac:
Keywords: N/A deleted, 031-backport added
Milestone: Tor: 0.2.9.x-final to Tor: 0.3.1.x-final

0.3.1 is now EOL. No further backport.

Trac:
Milestone: Tor: 0.3.1.x-final to Tor: 0.3.2.x-final

If we don't think we need to merge this to 0.2.9, it should be closed. I un-parented the child ticket.

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

closed

changed time estimate to 16h

mentioned in issue #24020 (moved)

mentioned in issue #25528 (moved)

moved to tpo/core/tor#20532 (closed)

mentioned in issue tpo/core/tor#25528 (closed)