I understand, buggy I really need to take out this sniproxy in favor of squid.
I'm planning that this path needs the HTTP violation flag on compile time, and by default value is off. So when turning on, it won't be an accident.
Host_verify_header would be a good name for this on/off option
Le 24 mars 2016 4:05 AM, "Amos Jeffries" <squid3@xxxxxxxxxxxxx> a écrit :
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
