Re: /bzr/squid3/trunk/ r11783: Fixed typos in the host_verify_strict description.

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Tue, 11 Oct 2011 13:44:56 +1300

 On Mon, 10 Oct 2011 17:11:35 -0600, Alex Rousskov wrote:
> On 10/10/2011 04:29 PM, Amos Jeffries wrote:
>> On Mon, 10 Oct 2011 08:39:00 -0600, Alex Rousskov wrote:
>>> ------------------------------------------------------------
>>> revno: 11783
>>> committer: Alex Rousskov <rousskov_at_measurement-factory.com>
>>> branch nick: trunk
>>> timestamp: Mon 2011-10-10 08:39:00 -0600
>>> message:
>>> Fixed typos in the host_verify_strict description.
>>>
>>> Frankly, the description is likely to still make little sense to
>>> uninitiated because we do not explain what is "Host vs IP
>>> validation"
>>> and what the "additional strict validation comparisons" are.
>>> There was
>>> an attempt to explain the latter, but I think it failed. Perhaps
>>> there
>>> are more typos that hide the intended meaning?
>>> modified:
>>> src/cf.data.pre
>>
>> How about:
>>
>> "
>> By default on intercept and tproxy traffic Squid verifies that the
>
> What about 'off' setting? It is the default, but it is not exactly
> the
> opposite of 'on' in this case. Perhaps we should rephrase for
> clarity.
>

 'with' or 'for'.

 "With intercept and tproxy traffic Squid verifies that the"

 These are always tested. There is no off switch for the intercepted
 traffic.

> Regardless of this option setting, when dealing with intercept and
> tproxy traffic, Squid always verifies [your paragraph below].
>
> By default, and when set to 'off', no additional checks are
> performed.
>

 Okay.

>
>> destination IP address matches the Host: header domain or IP (called
>> 'authority form URL'). The client will be presented with a 409
>> Conflict
>> error page and Squid logs a security warning if they do not match.
>
> This part looks good to me. I would s/if they do not match/if there
> is
> no match/ because there were a few things "they" can potentially
> refer
> to, but this is very minor.
>

>
>> When set to ON, this option enables additional strict comparisons on
>> forward-proxy and reverse-proxy traffic passing through Squid.
>
> It is not clear to me whether setting this option to ON enables
> "additional comparisons", "comparisons on forward-proxy and
> reverse-proxy traffic", or both.

 Same thing. The textual only applies on the regular traffic types.
 I'm not sure how to put that more precisely.

> I do not know whether the description
> below matches code, but it could be clarified like this:
>
> When set to 'on', Squid will also verify forward-proxy and
> reverse-proxy traffic. In addition to checking all traffic types,
> Squid will also perform more checks. These extra tests involve ...
>
> Again, I am not saying that the above is what Squid does. I am just
> providing one possible interpretation of the current text.
>
>
>> These additional tests involve textual domain comparisons to
>> ensure that the client sends a consistent Host header for the
>> destination server mentioned in the URL.
>
> Is there any way we can be more specific here than "consistent Host
> header"? If I am getting a "409 Conflict error page" with
> host_verify_strict on, this description will not help me to
> understand
> why. Can we explicitly list the extra or "strict" requirements that
> we
> are trying to enforce here?

 RFC 2616 section 14.23 is what we are trying to enforce.
 "
    The Host field value MUST represent
    the naming authority of the origin server or gateway given by the
    original URL
 "

 My definition of "consistent" is that they point at the same machine(s)
 equally specific (raw-IP) or fuzzy (FQDN).

 We check:
  * if a hostname, domain FQDN, or IP -> must be identical (case-less
 comparison)
  * scheme default port is optional in one or both
  * scheme non-default port is required identical in both

 So far the exceptions are (in this order):
  * empty Host: header -> skips tests
  * non-existent Host: header -> skips tests
  * intercepted traffic -> does DNS vs Host comparisons only
  * this option set to 'off' -> skip all URL-vs-Host tests
  * CONNECT requests with missing port on Host: -> ignore the port test

 Amos
Received on Tue Oct 11 2011 - 00:45:04 MDT

This archive was generated by hypermail 2.2.0 : Wed Oct 12 2011 - 12:00:06 MDT