Re: [squid-users] SSL Attacks against Squid in reverse proxy mode

On 17/10/2012 4:34 p.m., Will Roberts wrote:
> Hi,
>
> I'm using squid 3.1.20 as a reverse proxy to provide an SSL frontend
> as well as caching.
>
> I'm looking for configuration directives that would allow me to
> prevent squid from being susceptible to CRIME. Is there a way to pass
> a flag to the SSL library to disable compression (CRIME)?
>
> Thanks,
> --Will

CRIME operates by gleaning clues about the transmitted data (not the
keys!) from measuring how crafted requests get compressed and
transmitted. There are a couple of factors in Squid which prevent it
being vulnerable, or at worst no more vulnerable than HTTPS has ever been.

* Squid does not support SPDY protocol. The ease of CRIME stems from
SPDY mandatory compression of headers providing a consistent compression
dictionary across long-duration and multiple requests. Resulting in
effectivly a guarantee that crafted requests were comparable to the
attacked clients requests while also amplifiing the amount of available
attack clues with compression of headers.

* Squid does not support compression of headers. So information within
headers remains secure uness the SSL keys are broken via other means.
The indeterminate size of HTTP headers in between objects which may (or
may not) be compressed moves the blocks of data where useful clues can
be gleaned via CRIME in an almost unpredictable way. Also, each
compressed object in HTTP has its own dictionary - further raising the
difficulty of locating clues.

So risk of CRIME on regular HTTPS as serviced by Squid is quite low.

For the super paranoid;
   Squid acting as a reverse-proxy is able to alter the relayed request
headers and strip away the Accept-Encoding headers sent by the client
using "request_header_access Accept-Encoding deny all". Which should
result in the Server producing uncompressed responses even if the client
advertises compression support to Squid.
   This does not work on CONNECT requests where Squid has zero control
over what goes through inside the TLS encrypted tunnel. But then again,
for those requests Squid is not adding to the vulnerability either.

As for OpenSSL;
  IF you can find an OpenSSL flag that controls compression in the TLS
layer itself, any flags supported by the SSL library can be passed with
an sslflags= option; on https_port for incoming traffic, on cache_peer
for backend server links, or as sslproxy_sslflags for outbound HTTPS
connections (other than cache_peer links). If Squid does not accept a
flag already we will happily accept patches to add it.

HTH
Amos
Received on Wed Oct 17 2012 - 09:01:06 MDT