You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Kehlenbach, Andreas" <An...@PROSTEP.com> on 2015/01/09 11:59:45 UTC
Re: Is tomcat UserDatabaseRealm buggy?
Hello Chris,
Currently I've attached tomcat sources to my sample application.
The following I found out:
1) The problem occurs only if the nonce timed out.
1.1) After the nonce timed out, tomcat sends a new nonce, which the client correctly respond to. The new response contains the last send (new) nonce, an increased nonce count and the correct opaque.
in DigestAuthenticator. authenticate(Request request, HttpServletResponse response, LoginConfig config) a new DigestInfo object is build. This object then contains nonceStale = true. From my point of view this is a bug, because after a timeout a valid new nonce should be sent to the client.
- Andreas
PS: Please do not use Jersey 1.18.2, because the client also contains a bug. If the nonce timed out, the old and new authorization header is sent to tomcat. Thus, two authorization headers are transmitted and tomcat could not handle this. If you want to use this client, I could provide you a fix for this.
> -----Ursprüngliche Nachricht-----
> Von: Kehlenbach, Andreas [mailto:Andreas.Kehlenbach@PROSTEP.com]
> Gesendet: Dienstag, 23. Dezember 2014 08:33
> An: Tomcat Users List
> Betreff: [bulk]: AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?
>
> Hello Chris,
>
> Long story short: I had no time in past, but now I created a small sample.
> Attached you could find two archives.
> projects.zip: contains two eclipse projects (client and server) tomcat-
> config.zip contains three xmls which I copied into conf/ folder of tomcat.
>
> You could export the war file from within eclipse or just use the pre-
> exported war file with the tomcat.zip.
> The client project contains a ClientTest-class with a unit test. This test just
> fails if one is no longer "logged in". There should be a 401 at some point in
> time in access.log of tomcat.
>
> As I'm unable to attach stuff larger than 1MB you must manually add all
> needed jersey jars into projects of attached archive.
> MyClient\lib\jersey-client-1.18.2.jar
> MyClient\lib\jersey-core-1.18.2.jar
> MyClient\lib\junit-4.10.jar
>
> and
>
> MyWebApplication\WebContent\WEB-INF\lib\jersey-core-1.18.2.jar
> MyWebApplication\WebContent\WEB-INF\lib\jersey-server-1.18.2.jar
> MyWebApplication\WebContent\WEB-INF\lib\jersey-servlet-1.18.2.jar
>
> Hope it helps and merry christmas,
> Andreas
>
> > -----Ursprüngliche Nachricht-----
> > Von: Christopher Schultz [mailto:chris@christopherschultz.net]
> > Gesendet: Mittwoch, 26. November 2014 17:20
> > An: Tomcat Users List
> > Betreff: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA256
> >
> > Andreas,
> >
> > On 11/26/14 5:42 AM, Kehlenbach, Andreas wrote:
> > > I think I found the following bug in tomcat 7/8 with the following
> > > setup:
> > >
> > > We use tomcat 7.0.42 (but I tried 7.0.55 and 8.0.15 without
> > > success) and deployed a web service with jersey 1.18.2.
> > > Additionally we set up HTTP authentication. In our case DIGEST
> > > authentication, but I tried BASIC authentication the observed
> > > behavior is the same. We have a web service with login and logout
> > > methods, as well as some other methods which could only be invoked
> > > if a login request was made previously. Authentication works fine,
> > > till some point in time. At this point the client receives a HTTP
> > > response 401 Unauthorized. I double checked that the client sends
> > > correct credentials and nonce values. On server side I enabled
> > > logging (see attached log file). The log shows two web service
> > > calls, the first one returns successfully the last one reports the
> > > 401 error. As one could see in line 12 and 13 FEIN: Calling
> > > authenticate() Nov 18, 2014 2:58:25 PM
> > > org.apache.catalina.realm.RealmBase authenticate Tomcat delegates
> > > the authentication request to RealmBase class logs some stuff and
> > > returns with FEIN: Successfully passed all security constraints
> > >
> > > But in case of my error just these three lines are logged: FEIN:
> > > Calling authenticate() Nov 18, 2014 2:58:25 PM
> > > org.apache.catalina.authenticator.AuthenticatorBase invoke FEIN:
> > > Failed authenticate() test
> > >
> > > My server.xml is as follows: <… <Engine name="Catalina"
> > > defaultHost="localhost"> <Realm
> > > className="org.apache.catalina.realm.LockOutRealm"> <Realm
> > > className="org.apache.catalina.realm.UserDatabaseRealm"
> > > resourceName="UserDatabase" digest="md5"/> </Realm>
> > >
> > > <Host name="localhost" appBase="webapps" unpackWARs="true"
> > > autoDeploy="true" deployOnStartup="true">
> > >
> > > <Valve className="org.apache.catalina.valves.AccessLogValve"
> > > directory="logs" prefix="localhost_access_log." suffix=".txt"
> > > pattern="%h %l %u %t "%r" %s %b" />
> > >
> > > </Host> </Engine> <…
> > >
> > > I also tried to remove the LockOutRealm, but without success. As far
> > > as I understand with this setup class
> > > org.apache.catalina.realm.CombinedRealm.java is invoked to handle
> > > authentication. If I further understand correctly, then method
> > > authenticate(String username, String clientDigest,__String nonce,
> > > String nc, String cnonce, String qop,__String realmName, String
> > > md5a2) is also invoked. This method iterates over all configured
> > > Realms. It seems to me that, in case of the 401 error, the list of
> > > realms (Line 51) is empty and thus authentication fails.
> > >
> > > The error only occurs after many calls to the webservice. I was
> > > unable to identify any pattern, but it seems related to the nonce
> > > timeout, somehow. Could one verify this bug?
> >
> > What is the nonce timeout?
> >
> > Note that HTTP BASIC authentication does not use nonces, so the nonce
> > timeout wouldn't be the cause under those circumstances.
> >
> > How did you switch testing from HTTP DIGEST to HTTP BASIC
> authentication?
> > The stored credentials are of course incompatible. If you created a
> > small test case, can you share it with us?
> >
> > - -chris
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1
> > Comment: GPGTools - http://gpgtools.org
> >
> >
> iQIcBAEBCAAGBQJUdf2pAAoJEBzwKT+lPKRYYa0P/1lxVAmXeDshnYP47zSnyk
> > hj
> > wv5z86sX57H480VdYQLIIrTwj9KOa6Wifgd/YkC6fUihLNIa+kOe0Jhoq6+K/IIA
> >
> hh9ZHu/qVKUHOsuef5sYD15CWX/VDEkJUyy4G/qvSB1u0dM5vGUkWggZVvn
> > 5kwRG
> >
> 4V0CIg4M4bNAdki3M8ZYKp8fmD5qzYFnfmjJOKwvGiFk4nJjUZG0crVbQC69cy
> > eC
> >
> 5/7tnzswV6dPwyJdBj0b/yiMx0h58mt0BSKz/VNsukxa2WbP0P9csP7mA9gleF
> > UB
> >
> OQdupQ6KE5t8lQBHogHJ7QvjlOJT0Tesqn+NUbNuK8cAmntEg8HQc3b/Erqdly
> > 7G
> >
> GMIx9dhz381RyRlZbBbvwShVc9PK8H5klDfPlwWAQzXG55+iqSx0LS2yV4X+aA
> > ht
> > dxuE/Jc0gZRcb/s2KeUhNGR//Me1GPHStCl3nGxDMczdriEE0/Af+r6tvtXlwd0
> > W
> >
> 5SdVO1r3oar5e+aPBQMBqdmw47MyGx+vCdjY4jeuuoBm3XY4V2VJLrpZm993
> > PwTV
> >
> HgTqgREvgGzDgYkHy4Mm5Fus6YCw4GWWHjVJeff5DBezXigSBcbKtLWK4HoI1
> > zLA
> >
> 5k7Gm0liagpPsxovlt+OzgQ/kHqSE7qgTHgAWF8CRthOv4U8y4PJuZjPdvVeX9iE
> > oTrAPaf7gZymwtORZm1J
> > =83X2
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: users-help@tomcat.apache.org
>
> __________________________________________________________
> ______________
> PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt
> HR: Amtsgericht Darmstadt, HRB 8383
> Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz
> Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz)
> __________________________________________________________
> ______________
________________________________________________________________________
PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt
HR: Amtsgericht Darmstadt, HRB 8383
Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz
Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz)
________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: AW: Is tomcat UserDatabaseRealm buggy?
Posted by Mark Thomas <ma...@apache.org>.
On 09/01/2015 13:36, Kehlenbach, Andreas wrote:
> Hello,
>
> With debugging I finally found out why Jersey and Tomcat doesn't play
> well with digest authentication.
>
> If a nonce got stale and tomcat issues a new authentication request.
> Jersey answers this request and responds with a valid header in terms
> of the HTTP digest specification. The nonce-count field isn’t set to
> 1 by Jersey in this case. Instead the old value is increased.
In which case Jersey is not responding with a valid header in terms of
the HTTP Digest specification. The requirements of RFC-2617, section
3.2.2, "nonce-count" are:
<quote>
The nc-value is the hexadecimal count of the number of requests
(including the current request) that the client has sent with the nonce
value in this request. For example, in the first request sent in
response to a given nonce value, the client sends "nc=00000001".
</quote>
> This
> new value isn't accepted by tomcat (DigestInfo class,
> isNonceCountValid()). Tomcat forces this value to be 0 on new
> authentication.
As required by the specification.
> As the HTTP Digest authentication isn't clean at this point I
> strongly recommend to change tomcat sources and allow nonces with a
> random value on authentication. This could be achieved if the
> nonce-count is read from the client request on authentication.
This proposal makes no sense.
Nonces are random but they are server generated. The client must return
the nonce that it was sent.
The nonce-count is already read from the client and then validated
against what the server expects to see to prevent replay attacks.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
AW: Is tomcat UserDatabaseRealm buggy?
Posted by "Kehlenbach, Andreas" <An...@PROSTEP.com>.
Hello,
With debugging I finally found out why Jersey and Tomcat doesn't play well with digest authentication.
If a nonce got stale and tomcat issues a new authentication request. Jersey answers this request and responds with a valid header in terms of the HTTP digest specification.
The nonce-count field isn’t set to 1 by Jersey in this case. Instead the old value is increased. This new value isn't accepted by tomcat (DigestInfo class, isNonceCountValid()). Tomcat forces this value to be 0 on new authentication.
As the HTTP Digest authentication isn't clean at this point I strongly recommend to change tomcat sources and allow nonces with a random value on authentication. This could be achieved if the nonce-count is read from the client request on authentication.
- Andreas
> -----Ursprüngliche Nachricht-----
> Von: Kehlenbach, Andreas [mailto:Andreas.Kehlenbach@PROSTEP.com]
> Gesendet: Freitag, 9. Januar 2015 12:00
> An: Tomcat Users List
> Betreff: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?
>
> Hello Chris,
>
> Currently I've attached tomcat sources to my sample application.
> The following I found out:
>
> 1) The problem occurs only if the nonce timed out.
> 1.1) After the nonce timed out, tomcat sends a new nonce, which the client
> correctly respond to. The new response contains the last send (new) nonce,
> an increased nonce count and the correct opaque.
>
> in DigestAuthenticator. authenticate(Request request, HttpServletResponse
> response, LoginConfig config) a new DigestInfo object is build. This object
> then contains nonceStale = true. From my point of view this is a bug, because
> after a timeout a valid new nonce should be sent to the client.
>
> - Andreas
>
> PS: Please do not use Jersey 1.18.2, because the client also contains a bug. If
> the nonce timed out, the old and new authorization header is sent to tomcat.
> Thus, two authorization headers are transmitted and tomcat could not
> handle this. If you want to use this client, I could provide you a fix for this.
>
> > -----Ursprüngliche Nachricht-----
> > Von: Kehlenbach, Andreas [mailto:Andreas.Kehlenbach@PROSTEP.com]
> > Gesendet: Dienstag, 23. Dezember 2014 08:33
> > An: Tomcat Users List
> > Betreff: [bulk]: AW: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?
> >
> > Hello Chris,
> >
> > Long story short: I had no time in past, but now I created a small sample.
> > Attached you could find two archives.
> > projects.zip: contains two eclipse projects (client and server)
> > tomcat- config.zip contains three xmls which I copied into conf/ folder of
> tomcat.
> >
> > You could export the war file from within eclipse or just use the pre-
> > exported war file with the tomcat.zip.
> > The client project contains a ClientTest-class with a unit test. This
> > test just fails if one is no longer "logged in". There should be a 401
> > at some point in time in access.log of tomcat.
> >
> > As I'm unable to attach stuff larger than 1MB you must manually add
> > all needed jersey jars into projects of attached archive.
> > MyClient\lib\jersey-client-1.18.2.jar
> > MyClient\lib\jersey-core-1.18.2.jar
> > MyClient\lib\junit-4.10.jar
> >
> > and
> >
> > MyWebApplication\WebContent\WEB-INF\lib\jersey-core-1.18.2.jar
> > MyWebApplication\WebContent\WEB-INF\lib\jersey-server-1.18.2.jar
> > MyWebApplication\WebContent\WEB-INF\lib\jersey-servlet-1.18.2.jar
> >
> > Hope it helps and merry christmas,
> > Andreas
> >
> > > -----Ursprüngliche Nachricht-----
> > > Von: Christopher Schultz [mailto:chris@christopherschultz.net]
> > > Gesendet: Mittwoch, 26. November 2014 17:20
> > > An: Tomcat Users List
> > > Betreff: [bulk]: Re: Is tomcat UserDatabaseRealm buggy?
> > >
> > > -----BEGIN PGP SIGNED MESSAGE-----
> > > Hash: SHA256
> > >
> > > Andreas,
> > >
> > > On 11/26/14 5:42 AM, Kehlenbach, Andreas wrote:
> > > > I think I found the following bug in tomcat 7/8 with the following
> > > > setup:
> > > >
> > > > We use tomcat 7.0.42 (but I tried 7.0.55 and 8.0.15 without
> > > > success) and deployed a web service with jersey 1.18.2.
> > > > Additionally we set up HTTP authentication. In our case DIGEST
> > > > authentication, but I tried BASIC authentication the observed
> > > > behavior is the same. We have a web service with login and logout
> > > > methods, as well as some other methods which could only be invoked
> > > > if a login request was made previously. Authentication works fine,
> > > > till some point in time. At this point the client receives a HTTP
> > > > response 401 Unauthorized. I double checked that the client sends
> > > > correct credentials and nonce values. On server side I enabled
> > > > logging (see attached log file). The log shows two web service
> > > > calls, the first one returns successfully the last one reports the
> > > > 401 error. As one could see in line 12 and 13 FEIN: Calling
> > > > authenticate() Nov 18, 2014 2:58:25 PM
> > > > org.apache.catalina.realm.RealmBase authenticate Tomcat delegates
> > > > the authentication request to RealmBase class logs some stuff and
> > > > returns with FEIN: Successfully passed all security constraints
> > > >
> > > > But in case of my error just these three lines are logged: FEIN:
> > > > Calling authenticate() Nov 18, 2014 2:58:25 PM
> > > > org.apache.catalina.authenticator.AuthenticatorBase invoke FEIN:
> > > > Failed authenticate() test
> > > >
> > > > My server.xml is as follows: <… <Engine name="Catalina"
> > > > defaultHost="localhost"> <Realm
> > > > className="org.apache.catalina.realm.LockOutRealm"> <Realm
> > > > className="org.apache.catalina.realm.UserDatabaseRealm"
> > > > resourceName="UserDatabase" digest="md5"/> </Realm>
> > > >
> > > > <Host name="localhost" appBase="webapps" unpackWARs="true"
> > > > autoDeploy="true" deployOnStartup="true">
> > > >
> > > > <Valve className="org.apache.catalina.valves.AccessLogValve"
> > > > directory="logs" prefix="localhost_access_log." suffix=".txt"
> > > > pattern="%h %l %u %t "%r" %s %b" />
> > > >
> > > > </Host> </Engine> <…
> > > >
> > > > I also tried to remove the LockOutRealm, but without success. As
> > > > far as I understand with this setup class
> > > > org.apache.catalina.realm.CombinedRealm.java is invoked to handle
> > > > authentication. If I further understand correctly, then method
> > > > authenticate(String username, String clientDigest,__String nonce,
> > > > String nc, String cnonce, String qop,__String realmName, String
> > > > md5a2) is also invoked. This method iterates over all configured
> > > > Realms. It seems to me that, in case of the 401 error, the list of
> > > > realms (Line 51) is empty and thus authentication fails.
> > > >
> > > > The error only occurs after many calls to the webservice. I was
> > > > unable to identify any pattern, but it seems related to the nonce
> > > > timeout, somehow. Could one verify this bug?
> > >
> > > What is the nonce timeout?
> > >
> > > Note that HTTP BASIC authentication does not use nonces, so the
> > > nonce timeout wouldn't be the cause under those circumstances.
> > >
> > > How did you switch testing from HTTP DIGEST to HTTP BASIC
> > authentication?
> > > The stored credentials are of course incompatible. If you created a
> > > small test case, can you share it with us?
> > >
> > > - -chris
> > > -----BEGIN PGP SIGNATURE-----
> > > Version: GnuPG v1
> > > Comment: GPGTools - http://gpgtools.org
> > >
> > >
> >
> iQIcBAEBCAAGBQJUdf2pAAoJEBzwKT+lPKRYYa0P/1lxVAmXeDshnYP47zSnyk
> > > hj
> > >
> wv5z86sX57H480VdYQLIIrTwj9KOa6Wifgd/YkC6fUihLNIa+kOe0Jhoq6+K/IIA
> > >
> >
> hh9ZHu/qVKUHOsuef5sYD15CWX/VDEkJUyy4G/qvSB1u0dM5vGUkWggZVvn
> > > 5kwRG
> > >
> >
> 4V0CIg4M4bNAdki3M8ZYKp8fmD5qzYFnfmjJOKwvGiFk4nJjUZG0crVbQC69cy
> > > eC
> > >
> >
> 5/7tnzswV6dPwyJdBj0b/yiMx0h58mt0BSKz/VNsukxa2WbP0P9csP7mA9gleF
> > > UB
> > >
> >
> OQdupQ6KE5t8lQBHogHJ7QvjlOJT0Tesqn+NUbNuK8cAmntEg8HQc3b/Erqdly
> > > 7G
> > >
> >
> GMIx9dhz381RyRlZbBbvwShVc9PK8H5klDfPlwWAQzXG55+iqSx0LS2yV4X+aA
> > > ht
> > >
> dxuE/Jc0gZRcb/s2KeUhNGR//Me1GPHStCl3nGxDMczdriEE0/Af+r6tvtXlwd0
> > > W
> > >
> >
> 5SdVO1r3oar5e+aPBQMBqdmw47MyGx+vCdjY4jeuuoBm3XY4V2VJLrpZm993
> > > PwTV
> > >
> >
> HgTqgREvgGzDgYkHy4Mm5Fus6YCw4GWWHjVJeff5DBezXigSBcbKtLWK4HoI1
> > > zLA
> > >
> >
> 5k7Gm0liagpPsxovlt+OzgQ/kHqSE7qgTHgAWF8CRthOv4U8y4PJuZjPdvVeX9iE
> > > oTrAPaf7gZymwtORZm1J
> > > =83X2
> > > -----END PGP SIGNATURE-----
> > >
> > > --------------------------------------------------------------------
> > > - To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> > > For additional commands, e-mail: users-help@tomcat.apache.org
> >
> >
> __________________________________________________________
> > ______________
> > PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt
> > HR: Amtsgericht Darmstadt, HRB 8383
> > Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz
> > Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz)
> >
> __________________________________________________________
> > ______________
> __________________________________________________________
> ______________
> PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt
> HR: Amtsgericht Darmstadt, HRB 8383
> Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz
> Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz)
> __________________________________________________________
> ______________
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
________________________________________________________________________
PROSTEP AG, Dolivostraße 11, D-64293 Darmstadt
HR: Amtsgericht Darmstadt, HRB 8383
Vorstand: Dr. Bernd Pätzold (Vorsitz), Reinhard Betz
Aufsichtsrat: Dr. Heinz-Gerd Lehnhoff (Vorsitz)
________________________________________________________________________