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
----------
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)
2011/09/14 03:00:36.325| SECURITY ALERT: By user agent:
Lynx/2.8.8dev.8 libwww-FM/2.14 SSL-MM/1.4.1 OpenSSL/0.9.8r
2011/09/14 03:00:36.325| SECURITY ALERT: on URL:
http://proxy.corp.fedex.com/cgi-bin/date.cgi
2011/09/14 03:00:36.325| errorpage.cc(1243) BuildContent: No existing
error page language negotiated for ERR_INVALID_REQ. Using default
error file.
2011/09/14 03:00:36.325| The reply for GET
http://proxy/cgi-bin/date.cgi is 1, because it matched 'all'
2011/09/14 03:00:36.325| 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 REPLY:
---------
HTTP/1.1 409 Conflict
Server: squid/3.HEAD-BZR
Mime-Version: 1.0
Date: Tue, 13 Sep 2011 19:00:36 GMT
Content-Type: text/html
Content-Length: 4279
X-Squid-Error: ERR_INVALID_REQ 0
Content-Language: en
X-Cache: MISS from proxy
X-Cache-Lookup: NONE from proxy:8080
Via: 1.1 proxy (squid/3.HEAD-BZR)
Connection: close
----------
2011/09/14 03:00:36.325| client_side.cc(765) swanSong:
local=192.168.243.1:8080 remote=192.168.243.1:33673 flags=1
Thanks,
Jeff
Received on Tue Sep 13 2011 - 19:07:09 MDT
This archive was generated by hypermail 2.2.0 : Wed Sep 14 2011 - 12:00:02 MDT