Re: [PATCH] add DNT (Do Not Track) header

On 30/06/2012 7:47 p.m., Alexander Holler wrote:
> Am 27.06.2012 18:41, schrieb Alex Rousskov:
>> On 06/27/2012 05:09 AM, Alexander Holler wrote:
>>> Am 27.06.2012 12:57, schrieb Henrik Nordström:
>>>> ons 2012-06-27 klockan 10:45 +0200 skrev Alexander Holler:
>>>>>> Agreed. With the change to support arbitrary headers in
>>>>>> request_header_access this patch is not needed. We could also forget
>>>>>> many other less common headers.
>>
>>>>> It is, at least if people are using whitelists for headers which can
>>>>> pass the proxy.
>>
>>>> With the patch to support arbitrary headers in
>>>> request_header_access you
>>>> can match any header, and having the header defined in the source is
>>>> only an optimization for frequently accessed headers.
>>
>>> And it will require the need for a rewrite of the configuration and
>>
>> Would not both your patch and the general request_header_access patch
>> require configuration changes?
>
> No, the simple two-line-patch requires changes only if a
> header-whitelist is used _and_ DNT should be on this list. It also
> offers the possibility to use DNT in a blacklist environment, but I
> would assume that DNT isn't a header someone should (or want to)
> blacklist.
>
>>> doesn't help people which want or have to live with current versions.
>>
>> Both your patch and the general request_header_access patch can be
>> applied to "current versions". I agree that your patch is a lot easier
>> to port, of course. If general request_header_access is not backported,
>> your patch may be accepted for those versions instead.
>>
>>
>>> The patch was meant for the current (and maybe older) versions and I'm
>>> just unable to understand the high resistance to include such a simple
>>> two-line patch. Maybe the resistance is motivated by the header itself
>>> and not the patch, I don't know and have to speculate.
>>
>> You do not have to speculate. The resistance, at least on my part, is
>> motivated by the "death by thousands cuts" principle: Yes, we can
>> hard-code explicit handling of hundreds of headers that Squid does not
>> need to know about. Any single addition will help somebody and has
>> negligible negative side effects on its own, but in aggregate, they make
>> the code and performance worse.
>
> Sorry, I don't understand about what you are talking. Squid already uses
> hardcoded headers and the simple two-line patch just adds another one.
> No magic, no code degradation, no new bad algorithm. It just completes
> the already existing list of headers. It's that simple.

Funny you should point at top-10 dumest ideas in security below. We are
in the process of fixing bad idea #3. Enumerating goodness/badness was
found to be a dumb idea and rather than patching each mistaken piece of
good/bad we are re-writing the whole code segment to avoid hard-coded
enumeration.

>
> And that stupid patch should never have had engaged such a discussion,
> otherwise I never would have sent it, I didn't want to discuss the
> existing implementation with hardcoded headers nor did I want to discuss
> some other patches or better approaches.

Alexander, this simple patch is a workaround for a feature hole. A
feature hole which was at the time of submission in the process of being
closed. The short time it has taken this thread to discuss why we said
no about including it, that other patch has been completed, audited, and
passed for include into Squid.

As part of the audit I required that the other patch be presented in a
form suitable for backport to all existing Squid releases and the plan
is still to port it back at the earliest opportunity.

If I was to accept your patch, it would have been merged and removed
almost immediately along with all those other unnecessary headers which
have been registered in the past using patches just like this one. I'm
not happy with adding something non-standard to Squid. Particularly
given the likelihood it would have been added today and erased tomorrow.

>
>> This has nothing to do with the header itself. I know little about DNT,
>> but my response would be the same if the header was named DT :-)
>>
>>
>> BTW, do you or somebody you know run Squid with a white list of headers
>> (denying all other headers)? I am curious if such an approach can work
>> in a general deployment environment because it feels like it would break
>> many benign applications behind a proxy.
>
> I'm pretty sure whitelist configurations are used because of the
> second idea in "The six dumbest ideas in computer security". Besides
> that such an configuration is included (as comment) in the example
> configuration.

Well yes and no. When it comes to proxies, enumeration of goodness is
almost as dumb an idea as enumeration of badness. "Goodness" increases
randomly and unpredictably as HTTP headers are defined both by formal
specifications, corporation software developers, and even individual
developers.

>
> I don't know if those could be called "general deployment
> environments", but in today times where the need for a proxy to spare
> some traffic is often just non-existent, I'm not sure what a general
> deployment environment for a proxy is at all. Not to mention the
> existing warning (in the example configuration), that a white- or
> blacklist violates the HTTP standard. But I assume configurations
> which are using the [request|reply]_header_access directives can't be
> called "general deployment environments".

It comes down to a matter of definition. "Proxy" is a proxy, not a
nanny, governance caretaker, privacy filter, security gateway,
anti-virus, or anything else but a relay.

HTTP specification makes it abundantly clear that HTTP proxies MUST
relay all headers in both directions of flow without adding or removing
anything unless a specification supported by that proxy says to alter
it. Responsibility for their presence and content is placed on the
client and server software.

/rant warning

It is NOT the proxies place, nor the network administrators place to
edit their clients web traffic. A properly operating proxy simply relays
the requests and responses at high speed. The correct choice being to
*reject* requests which contain private information, etc. (despite
having no way of informing the client why such a rejection was done).
Altering things in the middle makes everything appear happy, but is
actually creating a set of lies in the traffic which slows the traffic
down as lies are added/removed, sometimes a LOT. The need people have of
doing this is a failure of browser and other client-end software
configuration or the user knowledge about how to do that configuration.

So yes, the warning, is exactly that. A *warning*. That by using the
config directive you are violating the RFC standards requirmets on HTTP
proxy. Problems of any kind (erasure of DNT and several other similar
attempts at features, being one such problem) are your own
responsibility, not ours.

/rant

Amos
Received on Sat Jun 30 2012 - 09:47:46 MDT