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 > >
