Some general thought on CRIME and Compression and Headers

Thinking through the various issues relating to the CRIME attack.. just
wanted to offer up some additional fodder for consideration..

:brainstorming_mode on

First of all, it is good to consider what the CRIME attack actually is.
Generally, if we have a block of header data that contains a mix of static
sensitive data (such as a session cookie) and attacker-provided dynamic
data, the attacker can repeatedly analyze the size of the compressed block
of data using different dynamic data values until  the sensitive data is
successfully reverse-engineered.

So far, the techniques we have explored to address this problem have been
to alter the compression mechanism (e.g. delta) so that the compression
ratio can't be effectively used to reverse engineer the sensitive data.
This, however, brings along a range of issues, not the least of which is
the fact that delta encoding is not nearly as efficient as gzip.

Thinking about it further, another approach presents itself that is
independent of the compression mechanism but requires more work from
implementers and application developers (and would require a general change
to the way a lot of software currently works)... That approach is to move
away from the use of static session-id cookies.

If, for instance, every message contained a dynamically generated token
derived from a secret session-key and a nonce, then it simply would not
matter if an attacker was able to guess the value by analyzing the
compression ratio... by the time they figured out the value, the value
would no longer be relevant.

So.. rather than...

  Server => Client

  Set-Cookie: session-id=some-static-key


  Client => Server

  Cookie: session-id=some-static-key

It would be...

  Server => Client

  Session-Key: some-private-session-key

  Client => Server

  Session-Key: dynamic-token-derived-from-session-key

Obviously this solution would only work for certain types of sensitive
 information.. and we currently have absolutely no way of knowing exactly
which bits of information in the headers are going to be interesting to an
attacker. But, at the very least, this would address a significant known
attack vector.

My experimental spdy key_nego mechanism [1] could theoretically play a role
here as well... providing the mechanism by which the dynamic session key is
negotiated, avoiding the use of Set-Cookie and compressed-headers entirely.

[1] http://tools.ietf.org/html/draft-snell-httpbis-keynego-00

- James