squid3 at treenet.co.nz
Fri Dec 18 23:52:06 UTC 2015
On 19/12/2015 12:30 p.m., dc wrote:
> Thank you very much for this detailed explanation!
> I have a setup where squid doesn't know about the original destination
> IP address,
* NAT/TPROXY is mandatory to happen on the Squid machine directly since
kernel and Squid are performing integrated operations.
* PROXY protocol passes the ORIGINAL_DST explicitly over the wire.
* SSL-Bump all happens "inside Squid".
Those are the only forms of interception Squid supports.
> so I tried to enforce using DNS responses as destination
> addresses for any request, without success. Looking at the relevant code
> I found the limitation (and CVE) to be quite obscure, but now I know why
> it's there.
> Since the vulnerability can't be exploited in my case anyway, I have
> altered the code to allow the replacement of the destination address
> regardless of a mismatch of the original dst.
If you are intercepting it can always be exploited. The browser sandbox
is just the easiest/common way to do so, with a known malware strain.
Any client capable of sending requests via an interception proxy can
achieve the same result with normal TCP connections.
If you are not intercepting then it is not relevant. Misconfigured
reverse proxy need to be fixed in the squid.conf and network design levels.
More information about the squid-users