On 07/18/2012 03:29 AM, Amos Jeffries wrote:
> On 18.07.2012 04:36, Tsantilas Christos wrote:
>> On 07/16/2012 05:43 AM, Amos Jeffries wrote:
>>> On 16.07.2012 14:42, Amos Jeffries wrote:
>>>> On 13.07.2012 05:30, Tsantilas Christos wrote:
>>>>>
>>>>>> src/forward.cc:
>>>>>> * It seems that selectPeerForIntercepted() is permitting pinned
>>>>>> destinations to pass-thru when Host header is non-validated.
>>>>>> Malicious intercepted clients now only need to send www-auth
>>>>>> credentials for a connection-auth scheme (triggering pinning) to be
>>>>>> able
>>>>>> to make poisoning attacks on any followup pipelined request.
>>>>>> eg:
>>>>>> GET / HTTP/1.1
>>>>>> Host: cahoots.server
>>>>>> WWW-authenticate: NTLM fake
>>>>>> \r\n
>>>>>> GET /poisoned-URI/ HTTP/1.1
>>>>>> Host: victim.site
>>>>>
>>>>> Inside selectPeerForIntercept there is the call:
>>>>> client->validatePinnedConnection
>>>>> Which checks if the host header is the correct one and if it is not
>>>>> unpins the connection.
>>>>>
>>>>
>>>> I've been considering this more and it appears that your point stands
>>>> up well. This is something we need in 3.2.
>>>>
>>>> Would you mind applying the particular selectPeerForIntercepted()
>>>> creation change separately as a new partial for the fix on bug 3579?
>>>
>>> Meh. I meant bug 3478.
>>
>> Amos, I believe this is not a solution to this bug
>
> It's not a full solution. But it is one more step towards it.
>
> I realized the other day that connection-auth on intercepted connections
> is also broken at present. Without your PINNED change each request is
> split up and sent down a brand new ORIGINAL_DST TCP connection. As you
> pointed out the pinned connection is always okay to ignore ORIGINAL_DST
> after pinning because what got pinned was an ORIGINAL_DST link anyway.
This part of the patch applied separately with revno: 12218 and message
header: "Bug 3478: Partial fix: Connection-auth on intercepted
connections is broken"
>
> Amos
>
>
Received on Wed Jul 18 2012 - 18:09:02 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 19 2012 - 12:00:03 MDT