You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Oleg Kalnichevski (JIRA)" <ji...@apache.org> on 2011/06/23 11:58:47 UTC
[jira] [Resolved] (HTTPCLIENT-1094) HttpClient generates new cnonce
on each request to server, causes issues with IIS
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Oleg Kalnichevski resolved HTTPCLIENT-1094.
-------------------------------------------
Resolution: Invalid
Jesse,
I reviewed and refactored the code in DigestScheme and found no evidence of any digest protocol violation in the existing algorithm. DigestScheme does indeed recalculate A1 value for MD5-sess for each request but the resultant values are consistent within the same session as long as all other parameters such as nonce, username and password remain the same. I added a test case to ensure cnonce and a1 values are calculated correctly for MD5-sess requests. I really have no choice but close this issue as invalid. I did discover though that the choice of cnonce values were rather poor (basically just current time) and therefore easily predictable. I replaced the old algorithm with a new one based on SecureRandom. Feel free to take a look at the new implementation and re-open issue if you find anything wrong with it.
Oleg
> HttpClient generates new cnonce on each request to server, causes issues with IIS
> ---------------------------------------------------------------------------------
>
> Key: HTTPCLIENT-1094
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1094
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient
> Affects Versions: 4.1.1
> Environment: Windows Server 2008 R2 Standard Edition SP1 (64-bit Intel)
> Internet Information Services 7.5
> JRE 1.6.0_24
> Reporter: Jesse Docken
> Attachments: Client-Server Headers.log, Implementations.txt
>
>
> While attempting to authenticate into the local IIS server, the first request completes successfully (in this case, it was a HEAD request). The next request (a GET request), however, generates a 401 error message. Re-issuing the request allows it to succeed.
> I compared the interactions between HttpClient and the server with Internet Explorer and Firefox and concluded that both Firefox and HttpClient generate new CNonce values on each request sent to the server, triggering the 401 response when it sends the new CNonce. Internet Explorer only generates a new CNonce if the server generates a new Nonce, which would force reauthentication anyway. According to RFC 2617 (3.2.2.2 A1), the A1 key for the response is only supposed to be generated once per authentication session, which Internet Explorer does properly. The specification does also say that the cnonce should be uniquely generated later in the response, which Firefox and HttpClient do, but Internet Explorer does not.
> This is somewhat messy, but the end result is this:
> First request to server: server asks for authentication
> Resend first request: generate cnonce "b8c2f608613eea3e3911e964f3983ce5", which is used in A1 and response
> Second request to server: reuse original A1 with first cnonce, generate new cnonce "55f807fbebfbde40bba8be0cfb6e8b38" which is used in response only
> This does seem odd, and I can't find any errata for the RFC that addresses the double-cnonce issue. I might also be misinterpreting the unq(cnonce) for request-digest, but it does explicitly state in 3.2.2.2 that A1 is only to be generated once per authentication session, which HttpClient does not do.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org