Search Mailing List Archives


Limit search to: Subject & Body Subject Author
Sort by: Reverse Sort
Limit to: All This Week Last Week This Month Last Month
Select Date Range     through    

[liberationtech] Iran blocks MP3, MP4, AVI and SWF files

Collin Anderson collin at averysmallbird.com
Sat Oct 6 13:36:02 PDT 2012


>
> File extension in URL requested, Content-Type or are they even finding
> their own Content-Type?


You are correct, all that it took to trigger the blocking was a php file
with the following:

header("Content-Type: audio/mpeg");

The server was adding the content-type header to the returned request
because of the file extension.

On Sat, Oct 6, 2012 at 3:58 PM, Fabio Pietrosanti (naif) <
lists at infosecurity.ch> wrote:

> 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
>



-- 
*Collin David Anderson*
averysmallbird.com | @cda | Washington, D.C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.stanford.edu/pipermail/liberationtech/attachments/20121006/8388b464/attachment.html>


More information about the liberationtech mailing list