Results 1 to 4 of 4

Thread: Hack Gzip to counter BREACH/CRIME ?

  1. #1
    Member
    Join Date
    Jun 2010
    Location
    CN
    Posts
    5
    Thanks
    1
    Thanked 1 Time in 1 Post

    Hack Gzip to counter BREACH/CRIME ?

    Hello,

    In recent BREACH attack http://breachattack.com/, I wonder if we could do something about gzip.

    For an HTML page, can we put some tricks in Huffman coding, so certain parts of the HTML (e.g. user inputs and tokens) is not compressed, while the rest of the HTML is compressed, but the output stream is compatible with gzip?

    Is this possible? TIA.

  2. #2
    Member m^2's Avatar
    Join Date
    Sep 2008
    Location
    Ślůnsk, PL
    Posts
    1,612
    Thanks
    30
    Thanked 65 Times in 47 Posts
    Yes it is. Both in Huffman and in LZ. Though it may need explicit support in a browser (it has to tell the library what to compress and what not to).

  3. #3
    Member
    Join Date
    Jun 2013
    Location
    USA
    Posts
    98
    Thanks
    4
    Thanked 14 Times in 12 Posts
    Already done with SPDY/4. See: https://groups.google.com/forum/#!to...ev/3W8YlAIgnls

    Note that you should forget about using compression on non-SPDY/4 sites. Also see: https://www.imperialviolet.org/2012/09/21/crime.html particularly the last paragraph.

  4. #4
    Member caveman's Avatar
    Join Date
    Jul 2009
    Location
    Strasbourg, France
    Posts
    190
    Thanks
    8
    Thanked 62 Times in 33 Posts
    Quote Originally Posted by est View Post
    Hello,

    In recent BREACH attack http://breachattack.com/, I wonder if we could do something about gzip.

    For an HTML page, can we put some tricks in Huffman coding, so certain parts of the HTML (e.g. user inputs and tokens) is not compressed, while the rest of the HTML is compressed, but the output stream is compatible with gzip?

    Is this possible? TIA.
    It could be done since a Deflate stream can be split in as many blocks you want (even empty blocks are allowed), type 0 blocks are not compressed, the usual LZ+Huffman compression sheme could also be restricted to Huffman only, unfortunatelly there is no way to enforce the type of block when using Zlib since it picks the smallest one.
    Now to mitigate the BREACH attack the easiest way is probably to somewhat randomize the compressed stream size, for instance :
    - adding between 0 and 9 empty type 1 blocks (each costs 13 bits) at the begining of the stream shouldn't be to hard
    - the way the Huffman tables are recorded could also receive a slight random twist (limiting RLE range, building suboptimal Huffman trees...) it would affect the type 2 block header size (which is usually between 300 and 1000 bits) without impacting the compressed body itself.

Similar Threads

  1. gzip - Intel IPP
    By M4ST3R in forum Download Area
    Replies: 5
    Last Post: 2nd June 2010, 15:09
  2. Gzip 1.2.4 hack (OpenWatcom compiles)
    By Rugxulo in forum Data Compression
    Replies: 9
    Last Post: 22nd May 2009, 00:17
  3. Advanced counter/predictor
    By encode in forum Data Compression
    Replies: 22
    Last Post: 27th May 2008, 23:43
  4. Prob/counter update
    By encode in forum Forum Archive
    Replies: 12
    Last Post: 28th November 2007, 22:34
  5. gzip-1.2.4-hack - a hacked version of gzip
    By encode in forum Forum Archive
    Replies: 63
    Last Post: 10th September 2007, 04:16

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •