[squid-users] substituing sniproxy for squid

[Luis Daniel Lucio Quiroz]

As A side note, I am reading the code seems file
src/client_side_request.cc function
ClientRequestContext::hostHeaderVerify() is responsible for this.

And to be exact this option:
    if (ia != NULL && ia->count > 0) {
       // Is the NAT destination IP in DNS?
       for (int i = 0; i < ia->count; ++i) {
           if (clientConn->local.matchIPAddr(ia->in_addrs[i]) == 0) {
               debugs(85, 3, HERE << "validate IP " << clientConn->local <<
" possible from Host:");
               http->request->flags.hostVerified = true;
               http->doCallouts();
               return;
           }
           debugs(85, 3, HERE << "validate IP " << clientConn->local << "
non-match from Host: IP " << ia->in_addrs[i]);
       }
   }
   debugs(85, 3, HERE << "FAIL: validate IP " << clientConn->local << "
possible from Host:");
   hostHeaderVerifyFailed("local IP", "any domain IP");



As far as I understand there is no a possible way.
Would you be interested on a patch to allow this behaivour optional?

--
Luis Daniel Lucio Quiroz
CISSP, CISM, CISA
Linux, VoIP and much more fun
www.okay.com.mx

Need LCR? Check out LCR for FusionPBX with FreeSWITCH
Need Billing? Check out Billing for FusionPBX with FreeSWITCH

2016-03-23 21:25 GMT-04:00 Luis Daniel Lucio Quiroz <
luis.daniel.lucio at gmail.com>:

> Thanks
>
> Well, I am now stuck with the Host header forgery detected
> Which it means that client and squid resolve different IP (in my use case
> that is what I want).
>
> I already have  host_verify_strict
> <http://www.squid-cache.org/Doc/config/host_verify_strict>   disabled,
> but that is not enough.
>
> Any advice? (Rather than do a patch and disable that verification? )
>
> --
> Luis Daniel Lucio Quiroz
> CISSP, CISM, CISA
> Linux, VoIP and much more fun
> www.okay.com.mx
>
> Need LCR? Check out LCR for FusionPBX with FreeSWITCH
> Need Billing? Check out Billing for FusionPBX with FreeSWITCH
>
> 2016-02-01 16:31 GMT-05:00 Luis Daniel Lucio Quiroz <
> luis.daniel.lucio at gmail.com>:
>
>> Thank you
>>
>> I understand what you mean, but ssl/tls will warm the browser if
>> something is modified.
>> Le 1 févr. 2016 7:08 AM, "Amos Jeffries" <squid3 at treenet.co.nz> a écrit :
>>
>>> On 1/02/2016 11:35 a.m., Luis Daniel Lucio Quiroz wrote:
>>> > Hello
>>> >
>>> > Can anyone give some clue, link something to read on how to do the
>>> HTTPs
>>> > work with SNI, i just want to forward to the correct server based on
>>> the
>>> > SNI. I want to get rid of SNIproxy in favor of squid.
>>>
>>> That should be possible with Squid-3.5 or later by intercepting the port
>>> 443 traffic (*not* reverse-proxy / accel) and using:
>>>
>>>  acl step1 at_step SslBumpStep1
>>>  ssl_bump peek step1
>>>  ssl_bump splice all
>>>
>>> But be aware that SNI does not provide any guarantee of "correct
>>> server". HTTP (even in its 'HTTPS' form) is a multiplexed messaging
>>> protocol. When you do the above Squid will not be able to protect you
>>> against any Host header attacks buried inside the TLS layer - not that
>>> sniproxy does either (in fact sniproxy seems by design to actively
>>> _enable_ those type of vulnerabilities).
>>>
>>> Amos
>>>
>>> _______________________________________________
>>> squid-users mailing list
>>> squid-users at lists.squid-cache.org
>>> http://lists.squid-cache.org/listinfo/squid-users
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squid-cache.org/pipermail/squid-users/attachments/20160323/63f68df3/attachment.html>