Re: [squid-users] [PATCH] Host header forgery detected even with appendDomain

 On Wed, 14 Sep 2011 03:07:01 +0800, Jeff Chua wrote:
> On Tue, Sep 13, 2011 at 4:28 PM, Amos Jeffries <squid3_at_treenet.co.nz>
> wrote:
>> On 13/09/11 18:54, Jeff Chua wrote:
>>> Latest squid is prevent connection to my known servers without
>>> local
>>> domain name. The version prior to June 15 allow connecting to URLs
>>> without the fully qualified domain names as in "moose" instead of
>>> "moose.xxx.com"
>>>
>>> The latest squid is throw the follwing error:
>>>
>>> 2011/09/13 09:17:53.420 kid1| SECURITY ALERT: Host header forgery
>>> detected
>>> on local=192.168.243.1:8080 remote=192.168.243.1:59291 FD 11
>>> flags=1
>>> (moose does not match moose.xxx.com)
>>>
>>>
>>> Here's a patch to get around the problem. By specifying
>>> "append_domain
>>> .xxx.com", squid should allows host that matches the domain part.
>>> This is
>>> useful for get back the old behavior so I don't need to type the
>>> full
>>> URLs for many sites at work I'm dealing with.
>>
>>
>> Thank you for reporting this.
>>
>>  The header forgery detection of regular proxy traffic only that the
>> URL
>> domain name matches the Host: header content. Some RFC mandated
>> leniency
>> permits the protocol default port to be optional on top of this.
>>
>> Domain names with no dots are legitimate public FQDN. The URL is
>> expected to
>> contain the abbreviated hostname and the Host: header also contain
>> that
>> abbreviated name. Such that both match and pass under exactly the
>> same
>> criteria as any other traffic.
>> ----------
>>
>> Squid applied append_domain only later in the processing.
>
> Amos,
>
> Can you move this rule to apply first in the processing?
>
>
>> If your client agent is requesting a mixture of no-dots and dotted
>> domain
>> names something is broken outside of the verify procedure and needs
>> to be
>> fixed.
>
> Yes, it's both dots and non-dots.
>
>
>> Are you able to investigate a little further as to what the received
>> syntax is and where it is coming from please?
>> (a trace like the above can be found at debug level 11,2 in your
>> Squid)
>
>
> Here's the trace ...
>
>
> bv2011/09/14 03:00:36.324| TcpAcceptor.cc(187) doAccept: New
> connection on FD 14
> 2011/09/14 03:00:36.324| TcpAcceptor.cc(262) acceptNext: connection
> on
> local=0.0.0.0:8080 remote=[::] FD 14 flags=9
> 2011/09/14 03:00:36.324| HTTP Client local=192.168.243.1:8080
> remote=192.168.243.1:33673 FD 17 flags=1
> 2011/09/14 03:00:36.325| HTTP Client REQUEST:
> ---------
> GET http://proxy/cgi-bin/date.cgi HTTP/1.0
> Host: proxy
> Accept: text/html, text/plain, text/css, text/sgml, */*;q=0.01
> Accept-Encoding: gzip, compress, bzip2
> Accept-Language: en
> Pragma: no-cache
> Cache-Control: no-cache
> User-Agent: Lynx/2.8.8dev.8 libwww-FM/2.14 SSL-MM/1.4.1
> OpenSSL/0.9.8r
> Referer: http://proxy/cgi-bin/date.cgi
>
>
> ----------

 Hmm, exactly as expected from a working client. This should pass
 validation without doing any append, because "proxy" == "proxy".

 Then one of them ceases to be "proxy". :(

> 2011/09/14 03:00:36.325| SECURITY ALERT: Host header forgery detected
> on local=192.168.243.1:8080 remote=192.168.243.1:33673 FD 17 flags=1
> (proxy does not match proxy.corp.fedex.com)

 This is strange. I built and verified these same inputs would pass on
 yesterdays 3.HEAD (rev.11715) before sending that last email. How are
 you locating the 3.HEAD code? rsync/tarball/bzr/cvs? and how recently?

 Amos
Received on Wed Sep 14 2011 - 03:37:59 MDT