Improving Meek With Adversarial Techniques (FOCI 19) about bbs HOT 1 OPEN

One of the research doors left open by this work is how to concretely implement the perturbed traffic flow feature distribution. Supposing you have a target feature vector that you want to be observed by the adversary, what do you do (in the code), to achieve that?

With meek it's no so easy, because its additional protocol layers and the overhead they add. If your feature vector calls for sending a packet of 400 bytes, you cannot simply send 400 bytes of application-layer payload, because those bytes are going to be prefixed by an HTTP header, and then the whole encapsulated in a TLS application data record. You would need to somehow reverse-engineer (perhaps using some simple optimization algorithm) what number of bytes of HTTP payload you need to send, to get 400 bytes on the wire.

Alternatively, you could collect traffic traces as these authors have done, but do it at the payload layer. (I.e., using some in-browser logging, not tcpdump.) That would give you the sizes and timings of typical HTTP request and response bodies, which if transferred to the pluggable transport, would give you the right traffic flow signature on the wire, assuming that the HTTP and TLS layers perform similarly. (The last assumption is questionable, because for example in a normal browser your browser collects cookies which change the size of HTTP headers as it runs; but then again, normal browsers already start with a stocked cookie jar and don't start from a clean configuration. There are a lot of assumptions that could be tested in this kind of work.)

from bbs.