[squid-users] substituing sniproxy for squid

Amos Jeffries squid3 at treenet.co.nz
Thu Mar 24 08:05:07 UTC 2016


On 24/03/2016 3:56 p.m., Luis Daniel Lucio Quiroz wrote:
> 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?
> 

This is the CVE-2009-0801 protection.

Any patch altering it needs to retain that protection as there are known
attacks in the wild.


Also be aware that the SNI field of TLS is *not* a exact equivalent for
Host. SNI lacks the ability to distinguish relative vs absoute domains
and aternative port numbers - both of which are common occurances in
Host headers.

Amos



More information about the squid-users mailing list