[tor-bugs] #5304 [Circumvention/Obfs4]: Obfsproxy should respect OutboundBindAddress in torrc

[Tor Bug Tracker & Wiki]

#5304: Obfsproxy should respect OutboundBindAddress in torrc
-------------------------------------------------+-------------------------
 Reporter:  korobkov                             |          Owner:  (none)
     Type:  defect                               |         Status:
                                                 |  needs_review
 Priority:  Medium                               |      Milestone:
Component:  Circumvention/Obfs4                  |        Version:
 Severity:  Normal                               |     Resolution:
 Keywords:  needs-spec-change needs-tor-change,  |  Actual Points:  1.25
  anti-censorship-roadmap                        |
Parent ID:  #30471                               |         Points:  1
 Reviewer:  phw                                  |        Sponsor:
                                                 |  Sponsor28-must
-------------------------------------------------+-------------------------

Comment (by teor):

 I did a review on the code, it looks good, but there's some code
 duplication we could avoid.

 Replying to [comment:30 dcf]:
 > It seems like `TOR_PT_OUTBOUND_BIND_ADDRESS_V*` should not be a single
 address, but should be tied to specific transport names, just like
 `TOR_PT_SERVER_BINDADDR` is. Otherwise there's no way to use different
 outbound addresses for different outbound transports, or set an outbound
 address for only one transport and let the other use the default.
 >
 > It would be good for implementation to reuse the
 `TOR_PT_SERVER_BINDADDR` syntax. Something like:
 > {{{
 > TOR_PT_OUTBOUND_BIND_ADDRESS_V4=obfs4-0.0.0.0:5000
 > }}}

 Tor doesn't support binding to outbound port, and neither does a lot of
 other software, because it's error-prone.
 Best to let the OS assign the port.

 As for using different IP addresses for each transport, sure, why not?

 > Remember that tor can run multiple transport plugins, and a transport
 plugin can run multiple transports. The PT spec already has the bug that
 you cannot run multiple instances of the same named transport with
 different options (because options are keyed by transport name); so it
 would be good to avoid making the problem worse with options that can only
 be specified globally.
 >
 > ----
 >
 > An alternative to extending the PT spec is to use per-connection
 arguments (on the client side), or SMETHOD ARGS: (on the server side).
 After all, the notion of a "port" or an "outbound address" only applies to
 a subset of notional transports.

 But outbound addresses are used by any transport that makes a TCP or UDP
 connection to a non-loopback address.
 Can you give an example of a transport that doesn't make these types of
 connections?

 (I can think of transports that use Unix domain sockets, but I'm not aware
 of any in production. And I'd expect there would be an IP connections
 somewhere along the way.)

 > This could be something to be handled at the level of the individual
 transport implementation, not globally at the level of the PT spec.

 The advantage of having it in the spec is that it's standardised.
 The advantage of using environmental variables is that the user can set
 them, even if the tor version doesn't support them.
 Env vars are particularly important for other apps that don't implement
 the latest spec.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/5304#comment:31>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online