On Fri, 23 May 2014 14:16:49 +0200 Philipp Winter phw@nymity.ch wrote:
[snippity]
- 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.
I went and added the code last night, so it's there if needed (as a command line option).
- 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.
On the gut feeling of "bigger handshakes = more random *waves hands*", I went and jacked it up last night. More real world data would be nice.
- 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.
I believe obfs4 does not have the plaintext recovery issue as the length field is separate from the AEAD construct (Though at present an adversary tampering with the length field is only caught by MAC errors). However I will go and implement randomizing the length on a out of bounds length value (as suggested in section 6 of the paper) to reduce the timing differential.
From reading the paper, I do not believe that ScrambleSuit's vulnerability leads to plaintext recovery either as it uses CTR-AES and recovery is based off CBC-AES, though as the authors note, there may be other side channel hazards.
- 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
This is the sort of thing that mjuarez is looking into as part of GSOC. As long as a padding frame type is defined, incorporating the results of his research at a later date should be possible without changes to the wire protocol.
Thanks for the feedback!