3

In this answer, @Thomas Pornin talks about remediating the CRIME attack and says:

(It is a shame to have to remove SSL compression, because it is very useful to lower bandwidth requirements, especially when a site contains many small pictures or is Ajax-heavy with many small requests, all beginning with extremely similar versions of a mammoth HTTP header. It would be better if the security model of JavaScript was fixed to prevent malicious code from sending arbitrary requests to a bank server; I am not sure it is easy, though.)

Suppose my website serves content from two HTTPS URLs: secure.company.com and images will be hosted at cdn.differentTLD.net. Note that I'm using different domains so no authentication cookies will be sent or validated. Also assume that this CDN holds static files and no authentication will be done.

  • Is it safe to enable TLS Compression only for the CDN?

I understand that @D.W. and @PulpSpy's answer can infer which file is being downloaded based on their post below.

  • That being said, can a lower-level TLS "secret" be exposed outside of the data that is in the HTTP protocol? (In the CRIME attack we seem to only talk about getting the cookie in the header)

  • Can any data gained from a CRIME exploit against the CDN be used against the other domain?

Community
  • 1
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • Wouldn't most content on a CDN be compressed already? It's usually JPEG/PNG images, compressed archives, video, audio, etc. TLS compression wouldn't really offer anything in such a case... – Polynomial Dec 03 '12 at 13:28
  • @Polynomial I'm mainly asking so that I can make sure I understand the exploit in various theoretical situations... though you bring up an interesting point. – makerofthings7 Dec 03 '12 at 13:58

1 Answers1

6

Compression-related vulnerabilities are about leakage: what the attacker can learn about the exchanged data, based on the data length. It makes sense only for confidential data; in the case of CRIME, the confidential data is the cookie which the client sends to the target server along his request.

If you have a server which does not exchange anything secret, in particular no cookie value, then there is no data to be leaked, hence no problem. Note that this is not restricted to cookies: if some secret requests are sent to the server (e.g. response to a login form with embedded password), then the attacker could try to use compression between that data and his forged request, since successive requests to the same server tend to reuse the same connection (TLS-level compression spans over the whole data flow, oblivious to HTTP request boundaries). We are talking about a server to which no secret data whatsoever is sent, and from which no secret data whatsoever is obtained. We must assume that not only the pictures are public data, but which picture is downloaded is also public information.

Note that enabling TLS-level compression will not buy you much anyway. Existing browsers do not support that compression any more, and pictures are already compressed.

Thomas Pornin
  • 320,799
  • 57
  • 780
  • 949