Re: Detect in an authenticator whether a connection is persistent or not
1983-01...@gmx.net wrote: I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a "Connection: close" after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Well, as long as there is support for connection storage should I file a bug about that? Go for it. The connector has to close the connection in my opinion. Not sure what you mean by that. I guess there is a misunderstanding here. There are two issues to be filed: 1. The long-term support for a connection-based store. 2. The above described behavior of the current SPNEGO connector in Tomcat 7. A DoS is possible when a client expects that the server has a connection context on a persistent connection. I was referring to the latter in the first place. Michael Hi. This might be slightly OT, but I just wanted to mention that in a Windows domain context, maintaining state at the level of the connection is essential. NTLM authentication requires several back-and-forth exchanges between the client and the server, in sequence. In the background, the server has to talk to a domain controller etc. This is a very heavy authentication mechanism, so it is the connection which is authenticated, to avoid having to re-authenticate (or at least verify the token) at each subsequent request from the same browser/client. That's also why NTLM authentication requires (or at least strongly suggests) keep-alive, and also why there are limitations using this through firewalls etc. As far as I know, some NTLM authentication mechanisms "fake" this by caching the client's IP address and client-side port number. For example, if you use Jespa (www.ioplex.com) under Tomcat, behind an Apache httpd front-end, you *must* forward the browser's client IP address and port number over the httpd-tomcat proxy connection, so that Jespa can retrieve the client's authentication status from this cache. Which all may point to another logical issue : If you were to implement a connection-level "object" in Tomcat to store such authentication information, it may work if Tomcat is accessed directly by the client. But if the client accesses Tomcat through a proxy, there is (I think) no guarantee that the same proxy connection to Tomcat would always be used by the same client. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
> >>> I have no usecase for this at the moment :-(, I only provide patches > for > >>> stuff I suffer from at work. > >> > >> The below looks like a use case to me. > >> > >>> As this [1] draft lays out Negotiate and Kerberos may apply to > >>> connection or request level auth. We are just lucky that the first > >>> gss_accept_sec_context makes the context complete in the SPNEGO > >>> authenticator. > >>> > >>> Some clients maintain the state and rely on the server to maintain the > >>> connection state too. Tomcat does not do that which means that the > >>> current SPNEGO authenticator has to issue a "Connection: close" after > >>> successful auth. Otherwise the client will reuse the connection and > keep > >>> sending requests w/o reauthenticating eventhough Tomcat requires to do > >>> so. In this case I have a Wireshark capture where this exactly happens > >>> and the clients traps in an endless loop and issues thousands of > >>> requests performs a DoS. > > > > Well, as long as there is support for connection storage should I file a > > bug about that? > > Go for it. > > > The connector has to close the connection in my opinion. > > Not sure what you mean by that. I guess there is a misunderstanding here. There are two issues to be filed: 1. The long-term support for a connection-based store. 2. The above described behavior of the current SPNEGO connector in Tomcat 7. A DoS is possible when a client expects that the server has a connection context on a persistent connection. I was referring to the latter in the first place. Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 19:32, Michael-O wrote: > Am 2012-10-27 20:22, schrieb Mark Thomas: >> On 27/10/2012 18:57, Michael-O wrote: >>> Am 2012-10-27 19:25, schrieb Mark Thomas: > Is this something worth being filed in Bugzilla as a longterm goal for > Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. >>> >>> That seems to be very tough. I hacked Tomcat code several times but >>> wouldn't claim that I am firm enough to implement such a tremendous >>> improvement. Interesting though that no one else yet requested such an >>> improvement. >> >> Yes, we are fairly tough on adding new features. We really don't want to >> add what, for most users, is bloat. We are usually happy to add hooks if >> folks need them to implement their particular itch. >> >> I wouldn't worry about the quality of the patch. The first one I wrote >> for Tomcat was (rightly) ripped to pieces by the committers at the time >> but the feature was implemented and is still there today. If a committer >> can see a cleaner way of doing the same thing then they'll either give >> you some pointers or just fix it and apply it. The main point is that if >> there is a change you want to see, then you need do be the driving force. >> >> Adding connection level notes shouldn't be too hard. The trickier part >> is exposing them to the high-level components that need them. Passing >> through the request is probably the way to go. > > As long as there is general interest in such a feature I will keep that > in mind and might take a look at it over Christmas. I'd certainly be prepared to look at it, both for SPNEGO and SPDY. >>> I have no usecase for this at the moment :-(, I only provide patches for >>> stuff I suffer from at work. >> >> The below looks like a use case to me. >> >>> As this [1] draft lays out Negotiate and Kerberos may apply to >>> connection or request level auth. We are just lucky that the first >>> gss_accept_sec_context makes the context complete in the SPNEGO >>> authenticator. >>> >>> Some clients maintain the state and rely on the server to maintain the >>> connection state too. Tomcat does not do that which means that the >>> current SPNEGO authenticator has to issue a "Connection: close" after >>> successful auth. Otherwise the client will reuse the connection and keep >>> sending requests w/o reauthenticating eventhough Tomcat requires to do >>> so. In this case I have a Wireshark capture where this exactly happens >>> and the clients traps in an endless loop and issues thousands of >>> requests performs a DoS. > > Well, as long as there is support for connection storage should I file a > bug about that? Go for it. > The connector has to close the connection in my opinion. Not sure what you mean by that. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On Sat, Oct 27, 2012 at 11:36 AM, ken dias wrote: > > Yes W8 is here but HPQ is still plummeting. Get rid of your CEO and get > someone who can improve your stock price! Que? -- Hassan Schroeder hassan.schroe...@gmail.com http://about.me/hassanschroeder twitter: @hassan - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: Detect in an authenticator whether a connection is persistent or not
Yes W8 is here but HPQ is still plummeting. Get rid of your CEO and get someone who can improve your stock price! > Date: Sat, 27 Oct 2012 19:57:30 +0200 > From: 1983-01...@gmx.net > To: users@tomcat.apache.org > Subject: Re: Detect in an authenticator whether a connection is persistent or > not > > Am 2012-10-27 19:25, schrieb Mark Thomas: > >> Is this something worth being filed in Bugzilla as a longterm goal for > >> Tomcat 8? > > > > Sure, but without a proposed patch I suspect it will sit there for a few > > years and then closed as WONTFIX. With a patch, it still might not get > > fixed but at least you'll know for sure and if the patch isn't too > > invasive (for the benefit it provides) it is likely to be applied. > > That seems to be very tough. I hacked Tomcat code several times but > wouldn't claim that I am firm enough to implement such a tremendous > improvement. Interesting though that no one else yet requested such an > improvement. > > I have no usecase for this at the moment :-(, I only provide patches for > stuff I suffer from at work. > > As this [1] draft lays out Negotiate and Kerberos may apply to > connection or request level auth. We are just lucky that the first > gss_accept_sec_context makes the context complete in the SPNEGO > authenticator. > > Some clients maintain the state and rely on the server to maintain the > connection state too. Tomcat does not do that which means that the > current SPNEGO authenticator has to issue a "Connection: close" after > successful auth. Otherwise the client will reuse the connection and keep > sending requests w/o reauthenticating eventhough Tomcat requires to do > so. In this case I have a Wireshark capture where this exactly happens > and the clients traps in an endless loop and issues thousands of > requests performs a DoS. > > Thanks, > > Mike > > [1] > http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01#section-1 > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 20:22, schrieb Mark Thomas: On 27/10/2012 18:57, Michael-O wrote: Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. Yes, we are fairly tough on adding new features. We really don't want to add what, for most users, is bloat. We are usually happy to add hooks if folks need them to implement their particular itch. I wouldn't worry about the quality of the patch. The first one I wrote for Tomcat was (rightly) ripped to pieces by the committers at the time but the feature was implemented and is still there today. If a committer can see a cleaner way of doing the same thing then they'll either give you some pointers or just fix it and apply it. The main point is that if there is a change you want to see, then you need do be the driving force. Adding connection level notes shouldn't be too hard. The trickier part is exposing them to the high-level components that need them. Passing through the request is probably the way to go. As long as there is general interest in such a feature I will keep that in mind and might take a look at it over Christmas. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. The below looks like a use case to me. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a "Connection: close" after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Well, as long as there is support for connection storage should I file a bug about that? The connector has to close the connection in my opinion. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 18:57, Michael-O wrote: > Am 2012-10-27 19:25, schrieb Mark Thomas: >>> Is this something worth being filed in Bugzilla as a longterm goal for >>> Tomcat 8? >> >> Sure, but without a proposed patch I suspect it will sit there for a few >> years and then closed as WONTFIX. With a patch, it still might not get >> fixed but at least you'll know for sure and if the patch isn't too >> invasive (for the benefit it provides) it is likely to be applied. > > That seems to be very tough. I hacked Tomcat code several times but > wouldn't claim that I am firm enough to implement such a tremendous > improvement. Interesting though that no one else yet requested such an > improvement. Yes, we are fairly tough on adding new features. We really don't want to add what, for most users, is bloat. We are usually happy to add hooks if folks need them to implement their particular itch. I wouldn't worry about the quality of the patch. The first one I wrote for Tomcat was (rightly) ripped to pieces by the committers at the time but the feature was implemented and is still there today. If a committer can see a cleaner way of doing the same thing then they'll either give you some pointers or just fix it and apply it. The main point is that if there is a change you want to see, then you need do be the driving force. Adding connection level notes shouldn't be too hard. The trickier part is exposing them to the high-level components that need them. Passing through the request is probably the way to go. > I have no usecase for this at the moment :-(, I only provide patches for > stuff I suffer from at work. The below looks like a use case to me. > As this [1] draft lays out Negotiate and Kerberos may apply to > connection or request level auth. We are just lucky that the first > gss_accept_sec_context makes the context complete in the SPNEGO > authenticator. > > Some clients maintain the state and rely on the server to maintain the > connection state too. Tomcat does not do that which means that the > current SPNEGO authenticator has to issue a "Connection: close" after > successful auth. Otherwise the client will reuse the connection and keep > sending requests w/o reauthenticating eventhough Tomcat requires to do > so. In this case I have a Wireshark capture where this exactly happens > and the clients traps in an endless loop and issues thousands of > requests performs a DoS. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 19:25, schrieb Mark Thomas: Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. That seems to be very tough. I hacked Tomcat code several times but wouldn't claim that I am firm enough to implement such a tremendous improvement. Interesting though that no one else yet requested such an improvement. I have no usecase for this at the moment :-(, I only provide patches for stuff I suffer from at work. As this [1] draft lays out Negotiate and Kerberos may apply to connection or request level auth. We are just lucky that the first gss_accept_sec_context makes the context complete in the SPNEGO authenticator. Some clients maintain the state and rely on the server to maintain the connection state too. Tomcat does not do that which means that the current SPNEGO authenticator has to issue a "Connection: close" after successful auth. Otherwise the client will reuse the connection and keep sending requests w/o reauthenticating eventhough Tomcat requires to do so. In this case I have a Wireshark capture where this exactly happens and the clients traps in an endless loop and issues thousands of requests performs a DoS. Thanks, Mike [1] http://tools.ietf.org/html/draft-montenegro-httpbis-multilegged-auth-01#section-1 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 17:56, Michael-O wrote: > Am 2012-10-27 18:38, schrieb Mark Thomas: >> On 27/10/2012 16:28, Michael-O wrote: >>> Am 2012-10-27 16:57, schrieb Mark Thomas: >> The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). >>> >>> Is there no way to tell that subsequent n requests come from the very >>> same socket connection? HTTP is just on top of TCP/IP. Something like >>> this should be transparent to HTTP though? >>> I am curious, since I know server implementations which indeed DO >>> maintain state without HTTP sessions but I do not know how they do that. >> >> It is easy if the same request object is reused for each request >> processed for a given connection. Tomcat doesn't do this. >> >> When a connection has data to process, first a processor is taken from >> the processor pool to process the data. The processor has a request >> object that is re-used. Each time an HTTP request is processed, a >> different processor and request object may be used. (This does vary >> slightly between the different connections but lets not complicate >> things). >> >> Undoing this is the major internal surgery I was referring to. You might >> be able to add an API to store/retrieve data to/from the connection >> (similar to notes on the session, but at the connection level) and >> access this from the authenticator (that is a lot further up the stack). >> That could still end up being pretty invasive. > > OK that's a statement. Tomcat does fully support persistent connections > but there is no state information maintained, right? Correct. Tomcat fully supports HTTP/1.1 and that requires keep-alive support. > The answer would be: There is clearly no way to store any information > for a given connection context and retrieve throughout the Tomcat code. Currently, yes. > Is this something worth being filed in Bugzilla as a longterm goal for > Tomcat 8? Sure, but without a proposed patch I suspect it will sit there for a few years and then closed as WONTFIX. With a patch, it still might not get fixed but at least you'll know for sure and if the patch isn't too invasive (for the benefit it provides) it is likely to be applied. > Thanks for the quick response, You are welcome. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 18:38, schrieb Mark Thomas: On 27/10/2012 16:28, Michael-O wrote: Am 2012-10-27 16:57, schrieb Mark Thomas: The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. OK that's a statement. Tomcat does fully support persistent connections but there is no state information maintained, right? The answer would be: There is clearly no way to store any information for a given connection context and retrieve throughout the Tomcat code. Is this something worth being filed in Bugzilla as a longterm goal for Tomcat 8? Thanks for the quick response, Michael - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 16:28, Michael-O wrote: > Am 2012-10-27 16:57, schrieb Mark Thomas: >> The only mechanism to maintain state between HTTP requests is the HTTP >> session. You might be able to hack something together (in a non-portable >> way) on a per connection basis but that is likely to require some rather >> major internal surgery for Tomcat (and may be rejected by the >> committers). > > Is there no way to tell that subsequent n requests come from the very > same socket connection? HTTP is just on top of TCP/IP. Something like > this should be transparent to HTTP though? > I am curious, since I know server implementations which indeed DO > maintain state without HTTP sessions but I do not know how they do that. It is easy if the same request object is reused for each request processed for a given connection. Tomcat doesn't do this. When a connection has data to process, first a processor is taken from the processor pool to process the data. The processor has a request object that is re-used. Each time an HTTP request is processed, a different processor and request object may be used. (This does vary slightly between the different connections but lets not complicate things). Undoing this is the major internal surgery I was referring to. You might be able to add an API to store/retrieve data to/from the connection (similar to notes on the session, but at the connection level) and access this from the authenticator (that is a lot further up the stack). That could still end up being pretty invasive. > At least the chromium link says how this can be done. Apache HTTP Cient > does that too. Why not Tomcat? I didn't say it couldn't be done. See above. >> It isn't unreasonable for use of an authentication to require an HTTP >> session. FORM auth does that so I don't immediately see why SPNEGO can't. > > FORM auth works very different compared to header-based auth. Form is > meant for human interaction with a browser which will always pass cookies. > I cannot expect that from a "machine" client nor can the client actively > say destroy that session unless a specific URL is called. "Connection: > close" can do that. Yes there are differences and it places requirements on the client but that doesn't make it a complete non-starter. I agree, if this can be done per connection it would be a lot better. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
Am 2012-10-27 16:57, schrieb Mark Thomas: On 27/10/2012 14:50, Michael-O wrote: Hi, several authentication mechanisms require a session (*not* HTTP session) or connection being initiated when authentication is performed and principal cached for subsquent requests [1], [2]. Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave stateful. I once contributed that code to Apache in bug 48465 [3] which does not behave like that. I like to align both authenticators. This issue initially popped up while fixing an issue in libserf [4] for the upcoming Apache Subversion version 1.8.0. How do I access that information in an authenticator? I do not intend to create a HTTP session for that for two reasons: 1. Creation of sessions should be upto the webapp. 2. There is no guarantee that the client will present the session cookie on a subsequent request. The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). Is there no way to tell that subsequent n requests come from the very same socket connection? HTTP is just on top of TCP/IP. Something like this should be transparent to HTTP though? I am curious, since I know server implementations which indeed DO maintain state without HTTP sessions but I do not know how they do that. At least the chromium link says how this can be done. Apache HTTP Cient does that too. Why not Tomcat? It isn't unreasonable for use of an authentication to require an HTTP session. FORM auth does that so I don't immediately see why SPNEGO can't. FORM auth works very different compared to header-based auth. Form is meant for human interaction with a browser which will always pass cookies. I cannot expect that from a "machine" client nor can the client actively say destroy that session unless a specific URL is called. "Connection: close" can do that. Mike - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Detect in an authenticator whether a connection is persistent or not
On 27/10/2012 14:50, Michael-O wrote: > Hi, > > several authentication mechanisms require a session (*not* HTTP session) > or connection being initiated when authentication is performed and > principal cached for subsquent requests [1], [2]. > > Now, I want to patch our SPNEGO authenticator in Tomcat 6 to behave > stateful. I once contributed that code to Apache in bug 48465 [3] which > does not behave like that. I like to align both authenticators. > This issue initially popped up while fixing an issue in libserf [4] for > the upcoming Apache Subversion version 1.8.0. > > How do I access that information in an authenticator? I do not intend to > create a HTTP session for that for two reasons: > > 1. Creation of sessions should be upto the webapp. > 2. There is no guarantee that the client will present the session cookie > on a subsequent request. The only mechanism to maintain state between HTTP requests is the HTTP session. You might be able to hack something together (in a non-portable way) on a per connection basis but that is likely to require some rather major internal surgery for Tomcat (and may be rejected by the committers). It isn't unreasonable for use of an authentication to require an HTTP session. FORM auth does that so I don't immediately see why SPNEGO can't. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
