The vulnerability exploited is a combination
of chosen
plaintext attack and
inadvertent information leakage through data compression similar to that
described in 2002 by the cryptographer John Kelsey.[3] It relies on the attacker being able to
observe the size of the ciphertext sent by the browser while at the same time inducing the browser to make multiple
carefully crafted web connections to the target site. The attacker then
observes the change in size of the compressed request payload, which contains
both the secret cookie that is sent by the browser only to the target site, and
variable content created by the attacker, as the variable content is altered.
When the size of the compressed content is reduced, it can be inferred that it
is probable that some part of the injected content matches some part of the
source, which includes the secret content that the attacker desires to
discover. Divide and
conquer techniques can then be used to
home in on the true secret content in a relatively small number of probe
attempts that is a small multiple of the number of secret bytes to be
recovered.
The CRIME exploit was hypothesized by Adam
Langley, and first demonstrated by the security
researchers Juliano Rizzo and Thai Duong, who also created the BEAST exploit. The exploit was due to be revealed in full
at the 2012 ekoparty security conference.Rizzo and Duong presented CRIME as a general
attack that works effectively against a large number of protocols, including
but not limited to SPDY (which always compresses request headers), TLS (which
may compress records) and HTTP (which may compress responses.
CRIME can be defeated by preventing the use
of compression, either at the client end, by the browser disabling the
compression of SPDY requests, or by the website preventing the use of data
compression on such transactions using the protocol negotiation features of the
TLS protocol. As detailed in The Transport Layer Security (TLS) Protocol
Version 1.2,the client sends a list of compression
algorithms in its ClientHello message, and the server picks one of them and
sends it back in its ServerHello message. The server can only choose a
compression method the client has offered, so if the client only offers 'none'
(no compression), the data will not be compressed. Similarly, since 'no
compression' must be allowed by all TLS clients, a server can always refuse to
use compression.
Comments
Post a Comment