[tor-project] Turning on timing obfuscation (iat-mode=1) for some default bridges

[Yawning Angel]

On Mon, 14 Nov 2016 16:56:03 -0800
David Fifield <david at 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/obfs4/obfs4.go?id=df6aeeca8cc8e953284ce1cb8a0910500579dfaf#n512
> {{{ // 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.torproject.org/pipermail/tor-project/attachments/20161115/65e8fe9e/attachment.sig>