4 ms·
I don't know if the browsers would tolerate this, but it should be possible to pad the compressed payload, rather than the source document. A DEFLATE stream [0
by pygy_ 13y ago
I don't know if the browsers would tolerate this, but it should be possible to pad the compressed payload, rather than the source document.
A DEFLATE stream [0] is made of blocks whose first bit determines whether it is the last one.
One could add a number of random bytes after the last block such that the payload always has the same length, or is a multiple of a reasonably large number of bytes.
This assumes that the decoder will ignore it whatever follows the last block.
Another, cleaner option: Use a Trailer HTTP header, using Chunked transfer encoding[1].
The technique should also work with gzip.
--
[0] http://en.wikipedia.org/wiki/DEFLATE#Stream_format http://en.wikipedia.org/wiki/DEFLATE#Stream_format, http://www.ietf.org/rfc/rfc1951.txt http://www.ietf.org/rfc/rfc1951.txt
[1] https://en.wikipedia.org/wiki/Chunked_transfer_encoding https://en.wikipedia.org/wiki/Chunked_transfer_encoding
- FZeroX 13y agoIt's not a sure fix though, there will be occasions where you can change the page length enough to hit the padding boundary.
- pygy_ 13y agoIndeed. You could do what CRIME does to TLS (I just discovered these attacks). You could also add a random amount of random padding. It would slow down the attack linearly if the random amount is taken from a uniform distribution. I wonder if it would be possible to make it slower by taking another distribution.