Re: [tor-dev] obfsproxy buffering

[Zack Weinberg <zackw@xxxxxxxxx>]

On Mon, Nov 18, 2013 at 10:47 AM, David Stainton <dstainton415@xxxxxxxxx> wrote:
>> Super-simple framing protocols often fall victim to attacks in which the
>> adversary messes with the length in the frame header.  See, for example,
>> "Plaintext Recovery Attacks Against SSH":
>> http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf
>
> Over Tor it won't be a problem because Tor is authenticated.

I think that's an oversimplistic way of looking at the problem, but
you're mostly right.

Suppose that your message framing is just

len (4 bytes plaintext) | LEN bytes of cipher text including higher
level MAC | ...

If an active MITM flips bits in the length field, you will feed the
wrong number of bytes to the decryptor and the MAC check will fail.
Moreover, this is an *unrecoverable* failure condition: there's no way
for you to get back in sync with the other end. You have to drop the
connection, and the other side has to respond to a connection drop in
a sensible fashion. (I wouldn't recommend trying to reconnect and
retransmit the queue - rather, propagate the failure up to Tor.) But,
because the length field is plaintext, there is no decryption oracle;
the adversary can't trick you into decrypting something that's not a
length field and treating the result as a length field. I think this
is probably acceptable for obfsK, which is just supposed to be
different from anything recognizable.

If you want all-bytes-on-the-wire-indistinguishable-from-randomness,
that is considerably harder -- a great deal of the complexity of the
"chopper" of https://hacks.owlfolio.org/pubs/2012-stegotorus.pdf is in
service of being able to encrypt the length field without exposing a
decryption oracle.  Note that I no longer think that design is sound,
but it will still give you an idea of what it takes.

zw
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev