Considerations for Protocols with Compression over TLS

Transport Layer Security is, needless to say, essential to contemporary customs in the Internet like secret communications on the web. Names, passwords, telephone numbers, credit card numbers, messages, session ids, and any other secrets are transported on TLS. Therefore, protecting TLS and underlying Public Key Infrastructure is our fundamental task. Unfortunately, TLS and PKI are not infallible, and sometimes vulnerable to new attack vectors. This document describes conditions for the CRIME attack which utilizes differences of compression rates to guess secret information from outside the encrypted transports and proposes possible mitigations of the threat that should be considered when someone designs protocols with compression.

"Commonly-used lossless compression algorithms leak information about the data being compressed, in the size of the compressor output." In other words, by nature compressing data has the risk of information leakage. Usually information from the size of compressed data is not enough to guess the secret easily; however, under some conditions the attack becomes much easier. Observing encrypted data itself is not so useful. Though, if the attacker can inject string into the compression context where the secret is compressed, the attacker would be able to know whether the injected string matches the secret or not. In addition, difference of the size of the compressed data in multiple tries will help the attacker to perform brute-force attacks. [[[More precise conditions are needed. For example, initalizing compression contexts on each try will be a great help.]]] [[[Note that ANY KIND OF COMPRESSION WILL REVEAL SECRETS REGARDLESS OF THE LAYER OF COMPRESSION, including TLS compression, SPDY, and HTTP gzip.]]]

The original CRIME is targeted at HTTP. Web browsers tend to make requests according to malicious scripts, sending secret strings automatically together with injected strings by the scripts. To make matters worse, TLS compression and SPDY had been compressing all data in the same context. Therefore, stealing session cookies by the CRIME attack was very easy. As a workaround, some web browsers disabled TLS compression and SPDY compression partially so that session cookies and bearer-token-type Authorization tokens cannot be stolen. However, compression of HTTP entities is still available and it is possible to guess some protions of HTTP entities if servers return injected strings in HTTP entities.

[[[More applications are needed? Currently we have not found such applications.]]]

In principle, abandon of compression completely solves the problem of information leakage by compression. It is &RECOMMENDED; to disable compression when communications are not trivial, unless traffic increase is considerable. If data are confidentital and other mitigations are inapplicable, all kinds of compression &MUST; be disabled.

The problem that this document describes is information leakage by compression. However, if transferred data are not sensitive, we do not have to take care of the problem. Therefore compressing non-sensitive data will save bandwidth without exposing sensitive data. Note that dynamically-generated contents can contain sensitive data and SHOULD NOT be compressed.

The CRIME attack utilizes differences of compression rate to estimate that the candidate string matches the sensitive data or not. In order to prevent such attacks, using static dictionary will be effective, especially when compressing patterned contents like HTTP headers.

If it is unavoidable to compress whole data in the same context, inserting random paddings will be available to prevent disclosure of the original size of compressed data. Note that this mitigation cannot prevent attackers from guessing secrets by statistical approaches. [[[Requirements of padding (ranges of length, randomness, and so on) and quantitative evaluations are needed.]]]

To achieve attacks on compression, attackers have to make multiple traffics in order to observe differences of compresion rate. Therefore, detecting too frequent requests and blocking such requests will mitigate attacks. Note that this mitigation cannot prevent attacks completely and &SHOULD; be used with other mitigations.

[[[There should be more mitigations.]]]

This document focuses on security.

This document does not require actions by IANA.