I propose that we turn on the obfs4's optional packet size and timing obfuscation on some of the default Tor Browser bridges.
The packet size and timing obfuscation can be off (iat-mode=0) or on (iat-mode=1). Currently, all of the default bridges, and probably ≈100% of BridgeDB bridges, have it turned off (iat-mode=0).
As far as I know, iat-mode=1 has never really been tried in practice. The reason I propose trying it is the current blocking situation in Kazakhstan. According to reports, obfs4 (along with meek and vanilla Tor) are blocked there--not only the built-in default bridges, but also secret bridges from BridgeDB. A user on IRC has been experimenting with the Kazakh firewall; the blocking seems to be some sort of probabilistic traffic analysis--it doesn't always block and the rate of blocking depends on the network load. That user would like to have iat-mode=1 set on some of the default bridges to see if it gets through the firewall.
Here are details on the Kazakhstan situation: https://bugs.torproject.org/20348
So I'm thinking it's a good idea to turn on iat-mode=1 on, say, 20% of the default bridges. That'll also be a good hedge against potential future blocking, as we can see if the bridges that use size and timing obfuscation are more resistant. It is safe for the server to turn on iat-mode=1 while the client still has iat-mode=0; the obfuscation will only apply in one direction but the connection will still work.
---- Addendum on how to activate iat-mode=1 on the server
If you built obfs4proxy from source, and you are using commit a7a2575cab or later, you just need to add one line to your torrc: ServerTransportOptions obfs4 iat-mode=1 Unfortunately this commit is not yet in a released version.
If you are using a released version, such as obfs4proxy-0.0.6, then you need to specify every other possible parameter in addition to iat-mode. Find the file <datadir>/pt_state/obfs4_state.json, and convert the JSON syntax into key=value syntax in a ServerTransportOptions, for example if obfs4_state.json contains {"node-id":"0af6c84b644856255dd858b2b189725db6ded51a","private-key":"d04e61ea38757ef67131a3032709e26bbf77a370aadf3950180fbf797973b365","public-key":"fedde584dc36265f9071ab6f7d845a9ae9e3cea5b9c956b252c1c7849aa2d006","drbg-seed":"5bb4dd59f507a89660c4d313f598ed56f4e9e0a620e129af","iat-mode":0} then add this to torrc: ServerTransportOptions obfs4 node-id=0af6c84b644856255dd858b2b189725db6ded51a private-key=d04e61ea38757ef67131a3032709e26bbf77a370aadf3950180fbf797973b365 public-key=fedde584dc36265f9071ab6f7d845a9ae9e3cea5b9c956b252c1c7849aa2d006 drbg-seed=5bb4dd59f507a89660c4d313f598ed56f4e9e0a620e129af iat-mode=1 You will know you need to do this if, when you try to set iat-mode=1 by itself, you get the tor.log error: [warn] Server managed proxy encountered a method error. (obfs4 missing argument 'private-key')
On Mon, 14 Nov 2016 16:56:03 -0800 David Fifield david@bamsoftware.com wrote: [snip]
Here are details on the Kazakhstan situation: https://bugs.torproject.org/20348
I was going to reply to the ticket, but I don't want to get spammed with trac e-mails the next time someone decides to act like a petulant child.
But since it may be useful to someone:
Replying to [comment:32 dcf]:
The delay can be up to 10 ms. Why this may be a problem is the sleep happens during thr round trip between client and server. If the round-trip time is greater than the delay, then it is as if there was no delay. Delays happen only once per write (i.e. obfs4 doesn't split up writes to insert delays). So the timing obfuscation may be less effective during the handshake phase than during the steady state, which can have consecutive writes not bound by latency.
It *can* split writes to insert delays. See `iat-mode=2`.
Another potential problem is that the obfs4 code dies on short writes. This is actually documented: https://gitweb.torproject.org/pluggable-transports/obfs4.git/tree/transports... {{{ // Write the pending data onto the network. Partial writes are fatal, // because the frame encoder state is advanced, and the code doesn't keep // frameBuf around. In theory, write timeouts and whatnot could be // supported if this wasn't the case, but that complicates the code. }}} It sounds like kzblocked has actually gotten it to happen, maybe on a slow link. They were going to find out what `err` is when a short write happens.
Unless they're messing with the send socket buffer size and setting it to something pathologically low, this should basically never happen (to my knowledge, no one has complained about it). I think this is a red herring.
(And if they are, why. There's better ways to regulate write size.)
The correct way to fix this sort of attack is to switch to a model where the transport schedules writes on it's own regardless of if it has data queued or not. I was going to do something like that for my obfs4 successor, but development on that is on hold for now, and I don't know when I'll get back to it. There's easier distinguishers for obfs4 traffic than this sort of analysis anyway....
If you built obfs4proxy from source, and you are using commit a7a2575cab or later, you just need to add one line to your torrc: ServerTransportOptions obfs4 iat-mode=1 Unfortunately this commit is not yet in a released version.
I'll probably end up tagging a release "Soon". This can be sooner if it helps.
Regards,
Yawning Angel:
I'll probably end up tagging a release "Soon". This can be sooner if it helps.
Thanks for all the good work, Yawning. I think it will be helpful to do that for majority of the operators since we've always encouraged people to use packages instead of building from source.
And speaking of packages, can we also please make sure the packages on deb.tpo are being updated as well? I've recently found out that they're behind the packages on debian stable/unstable/testing. Having a package on deb.tpo is useful specially if you don't run any of those. For instance, some of my bridges are running on wheezy still (because of some limitations from the host) and I have realized that I'm not necessarily running the latest version of obfs4proxy.
Thanks!
On Tue, 15 Nov 2016 17:31:00 +0000 Nima Fatemi nima@torproject.org wrote:
Yawning Angel:
I'll probably end up tagging a release "Soon". This can be sooner if it helps.
I tagged 0.0.7, put the tarball/signature in the traditional place, and sent a release note to tor-dev@.
[snip]
And speaking of packages, can we also please make sure the packages on deb.tpo are being updated as well? I've recently found out that they're behind the packages on debian stable/unstable/testing. Having a package on deb.tpo is useful specially if you don't run any of those. For instance, some of my bridges are running on wheezy still (because of some limitations from the host) and I have realized that I'm not necessarily running the latest version of obfs4proxy.
I do not know who manages those packages.
Regards,
David Fifield david@bamsoftware.com wrote Mon, 14 Nov 2016 16:56:03 -0800:
So I'm thinking it's a good idea to turn on iat-mode=1 on, say, 20% of the default bridges. That'll also be a good hedge against potential future blocking, as we can see if the bridges that use size and timing obfuscation are more resistant. It is safe for the server to turn on iat-mode=1 while the client still has iat-mode=0; the obfuscation will only apply in one direction but the connection will still work.
ndnop3 is now running with iat-mode=1.
Yawning Angel yawning@schwanenlied.me wrote Tue, 15 Nov 2016 01:19:13 +0000:
The delay can be up to 10 ms. Why this may be a problem is the sleep happens during thr round trip between client and server. If the round-trip time is greater than the delay, then it is as if there was no delay. Delays happen only once per write (i.e. obfs4 doesn't split up writes to insert delays). So the timing obfuscation may be less effective during the handshake phase than during the steady state, which can have consecutive writes not bound by latency.
It *can* split writes to insert delays. See `iat-mode=2`.
ndnop5 is now running with iat-mode=2. I will keep an eye on CPU usage as I understand this is expensive.
Let me know if you think this is a bad idea.
On Tue, Nov 15, 2016 at 11:33:14AM +0100, Linus Nordberg wrote:
ndnop3 is now running with iat-mode=1.
ndnop5 is now running with iat-mode=2. I will keep an eye on CPU usage as I understand this is expensive.
Thanks for making this change. I opened a ticket to make the matching change in Tor Browser in https://bugs.torproject.org/20837#comment:1.
I wouldn't expect iat-mode=2 to use a lot of CPU. It's expensive in the sense that it "wastes" bandwidth by adding extra padding and delays.
On Mon, Nov 14, 2016 at 04:56:03PM -0800, David Fifield wrote:
I propose that we turn on the obfs4's optional packet size and timing obfuscation on some of the default Tor Browser bridges.
The packet size and timing obfuscation can be off (iat-mode=0) or on (iat-mode=1). Currently, all of the default bridges, and probably ≈100% of BridgeDB bridges, have it turned off (iat-mode=0).
So I'm thinking it's a good idea to turn on iat-mode=1 on, say, 20% of the default bridges. That'll also be a good hedge against potential future blocking, as we can see if the bridges that use size and timing obfuscation are more resistant. It is safe for the server to turn on iat-mode=1 while the client still has iat-mode=0; the obfuscation will only apply in one direction but the connection will still work.
I'm aware of three bridges that changed their iat-mode setting. I opened https://bugs.torproject.org/20837 to make the matching change in the client settings.
These are the changes that are in the patch: ndnop3 → iat-mode=1 ndnop5 → iat-mode=2 Lisbeth → iat-mode=1 If anyone else changed the setting but didn't tell me, tell me now so I can add it to the patch. If you didn't change anything, you don't need to change anything; 3 out of 19 default bridges is probably enough for now.
By the way, we got a report that iat-mode=1 and iat-mode=2 both worked to get through a particular firewall (and neither worked against another particular firewall). https://lists.torproject.org/pipermail/tor-talk/2016-November/042586.html
tor-project@lists.torproject.org
-
David Fifield -
Linus Nordberg -
Nima Fatemi -
Yawning Angel