During the last few months there have again been a number of bug reports and queries from administrators seeing Zero Sized Reply error pages being produced by Squid 3.2 and later.
These “errors” are produced when Squid sends an HTTP request, then something out in the network goes wrong and the TCP connection gets severed while Squid is still waiting for the start of HTTP response to arrive. As you can imagine this is a little vague because that “something” is any one of a large set of potential networking problems.
Investigation of the old usual culprits in ECN, Window Scaling, PMTUd, and CONNECT proxying ruled them out leaving us mostly in the dark.
Testing without the proxy appeared to work fine. As did small short transactions even through the proxy. Leaving us more than a little confused.
The most common theme this time seems to be Windows based SSL/TLS services with recent but not top of the line software versions. IIS or Sharepoint on Server 2008 and 2010 for example.
Daniel Beschorner has done some investigating and reported this:
Since Squid 3.2 the SSL flag SSL_OP_ALL is no longer enabled by default in Squid. It enables different workarounds in the OpenSSL library.
Windows / IIS seems to get confused by empty packets (to mitigate the BEAST attack) sent from OpenSSL in TLS 1.0.
So the possibilities are:
- http://support.microsoft.com/kb/2634328 (patch your Windows)
- use TLS>1.0 (BEAST-safe by design)
- disable BEAST mitigation by ssloptions=ALL in squid.conf (insecure)
We have also had remarkably similar problem reports about iTunes servers. That one is still unconfirmed and unresolved.
The Squid Web Proxy/Cache Blog 