Re: problems with the squid-2.5 connection pinning
- Original Message - From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: "Steven Wilton" <[EMAIL PROTECTED]> Cc: Sent: Wednesday, April 19, 2006 2:43 PM Subject: RE: problems with the squid-2.5 connection pinning ons 2006-04-19 klockan 07:38 +0800 skrev Steven Wilton: When I was sending the "Connection: Proxy-support" header, IE only sent the initial request, and never actually tried to complete the NTLM authentication handshake. Removing this header made everything work again. Odd.. I still have the "Proxy-Support: Session-Based-Authentication" header (as specified in the document fragment that you posted to the list). I'm not sure if that makes any difference for child proxies, and IE works both with and without this header. The reason to this header is child proxies not having support for this kind of connections. By having it in the Connection header such child proxies won't forward the header to it's clients. Hmm.. are you running transparent interception? If so then none of this applies. The header is only relevant on proxied connections, not intercepted connections. Yes, I am running transparent interception. Are both these headers only relevant for non-transparent connections? If so, I can enable/disable them depending on which acceleration options are enabled. regards Steven
RE: problems with the squid-2.5 connection pinning
ons 2006-04-19 klockan 07:38 +0800 skrev Steven Wilton: > When I was sending the "Connection: Proxy-support" header, IE only sent the > initial request, and never actually tried to complete the NTLM > authentication handshake. Removing this header made everything work again. Odd.. > I still have the "Proxy-Support: Session-Based-Authentication" header (as > specified in the document fragment that you posted to the list). I'm not > sure if that makes any difference for child proxies, and IE works both with > and without this header. The reason to this header is child proxies not having support for this kind of connections. By having it in the Connection header such child proxies won't forward the header to it's clients. Hmm.. are you running transparent interception? If so then none of this applies. The header is only relevant on proxied connections, not intercepted connections. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
RE: problems with the squid-2.5 connection pinning
> -Original Message- > From: Henrik Nordstrom [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 19 April 2006 12:10 AM > To: Steven Wilton > Cc: squid-dev@squid-cache.org > Subject: Re: problems with the squid-2.5 connection pinning > > tis 2006-04-18 klockan 08:05 +0800 skrev Steven Wilton: > > > Due to other changes in the squid source, I needed to set the > > "must_keepalive" flag on the request to stop squid from closing the > > client-side connection > > Hmm.. a bit curious on what this might be. But I guess it's the > persistent_connection_after_error directive.. > > But I think you are correct. There is little choice but to set > must_keepalive on pinned connections. Connection semantic is a bit > different from normal connections. Yes, it didn't like the initial 403 error, and closed the connection. > > and I also had to remove the "Connection: > > Proxy-support" header from being sent back to the client > (this caused IE to > > get really confused). > > Ugh.. removing this can get you in quite bad situation if > there is child > proxies. > > Can you share some more light on this issue? When I was sending the "Connection: Proxy-support" header, IE only sent the initial request, and never actually tried to complete the NTLM authentication handshake. Removing this header made everything work again. I still have the "Proxy-Support: Session-Based-Authentication" header (as specified in the document fragment that you posted to the list). I'm not sure if that makes any difference for child proxies, and IE works both with and without this header. regards Steven -- No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.1.385 / Virus Database: 268.4.3/316 - Release Date: 17/04/2006
Re: problems with the squid-2.5 connection pinning
tis 2006-04-18 klockan 08:05 +0800 skrev Steven Wilton: > Due to other changes in the squid source, I needed to set the > "must_keepalive" flag on the request to stop squid from closing the > client-side connection Hmm.. a bit curious on what this might be. But I guess it's the persistent_connection_after_error directive.. But I think you are correct. There is little choice but to set must_keepalive on pinned connections. Connection semantic is a bit different from normal connections. > and I also had to remove the "Connection: > Proxy-support" header from being sent back to the client (this caused IE to > get really confused). Ugh.. removing this can get you in quite bad situation if there is child proxies. Can you share some more light on this issue? Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
- Original Message - From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: "Steven Wilton" <[EMAIL PROTECTED]> Cc: Sent: Saturday, April 15, 2006 11:15 PM Subject: Re: problems with the squid-2.5 connection pinning lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: Having seen your patch, I've added the Proxy-Support: headers, and also added a "pinning" flag to the request->flags struct to allow identification of a pinned connection. Looking at your patch I think you got the logics slightly wrong when adding the flag. Pinning is a property of the connections, not the individual requests. From the point where the server connection has indicated use of Microsoft authentication scheme the server-side connection should be exclusively reserved for the specific client connection, and requests from the same client connection should be handled both as pinned looking for a matching reserved server connection and as authenticated even if there is no Authorize header (Microsoft authentication only sends Authorize headers on the first request on the connection, subsequent requests automatically inherit the same credentials) Thanks for pointing this out. I've updated the pinning patch to fix this problem, and tested on my home connection. I can confirm that it works for a simple http GET command, and I'll do further testing and update this list with the results using frontpage (which uses a variety of other http methods to transfer data). Due to other changes in the squid source, I needed to set the "must_keepalive" flag on the request to stop squid from closing the client-side connection, and I also had to remove the "Connection: Proxy-support" header from being sent back to the client (this caused IE to get really confused). regards Steven pinning.patch Description: Binary data
Re: problems with the squid-2.5 connection pinning
- Original Message - From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: "Steven Wilton" <[EMAIL PROTECTED]> Cc: Sent: Saturday, April 15, 2006 11:15 PM Subject: Re: problems with the squid-2.5 connection pinning lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: Having seen your patch, I've added the Proxy-Support: headers, and also added a "pinning" flag to the request->flags struct to allow identification of a pinned connection. Looking at your patch I think you got the logics slightly wrong when adding the flag. Pinning is a property of the connections, not the individual requests. From the point where the server connection has indicated use of Microsoft authentication scheme the server-side connection should be exclusively reserved for the specific client connection, and requests from the same client connection should be handled both as pinned looking for a matching reserved server connection and as authenticated even if there is no Authorize header (Microsoft authentication only sends Authorize headers on the first request on the connection, subsequent requests automatically inherit the same credentials) Hmm, you're right. I'll follow the example in your patch to mark the client connection as pinned, and use this information to modify the pconn key. Regards Steven
Re: problems with the squid-2.5 connection pinning
On Sat, Apr 15, 2006, Kinkie wrote: > IIRC they do. They just accept the new challenge and re-auth. Only case > when the user gets an auth-prompt is when a 407 is sent back on an > AUTHENTICATE packet. > But closing the connection is in any case less prone to interpretation > doubts. Could someone please test it? I don't have access to anything which does NTLM auth at the moment. adrian
Re: problems with the squid-2.5 connection pinning
On Sat, 2006-04-15 at 17:03 +0200, Henrik Nordstrom wrote: > lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: > > > Is it really a problem if the client is sent a new auth challenge? If the > > client connection is closed because the server went away, the client will > > most likely need to refresh the page, which will result in a new auth > > challenge being issued anyway. > > Yes, but here the client expects the auth challenge. > > The problem with sending a new auth challenge on an already > authenticated NTLM/Negotiate is that as far as the client knows this > connection to the web server is already authenticated, and receiving a > new auth challenge on the same connection can only mean that the > previously sent credentials isn't acceptable for the requested object > and the end-user has to be queried for a new login.. or at least so is > the principle behind how authentication works in HTTP. Now with > Microsoft already ignoring the specifications in many other aspects they > probably ignore this as well.. IIRC they do. They just accept the new challenge and re-auth. Only case when the user gets an auth-prompt is when a 407 is sent back on an AUTHENTICATE packet. But closing the connection is in any case less prone to interpretation doubts. Kinkie
Re: problems with the squid-2.5 connection pinning
On Sat, Apr 15, 2006, Steven Wilton wrote: > I'm planning on deploying this patch out on our servers as soon as I get > the chance. I'll let you know how it goes. Excellent! Let me know how it goes and I'll merge it over. I'll then deploy it on a couple of caches and report back. Adrian
Re: problems with the squid-2.5 connection pinning
I'm planning on deploying this patch out on our servers as soon as I get the chance. I'll let you know how it goes. Steven - Original Message - From: "Adrian Chadd" <[EMAIL PROTECTED]> To: "Steven Wilton" <[EMAIL PROTECTED]> Cc: Sent: Saturday, April 15, 2006 12:53 PM Subject: Re: problems with the squid-2.5 connection pinning Are you planning on running this version of the patch (and the tproxy support) on your production caches any time soon? I'd like to place this on my proxy servers but I don't want to be a beta tester. Not yet, at least. :) Adrian On Sat, Apr 15, 2006, Steven Wilton wrote: We've been using a patch that allows NTLM auth to work through our proxies for a while now. The version we're using does depend on the tproxy patch that we've also applied, and it essentially adds the client's ip address and port to the pconn key when the server connection is spoofing the client's ip address. As a result of using the existing pconn code, we do not handle the closing of the server connection any differently from any other persistent connection failing. This has not generated errors that I have heard of from any client using our proxy servers, and we do transparently proxy all our client access to web servers. Having seen your patch, I've added the Proxy-Support: headers, and also added a "pinning" flag to the request->flags struct to allow identification of a pinned connection. I've attached a modified version of the patch we're using for comment, as it uses the existing persistent connection methods and does not add any new sections of code that will terminate connections (and this version will apply to the squid 2.5 tree without needing the tproxy patch applied). I've not looked into the http specs to see if I'm breaking any rules here, but in practice we're not seeing problems with this style of connection pinning. Steven
Re: problems with the squid-2.5 connection pinning
lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: > Having seen your patch, I've added the Proxy-Support: headers, and also > added a "pinning" flag to the request->flags struct to allow identification > of a pinned connection. Looking at your patch I think you got the logics slightly wrong when adding the flag. Pinning is a property of the connections, not the individual requests. From the point where the server connection has indicated use of Microsoft authentication scheme the server-side connection should be exclusively reserved for the specific client connection, and requests from the same client connection should be handled both as pinned looking for a matching reserved server connection and as authenticated even if there is no Authorize header (Microsoft authentication only sends Authorize headers on the first request on the connection, subsequent requests automatically inherit the same credentials) Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
lör 2006-04-15 klockan 09:10 +0800 skrev Steven Wilton: > Is it really a problem if the client is sent a new auth challenge? If the > client connection is closed because the server went away, the client will > most likely need to refresh the page, which will result in a new auth > challenge being issued anyway. Yes, but here the client expects the auth challenge. The problem with sending a new auth challenge on an already authenticated NTLM/Negotiate is that as far as the client knows this connection to the web server is already authenticated, and receiving a new auth challenge on the same connection can only mean that the previously sent credentials isn't acceptable for the requested object and the end-user has to be queried for a new login.. or at least so is the principle behind how authentication works in HTTP. Now with Microsoft already ignoring the specifications in many other aspects they probably ignore this as well.. Closing a persistent connection at any time after the previous reply has been sent is something clients working with persistent connections MUST handle, and the client SHOULD automatically retry the request in such situation (with just a few exceptions like POST/PUT where the end-user SHOULD be queried if the operation should be retried) > We've been using a patch that allows NTLM auth to work through our proxies > for a while now. The version we're using does depend on the tproxy patch > that we've also applied, and it essentially adds the client's ip address and > port to the pconn key when the server connection is spoofing the client's ip > address. As a result of using the existing pconn code, we do not handle the > closing of the server connection any differently from any other persistent > connection failing. This has not generated errors that I have heard of from > any client using our proxy servers, and we do transparently proxy all our > client access to web servers. Good. This would simplify things quite a bit. > Having seen your patch, I've added the Proxy-Support: headers, and also > added a "pinning" flag to the request->flags struct to allow identification > of a pinned connection. I've attached a modified version of the patch we're > using for comment, as it uses the existing persistent connection methods and > does not add any new sections of code that will terminate connections (and > this version will apply to the squid 2.5 tree without needing the tproxy > patch applied). Great! > I've not looked into the http specs to see if I'm breaking any rules here, > but in practice we're not seeing problems with this style of connection > pinning. The whole idea is outside of specs anyway. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
Are you planning on running this version of the patch (and the tproxy support) on your production caches any time soon? I'd like to place this on my proxy servers but I don't want to be a beta tester. Not yet, at least. :) Adrian On Sat, Apr 15, 2006, Steven Wilton wrote: > We've been using a patch that allows NTLM auth to work through our proxies > for a while now. The version we're using does depend on the tproxy patch > that we've also applied, and it essentially adds the client's ip address > and port to the pconn key when the server connection is spoofing the > client's ip address. As a result of using the existing pconn code, we do > not handle the closing of the server connection any differently from any > other persistent connection failing. This has not generated errors that I > have heard of from any client using our proxy servers, and we do > transparently proxy all our client access to web servers. > > Having seen your patch, I've added the Proxy-Support: headers, and also > added a "pinning" flag to the request->flags struct to allow identification > of a pinned connection. I've attached a modified version of the patch > we're using for comment, as it uses the existing persistent connection > methods and does not add any new sections of code that will terminate > connections (and this version will apply to the squid 2.5 tree without > needing the tproxy patch applied). > > I've not looked into the http specs to see if I'm breaking any rules here, > but in practice we're not seeing problems with this style of connection > pinning. > > Steven
Re: problems with the squid-2.5 connection pinning
- Original Message - From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: "Adrian Chadd" <[EMAIL PROTECTED]> Cc: Sent: Friday, April 14, 2006 5:32 PM Subject: Re: problems with the squid-2.5 connection pinning Was anything ever written to define/clarify the semantics of connection pinning (at least for NTLM authentication) ? I couldn't find anything with a quick browse with google defining the behaviour (so I could see how the error condition should be handled.) Let me know when you have something and I'll test it out. If the server connection is gone we have little choice but to close the client connection as well. This due to the client considering that connection already authenticated and sending a new authentication challenge on the same client connection would be considered by the client as "access denied for this user, ask the user if he has another login which might be granted access to the requested object". Is it really a problem if the client is sent a new auth challenge? If the client connection is closed because the server went away, the client will most likely need to refresh the page, which will result in a new auth challenge being issued anyway. If there are any other issues raised by keeping the client connection open, these other issues would be good reason to close the client connection. We've been using a patch that allows NTLM auth to work through our proxies for a while now. The version we're using does depend on the tproxy patch that we've also applied, and it essentially adds the client's ip address and port to the pconn key when the server connection is spoofing the client's ip address. As a result of using the existing pconn code, we do not handle the closing of the server connection any differently from any other persistent connection failing. This has not generated errors that I have heard of from any client using our proxy servers, and we do transparently proxy all our client access to web servers. Having seen your patch, I've added the Proxy-Support: headers, and also added a "pinning" flag to the request->flags struct to allow identification of a pinned connection. I've attached a modified version of the patch we're using for comment, as it uses the existing persistent connection methods and does not add any new sections of code that will terminate connections (and this version will apply to the squid 2.5 tree without needing the tproxy patch applied). I've not looked into the http specs to see if I'm breaking any rules here, but in practice we're not seeing problems with this style of connection pinning. Steven pinning.patch Description: Binary data
Re: problems with the squid-2.5 connection pinning
fre 2006-04-14 klockan 17:07 +0800 skrev Adrian Chadd: > Was anything ever written to define/clarify the semantics of connection > pinning (at least for NTLM authentication) ? I couldn't find anything > with a quick browse with google defining the behaviour (so I could > see how the error condition should be handled.) > > Let me know when you have something and I'll test it out. It's vaguely defined by the Kerberos/Negotiate I-D by Microsoft, the rest has to be deduced from NTLM authentication and HTTP specifications on persistent connections.. What the I-D says (draft-jaganathan-kerberos-http-01.txt): If an HTTP proxy is used between the client and server, it must take care to not share authenticated connections between different authenticated clients to the same server. If this is not honored, then the server can easily lose track of security context associations. A proxy that correctly honors client to server authentication integrity will supply the "Proxy-support: Session- Based-Authentication" HTTP header to the client in HTTP responses from the proxy. The client MUST NOT utilize the SPNEGO HTTP authentication mechanism through a proxy unless the proxy supplies this header with the "401 Unauthorized" response from the server. My comments: Connection pinning is to support end-to-end connection relations as required by NTLM and Negotiate. Once the connections are pinned they enter a very close relation. The prime requirement is that requests must not be sent on another server connection, and other client requests must not be sent on this server connection. This due to the Microsoft design bug that NTLM/Negotiate authentication being tied to the TCP connection, not the request as such.. If the server connection is gone we have little choice but to close the client connection as well. This due to the client considering that connection already authenticated and sending a new authentication challenge on the same client connection would be considered by the client as "access denied for this user, ask the user if he has another login which might be granted access to the requested object". On persistent connection error conditions such as when the server closes the connection while we attempt to forward the next request it's best to do the same on the client to make things behave more like when no proxy is being used. Technically the HTTP specs says we should send an error message if acting as a proxy and not being able to forward the request for some reason (which this could count as), but the tricky part is that it can not really be expected clients know what to do with that error so I prefer to see pinned connections as more like tunnels via the proxy even if we still do full protocol parsing and even caching of public content. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
On Fri, Apr 14, 2006, Henrik Nordstrom wrote: > fre 2006-04-14 klockan 16:46 +0800 skrev Adrian Chadd: > > > Why not? It should call the close handlers shouldn't it? > > It should.. > > but as I said the code looks a bit confused at the moment. Need to read > it again to remember what I really intended. Ok. Was anything ever written to define/clarify the semantics of connection pinning (at least for NTLM authentication) ? I couldn't find anything with a quick browse with google defining the behaviour (so I could see how the error condition should be handled.) Let me know when you have something and I'll test it out. Adrian
Re: problems with the squid-2.5 connection pinning
fre 2006-04-14 klockan 16:46 +0800 skrev Adrian Chadd: > Why not? It should call the close handlers shouldn't it? It should.. but as I said the code looks a bit confused at the moment. Need to read it again to remember what I really intended. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
On Fri, Apr 14, 2006, Henrik Nordstrom wrote: > No, this would not be a good idea I think. Why not? It should call the close handlers shouldn't it? > I will look into this shortly. Seems the code is somewhat confused at > the moment. Ok. Adrian
Re: problems with the squid-2.5 connection pinning
fre 2006-04-14 klockan 08:14 +0800 skrev Adrian Chadd: > Hm, so comm_close() on the FD? No, this would not be a good idea I think. I will look into this shortly. Seems the code is somewhat confused at the moment. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
On Thu, Apr 13, 2006, Henrik Nordstrom wrote: > tor 2006-04-13 klockan 16:42 +0800 skrev Adrian Chadd: > > > This should make squid retry the connection to the server. Is this what > > it should do? Are there any documents outlining what the behaviour > > "should" be? > > If the pinned server connection is gone Squid should abort the request > and close the client connection, preferably without even sending an > error message if possible.. Hm, so comm_close() on the FD? Adrian
Re: problems with the squid-2.5 connection pinning
tor 2006-04-13 klockan 16:42 +0800 skrev Adrian Chadd: > This should make squid retry the connection to the server. Is this what > it should do? Are there any documents outlining what the behaviour > "should" be? If the pinned server connection is gone Squid should abort the request and close the client connection, preferably without even sending an error message if possible.. Regards Henrik signature.asc Description: Detta är en digitalt signerad meddelandedel
Re: problems with the squid-2.5 connection pinning
On Thu, Apr 13, 2006, Adrian Chadd wrote:
> I've found a problem with the connection pinning:
>
> 2006/04/13 11:50:25| fwdConnectStart: Pinned connection to
> mail.aiondiagnostics.com:80 gone, aborting request
> 2006/04/13 11:50:25| assertion failed: forward.c:114: "!EBIT_TEST(e->flags,
> ENTRY_FWD_HDR_WAIT)"
Here's the patch, which doesn't crash. I am not convinced its the "right"
thing to do as I don't quite understand what the semantics of connection
pinning should be.
--- src/forward.c e2fc1a6c5fd200cd0174d0c5c2743c0e2c4942be
+++ src/forward.c 9f95615544cf9a25014da9175125f91f684b9fce
@@ -406,7 +406,10 @@
fd = getPinnedFD(fwdState->request->pinned_connection,
fwdState->request);
if (fd < 0) {
debug(17, 1) ("fwdConnectStart: Pinned connection to %s:%d gone,
aborting request\n", fwdState->request->host, fwdState->request->port);
- storeAbort(fwdState->entry);
+ //storeAbort(fwdState->entry);
+err = errorCon(ERR_CONNECT_FAIL, HTTP_SERVICE_UNAVAILABLE);
+err->xerrno = errno;
+fwdFail(fwdState, err);
return;
}
fwdState->server_fd = fd;
This should make squid retry the connection to the server. Is this what
it should do? Are there any documents outlining what the behaviour
"should" be?
Adrian
