<div dir="ltr"><div>1. You're forgetting I only refer specific traffic using /etc/hosts to squid.</div><div>2. What do you suggest ? I want to use the SNI as the direction of the traffic, not the forwarded IP address.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 10, 2016 at 6:30 AM, Amos Jeffries <span dir="ltr"><<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 9/01/2016 7:48 a.m., Nir Krakowski wrote:<br>
> This is what needs to be done to get it to work in squid >3.5 in function<br>
> ClientRequestContext::hostHeaderIpVerify(const ipcache_addrs* ia, const<br>
> Dns::LookupDetails &dns):<br>
><br>
<br>
</span>Hell NO!!!!<br>
<br>
clientConn is the state data about the TCP connection the message<br>
arrived on. HTTP and SSL-Bump in no way alter the reality of what<br>
src/dst IPs those TCP packets contain.<br>
<br>
There may be a bug needing a fix, but it absolutely is not that patch.<br>
<br>
<br>
By applying that patch you are allowing a remote sender to both bypass<br>
all your Squid protections, and any network firewall security you may<br>
have external to Squid. While simultaneously recording in your Squid<br>
logs any value of its choosing for the destination IPs of its attack<br>
traffic.<br>
<span class="HOEnZb"><font color="#888888"><br>
Amos<br>
<br>
</font></span></blockquote></div><br></div>