tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: AW: Is tomcat UserDatabaseRealm buggy?
Date Fri, 09 Jan 2015 13:56:09 GMT
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:
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".

>  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.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message