Opened 7 months ago

Last modified 7 days ago

#29128 new defect

Place complete obfs4 bridge line in accessible location

Reported by: phoul Owned by:
Priority: Medium Milestone: Tor: unspecified
Component: Core Tor/Tor Version:
Severity: Normal Keywords: tor-pt, tor-doc, 040-deferred-20190220, network-team-roadmap-november
Cc: cohosh, phw 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 (14)

comment:1 Changed 7 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 7 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 6 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 4 months ago by cohosh

Cc: cohosh added

A duplicate ticket #30331 was filed about this recently

comment:5 Changed 3 months ago by phw

Parent ID: #30471

comment:6 Changed 3 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 3 months ago by phw

Cc: phw added

comment:8 Changed 2 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 4 weeks 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 2 weeks ago by pili

Sponsor: Sponsor28

comment:11 in reply to:  9 ; Changed 10 days 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 days 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 7 days ago by gaba

Sponsor: Sponsor28Sponsor28-must

comment:14 Changed 7 days ago by gaba

Keywords: network-team-roadmap-november added
Note: See TracTickets for help on using tickets.