Amos Jeffries wrote:
>> Amos Jeffries wrote:
>>>> So of course the problem is proventia corrupting the HTTP headers and
>>>> we will raise an issue about that with IBM.
>>>>
>>>> But for the time being: is there a chance to make squid more
>>>> "tolerant" about those kind of problems? Without surprize I did not
>>>> find any fitting config options :-)
>>>>
>>> Not nearly as easy as it will be for IBM to issue a fix for it. Or even
>>> to replace the box with free software that works well.
>> Hehe, sure, no objections, it is just the world being far from perfect :-)
>>
>>> Not also without opening some potential data-injection and cache
>>> poisoning flaws into Squid.
>>>
>>> Consider what happens with:
>>>
>>> HTTP/1.1 200 OK
>>> Bwahaha: "
>>> Cache-Control: private
>>>
>>> ...something you really did not want public...
>>> .
>>>
>>> vs:
>>>
>>> HTTP/1.1 200 OK
>>> Content-Type: "fu
>>> bar: tender: and: wine"
>>> Cache-Control: private
>> Hmm, reading the specs for HTTP message headers [1] I think this could
>> be done without imposing security issues. As per specification your last
>> example would read correctly:
>>
>> -------CUT-------
>> HTTP/1.1 200 OK
>> Content-Type: "fu
>> bar: tender: and: wine"
>> Cache-Control: private
>> -------CUT-------
>>
>> note the leading whitespace.
>
> I know. Both of what I pointed are two cases of the same brokenness. Squid
> handles the one is can interpret 'safely'[1] (second), but at expense of
> dropping the first set when no termination can be found at all and its
> clearly very unsafe to make assumptions.
>
> [1] for some vague value of safe the paranoid in me gets very edgy about
> as-is.
Yes, I understand, thanks for the clearance.
I agree that problems should be fixed where they occur and workarounds
should remain the exception.
-- Udo Rader, CTO http://www.bestsolution.at http://riaschissl.blogspot.comReceived on Thu Apr 23 2009 - 08:36:28 MDT
This archive was generated by hypermail 2.2.0 : Thu Apr 23 2009 - 12:00:01 MDT