On Thu, Sep 20, 2012 at 12:38 PM, Scott Fluhrer (sfluhrer) <[email protected]> wrote: > With IPSec, compression happens on a per-packet basis; the contents of > previous packets do not affect how this packet is compressed in any way. > Hence, there would be a vulnerability only if the attacker can somehow create > a single packet that contains both the unknown cookies, as well as his chosen > text. If he can, then likely he could (with sufficient cleverness) figure > out a way to exploit it. However, if his chosen packets contain only what he > picked and not the cookies (or whatever else he is interested in), there's no > vulnerability.
Indeed, and for the BEAST attack being able to manage buffering (via a "flush" operation, in that case) was critical to the exploit. And such buffering functionality existed, indeed. If the question is "is IPsec (ESP) immune to this attack" and the answer is (as I think it is) "it depends on the application" then the fail-safe thing to do is to disable compression in IPsec (I'm not necessarily recommending that though). Nico -- _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
