On 10/6/12 9:41 PM, Collin Anderson wrote: > What is particularly different in this case is that this filtering > does not return a 403 Code or TCP RST -- when a GET request for a .mp3 > file is sent, the connection is simply blocked. The server can send > whatever it likes, but the client will not see anymore traffic after > that. This is abnormal, but it does not seem to be a DPI rule (zero'ed > out .mp3: blocked, .mp3 renamed to .rawr: successful transmission). I > pointed out a few days ago on Twitter that there will probably be new > Internet interference in the wake of the rapid currency depreciation, > this seems to align with that theory and the increased jamming of > international broadcasting. It won't last but it is definitely a way > to poke at the infrastructure. >From technical point of view, what are they looking at? File extension in URL requested, Content-Type or are they even finding their own Content-Type?
Depending on how do they do that, it maybe easier to provide some guidelines to workaround them. And if they are not DPIing it with packet re-assembly, then we can use the Philip Winter's techniques (http://www.cs.kau.se/philwint/static/gfc/) of small-sized windows-size on server-side to bypass their filter purely server-side (https://github.com/NullHypothesis/brdgrd) that worked successfully in stopping GFW Tor Bridge fingerprinting. -naif -- Unsubscribe, change to digest, or change password at: https://mailman.stanford.edu/mailman/listinfo/liberationtech
