Re: substituing sniproxy for squid

[Luis Daniel Lucio Quiroz <luis.daniel.lucio@xxxxxxxxx>]

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@xxxxxxxxx>:

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   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@xxxxxxxxx>:

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@xxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users

_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users