hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1855) Digest auth: Nonce counter not incremented after reuse
Date Sun, 19 Nov 2017 19:13:00 GMT

    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1855?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16258571#comment-16258571

ASF GitHub Bot commented on HTTPCLIENT-1855:

Github user agherardi commented on a diff in the pull request:

    --- Diff: httpclient5/src/main/java/org/apache/hc/client5/http/auth/AuthCache.java ---
    @@ -45,4 +45,8 @@
         void clear();
    +    boolean canCache(String name);
    +    boolean needsUpdatingAfterReusing(String name);
    --- End diff --
    Yes. Consider the following scenario:
    - The auth cache contains a DigestScheme for host H, with nonce=N and nonce count=1
    - Thread A needs to send a request to host H. The thread retrieves the DigestScheme from
the cache, increments nonce count to 2 and uses N to create an Authorization header for its
HTTP request.
    - Thread B also needs to send a request to host H. If the cache returns the same DigestScheme,
thread B creates an Authorization header for its HTTP request with nonce=N and nonce count=3.
    - If thread B sends its HTTP request before thread A sends its HTTP request, host H rejects
thread B's request because the nonce count is 3 instead of 2.
    IMO, a DigestScheme needs to be removed from the cache until a response is received from
the server, so that no other thread can use the same nonce. If a successful response is received
from the server, the DigestScheme can be re-cached with an updated nonce count.
    I wrote a custom AuthCache that implements the behavior above. The cache stores AuthSchemes
unserialized. The cost of un-caching and re-caching  DigestSchemes for every message exchange
is minimal, especially when  compared to the cost of a network roundtrip if the request needs
to be resent due to the nonce count being out-of-sequence.
    The needsUpdatingAfterReusing method allowed me to implement the custom AuthCache, which
is not part of this merge request. BasicAuthCache's implementation of needsUpdatingAfterReusing
returns FALSE, so BasicAuthCache is not updated on very message exchange - which is what you

> Digest auth: Nonce counter not incremented after reuse
> ------------------------------------------------------
>                 Key: HTTPCLIENT-1855
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1855
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpClient (classic)
>    Affects Versions: 4.5.2
>            Reporter: Alessandro Gherardi
>         Attachments: HttpClient5Digest.java, HttpClientDigest.java, httpclient5.log,
> I have a client app using httpclient 4.5.2 with BasicCredentialsProvider and BasicAuthCache.
and web server that requires HTTP digest authentication. 
> The client sends 3 requests to the web server. 
> When the app sends the first request, the server returns an HTTP 401 with a digest challenge.
httpclient automatically retries the request with the Authorization header. The header contains
the nonce returned by the server and a nonce counter (nc) of 1. The retry succeeds and httpclient
caches the DigestScheme.
> For the second request, httpclient uses the cached DigestScheme to calculate the Authorization
header pre-emptively. The header contains the same nonce and specifies a nonce counter of
2. The request succeed without requiring a retry.
> For the third request, httpclient uses the cached DigestScheme to calculate the Authorization
header pre-emptively. Even though the header contains the same nonce, the nonce counter is
set to 2 again. This causes the server to return a 401. httpclient should have incremented
the nonce counter to 3.
> I believe that the root cause of this problem is that, although DigestScheme increases
the nonceCount field every time the authenticate() method is called, HttpAuthenticator does
not re-cache DigestScheme after reusing it. The re-cache is needed because BasicAuthCache
stores DigestScheme in serialized format.

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message