Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
David Fifield david@bamsoftware.com writes:
[ text/plain ] Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
Hey David,
sounds like an easy idea worth trying.
I ran the above iptables command on LeifEricson. Let me know if it doesn't work.
I wonder why censors are afraid of blocking the whole IP address...
On 17 Aug 2016, at 00:14, George Kadianakis desnacked@riseup.net wrote:
David Fifield david@bamsoftware.com writes:
[ text/plain ] Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
Hey David,
sounds like an easy idea worth trying.
I ran the above iptables command on LeifEricson. Let me know if it doesn't work.
I wonder why censors are afraid of blocking the whole IP address…
Here's some speculation:
It could be situational: APNIC simply doesn't have that many IP addresses to go around, and Australia/NZ snarfed up a lot of them early on. So they may want to minimise blocking, to avoid impacting other services.
The simplest explanation is that they can identify IP/Port, and so they block IP/Port.
Tim
Tim Wilson-Brown (teor)
teor2345 at gmail dot com PGP C855 6CED 5D90 A0C5 29F6 4D43 450C BA7F 968F 094B ricochet:ekmygaiu4rzgsk6n xmpp: teor at torproject dot org
On Mon, Aug 15, 2016 at 09:45:05PM -0700, David Fifield wrote:
Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
The following bridges have each opened up 10 additional obfs4 ports, through which we can begin rotating in the next release: LeifEricson GreenBelt MaBishomarim JonbesheSabz Azadi
Do any other bridge operators want to help by opening additional ports before they are needed?
Here is a recipe to generate 10 random ports and forward them using iptables:
$ python2 -c 'import random; print ",".join("%d"%x for x in sorted([random.randrange(1024,65536) for _ in range(10)]))' 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403
iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403 -j REDIRECT --to-port <obfs4port>
I can apply this on my bridge. My own bridge isn’t included in the default TBB, so does it make sense to open more ports? What would be the correct way to distribute the newly opened ports to the Bride Authorities?
Op 31 aug. 2016, om 00:44 heeft David Fifield david@bamsoftware.com het volgende geschreven:
On Mon, Aug 15, 2016 at 09:45:05PM -0700, David Fifield wrote:
Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
The following bridges have each opened up 10 additional obfs4 ports, through which we can begin rotating in the next release: LeifEricson GreenBelt MaBishomarim JonbesheSabz Azadi
Do any other bridge operators want to help by opening additional ports before they are needed?
Here is a recipe to generate 10 random ports and forward them using iptables:
$ python2 -c 'import random; print ",".join("%d"%x for x in sorted([random.randrange(1024,65536) for _ in range(10)]))' 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403
iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403 -j REDIRECT --to-port <obfs4port> _______________________________________________ tor-project mailing list tor-project@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-project
On Wed, Aug 31, 2016 at 01:57:45PM +0200, Tor Dev wrote:
I can apply this on my bridge. My own bridge isn’t included in the default TBB, so does it make sense to open more ports? What would be the correct way to distribute the newly opened ports to the Bride Authorities?
I'm afraid this only makes sense for the TBB default bridges. For the ordinary bridges that go to the bridge authority, forwarding ports with iptables won't work because, as you correctly assume, the bridge authority won't know about the newly opened ports.
One thing you could do, if you suspect your bridge has been blocked, is change the actual listening port that tor knows about; i.e., with ServerTransportListenAddr. Then, you should additionally forward the previous port to the new port, so that anyone who knew of your bridge on the old port will continue to be able to use it.
Another option is to run a separate tor process on a different port: https://www.torservers.net/wiki/setup/server#multiple_tor_processes
David Fifield transcribed 3.1K bytes:
On Mon, Aug 15, 2016 at 09:45:05PM -0700, David Fifield wrote:
Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
This is pretty easy to do on the bridge operators' part. They just need to forward a range of ports to their existing obfs4 port, something like this: iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 50000:50009 -j REDIRECT --to-port <obfs4port> Then, the Tor Browser developers can choose a fresh port in each new release.
The following bridges have each opened up 10 additional obfs4 ports, through which we can begin rotating in the next release: LeifEricson GreenBelt MaBishomarim JonbesheSabz Azadi
Do any other bridge operators want to help by opening additional ports before they are needed?
Here is a recipe to generate 10 random ports and forward them using iptables:
$ python2 -c 'import random; print ",".join("%d"%x for x in sorted([random.randrange(1024,65536) for _ in range(10)]))' 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403
iptables -A PREROUTING -t nat -i eth0 -p tcp --match multiport --dports 5585,13960,20045,30354,32413,34676,40455,40471,53993,60403 -j REDIRECT --to-port <obfs4port>
I've forwarded this to the operators of some of the remaining default bridges, who I believe are not on this list.
On Tue, Aug 30, 2016 at 03:44:39PM -0700, David Fifield wrote:
On Mon, Aug 15, 2016 at 09:45:05PM -0700, David Fifield wrote:
Lynn Tsai and I just published a report on the blocking of Tor Browser's default obfs4 bridges. https://www.bamsoftware.com/proxy-probe/ https://www.usenix.org/system/files/conference/foci16/foci16-paper-fifield.p... One of the things we found is that the Great Firewall of China blocks the default bridges--but it takes a little while after release for them to do it. We saw delays as short as 2 days and as long as 36 days. We also found that when they block a bridge, they don't block the whole IP address; they just block a single port and other ports on the same IP remain accessible.
We can take advantage of these peculiarities by opening additional obfs4 ports on the default bridges, and changing the port numbers on each release. We'd keep the old ports open for people who haven't upgraded yet, but those who upgrade will start using the new ports. This way, we can make the bridges temporarily reachable after each new release--at least until the censors figure out what we're doing and start blocking more aggressively.
The following bridges have each opened up 10 additional obfs4 ports, through which we can begin rotating in the next release: LeifEricson GreenBelt MaBishomarim JonbesheSabz Azadi
Lynn just filed a ticket to rotate ports for these 5 bridges, plus Mosaddegh. https://bugs.torproject.org/20092 The old ports will continue to work.
tor-project@lists.torproject.org
-
David Fifield -
George Kadianakis -
isis agora lovecruft -
teor -
Tor Dev