<div dir="ltr">As A side note, I am reading the code seems file<div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">src/client_side_request.cc </span></span>function <span style="color:rgb(0,0,0);font-family:monospace">ClientRequestContext::hostHeaderVerify() </span>is responsible for this. </div><div><br></div><div>And to be exact this option:</div><div><span style="font-family:monospace"><span style="color:rgb(0,0,0)">    if (ia != NULL && ia->count > 0) {
</span><br>        // Is the NAT destination IP in DNS?
<br>        for (int i = 0; i < ia->count; ++i) {
<br>            if (clientConn->local.matchIPAddr(ia->in_addrs[i]) == 0) {
<br>                debugs(85, 3, HERE << "validate IP " << clientConn->local << " possible from Host:");
<br>                http->request->flags.hostVerified = true;
<br>                http->doCallouts();
<br>                return;
<br>            }
<br>            debugs(85, 3, HERE << "validate IP " << clientConn->local << " non-match from Host: IP " << ia->in_addrs[i]);
<br>        }
<br>    }
<br>    debugs(85, 3, HERE << "FAIL: validate IP " << clientConn->local << " possible from Host:");
<br>    hostHeaderVerifyFailed("local IP", "any domain IP");<br>
<br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace"><br></span></div><div><span style="font-family:monospace">As far as I understand there is no a possible way.</span></div><div><span style="font-family:monospace">Would you be interested on a patch to allow this behaivour optional?</span></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>--</div><div>Luis Daniel Lucio Quiroz<br>CISSP, CISM, CISA<br>Linux, VoIP and much more fun<br><a href="http://www.okay.com.mx" target="_blank">www.okay.com.mx</a><br><br>Need LCR? Check out LCR for FusionPBX with FreeSWITCH<br>Need Billing? Check out Billing for FusionPBX with FreeSWITCH</div></div></div></div>
<br><div class="gmail_quote">2016-03-23 21:25 GMT-04:00 Luis Daniel Lucio Quiroz <span dir="ltr"><<a href="mailto:luis.daniel.lucio@gmail.com" target="_blank">luis.daniel.lucio@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Thanks<div><br></div><div>Well, I am now stuck with the <span style="color:rgb(0,0,0);font-family:monospace">Host header forgery detected </span></div><div>Which it means that client and squid resolve different IP (in my use case that is what I want).</div><div><br></div><div>I already have <span style="color:rgb(0,0,0);font-family:Arial,'Lucida Grande',sans-serif;font-size:13.6px;line-height:17px"> </span><a href="http://www.squid-cache.org/Doc/config/host_verify_strict" title="SquidConf" style="color:rgb(89,123,179);border:0px;font-family:Arial,'Lucida Grande',sans-serif;font-size:13.6px;line-height:17px" target="_blank">host_verify_strict</a><span style="color:rgb(0,0,0);font-family:Arial,'Lucida Grande',sans-serif;font-size:13.6px;line-height:17px"> </span>  disabled, but that is not enough.  </div><div><br></div><div>Any advice? (Rather than do a patch and disable that verification? )</div></div><div class="gmail_extra"><br clear="all"><div><div><div dir="ltr"><div>--</div><div><span class="">Luis Daniel Lucio Quiroz<br>CISSP, CISM, CISA<br>Linux, VoIP and much more fun<br><a href="http://www.okay.com.mx" target="_blank">www.okay.com.mx</a><br><br></span>Need LCR? Check out LCR for FusionPBX with FreeSWITCH<br>Need Billing? Check out Billing for FusionPBX with FreeSWITCH</div></div></div></div><div><div class="h5">
<br><div class="gmail_quote">2016-02-01 16:31 GMT-05:00 Luis Daniel Lucio Quiroz <span dir="ltr"><<a href="mailto:luis.daniel.lucio@gmail.com" target="_blank">luis.daniel.lucio@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Thank you</p>
<p dir="ltr">I understand what you mean, but ssl/tls will warm the browser if something is modified.</p><div><div>
<div class="gmail_quote">Le 1 févr. 2016 7:08 AM, "Amos Jeffries" <<a href="mailto:squid3@treenet.co.nz" target="_blank">squid3@treenet.co.nz</a>> a écrit :<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 1/02/2016 11:35 a.m., Luis Daniel Lucio Quiroz wrote:<br>
> Hello<br>
><br>
> Can anyone give some clue, link something to read on how to do the HTTPs<br>
> work with SNI, i just want to forward to the correct server based on the<br>
> SNI. I want to get rid of SNIproxy in favor of squid.<br>
<br>
That should be possible with Squid-3.5 or later by intercepting the port<br>
443 traffic (*not* reverse-proxy / accel) and using:<br>
<br>
 acl step1 at_step SslBumpStep1<br>
 ssl_bump peek step1<br>
 ssl_bump splice all<br>
<br>
But be aware that SNI does not provide any guarantee of "correct<br>
server". HTTP (even in its 'HTTPS' form) is a multiplexed messaging<br>
protocol. When you do the above Squid will not be able to protect you<br>
against any Host header attacks buried inside the TLS layer - not that<br>
sniproxy does either (in fact sniproxy seems by design to actively<br>
_enable_ those type of vulnerabilities).<br>
<br>
Amos<br>
<br>
_______________________________________________<br>
squid-users mailing list<br>
<a href="mailto:squid-users@lists.squid-cache.org" target="_blank">squid-users@lists.squid-cache.org</a><br>
<a href="http://lists.squid-cache.org/listinfo/squid-users" rel="noreferrer" target="_blank">http://lists.squid-cache.org/listinfo/squid-users</a><br>
</blockquote></div>
</div></div></blockquote></div><br></div></div></div>
</blockquote></div><br></div>