[tor-relays] obfs4 bridge current setup is not entirely clear

[s7r]

Hi,

I ran into some new IP space and I decided to change a cluster of obfs4 
bridges that are more than 4 year old. When I set them up I don't 
remember spending so much time.

So, Debian latest and Tor latest from deb.torproject.org nightly.

GoLang from the official website (as it's the latest version) and 
obfs4proxy cloned from its default git repository.

1. The page at 
https://community.torproject.org/relay/setup/bridge/debian-ubuntu/ needs 
a small revision.

This page must be changed, for Debian it doesn't work simply $ edit 
tor at .service tor at default.service , change to NoNewPrivileges=no, save 
and quit.

For me it only worked by editing
/lib/systemd/system/tor at .service and 
/lib/systemd/system/tor at default.service with NoNewPrivileges=no and then:

$ sudo systemctl daemon-reload.

Setcap command is ok but it also need to mention to install the package 
in Debian libcap2-bin as well as an additional step:

Under Debian, if obfs4proxy is installed in a different place, for 
example like in its git documentation /usr/local/bin/obfs4proxy then you 
also need to edit this file:

/etc/apparmor.d/abstractions/tor

and add one line (or change the default obfs4proxy line to):

   /usr/local/bin/obfs4proxy Pix,

Substitute path if different and then:
$ sudo systemctl restart apparmor.
------------------------------------------------


2. It was recommended on the mail list that obfs4 bridges should not 
open their ORPorts publicly to prevent scanning the entire 1-65536 port 
range and determine it's a Tor bridge. OK.

But if you try:

ORPort 127.0.0.1:auto
ORPort [::1]:auto
AssumeReachable 1 # needed to skip ORPort reachability test

Tor will start but it will constantly complain in the log with:

[warn] The IPv4 ORPort address 127.0.0.1 does not match the descriptor 
address REAL_IPv4_ADDRESS. If you have a static public IPv4 address, use 
'Address <IPv4>' and 'OutboundBindAddress <IPv4>'. If you are behind a 
NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort 
<InternalPort> NoAdvertise'.

[warn] The IPv6 ORPort address ::1 does not match the descriptor address 
REAL_IPv6_ADDRESS. If you have a static public IPv4 address, use 
'Address <IPv6>' and 'OutboundBindAddress <IPv6>'. If you are behind a 
NAT, use two ORPort lines: 'ORPort <PublicPort> NoListen' and 'ORPort 
<InternalPort> NoAdvertise'.

I guess it's OK to continue to run it even with this as I do understand 
the log messages and it's the desired effect, but isn't it confusing for 
less experienced users? They might think something is wrong when it is not.

The recommended way is to add a simple logic to skip that check, because 
we can't remove it, it's vital necessary for relays (not bridges) behind 
NAT or dynDNS or whatever. So if BridgeRelay 1 is set and 
$some_transport enabled, ignore the ORPort and descriptor check / log. 
and instead check the pluggable transport if port open and listening.

Or even better, code a pluggable transport port reachability test before 
building and uploading the descriptor, by cloning the code that does 
this for ORPorts to the pluggable transport ports. This would need a 
proposal that covers all use cases.


3. ServerTransportListenAddr can be used just once and it's difficult 
for dual-stack which is now the vast majority.

It's known for many years that each pluggable transport supports just 
one ServerTransportListenAddr line, the second one is simply ignored. 
Tickets for this exist.

So what is the best way to for an user to open both IPv4 and IPv6 
pluggable transport ports?

In Debian I have achieved it by using as wildcard 
ServerTransportListenAddr [::]:80 since the wildcard [::] under Debian 
binds to all IPv4 and IPv6 addresses on all interfaces, but this might 
not be the same for all operating systems.

Also, how does BridgeDB determine in case wildcard [::] is used if the 
pluggable transport is IPv4, IPv6 or both? Which one is used when 
BridgeDB sends this bridge to clients?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-relays/attachments/20231108/416cc8d8/attachment.sig>