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