Towards Comprehensive Analysis of Tor Hidden Service Access Behavior Identification Under Obfs4 Scenario

[kalikaneko]

Towards Comprehensive Analysis of Tor Hidden Service Access Behavior Identification Under Obfs4 Scenario
Xuebin Wang, Zeyu Li, Wentao Huang, Meiqi Wang, Jinqiao Shi, Yanyan Yang

dataset: https://github.com/Meiqiw/obfs4-mingan

In this paper, we present a novel approach to identify Tor hidden service access activity with key sequences under Obfs4 scenario. By calculating the key cell signals occurred during Tor hidden service access process, we get the start index and window size of the key TCP package sequence of traffic. In order to verify the effectiveness of this method, we perform comprehensive analysis under nine scenarios of different Obfs4 transmission model. We find through experimental results that there is a TCP package sequence window, which has a great contribution to identifying Tor hidden service access traffic. Only use the key TCP sequence as input, we can achieve more than 90% accuracy as well as recall in nine scenarios.

[wkrp]

I think this is the research paper that corresponds to the data set.

https://dl.acm.org/doi/10.1145/3491396.3506532

What brought it to your attention?

[kalikaneko]

Sorry, I forgot to include the link.

The article itself doesn't look particularly good, but some things caught my interest:

1. its procedence.
2. the open dataset - so that any classifier can be replicated.
3. the claim that the access to onion services can be fingerprinted, even when obfuscated with obfs4.
4. even assuming obfs4 is broken, the approach here does not focus on the handshake, but on the data exchange: they build a classifier based only on TCP sequences (of package sizes, per flow).
5. it claims that the use of IAT modes only increases the window lenght needed to identify traffic to/from hidden services.
6. even if just-another-low-quality, unreproducible theoretical attack, they only use the DF classifier for classification with a single feature, not feature extraction. Looking at the results, they claim a window size of only 130 packets for the worst case, which looks to me like it lowers the bar for the potential use of such an online classifier.

If all this is true, it might be interesting to think about adding cover traffic to any obfs4 successor.

That, and perhaps try to play with adversarial attacks that can confuse the classifier, since DF is just a CNN ;)

Anyway, feel free to close if it doesn't seem relevant to discuss further, I understand the need for some filtering criteria.

[wkrp]

It's all good, don't worry about it. It's encouraged to post anything you've read that you've found interesting.

If all this is true, it might be interesting to think about adding cover traffic to any obfs4 successor.

It's actually possible to get almost arbitrary traffic shaping in obfs4. iat-mode=1 and iat-mode=2 are not the limit. You can use the obfs4 protocol to make a constant bitrate flow, for example, or implement other shaping strategies, from website fingerprinting research for example. It's just not implemented by default, and requires some refactoring of the obfs4proxy internals.

• https://people.torproject.org/~dcf/obfs4-timing/
• [tor-dev] The limits of timing obfuscation in obfs4

The idea is: you have an algorithm for the traffic schedule that is independent of the tunneled applications actual traffic sending. When the schedule calls for a certain number of bytes to be sent at a certain time, you send encrypted application data if there is any available; otherwise you send padding.

Something similar is possible with Shadowsocks AEAD ciphers using encryptions of empty plaintexts, even though Shadowsocks doesn't have explicit support for padding. I heard this idea from @fortuna. When you need a source of bytes for padding, you can encrypt a zero-length plaintext, which gives you 34 bytes that decrypt to nothing: 2 bytes encrypted length field, 16 bytes length field authentication tag, 0 bytes encrypted payload, 16 bytes payload authentication tag. You can concatenate as many of these empty ciphertexts as you need to satisfy the traffic schedule.

[Yawning]

Defending against these sort of attacks is beyond the threat model of the obfs4 traffic shaper implementation (and to be honest is beyond the threat model of obfs4 in general).

For a while I was working on something that supported using an at-the-time state of the art anti-fingerprinting defense, but I stopped working on it because I lost interest. I have been told that some people evaluated it for a research paper and it worked quite well, though even with some congestion awareness trickery, it did burn a (to me) unreasonable amount of bandwidth.

Edit: Don't take this as a suggestion to go dig up the code for my old prototype either, There is quite a bit of the design that I would change in the unlikely event that I were to do it again.

[kalikaneko]

Defending against these sort of attacks is beyond the threat model of the obfs4 traffic shaper implementation (and to be honest is beyond the threat model of obfs4 in general).

Thanks for the clarification, it makes sense. Intuitively I would have expected that the protections against fingerprinting via packet timing had been somehow more effective.

some people evaluated it for a research paper and it worked quite well

I'd be interested in any pointers to that, if it's been published. My hunch is that, for the particular case of convolutional neural nets (which seem to be on the top accuracy for the classifiers I've seen so far), there might be a relatively cheap set of perturbations that would flip the output. I have no hands-on experience with that, but it looks like a fun experiment to run (the most extreme of such attacks on the classifiers is perhaps https://arxiv.org/abs/1710.08864).