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.
Amos
Received on Wed Jul 18 2012 - 00:29:47 MDT
This archive was generated by hypermail 2.2.0 : Thu Jul 19 2012 - 12:00:03 MDT