I have recently set up a bridge and was reading some old emails on the list. I found some instructions from s7r on setting up obfs4 and obfs3:
Sample torrc entry for enabling obfs4 and obfs3: ExtORPort auto ServerTransportPlugin obfs3,obfs4 exec /usr/bin/obfs4proxy ServerTransportListenAddr obfs3 [::]:port ServerTransportListenAddr obfs4 [::]:port
To make the bridge even better, you can bind obfs3 and obfs4 to lower ports (< 1024), if you have them free, such as obfs3 on 80 and obfs4 on 443 (for example).
This seemed like a good idea (I am not running a web server).
I am running tor 0.2.4.27, which does not seem to support ExtORPort. From some other recommended bridge setup I had previously set ORPort to 443. I tried changing my config to:
ORPort auto ServerTransportListenAddr obfs3 0.0.0.0:80 ServerTransportListenAddr obfs4 0.0.0.0:443
(and doing the capabilities stuff, of course).
This didn't work -- obfs4 complained that 443 was in use (is that because I had previously set it for ORPort?). So, for now, I have set obfs4 to a random high port.
I will admit to being pretty confused about the recommended bridge setting for ORPort and the obfs ports (and what ExtORPort does differently). Does anyone have a recommendation for what I should do? Do I need to upgrade to tor 0.2.5?
On Tue, 05 May 2015 13:51:34 +0100 R-one r1@cryptoisimportantto.me wrote:
[snip]
This didn't work -- obfs4 complained that 443 was in use (is that because I had previously set it for ORPort?). So, for now, I have set obfs4 to a random high port.
I will admit to being pretty confused about the recommended bridge setting for ORPort and the obfs ports (and what ExtORPort does differently). Does anyone have a recommendation for what I should do? Do I need to upgrade to tor 0.2.5?
ORPort should be sent to something random, that is externally reachable and not in use by anything else.
ExtORPort should be set to "auto", it only listens on the loopback interface, so it doesn't need external reachability.
The obfs ports can be unset (No ServerTransportListenAddr line) in which case they will be random, or set to specific ports to attempt to bypass naive attempts at protocol whitelisting.
You need to upgrade to tor 0.2.5.x or later to be a useful obfs4 bridge period because Bridges running 0.2.4.x will publish broken bridge configurations to BridgeDB, and will not ever get served to users. (Yes, tor should log a warning whenever such situations occur, see #13202 for people shooting that idea down when I first brought it up a long time ago.)
No idea about the port already in use thing. Check the processes on the system to see if you have a defunct obfs4proxy instance hanging around (obfs4proxy 0.0.5 makes this less likely to happen).
Regards,
tor-relays@lists.torproject.org