tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: Detect in an authenticator whether a connection is persistent or not
Date Sun, 28 Oct 2012 13:06:09 GMT 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

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 ( 
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:
For additional commands, e-mail:

View raw message