Opened 17 months ago

Last modified 2 weeks ago

#29128 assigned defect

Place complete obfs4 bridge line in accessible location

Reported by: phoul Owned by: catalyst
Priority: Medium Milestone: Tor: 0.4.4.x-final
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-pt, tor-doc, 040-deferred-20190220, network-team-roadmap-2020Q1, network-team-roadmap-2020Q2 anticensorship-wants 044-should?
Cc: cohosh, phw, catalyst Actual Points:
Parent ID: #30471 Points:
Reviewer: Sponsor: Sponsor28-must

Description

Currently operators wanting to distribute or use personal obfs4 bridges must follow 5 steps:

  1. Determine their bridge's IP address
  2. Check logs for their bridge's fingerprint
  3. Check logs for which port obfs4 is running on
  4. Retrieve their obfs4 cert from /var/lib/tor/pt_state/obfs4_bridgeline.txt
  5. String the above together in the following format:
Bridge obfs4 <IP ADDRESS>:<PORT> <FINGERPRINT> cert=$FROMSTEP4 iat-mode=0

This can be a confusing process, and is only fully explained upon opening /var/lib/tor/pt_state/obfs4_bridgeline.txt; however it leaves filling in the fields (with the exception of the cert) to the user.

Having the complete bridge line placed somewhere accessible would make this process much less painful for operators.

Child Tickets

Change History (21)

comment:1 Changed 17 months ago by dgoulet

Keywords: tor-pt tor-doc added
Milestone: Tor: 0.4.0.x-final
Status: newneeds_information

What do you mean "accessible" here? If it is not in pt_state/ then it has to be at the very least at the root of the Tor data directory. Seems to me that we should probably update our documentation to tell the operator where to find that line?

comment:2 Changed 16 months ago by phoul

The complete line is not placed anywhere currently, only instructions for forming it yourself are present in /var/lib/tor/pt_state/obfs4_bridgeline.txt (and the cert portion of the bridge line).

This has caused confusion, and it was requested that the complete line be placed somewhere so operators can copy/paste without having to fill in the blanks on their own. It was also mentioned on IRC that it might be desirable to have this printed in the tor log, along with the other bridge details.

comment:3 Changed 16 months ago by nickm

Keywords: 040-deferred-20190220 added
Milestone: Tor: 0.4.0.x-finalTor: unspecified

Deferring 51 tickets from 0.4.0.x-final. Tagging them with 040-deferred-20190220 for visibility. These are the tickets that did not get 040-must, 040-can, or tor-ci.

comment:4 Changed 13 months ago by cohosh

Cc: cohosh added

A duplicate ticket #30331 was filed about this recently

comment:5 Changed 13 months ago by phw

Parent ID: #30471

comment:6 Changed 13 months ago by phw

Over in #30331, it was suggested to either log the full bridge line, or write it to something like $DATADIR/pt_state/bridgelines.txt, along with all other PTs that the bridge runs. The problem with a log message is that bridge operators may accidentally publish their bridge when they paste their logs, e.g., here on trac.

I suppose a bridge could write to bridgelines.txt before it publishes its descriptor because that's when all the necessary information is available?

comment:7 Changed 13 months ago by phw

Cc: phw added

comment:8 Changed 12 months ago by phw

We briefly discussed this in today's anti-censorship meeting. We believe that tor should create its bridge lines and write it to a file in its data directory, e.g., bridges-lines. We believe that pt_state/ should be reserved for pluggable transports.

comment:9 Changed 11 months ago by nickm

Is there a standardized way for Tor to learn from the PT which fields it should put in the Bridge line? It knows the fingerprint, and it has a good guess about the address field (though the PT may want to override that), but it usually needs the PT's help to learn the port and any other fields.

comment:10 Changed 10 months ago by pili

Sponsor: Sponsor28

comment:11 in reply to:  9 ; Changed 10 months ago by phw

Replying to nickm:

Is there a standardized way for Tor to learn from the PT which fields it should put in the Bridge line? It knows the fingerprint, and it has a good guess about the address field (though the PT may want to override that), but it usually needs the PT's help to learn the port and any other fields.


I believe that all we need is in the SMETHOD line that Tor reads from the PT proxy's stdout. Our pt-spec.txt documents its format as:

SMETHOD <transport> <address:port> [options]

Note that [options] will need a bit of processing because it's currently defined as ARGS:[<Key>=<Value>,]+[<Key>=<Value>].

comment:12 in reply to:  11 Changed 10 months ago by teor

Status: needs_informationnew

Replying to phw:

Replying to nickm:

Is there a standardized way for Tor to learn from the PT which fields it should put in the Bridge line? It knows the fingerprint, and it has a good guess about the address field (though the PT may want to override that), but it usually needs the PT's help to learn the port and any other fields.


I believe that all we need is in the SMETHOD line that Tor reads from the PT proxy's stdout.

The complete PT line is sent to bridge users by BridgeDB.
(That line *must* contain all the required information, otherwise bridge users wouldn't be able to use the bridge.)

BridgeDB gets bridge PT lines from bridge extra-info document "transport" lines:
https://gitweb.torproject.org/torspec.git/tree/dir-spec.txt#n1211

These lines come from pt_get_extra_info_descriptor_string(), which you should be able to just dump to a file:
https://github.com/torproject/tor/blob/989b6325d671744aacec191b181e8b0b0fee35be/src/feature/client/transports.c#L1613

comment:13 Changed 10 months ago by gaba

Sponsor: Sponsor28Sponsor28-must

comment:14 Changed 10 months ago by gaba

Keywords: network-team-roadmap-november added

comment:15 Changed 5 months ago by gaba

Keywords: network-team-roadmap-2020Q1 added; network-team-roadmap-november removed

comment:16 Changed 3 months ago by catalyst

Cc: catalyst added

comment:17 Changed 2 months ago by gaba

Owner: set to catalyst
Status: newassigned

comment:18 Changed 2 months ago by gaba

Keywords: network-team-roadmap-2020Q2 added

move tickets into the 2020 Q2 roadmap for the network team

comment:19 Changed 7 weeks ago by catalyst

Scope question: do we want to do this for non-PT bridges as well? More generally, any ideas about a reasonable stage of startup or periodic tasks to do it?

comment:20 Changed 7 weeks ago by teor

On IRC, catalyst said that pt_get_extra_info_descriptor_string() doesn't completely support IPv6. It looks like that's a known issue, see #7961.

For IPv6, you can use the router_get_advertised_ipv6_or_ap() function. But I'm not sure which tor version we added the function in.

See also #31009, where we replace internal IP addresses in descriptors, with the published IP address. We should make sure that fix also gets written to this file.

comment:21 Changed 2 weeks ago by nickm

Keywords: anticensorship-wants 044-should? added
Milestone: Tor: unspecifiedTor: 0.4.4.x-final
Note: See TracTickets for help on using tickets.