Opened 7 years ago

Last modified 2 weeks ago

#5304 needs_review defect

Obfsproxy should respect OutboundBindAddress in torrc

Reported by: korobkov Owned by:
Priority: Medium Milestone:
Component: Circumvention/Obfs4 Version:
Severity: Normal Keywords: needs-spec-change needs-tor-change, anti-censorship-roadmap
Cc: Actual Points: 1.25
Parent ID: #30471 Points: 1
Reviewer: phw Sponsor: Sponsor28-must

Description

Rather it just binds to * (any IP).

Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.

Child Tickets

Change History (34)

comment:1 Changed 5 years ago by asn

Resolution: wontfix
Status: newclosed

We have the torrc ServerTransportListenAddr directive these days.
It should work for this use case.

comment:2 Changed 5 years ago by arma

Isn't the ListenAddr dictate how to bind your listening connection, and outboundbindaddress dictates how to bind your outgoing connection? They sure sound like different things.

comment:3 Changed 5 years ago by asn

Keywords: needs-spec-change needs-tor-change added
Resolution: wontfix
Status: closedreopened

Ah, indeed.
This sounds like a legitimate use case then.

We will probably need a pt-spec.txt change for this. TOR_PT_SERVER_BINDADDR specifies the listening bind address.

comment:4 Changed 20 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

comment:5 Changed 6 months ago by teor

Owner: asn deleted
Status: reopenedassigned

asn does not need to own any obfuscation tickets any more. Default owners are trouble.

comment:6 Changed 5 months ago by cohosh

Status: assignednew

tickets are unassigned, reverting to 'new'

comment:7 Changed 2 months ago by arma

Component: Archived/ObfsproxyCircumvention/Obfs4

rescuing a ticket that still matters.

we would also need a way for the parent (tor) to tell the child (obfsproxy) about this request.

comment:8 Changed 2 months ago by ahf

Keywords: sponsor19-can added
Sponsor: Sponsor19

comment:9 Changed 2 months ago by ahf

There should also be an option for clients, since clients are also used for HS operators (which are more server-like).

comment:10 Changed 2 months ago by arma

Sounds like it could be the same option for both clients and server side, but we would want to pick a more general name than FOO_SERVER_BAR.

For example, something like TOR_PT_OUTBOUND_BIND_ADDRESS would be an ok color for the bike shed.

comment:11 Changed 2 months ago by ahf

But it's not just for binding it is also for being used as source address for outgoing connections. Maybe TOR_PT_OUTBOUND_ADDRESS ?

comment:12 Changed 2 months ago by phw

Parent ID: #30471

comment:13 in reply to:  11 ; Changed 2 months ago by phw

Replying to ahf:

But it's not just for binding it is also for being used as source address for outgoing connections. Maybe TOR_PT_OUTBOUND_ADDRESS ?

I don't follow: isn't "use this address for an outgoing connection" also called "binding"? And that's why we call it OutboundBindAddress in tor?

comment:14 in reply to:  13 Changed 2 months ago by ahf

Replying to phw:

I don't follow: isn't "use this address for an outgoing connection" also called "binding"? And that's why we call it OutboundBindAddress in tor?

You are right. I think I thought we had another option similar to this that didn't have Bind in its name. It looks like we don't.

comment:15 Changed 2 months ago by ahf

Actual Points: 0.2
Points: 1
Status: newneeds_review

Added a spec patch here: https://github.com/ahf/torspec/commit/c5ed6c20a9c38c15bae61821d81a97bc79e59b9c

Asking phw and dcf on IRC if one of them is up for reviewing.

comment:16 in reply to:  15 ; Changed 2 months ago by phw

Replying to ahf:

Added a spec patch here: https://github.com/ahf/torspec/commit/c5ed6c20a9c38c15bae61821d81a97bc79e59b9c

Asking phw and dcf on IRC if one of them is up for reviewing.

I have three minor remarks that I left as comments in your GitHub patch. Other than that, it looks good to me!

One more question: Do we currently have any PTs where the server proxy could use this feature? As I understand, in all our deployed PTs, only the client proxies are making outgoing connections.

comment:17 in reply to:  16 Changed 2 months ago by ahf

Replying to phw:

I have three minor remarks that I left as comments in your GitHub patch. Other than that, it looks good to me!

Should be fixed with https://github.com/ahf/torspec/commit/18fead7a8b968107df0b39ca241d758a162db919

