[
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: [email protected]
For additional commands, e-mail: [email protected]
