Re:New attack plucks secrets from HTTPS-protected pages
by FZeroX on Friday August 02, 2013 @06:39PM
(#6150114)
It's not a sure fix though, there will be occasions where you can change the page length enough to hit the padding boundary.
Re:New attack plucks secrets from HTTPS-protected pages
by pygy_ on Friday August 02, 2013 @07:56PM
(#6150385)
Indeed. 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.
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://www.ietf.org/rfc/rfc1951.txt
[1] https://en.wikipedia.org/wiki/Chunked_transfer_encoding