Opened 19 months ago

Last modified 3 months ago

#20532 merge_ready defect

Make sure directory_initiate_request handles pluggable transports correctly

Reported by: teor Owned by: catalyst
Priority: High Milestone: Tor: 0.2.9.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: bridge-client, bridge-bypass
Cc: asn Actual Points:
Parent ID: Points: 2
Reviewer: Sponsor: SponsorM

Description

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.

Child Tickets

TicketStatusOwnerSummaryComponent
#24020newCan authorities use multihop circuits rather than direct connections to detect running routers?Core Tor/Tor

Change History (24)

comment:1 Changed 19 months ago by cypherpunks

We have been unable to confirm this

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

comment:2 Changed 19 months ago by asn

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

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

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

comment:3 Changed 19 months ago by teor

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/

comment:4 Changed 19 months ago by teor

(asn has confirmed this on irc)

comment:5 Changed 17 months ago by dgoulet

Keywords: triage-out-030-201612 added
Milestone: Tor: 0.3.0.x-finalTor: 0.3.1.x-final

Triaged out on December 2016 from 030 to 031.

comment:6 Changed 15 months ago by nickm

Points: 2
Priority: MediumHigh

comment:7 Changed 13 months ago by dgoulet

Summary: Make sure directory_initiate_command_rend handles pluggable transports correctlyMake sure directory_initiate_request handles pluggable transports correctly

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

comment:8 Changed 12 months ago by arma

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

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

comment:9 Changed 12 months ago by nickm

Keywords: triage-out-030-201612 removed

comment:10 Changed 11 months ago by catalyst

Owner: set to catalyst
Status: newaccepted

comment:11 Changed 11 months ago by 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

comment:12 Changed 11 months ago by asn

Cc: asn added

comment:13 Changed 11 months ago by catalyst

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

comment:14 Changed 11 months ago by nickm

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

comment:15 Changed 11 months ago by pastly

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.

Last edited 11 months ago by pastly (previous) (diff)

comment:16 Changed 10 months ago by catalyst

Sponsor: SponsorM

comment:17 Changed 7 months ago by catalyst

Status: acceptedneeds_review

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.

comment:18 Changed 7 months ago by nickm

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

comment:19 Changed 7 months ago by nickm

Status: needs_reviewmerge_ready

Merging to 0.3.2 and forward; marking for potential backport.

comment:20 Changed 7 months ago by catalyst

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.

comment:21 Changed 7 months ago by catalyst

Milestone: Tor: 0.3.1.x-finalTor: 0.3.0.x-final

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.

comment:22 in reply to:  21 Changed 7 months ago by teor

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 will address another root cause, by only checking routerinfo addresses for configured bridges.

comment:23 Changed 3 months ago by nickm

Milestone: Tor: 0.3.0.x-final

Move all still-open 0.3.0 tickets to 0.2.9

comment:24 Changed 3 months ago by nickm

Milestone: Tor: 0.2.9.x-final
Note: See TracTickets for help on using tickets.