CRIME mitigation involves disabling TLS compression. My server offers services only via XML-RPC and does not make use of Cookies, which is what CRIME exploits. Does this mean that I can turn on TLS compression without worrying about being compromised? We use basic access authentication which seems like it would be equally as vulnerable to the CRIME attack as cookies.

  • What is the client for your application? Is it a bespoke client, or a web browser?
    – paj28
    Dec 10, 2013 at 11:28
  • A proprietary XML-RPC client.
    – ChaimKut
    Dec 10, 2013 at 11:54
  • If server and client cooperate, they can apply a mask to the secret which differs on each request. Dec 10, 2013 at 12:38
  • @ChaimKut in that case you don't need to worry about CRIME. The exploit relies on the attacker being able to make cross-site requests from a browser.
    – paj28
    Dec 10, 2013 at 14:25

2 Answers 2


The CRIME attack is about making the target client to send phony GET requests to the server, such that each request:

  1. contains the path chosen by the attacker,
  2. and also contains some secret value that the attacker is interested in.

A practical implementation, when the client is a Web browser, is some malicious Javascript which manipulates the DOM to make hidden <img> tags. Each such tag makes the client do a GET to the server.

If the client is configured to automatically send the user password, as part of Basic Authentication, in the relevant header for each request, then it can be attacked just like a cookie. CRIME applies.

An important point, though, is that CRIME is a Chosen-Plaintext Attack: it works in contexts where the attacker can make the victim issue requests containing both the secret value, and some data that the attacker can choose. This certainly applies to a Web browser, but not necessarily to other contexts such as a custom XML-RPC client. It really depends on what the requests contain.

In general, compression of any kind inherently increases information leaks, because encryption does not hide data size, and compression makes data size dependent on data contents. The specific case of CRIME is when the compression is applied at the SSL level, because it then encompasses an area (the HTTP headers) full of values which are, from the point of view of the attacker, very juicy. However, if there is a secret value that the attacker wants to obtain, such that the value is located in the request bodies, then HTTP-level compression could be equally vulnerable.

If you want the benefits of compression, then you will also get the disadvantages of compression, namely this increase in leaks. This requires some thorough, specific analysis.

(Note that size-related leakages are not specific to compression; text-based representations, e.g. a decimal integer in XML, can also have a variable size which depends on the exact data contents; however, compression exacerbates the issue, making it much easier to turn the leak into a successful attack.)


It doesn't really matter if crime is attacking your cookie value or your basic auth. In the end it's just decrypting a certain value.

  • I ask because all of the various sources of information about CRIME, like threatpost.com/… , all emphasize stealing cookies and I haven't seen basic access auth mentioned anywhere (even though it seems like it would be similarly vulnerable).
    – ChaimKut
    Dec 10, 2013 at 11:56
  • because the demonstration itself was performed on cookies. CRIME is still very hard to pull off in real life. Just a quick question why you wouldn't just disable compression Dec 10, 2013 at 12:16
  • Was simply wondering if I could still take advantage of savings allowed by compression. If basic access is also vulnerable, though, then I'll need to disable.
    – ChaimKut
    Dec 10, 2013 at 12:32
  • remember that SSL/TLS takes part on a layer 6 and not layer 7. Dec 10, 2013 at 12:41

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .