libmicrohttpd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [libmicrohttpd] Possible bug in http digest


From: Manuel Argüelles
Subject: Re: [libmicrohttpd] Possible bug in http digest
Date: Mon, 4 Aug 2014 14:06:33 -0500
User-agent: Mutt/1.5.23 (2014-03-12)

Hello Christian,

Thanks for taking the time to clarify things for me, everything makes
perfect sense now :)

Cheers,


On Sat, Aug 02, 2014 at 09:57:03PM +0200, Christian Grothoff wrote:
> 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
> > 
> > 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]