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

Ping.

I'm just waiting on finalization of the update to these docs before I
release 3.2.0.13 and port the verify checks down to 3.1.16.

Amos

On 11/10/11 13:44, Amos Jeffries wrote:
> 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 Wed Oct 12 2011 - 08:00:09 MDT