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
