Tweeted twitter.com/#!/StackSecurity/status/249116120257282048
2 provide some links to justify the claims
source | link

The CRIME attack taught us that using compression can endanger confidentiality. In particular, it is dangerous to concatenate attacker-supplied data with sensitive secret data and then compress and encrypt the concatenation; any time we see that occurring, at any layer of the system stack, we should be suspicious of the potential for CRIME-like attacks.

Now the CRIME attack, at least as it has been publicly described so far, is an attack on TLS compression. Background: TLS includes a built-in compression mechanism, which happens at the TLS level (the entire connection is compressed). Thus, we have a situation where attacker-supplied data (e.g., the body of a POST request) gets mixed with secrets (e.g., cookies in the HTTP headers), which is what enabled the CRIME attack.

However there are also other layers of the system stack that may use compression. I am thinking especially of HTTP compression. The HTTP protocol has built-in support for compressing any resources that you download over HTTP. When HTTP compression is enabled, compression is applied to the body of the response (but not the headers). HTTP compression will be enabled only if both the browser and the server support it, but most browsers and many serversmany servers do, because it improves performance. Note that HTTP compression is a different mechanism from TLS compression; HTTP compression is negotiated at a higher level of the stack, and only applies to the body of the response. However, HTTP compression can be applied to data that is downloaded over a SSL/TLS connection, i.e., to resources downloaded via HTTPS.

My question: Is HTTP compression safe to use, on HTTPS resources? Do I need to do something special to disable HTTP compression of resources that are accessed over HTTPS? Or, if HTTP compression is somehow safe, why is it safe?

The CRIME attack taught us that using compression can endanger confidentiality. In particular, it is dangerous to concatenate attacker-supplied data with sensitive secret data and then compress and encrypt the concatenation; any time we see that occurring, at any layer of the system stack, we should be suspicious of the potential for CRIME-like attacks.

Now the CRIME attack, at least as it has been publicly described so far, is an attack on TLS compression. Background: TLS includes a built-in compression mechanism, which happens at the TLS level (the entire connection is compressed). Thus, we have a situation where attacker-supplied data (e.g., the body of a POST request) gets mixed with secrets (e.g., cookies in the HTTP headers), which is what enabled the CRIME attack.

However there are also other layers of the system stack that may use compression. I am thinking especially of HTTP compression. The HTTP protocol has built-in support for compressing any resources that you download over HTTP. When HTTP compression is enabled, compression is applied to the body of the response (but not the headers). HTTP compression will be enabled only if both the browser and the server support it, but most browsers and many servers do. Note that HTTP compression is a different mechanism from TLS compression; HTTP compression is negotiated at a higher level of the stack, and only applies to the body of the response. However, HTTP compression can be applied to data that is downloaded over a SSL/TLS connection, i.e., to resources downloaded via HTTPS.

My question: Is HTTP compression safe to use, on HTTPS resources? Do I need to do something special to disable HTTP compression of resources that are accessed over HTTPS? Or, if HTTP compression is somehow safe, why is it safe?

The CRIME attack taught us that using compression can endanger confidentiality. In particular, it is dangerous to concatenate attacker-supplied data with sensitive secret data and then compress and encrypt the concatenation; any time we see that occurring, at any layer of the system stack, we should be suspicious of the potential for CRIME-like attacks.

Now the CRIME attack, at least as it has been publicly described so far, is an attack on TLS compression. Background: TLS includes a built-in compression mechanism, which happens at the TLS level (the entire connection is compressed). Thus, we have a situation where attacker-supplied data (e.g., the body of a POST request) gets mixed with secrets (e.g., cookies in the HTTP headers), which is what enabled the CRIME attack.

However there are also other layers of the system stack that may use compression. I am thinking especially of HTTP compression. The HTTP protocol has built-in support for compressing any resources that you download over HTTP. When HTTP compression is enabled, compression is applied to the body of the response (but not the headers). HTTP compression will be enabled only if both the browser and the server support it, but most browsers and many servers do, because it improves performance. Note that HTTP compression is a different mechanism from TLS compression; HTTP compression is negotiated at a higher level of the stack, and only applies to the body of the response. However, HTTP compression can be applied to data that is downloaded over a SSL/TLS connection, i.e., to resources downloaded via HTTPS.

My question: Is HTTP compression safe to use, on HTTPS resources? Do I need to do something special to disable HTTP compression of resources that are accessed over HTTPS? Or, if HTTP compression is somehow safe, why is it safe?

1
source | link

Is HTTP compression safe?

The CRIME attack taught us that using compression can endanger confidentiality. In particular, it is dangerous to concatenate attacker-supplied data with sensitive secret data and then compress and encrypt the concatenation; any time we see that occurring, at any layer of the system stack, we should be suspicious of the potential for CRIME-like attacks.

Now the CRIME attack, at least as it has been publicly described so far, is an attack on TLS compression. Background: TLS includes a built-in compression mechanism, which happens at the TLS level (the entire connection is compressed). Thus, we have a situation where attacker-supplied data (e.g., the body of a POST request) gets mixed with secrets (e.g., cookies in the HTTP headers), which is what enabled the CRIME attack.

However there are also other layers of the system stack that may use compression. I am thinking especially of HTTP compression. The HTTP protocol has built-in support for compressing any resources that you download over HTTP. When HTTP compression is enabled, compression is applied to the body of the response (but not the headers). HTTP compression will be enabled only if both the browser and the server support it, but most browsers and many servers do. Note that HTTP compression is a different mechanism from TLS compression; HTTP compression is negotiated at a higher level of the stack, and only applies to the body of the response. However, HTTP compression can be applied to data that is downloaded over a SSL/TLS connection, i.e., to resources downloaded via HTTPS.

My question: Is HTTP compression safe to use, on HTTPS resources? Do I need to do something special to disable HTTP compression of resources that are accessed over HTTPS? Or, if HTTP compression is somehow safe, why is it safe?