[tor-relays] Multiple ServerTransportListenAddr OBFS2|3|4 Configuration

All:

I noticed that the obfs2, obfs3, and obfs4 transport names seem to be hardcoded into tor.

I have been able to configure the torrc to register each of the transports for multiple ServerTransportListenAddr:

# cat torrc
ORPort xxx.xxx.xxx.xxx:443 NoListen
ORPort 192.168.0.31:9001 NoAdvertise
SocksPort 9050
SocksPort 192.168.0.31:9050
ControlPort 9051
HTTPTunnelPort 9080
HTTPTunnelPort 192.168.0.31:9080
ExtORPort 192.168.0.31:auto
BridgeRelay 1
BridgeDistribution moat
ServerTransportPlugin obfs2 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs2 192.168.0.31:3102
ServerTransportOptions obfs2 iat-mode=2
ServerTransportPlugin obfs3 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs3 192.168.0.31:3103
ServerTransportOptions obfs3 iat-mode=2
ServerTransportPlugin obfs4 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs4 192.168.0.31:3104
ServerTransportOptions obfs4 iat-mode=2
DirCache 1
ExitRelay 0

# grep -i obfs ./torlog
2022/12/14 00:39:07 [NOTICE]: obfs4proxy-0.0.14 - launched
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs2' at '192.168.0.31:3102'
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs3' at '192.168.0.31:3103'
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs4' at '192.168.0.31:3104'

# netstat -anp | grep obfs4proxy
tcp 0 0 192.168.0.31:3102 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3103 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3104 0.0.0.0:* LISTEN 30185/obfs4proxy

My question is whether the respective obfs2|3|4 transport names force the corresponding protocol?

If so... Are there any ServerTransportOptions that can force the obfs4 protocol on the legacy obfs2|3 transports?

Also... It wasn't clear in the manual whether obfs4proxy -enableLogging takes an optional path/file?

I appreciate any knowledge on the subjects.

Respectfully,

Gary

···

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

Hi,

I noticed that the obfs2, obfs3, and obfs4 transport names seem to be hardcoded into tor.

obfs2/3/4 has no special meaning to tor. In fact if you grep the
codebase, you'll find obfs2 and obfs4 appears only in comments and
tests, and obfs3 doesn't show up.
The ability of obfs4proxy to work as obfs2 and obfs3 is its own
feature, outside of tor. From https://github.com/Yawning/obfs4:

As an added bonus, obfs4proxy also supports acting as an obfs2/3 client and bridge to ease the transition to the new protocol.

My question is whether the respective obfs2|3|4 transport names force the corresponding protocol?

It does force the use of the protocol you specified, or at least it
should and if it doesn't, that's a bug to report. You can quickly
check this by connecting to an obfs4 bridge while saying it's obfs3:
tor won't bootstrap.

Also... It wasn't clear in the manual whether obfs4proxy -enableLogging takes an optional path/file?

It doesn't, logs are stored in $TOR_PT_STATE_LOCATION/obfs4proxy.log
(usually that would be /var/lib/tor/pt_state/obfs4proxy.log)

Regards,

trinity-1686a

···

On Wed, 14 Dec 2022 at 10:02, Gary C. New via tor-relays <tor-relays@lists.torproject.org> wrote:

All:

I noticed that the obfs2, obfs3, and obfs4 transport names seem to be hardcoded into tor.

I have been able to configure the torrc to register each of the transports for multiple ServerTransportListenAddr:

# cat torrc
ORPort xxx.xxx.xxx.xxx:443 NoListen
ORPort 192.168.0.31:9001 NoAdvertise
SocksPort 9050
SocksPort 192.168.0.31:9050
ControlPort 9051
HTTPTunnelPort 9080
HTTPTunnelPort 192.168.0.31:9080
ExtORPort 192.168.0.31:auto
BridgeRelay 1
BridgeDistribution moat
ServerTransportPlugin obfs2 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs2 192.168.0.31:3102
ServerTransportOptions obfs2 iat-mode=2
ServerTransportPlugin obfs3 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs3 192.168.0.31:3103
ServerTransportOptions obfs3 iat-mode=2
ServerTransportPlugin obfs4 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs4 192.168.0.31:3104
ServerTransportOptions obfs4 iat-mode=2
DirCache 1
ExitRelay 0

# grep -i obfs ./torlog
2022/12/14 00:39:07 [NOTICE]: obfs4proxy-0.0.14 - launched
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs2' at '192.168.0.31:3102'
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs3' at '192.168.0.31:3103'
Dec 13 17:41:48.000 [notice] Registered server transport 'obfs4' at '192.168.0.31:3104'

# netstat -anp | grep obfs4proxy
tcp 0 0 192.168.0.31:3102 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3103 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3104 0.0.0.0:* LISTEN 30185/obfs4proxy

