digest authentication stale nonce
Some minimal platforms may have a clock which is not backed up and may likely initialize to Jan 1, 1970. In the case described, the clock is fully functional, just set decades early.
When using digest authentication, the nonce aging implementation considers as "stale" any nonce generated when clock time is less than roughly mid-1978.
In function mod_auth_check_digest(), a hex timestamp prefixed to a received nonce is checked. if the hex timestamp is less than 8 digits, the nonce is considered stale, and a 401 response is sent with the attribute stale=true, and a new nonce.
With each nonce being rejected as stale, the browser responds by re-sending with the new nonce provided in the 401 response (in this case, the browser enters no password dialog with the user). The new request is immediately rejected as stale, ad-infinitum. The resulting request/response loop is automatic and rapid, and is ended only by killing the server or the browser.
The function buffer_append_uint_hex() in buffer.c assures that the hex timestamp generated for a nonce will be less than 8 digits for sufficiently early clock times.
A workaround is simple. The clock is set to a later date before starting lighttpd. This user arbitrarily chose 1/1/2000, as absolute time is not critical in his system.
The issue is entered here in the hopes that others experiencing the problem may at least discover the workaround.
Observed in versions 1.4.41 and 1.4.45, not sure what other versions are affected.
- Status changed from New to Duplicate
- Target version set to 1.4.46
This is not really a bug in lighttpd. The time is not 1978, and the time is not 1970. Those are both in the distant past.
In any case, a workaround has already been implemented in lighttpd git master in 83759aed and will be part of lighttpd 1.4.46.
Also available in: Atom