On Wed, May 21, 2014 at 06:36:52AM +0000, Yawning Angel wrote:
- obfs4 always does a full handshake. ScrambleSuit style session ticket handshakes are not supported. Even with Elligator2 mapping taken into account, the obfs4 handshake is significantly faster, so there is less of a need for this.
That's probably a good idea as it leads to less code and complexity. We added session tickets when we were experimenting with a proof-of-work scheme instead of the shared secret which is now wrapped around UniformDH. The PoW scheme turned out to be unpractical but we kept session tickets as they still provided a small computational benefit.
- Should obfs4proxy also have (disabled) IAT obfuscation? Adding it later will not require wire protocol changes.
I don't think that inter-arrival times are a significant practical threat at this point. In addition, it has a major impact on throughput which is the reason why obfsproxy's ScrambleSuit ships with the option being disabled. As you write, it shouldn't be a problem to add IAT obfuscation later on if it turns out to be important for some reason.
- The handshake length mimics ScrambleSuit in terms of maximum padding (< 1500 bytes). Should this be increased to be similar to obfs3 (~8k of maximum padding)? The server side cost for this shouldn't be that high.
I'm not sure if sound decisions can be made without comprehensive data showing how real-world protocols behave. ScrambleSuit's (and perhaps also obfs3's) padding length was determined by gut feeling, so ~8k might be fine as well.
- Is this different enough from ScrambleSuit to be worth deploying? I would be ok with this ending up as "just a research project" and shelving it if the consensus is otherwise.
While you're at it, there are some other things which might be worth improving:
- ScrambleSuit's framing mechanism is vulnerable to this attack: http://www.isg.rhul.ac.uk/~kp/SandPfinal.pdf In a nutshell, the receiver needs to decrypt the ScrambleSuit header before it is able to verify the HMAC which makes it possible for an attacker to tamper with the length fields. While there are probably simpler attacks, it would be nice to have a fix for this problem.
- We didn't push the idea of polymorphism very far. There are more flow characteristics such as "packet directions", "total bytes sent", or "total bytes received" which could be disguised in a systematic fashion. While reasonable protection against traffic analysis is tricky, we could at least decrease a classifier's accuracy a bit more. Some ideas could be taken from this paper: http://arxiv.org/pdf/1401.6022v1.pdf
Cheers, Philipp