CRIME like attack and locality of randomized data

Question

I am not an information security expert (just a developer) and recently discovered this kind of vulnerability, and have a few questions (so sorry if I misinterpreted something about how the attack works).

In the product I am developing where i'm employed, there are two cookies, a regular session cookie and a cookie with an authorization token inside (it is not relevant why I need two cookies).

Both live as long as the session is live, but because i am a bit paranoid i made the authorization token encrypted.

What I mean is that the random string (the authorization token) that never changes (server-side) through the session lifespan is not sent in plaintext (the client never knows his authorization token) but is encrypted with AES CBC before sending it to the client. I think it's particularly relevant that IV is changed for each request, so basically authorization token is a constant 200B long sting, of random data that changes for each request.

Is that enough to break the relation between compressed text and length, or does the relation also involve where data are?

I mean if the session cookie (that an attacker would like to guess) is at the beginning of the request, and the random authorization cookie is at the bottom, even if randomized it's too far to give me any benefit (I expect gzip have some locality in applying compression).

Answer 1

I think you misunderstand the CRIME attack.

The fixed length of the cookie value is irrelevant, as is the fact that it's encrypted and changed after each request. I'm not even sure what you're trying to achieve by encrypting the cookie value, because what you describe (random fixed-length value) seems to be no different than a plain old session cookie. But that's another topic.

In a CRIME attack, the attacker triggers HTTPS request to the target server, using the path as input. Since both the path and the secret cookie value are included in the same request, the size of the compressed request will depend on whether the attacker's input matches the cookie value. As a simplified example: Let's assume your encrypted cookie value is auth=7pn1. The attacker now tries different paths: /auth=0, /auth=1, /auth=2, ..., /auth=a, ... When they reach /auth=7, they'll observe that the compressed request size is smaller than in the other cases. The reason is that the cookie value actually begins with auth=7, allowing the compression algorithm to get rid of this redundancy and reduce the request size. Next the attacker tries /auth=70, /auth=71, /auth=72, ..., /auth=7a, ... Again they'll observe a reduced size when they reach /auth=7p, because their guess matches the first two bytes of the cookie value. They continue until they know the complete cookie value auth=7pn1.

It's irrelevant that some script on your server would change the authorization cookie after each request, because the attacker will never send the request to this script. From the server's perspective, the request paths used in the attack are simply nonexistent and will probably result in a 404 response.

Note that CRIME doesn't work in any recent browser, because it relies on TLS-level compression which is now deactivated. Other compression-related attacks like BREACH work differently, since they attack the responses rather than the requests. The value of cookies or the location of HTTP headers isn't relevant in this case, only what gets reflected in the server response (e.g. anti-CSRF tokens embedded into forms).