The bug can be corrected with these steps :

get this patch ftp://ftp.tuwien.ac.at/.vhost/www.squid-cache.org/Versions/v3/3.4/changesets/squid-3.4-13098.patch [^] in
/root/rpmbuild/SOURCES

modify it with

--- src/auth/digest/UserRequest.cc 2013-11-29 10:55:53 +0000
+++ src/auth/digest/UserRequest.cc 2014-03-05 02:48:25 +0000
@@ -153,7 +153,7 @@
         /* check for stale nonce */
         if (!authDigestNonceIsValid(digest_request->nonce, digest_request->nc)) {
             debugs(29, 3, HERE << "user '" << auth_user->username() << "' validated OK but nonce stale");
- auth_user->credentials(Auth::Failed);
+ auth_user->credentials(Auth::Handshake);
             digest_request->setDenyMessage("Stale nonce");
             return;
         }

AND

@ -214,8 +215,14 @@
 
     if ((static_cast<Auth::Digest::Config*>(Auth::Config::Find("digest"))->authenticateProgram) && authDigestNonceLastRequest(nonce)) {
         flags.authinfo_sent = 1;
- debugs(29, 9, HERE << "Sending type:" << type << " header: 'nextnonce=\"" << authenticateDigestNonceNonceb64(nonce) << "\"");
- httpHeaderPutStrf(&rep->header, type, "nextnonce=\"%s\"", authenticateDigestNonceNonceb64(nonce));
+ Auth::Digest::User *digest_user = dynamic_cast<Auth::Digest::User *>(user().getRaw());
+ digest_nonce_h *nextnonce = digest_user->currentNonce();
+ if (!nextnonce || authDigestNonceLastRequest(nonce)) {
+ nextnonce = authenticateDigestNonceNew();
+ authDigestUserLinkNonce(digest_user, nextnonce);
+ }
+ debugs(29, 9, "Sending type:" << type << " header: 'nextnonce=\"" << authenticateDigestNonceNonceb64(nextnonce) << "\"");
+ httpHeaderPutStrf(&rep->header, type, "nextnonce=\"%s\"", authenticateDigestNonceNonceb64(nextnonce));
     }
 }


THEN change the squid.spec in /root/rpmbuild/SPECS

7 Release: 28%{?dist}
...
55 Patch217: squid-3.4-13098.patch
...
134 %patch217 -p0


then it works....

Fabrice, could you provide me with a more specific reproducer? I was unable to recreate the problem by just 'configuring digest authentication' in the affected Squid version.

This is what I tried:

# rpm -q squid
squid-3.3.8-26.el7.x86_64

# htdigest -c /etc/squid/passwd moria gandalf
Adding password for gandalf in realm moria.
New password: mellon
Re-type new password: mellon

# cat /etc/squid/squid.conf
auth_param digest program /usr/lib64/squid/digest_file_auth -c /etc/squid/passwd
auth_param digest children 5
auth_param digest realm moria
acl foo proxy_auth REQUIRED
http_access allow foo
http_access deny all
http_port 3128

# systemctl start squid

Now, when I configure Firefox to use this Squid instance as an HTTP proxy and navigate to, say, www.squid-cache.org, the whole page is loaded at once, without the necessity of re-entering the credentials for each downloaded file.

Similarly, when downloading a file with curl:

# curl -v --proxy-digest -U gandalf:mellon -x localhost:3128 www.squid-cache.org

the Proxy-Authorization header can be reused for future proxied requests without re-entering the credentials as well.

So I wonder, what am I missing?

Never mind, I found the necessary configuration here:

https://bugzilla.mozilla.org/show_bug.cgi?id=378152#c0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHSA-2016-2600.html