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, Why not? * 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. Amos _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
