Opened 7 years ago

Last modified 2 days 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, sponsor19-can
Cc: Actual Points: 0.25
Parent ID: #30471 Points: 1
Reviewer: phw Sponsor: Sponsor19

Description

Rather it just binds to * (any IP).

Tested with latest git obfsproxy and Tor 0.2.3.12-alpha.

Child Tickets

Change History (25)

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 18 months ago by teor

Severity: Normal

Set all open tickets without a severity to "Normal"

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

Status: assignednew

tickets are unassigned, reverting to 'new'

comment:7 Changed 10 days 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 10 days ago by ahf

Keywords: sponsor19-can added
Sponsor: Sponsor19

comment:9 Changed 10 days 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 10 days 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 10 days 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 8 days ago by phw

Parent ID: #30471

comment:13 in reply to:  11 ; Changed 8 days 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 8 days 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 5 days 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 4 days 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 4 days 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 4 days ago by ahf

Reviewer: phw

comment:19 Changed 3 days 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 3 days 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 3 days 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 days 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 days ago by ahf

Actual Points: 0.20.25
Status: needs_revisionneeds_review

comment:24 Changed 2 days 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!

Note: See TracTickets for help on using tickets.