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
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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
On Wednesday, December 14, 2022, 02:55:05 AM MST, trinity pointard <trinity.pointard@gmail.com> wrote: 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 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 https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
_______________________________________________ tor-relays mailing list tor-relays@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays
participants (2)
-
Gary C. New -
trinity pointard