1. 19
  1.  

  2. 2

    Will have to wait and see the full presentation/release, but at this time it seems like adding a random sized block of data to every response would thwart this side channel attack.

    1. 5

      I don’t think that’s necessarily true. The attacker could use multiple requests to determine the expected distribution of response sizes, and see if alterations to the content change the distribution or not. It would slow things down by requiring multiple requests for each oracle check, but with good guesses of the encrypted data and some pre-attack measurement of the payload size distribution from target sites, I suspect it would still be viable.

      1. 3

        Choice of random data would be important as well - you’d have to be sure to keep varying the entropy of your random blob or else you’d end up clamping the slewing effect.

        In other words, if I add between 512 and 1024 bits of base64(rand()) to each call, you’d end up with highly incompressible data so your expected added size would be close to [512, 1024]. If I reuse 512 to 1024 bits of the page the data would be highly compressible, so we’d end up clamping the window low.

        1. 3

          Padding for this purpose needs to pad so that everything is the same size, or at least doesn’t depend on the original size. Adding a random amount of data when the attacker can make as many requests as they want doesn’t help because, as you say, with enough iterations it averages out.

          1. 2

            I agree, but padding would defeat the point (at least a little) of compression.

            1. 2

              Hmm… I’m still not convinced that padding would eliminate the attack. If you pad to target a specific size for all responses, what happens when the response is at or over that size without padding? Seems like the attacker could add her own padding as part of the request to remove the target site’s headroom to add padding to hit a target size. If the target site uses multiple target sizes to compensate, then for the attacker, it becomes a game of getting as close as possible to that boundary and seeing what additional content pushes it to the next size interval.

              It may be my lack of imagination, but I’m having a hard time thinking of a way to add data to mitigate this attack, given that there’s a lower bound on response size determined by the useful content in the response, and an upper bound to how much the target can pad the response before defeating the point of compression altogether.

              1. 1

                Yeah, those are good points; I think you’re probably right. (Sorry for not replying sooner!)

        2. 2

          I’m curious if a locked down CSP Header would help prevent sites from being exploited, although I guess it would depend on where the JS got loaded from. If the attacker was able to get malicious JS served from the site or an approved origin then this would still be exploitable.

          1. 1

            It would certainly reduce the attack surface. I think using something like uMatrix is also a good idea.