On Wed, 14 Sep 2011 03:07:01 +0800, Jeff Chua wrote:
On Tue, Sep 13, 2011 at 4:28 PM, Amos Jeffries <squid3@xxxxxxxxxxxxx>
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
