[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipsec
Subject:    Re: [IPsec] IPsec compression - vulnerable to CRIME-style attack or not?
From:       Nico Williams <nico () cryptonector ! com>
Date:       2012-09-20 18:20:42
Message-ID: CAK3OfOg9cyv0XUg6YKN=7N5NVDKmgipQDdD_pOGwt_KCdEot=Q () mail ! gmail ! com
[Download RAW message or body]

On Thu, Sep 20, 2012 at 12:38 PM, Scott Fluhrer (sfluhrer)
<sfluhrer@cisco.com> 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
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


[prev in list] [next in list] [prev in thread] [next in thread]