One more question: Do we currently have any PTs where the server proxy could use this feature? As I understand, in all our deployed PTs, only the client proxies are making outgoing connections.

I don't think we do right now, no.

comment:18 Changed 2 months ago by ahf

Reviewer: phw

comment:19 Changed 2 months ago by dcf

Does tor need to care whether the PT proxy understands/honors TOR_PT_OUTBOUND_BIND_ADDRESS? tor can set the variable but it will be ignored by every existing PT proxy. If it's a critical for tor to know whether the variable is being honored, then, there could be an acknowledgement message along the lines of PROXY OK.

comment:20 Changed 2 months ago by ahf

I don't think it's needed for us to receive an acknowledgement from the PT that it will honor it. In the ideal world PT's would be sandboxed somehow where we could easily spot if they don't honor it, but we are not there yet.

comment:21 Changed 2 months ago by teor

Status: needs_reviewneeds_revision

There's only one env var for bind addresses. But the Tor configuration allows an IPv4 and an IPv6 bind address. If a pluggable transport makes both IPv4 and IPv6 connections, it will need both addresses. I suggest we create two variables, _V4 and _V6.

comment:22 Changed 2 months ago by ahf

Good point, Teor. The current design only allows you to specify either an IPv4 address or an IPv6 address.

I'll revise the spec change to V4/V6 variants of the variable. Thanks!

comment:23 Changed 2 months ago by ahf

Actual Points: 0.20.25
Status: needs_revisionneeds_review

comment:24 Changed 2 months ago by teor

Just one grammar nitpick: "IPv6 loopback address". I made a comment on the commit.

Otherwise it looks good to me.
Thanks for using documentation IP address ranges!

comment:26 Changed 6 weeks ago by phw

Status: needs_reviewmerge_ready

Looks good, thanks ahf.

comment:27 Changed 6 weeks ago by phw

Sponsor: Sponsor19Sponsor28-must

Moving from Sponsor 19 to Sponsor 28.

comment:28 Changed 5 weeks ago by gaba

Keywords: anti-censorship-roadmap added; sponsor19-can removed

comment:29 Changed 2 weeks ago by ahf

Actual Points: 0.251.25
Status: merge_readyneeds_review

Added implementation for Tor in https://github.com/torproject/tor/pull/1164

This implementation should reflect the spec changes that have already been reviewed by phw and teor in https://github.com/ahf/torspec/compare/bugs/5304

comment:30 Changed 2 weeks ago by 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

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. This could be something to be handled at the level of the individual transport implementation, not globally at the level of the PT spec.

comment:31 in reply to:  30 ; Changed 2 weeks ago by teor

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

Replying to 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.

comment:32 Changed 2 weeks ago by teor

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

But since the user can only set one value for each environmental variable, we should treat an unqualified address as applying to every transport that isn't named.

So we would end up with something like:

TOR_PT_OUTBOUND_BIND_ADDRESS_V4=obfs4-0.0.0.0,snowflake-203.0.113.4,203.0.113.2

I'm not sure if we need this level of complexity in our implementation?
We could put transport-qualified addresses in the spec, but avoid implementing them until we actually have some demand for them.

comment:33 in reply to:  32 Changed 2 weeks ago by ahf

Replying to teor:

But since the user can only set one value for each environmental variable, we should treat an unqualified address as applying to every transport that isn't named.

So we would end up with something like:

TOR_PT_OUTBOUND_BIND_ADDRESS_V4=obfs4-0.0.0.0,snowflake-203.0.113.4,203.0.113.2

I'm not sure if we need this level of complexity in our implementation?
We could put transport-qualified addresses in the spec, but avoid implementing them until we actually have some demand for them.

I also don't see much sense in implementing this additional complexity and this was considered when the spec change was proposed.

For Tor clients I cannot think of any use case where you want to have multiple different source addresses for different transports since most people will have up to two different IP's, at max, per family (wifi/ethernet, whonix internal/external IP in Qubes, internal/external interface on a router).

For Tor bridges: I think everybody who wants to run multiple transports would be much better off running multiple instances of Tor itself with a single transport enabled given that they then get access to statistics and other useful information on how their bridge is doing. Or what am I missing here?

comment:34 in reply to:  31 Changed 2 weeks ago by dcf

Replying to teor:

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.

I'm sorry, I misunderstood what this was about, especially regarding address versus port. I should not have commented.

Note: See TracTickets for help on using tickets.