My question is whether the respective obfs2|3|4 transport names force the corresponding protocol?

If so... Are there any ServerTransportOptions that can force the obfs4 protocol on the legacy obfs2|3 transports?

Also... It wasn't clear in the manual whether obfs4proxy -enableLogging takes an optional path/file?

I appreciate any knowledge on the subjects.

Respectfully,

Gary
_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page

_______________________________________________
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

1 Like

Hi trinity!

As an added bonus, obfs4proxy also supports acting as an obfs2/3 client and bridge to ease the transition to the new protocol.

My question is whether the respective obfs2|3|4 transport names force the corresponding protocol?

It does force the use of the protocol you specified, or at least it
should and if it doesn’t, that’s a bug to report. You can quickly
check this by connecting to an obfs4 bridge while saying it’s obfs3:
tor won’t bootstrap.

Your recommended testing confirms that the “transport” portion of the ServerTransportListenAddr directive is an actual option passed and recognized by obfs4proxy (not just a label).

This point was made confusing by the “Example: ServerTransportOptions obfs45 shared-secret=bridgepasswd cache=/var/lib/tor/cache” in the Tor manual. Notice the “obfs45” transport, which errors with “[warn] Server managed proxy encountered a method error. (obfs45 no such transport is supported).” I’m assuming this is a typo in the Tor manual?

Finally, it appears that BridgeDB hands-out the transport type with the ServerTransportListenAddr:Port and nullifies my attempts at providing multiple obfs4proxy listeners per Tor instance.

It’s unfortunate that only a single ServerTransportListenAddr:Port can be spawned per Transport per Tor instance. Hopefully, this will be remedied in Arti.

Also… It wasn’t clear in the manual whether obfs4proxy -enableLogging takes an optional path/file?

It doesn’t, logs are stored in $TOR_PT_STATE_LOCATION/obfs4proxy.log
(usually that would be /var/lib/tor/pt_state/obfs4proxy.log)

I appreciate you confirming the obfs4proxy -enableLogging question as well. It seems like a symlink will have to do.

Thank you for your time and assistance.

Respectfully,

Gary

···

On Wednesday, December 14, 2022, 02:55:05 AM MST, trinity pointard trinity.pointard@gmail.com wrote:

On Wed, 14 Dec 2022 at 10:02, Gary C. New via tor-relays tor-relays@lists.torproject.org wrote:

All:

I noticed that the obfs2, obfs3, and obfs4 transport names seem to be hardcoded into tor.

I have been able to configure the torrc to register each of the transports for multiple ServerTransportListenAddr:

cat torrc

ORPort xxx.xxx.xxx.xxx:443 NoListen
ORPort 192.168.0.31:9001 NoAdvertise
SocksPort 9050
SocksPort 192.168.0.31:9050
ControlPort 9051
HTTPTunnelPort 9080
HTTPTunnelPort 192.168.0.31:9080
ExtORPort 192.168.0.31:auto
BridgeRelay 1
BridgeDistribution moat
ServerTransportPlugin obfs2 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs2 192.168.0.31:3102
ServerTransportOptions obfs2 iat-mode=2
ServerTransportPlugin obfs3 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs3 192.168.0.31:3103
ServerTransportOptions obfs3 iat-mode=2
ServerTransportPlugin obfs4 exec /opt/bin/obfs4proxy -enableLogging
ServerTransportListenAddr obfs4 192.168.0.31:3104
ServerTransportOptions obfs4 iat-mode=2
DirCache 1
ExitRelay 0

grep -i obfs ./torlog

2022/12/14 00:39:07 [NOTICE]: obfs4proxy-0.0.14 - launched
Dec 13 17:41:48.000 [notice] Registered server transport ‘obfs2’ at ‘192.168.0.31:3102’
Dec 13 17:41:48.000 [notice] Registered server transport ‘obfs3’ at ‘192.168.0.31:3103’
Dec 13 17:41:48.000 [notice] Registered server transport ‘obfs4’ at ‘192.168.0.31:3104’

netstat -anp | grep obfs4proxy

tcp 0 0 192.168.0.31:3102 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3103 0.0.0.0:* LISTEN 30185/obfs4proxy
tcp 0 0 192.168.0.31:3104 0.0.0.0:* LISTEN 30185/obfs4proxy

My question is whether the respective obfs2|3|4 transport names force the corresponding protocol?

If so… Are there any ServerTransportOptions that can force the obfs4 protocol on the legacy obfs2|3 transports?

Also… It wasn’t clear in the manual whether obfs4proxy -enableLogging takes an optional path/file?

I appreciate any knowledge on the subjects.

Respectfully,

Gary


tor-relays mailing list
tor-relays@lists.torproject.org
tor-relays Info Page


tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays