Search squid archive

Re: substituing sniproxy for squid

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

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




[Index of Archives]     [Linux Audio Users]     [Samba]     [Big List of Linux Books]     [Linux USB]     [Yosemite News]

  Powered by Linux