Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.
Sign up to join this community
I have read that BREACH was a side channel compression attack against TLS however focuses on HTTP response compression. If a site has disabled support for TLS compression does that still mean it can be compromised by an attack such as CRIME, BREACH, etc...using HTTP compression/HTTP responses?
Also, does this type of attack require compression support from both the browser and the server to be successful?
From the BREACH Wikipedia page:
BREACH exploits the compression in the underlying HTTP protocol. Therefore, turning off TLS compression makes no difference to BREACH, which can still perform a chosen-plaintext attack against the HTTP payload.
However CRIME can be mitigated by removing support for TLS compression.
In TLS the compression algorithm is negotiated between the client and server. The client proposes a list of suitable algorithms, and the server chooses one from that set. They have to agree upon an algorithm, and if they don't then the connection fails. So for CRIME it would require compression support from both ends.
However, as it was stated above for BREACH the HTTP compression is exploited, not the TLS compression. HTTP Compression:
HTTP data is compressed before it is sent from the server: compliant browsers will announce what methods are supported to the server before downloading the correct format; browsers that do not support compliant compression method will download uncompressed data.
Based on this, both the client and server would have to support some kind of compression (generally GZIP or DEFLATE) for this attack to work.
BREACH and CRIME don't compromise sites, because they are attacks on clients, not on servers. The server is still involved in that, for instance, TLS compression won't be used unless the server agrees; so that, even if the CRIME attack targets the client, the server can refuse to use compression and this indirectly protects vulnerable clients.
Both attacks relate to the same general principle: encryption hides data contents, but not data size. Compression makes data size dependent on data contents. Therefore, compression can leak information on data contents that encryption won't protect. If the attacker is in a position where he can inject some data of his own along with the data that he tries to recover (formally, a chosen-plaintext attack), then he wins.
CRIME was an application of this concept to TLS-level compression in a Web context. The Web allows for Javascript, that can be hostile and issue requests (subject to some constraints in the case of cross-site requests); this is how the attacker can achieve a CPA situation. Deactivating TLS-level compression fixes the issue, and it was not really fixable in any other way, because the compression-induced data leakage is a very generic concept. Note that HTTP-level compression does nothing for or against CRIME, since CRIME concentrates on the header (the request path and the cookie).
BREACH is another application of the concept, this time on HTTP-level compression. HTTP-level compression is performed only on request bodies, not on the HTTP headers, so BREACH is harder to pull off (while CRIME worked whenever a cookie was involved, BREACH requires the site contents to be amenable in some way to the attack). Disabling TLS compression will do nothing for or against BREACH.
Anyway, compression (be it for TLS or only for HTTP request/response bodies) will be applied by any machine only if it is reasonably sure that the machine at the other end of the connection will understand it -- because of some prior indication to that effect (in the TLS ClientHello message for TLS, in a request header for HTTP). There will be no compression, hence no attack, unless both client and server support it and agree to use it. This is how mitigation for attacks on clients can be applied on the server.
