Re: [libmicrohttpd] Possible bug in http digest

[Christian Grothoff]

Hi!

The failure is intentional, as this is the logic that
protects against replay attacks (nonce = number used once,
so if you call the authentication logic *twice* using the
same login information from the client, it MUST fail).

Your suggestion to not check for authentication a second
time after 100 CONTINUE is the correct answer: if you
have already checked (i.e. *con_cls no longer NULL),
you MUST NOT check again.  As MHD guarantees you that
this request is from the same TCP connection (or hopefully
SSL session), the previous authentication is still valid
by design.

Happy hacking!

Christian

On 08/01/2014 01:31 AM, Manuel Argüelles wrote:
> Hello,
> 
> I'm having a problem with digest authentication. I'm using
> libmicrohttpd version 0.9.37.
> 
> I'm trying to use digest authentication for post method, followed the
> examples but got a weird behavior; in the request handler I check if
> it is a post message (not using auth for get), if so, try to
> authenticate and then handle it to the post_processor.
> 
> On the first run MHD_digest_auth_get_username() returns null, the
> response is successfully added with MHD_queue_auth_fail_response() and
> MHD_YES is returned.
> 
> On the second run, MHD_digest_auth_get_username() returns the user
> name, MHD_digest_auth_check() returns MHD_YES and post processor is
> created with MHD_create_post_processor() and MHD_YES is returned.
> 
> At this point and based on curl output with -v, client gets a 100
> continue.
> 
> Client continues, MHD_digest_auth_get_username() returns the user but
> now MHD_digest_auth_check() returns MHD_NO with debug message:
> 
> "Stale nonce received.  If this happens a lot, you should probably
> increase the size of the nonce array."
> 
> And MHD_queue_auth_fail_response() returns MHD_NO as well, which
> leaves me with nothing for the client: "Empty reply from server".
> 
> I have MHD_OPTION_NONCE_NC_SIZE set to 60000, but to me it looks like
> if everything (digest related) gets cleared up after the second run
> (when I create the post processor and return MHD_YES) so it fails
> because there isn't an initial MHD_queue_auth_fail_response()...
> 
> Does this looks plausible? If so, is it a bug or an expected behavior?
> am I doing something wrong?
> 
> Or, should I keep track of the authenticated connections? Because if I
> only try to authenticate when *con_cls is null then everything works
> fine, but I'm not sure if this is the correct way.
> 
> Regards
> 
>

signature.asc
Description: OpenPGP digital signature