The state-of-the-art website fingerprinting defense is WTF-PAD by Juarez et al. [0]. WTF-PAD stands for Website Traffic Fingerprinting Protection with Adaptive Defense, but yeah, WTF-PAD just has a better ring to it. As the name suggests it is based on a defense against traffic analysis known as adaptive padding by Shmatikov and Wang [1]. The figure below, from Juarez et al., shows the adaptive padding (AP) algorithm as a finite state machine.

ap

There are three states:

  • S: idle/waiting for real data to be sent.
  • B: burst mode, real data is being sent.
  • G: gap mode, we’re sending fake data in a gap of real data.

Transition from state S to B happens when real data is sent. On transition to state B, sample a histogram Hb to get value t that is either a duration of time or the inf value. The inf value (for the infinity bin in the histogram) signals that you should exit the current state, returning to state S. When a duration is sampled, start a timer for the specific duration, and if the timer expires, transition to state G. If real data is sent, then enter state B again, sampling Hb and either replacing the timer t or exiting due to inf. Finally, upon entering state G, send dummy data (padding) and sample another histogram Hg: the result being either another timer that upon expiration takes you back to G or you exit on sampling inf. Note also that, if in state G, you also exit back to state B when real data is sent.

If that sounds annoying, think of it like this:

  • If we ever have to send real data, send the real data right away, and go to burst mode.
  • In burst mode, wait a reasonable amount of time before sending dummy data.
  • When we send dummy data, in gap mode, try to only send a reasonable amount and never send dummy data if we have real data to send.
  • Have a chance to go back to idle/waiting state when not sending any data (otherwise we’re just sending crap back and forth).

The annoying questions are:

  • What is a reasonable amount of time to wait before sending dummy data, and
  • how much dummy data should be send?

WTF-PAD

In WTF-PAD, there are two AP state machines in the pluggable transport client and server:

  • on sending data to the other end-point, and
  • on receiving data from the other end-point.

By also having APs that react to receiving data from the other end-point, fake request-response traffic is generated similar to HTTP connections and web-based traffic. WTF-PAD also includes control messages from client to server that controls the histograms used by the server.

The histograms are the really trick part of WTF-PAD, since dummy data (padding) has to be sent in such a way that an attacker cannot distinguish between real and fake data. Since data is encrypted (and in the case of Tor, also padded to fixed sizes in cells) the key characteristic left for distinguishing is time. More precisely, the issue is inter-arrival times between packets.

Looking at statistics on inter-arrival times from packet traces of Tor traffic, the WTF-PAD authors note that (log-)normal distributions provide a good fit. Simulating the WTF-PAD defense on traffic traces from Tor, the authors manage to create a defense with significantly low overhead compared to prior work but comparable defense, as shown in the figure below.

wtfpad

Really impressive! The WTF-PAD paper got the outstanding student paper award at ESORICS 2016 for a good reason. On the down side, it appears like finding the optimal histograms is a challenge in practise, and as I have understood it a focus of future work. When this is resolved, WTF-PAD is by far the best candidate for deployment in Tor as a website fingerprinting defense.

References