curl -v -H 'Accept-Encoding: gzip' 'https://cdnjs.cloudflare.com/ajax/libs/Colors.js/1.2.2/colors.min.js'

As you can see, result is gzipped.

My assumption is since they are serving from 3rd party domain, it is safe for me. I only need to disable when it is served from my own domain, right?

  • 2
    Should be safe since the file content isn't secret. CRIME only broke confidentiality, not authenticity. – CodesInChaos Aug 13 '13 at 18:17

First note that you are not using SSL-level compression, but HTTP-level compression: there is a HTTP header which describes the mode of compression. The compression is applied to the HTTP response body only, i.e. the colors.min.js file, at the exclusion of anything else, in particular HTTP cookies or other such values.

Compression is unsafe when applied on secret values and the attacker has the possibility to get many examples of compressed data with the same secret repeated in all of them, but also with variants. In particular when the attacker gets to insert data chosen by him within the data sequence that is compressed.

In the case you show, there is no secret data at all; the data sequence that is compressed is a completely public piece of Javascript. Compression is abused into attacks by its ability to leak information about data contents through the data length (and the length is not protected by any subsequent encryption). If the source data is completely public, then there is no information to leak, and therefore no attack.

(Though colors.min.js is public, you still want to get over HTTPS, not for confidentiality but for integrity: you want to prevent active attackers from changing the Javascript code on the fly.)

Even if the compressed data was not public, a static file could still be served with compression, because compression is deterministic and would yield the exact same sequence of bytes every time, so, in particular, always the same length -- nothing to learn for the attacker.

  • Thanks, I am a little bit confused by SSL compression & HTTP compression, 1. are there any example of public site using SSL compression? Can it be checked via curl? 2. I assume HTTP compression also hurt security if the data is secret, right? – Ryan Aug 14 '13 at 3:54
  • SSL compression has been mostly deactivated everywhere in the aftermath of the CRIME attack. I don't think curl would show it; it is very internal to the SSL library. openssl s_client would tell you if the server allows compression, but since modern Web browsers don't support it anymore, it won't be used in practice. – Tom Leek Aug 14 '13 at 10:44
  • HTTP-level compression can hurt when that which is compressed contains both secret data and attacker-chosen data, in the same response body. Apparently this can happen in some web site; so-called "BREACH attack" seems to be a demonstration of such a thing. This depends on the Web site and its structure. Generally, "static pages" can be safely compressed, because, by being static, they won't include attacker-chosen data. – Tom Leek Aug 14 '13 at 10:47
  • 1
    You can keep compression for everything which is not in SSL. For things which are protected by SSL, you can safely keep compression for static pages; for anything generated dynamically, well... it depends. So the generic safe thing is to disable HTTP-level compression for all dynamic pages served over SSL. – Tom Leek Aug 15 '13 at 11:05
  • 1
    They have a potential problem. The Devil is in the details. See this site: to abuse HTTP compression into an attack, the site must offer a page which contains a secret that the attacker is after, and reflects some data that the attacker can choose. This may or may not apply to Yahoo's login page. – Tom Leek Aug 16 '13 at 17:32

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.