[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