Am Samstag, 10. August 2013, 18:11:09 schrieb Dirk-Willem van Gulik: > So the only fundamental thing we can do (i.e. if we want to go > beyond guessing (future) browser and developer introduced > vulnerabilities at higher layers) is a wee bit of > padding/random*-cruft insertion in key places. Perhaps even doing > so by default.
I think in general, an attacker should not be able to find out where headers end and where the body starts just by looking at the encrypted traffic. Therefore adding some header of random length should be just as effective as doing the padding somewhere in the body. Shouldn't it? To defend against spurious flush buckets at the end of the headers, one could do some padding by doing random chunking at the start of the body. I think the chunk header is allowed to start with leading zeroes and it seems unlikely that an implementation will misinterpret that (at least much more unlikely than clients being broken by chunk extensions or chunk trailers). Maybe we could add a random number of leading zeros to some chunk headers? However, before we go this way, someone should do the math how many more requests are necessary for which length of padding.
