]> git.ipfire.org Git - thirdparty/squid.git/commit
Do not blindly forward cache peer CONNECT responses.
authorAlex Rousskov <rousskov@measurement-factory.com>
Sun, 28 Jun 2015 14:08:31 +0000 (07:08 -0700)
committerAmos Jeffries <squid3@treenet.co.nz>
Sun, 28 Jun 2015 14:08:31 +0000 (07:08 -0700)
commit74f35ca845c00f3b7a5bf97b23f19ce363fede25
tree63810a365c1142163ff6616412d1c7a1aedf104b
parent15c9c82c32f38f23ea6a36371a4c2dbef57e5f5f
Do not blindly forward cache peer CONNECT responses.

Squid blindly forwards cache peer CONNECT responses to clients. This
may break things if the peer responds with something like HTTP 403
(Forbidden) and keeps the connection with Squid open:
  -  The client application issues a CONNECT request.
  -  Squid forwards this request to a cache peer.
  -  Cache peer correctly responds back with a "403 Forbidden".
  -  Squid does not parse cache peer response and
     just forwards it as if it was a Squid response to the client.
  -  The TCP connections are not closed.

At this stage, Squid is unaware that the CONNECT request has failed. All
subsequent requests on the user agent TCP connection are treated as
tunnelled traffic. Squid is forwarding these requests to the peer on the
TCP connection previously used for the 403-ed CONNECT request, without
proper processing. The additional headers which should have been applied
by Squid to these requests are not applied, and the requests are being
forwarded to the cache peer even though the Squid configuration may
state that these requests must go directly to the origin server.

This fixes Squid to parse cache peer responses, and if an error response
found, respond with "502 Bad Gateway" to the client and close the
connections.
src/tunnel.cc