378152 - digest authentication against (squid) proxy re-prompts for password needlessly

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Jaco Kroon]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.2) Gecko/20070320 Firefox/2.0.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.2) Gecko/20070320 Firefox/2.0.0.2

I'm not 100 % sure whether this is a bug in Firefox or in squid, but since IE6 (seems to) work correctly I'm going to assume (for the moment) that it's a bug in FF.  Basically, my squid proxy is configured to allow all requests, except google.co.za to pass through without authentication being required, however, you must be authenticated to access google.co.za (test setup).  Now, the first time I try to access www.google.co.za it correctly prompts me for credentials, however, when the given nonce_max_duration expires I'm re-prompted for authentication details, even though the cached credentials (or cached H(A1) value - depending on what FF actually caches) should work just fine.

These are the headers (using tcpdump + wireshark) that I see:

Initial request:

GET http://www.google.co.za/ HTTP/1.1
Host: www.google.co.za
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.2) Gecko/20070320 Firefox/2.0.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: PREF=ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

HTTP/1.0 407 Proxy Authentication Required
Server: squid/2.6.STABLE12
Date: Fri, 20 Apr 2007 07:36:03 GMT
Content-Type: text/html
Content-Length: 1292
Expires: Fri, 20 Apr 2007 07:36:03 GMT
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Digest realm="proxy", nonce="Y20oRkCzLghf338h", qop="auth", stale=false
X-Cache: MISS from chimera
X-Cache-Lookup: NONE from chimera:3128
Via: 1.0 chimera:3128 (squid/2.6.STABLE12)
Proxy-Connection: close

This is obviously fine, no credentials provided, access rejected, FF is provided with realm and nonce values and can now prompt for username/password, after which this conversation takes place:

GET http://www.google.co.za/ HTTP/1.1
Host: www.google.co.za
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.2) Gecko/20070320 Firefox/2.0.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: PREF=ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Proxy-Authorization: Digest username="jkroon", realm="proxy", nonce="Y20oRkCzLghf338h", uri="/", response="76bfa005c90e7bfcd0862f6a46ce5bce", qop=auth, nc=00000001, cnonce="ed2a9403414d674d"

HTTP/1.0 200 OK
Cache-Control: private
Content-Type: text/html; charset=UTF-8
Set-Cookie: PREF=ID=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX; expires=Sun, 17-Jan-2038 19:14:07 GMT; path=/; domain=.google.co.za
Content-Encoding: gzip
Server: GWS/2.1
Content-Length: 1525
Date: Fri, 20 Apr 2007 07:37:52 GMT
X-Cache: MISS from chimera
X-Cache-Lookup: MISS from chimera:3128
Via: 1.0 chimera:3128 (squid/2.6.STABLE12)
Proxy-Connection: keep-alive

Great!  We retrieved our webpage.  Very nice, we can now browse, for a while at least, at which time this happens:

GET http://www.google.co.za/ HTTP/1.1
Host: www.google.co.za
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.2) Gecko/20070320 Firefox/2.0.0.2
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: en-gb,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Proxy-Connection: keep-alive
Cookie: PREF=ID=1901d253b6c603d3:TM=1169109767:LM=1169109767:S=LJIPT_Nemz-ATrW_                                                                                     Proxy-Authorization: Digest username="jkroon", realm="proxy", nonce="Y20oRkCzLghf338h", uri="/", response="73faa63c736e7378457bed83c891bfc1", qop=auth, nc=00000003, cnonce="e58899cea1c19101"
Cache-Control: max-age=0

HTTP/1.0 407 Proxy Authentication Required
Server: squid/2.6.STABLE12
Date: Fri, 20 Apr 2007 07:51:43 GMT
Content-Type: text/html
Content-Length: 1292 
Expires: Fri, 20 Apr 2007 07:51:43 GMT 
X-Squid-Error: ERR_CACHE_ACCESS_DENIED 0
Proxy-Authenticate: Digest realm="proxy", nonce="D3EoRkCzLgiXe2Iy", qop="auth", stale=false
X-Cache: MISS from chimera
X-Cache-Lookup: NONE from chimera:3128
Via: 1.0 chimera:3128 (squid/2.6.STABLE12)
Proxy-Connection: close

At this point FF against prompts for username/password.  I suspect that it may actually be squid that is in the wrong here, it should probably set stale=true?

Point being that IE6 works and FF doesn't.  So I'd recommend the following action, we have credentials, so since the nonce that got sumitted differs from the new one in the challenge, we can first retry with the new nonce, and if that fails again - prompt for new credentials.  Basically this puts credentials in a binary state "confirmed" or "tentative".  When initially prompted they go into tentative, they get submitted, if we get OK they are confirmed, else they get discarded and obviously re-prompted.  if confirmed credentials fail, they go into tentative and retried with the new nonce value, handling as previously.

Reproducible: Always

Actual Results:  
Get prompted every 10 minutes for credentials even though they haven't changed.

Expected Results:  
To only be prompted the first time, or when the credentials really does fail.

The relevant part of my squid config:

auth_param digest program /usr/libexec/squid/digest_pw_auth /tmp/digest_hashes
auth_param digest children 1
auth_param digest concurrency 0
auth_param digest nonce_garbage_interval 5 minutes
auth_param digest nonce_max_duration 10 minutes
auth_param digest nonce_max_count 50
auth_param digest nonce_strictness off
auth_param digest check_nonce_count on
auth_param digest post_workaround off
auth_param digest realm proxy

Comment 1

[Jo Hermans]

Does it work when you set check_nonce_count to off ?

It might be a dupe of bug 114451 : we've sent "nc=00000001" first, and later "nc=00000003"

Comment 2

[Jaco Kroon]

No, it doesn't.

Note that I already had "nonce_strictness" off, based on the information in that bug report.  Even with check_nonce_count off it doesn't make a difference, it's when nonce_max_duration has expired that I see the problem.

Comment 3

[u279076]

Jaco, can you try on Firefox 2.0.0.4 please and let us know your findings.

Thanks

Comment 4

[Jaco Kroon]

Looks like it's already working in 2.0.0.3 which I'm currently running.  I can't reproduce, if you really want I'll test 2.0.0.4 as well for you (I'm busy updating anyway).

Thanks for the good work, keep it up.

Comment 5

[Jaco Kroon]

I spoke too soon, 2.0.0.3 still does it, after 10 minutes of inactivity.  Strange, I definitely tested over a longer period than 10 minutes, yet just now it again prompted me for credentials.

Comment 6

[u279076]

Have you tried 2.0.0.4 yet?  Thanks.

Comment 7

[Jaco Kroon]

Seems to be working.  Was there specific code going into 2.0.0.4 to fix this issue?

Comment 8

[Jaco Kroon]

And again no.  Just as I submitted this page I got re-requested.

Comment 9

[Justin Dolske [:Dolske]]

This isn't a password manager issue, as whatever's going on is at the protocol level. So I'm moving this to Core / Networking:HTTP.

I think you hit upon the answer, with noting that the proxy is replying with a stale=false directive. RFC 2617 says:

     [...]The server should only set stale to TRUE
     if it receives a request for which the nonce is invalid but with a
     valid digest for that nonce (indicating that the client knows the
     correct username/password). If stale is FALSE, or anything other
     than TRUE, or the stale directive is not present, the username
     and/or password are invalid, and new values must be obtained.

I think IE6's behavior here is wrong. The reply FF is getting indicates that the supplied credentials are now invalid. The fact that they worked previously doesn't mean they're still correct... For example, this reply could indicate that the user changed their password. Or, say, a login purchased for limited browsing session has expired. Or maybe the proxy just wants to force a re-authentication, so that it knows you're really you.

I'd suggest trying a Squid configuration such that |stale=true| is being sent, and see if that works as expected.

Comment 10

[u279076]

So is this fixed and can it be resolved WORKSFORME now?  Or if it isnt a password manager issue, can we get it moved to the right component?

Thanks.

Comment 11

[Jaco Kroon]

No, this is not fixed.

You're welcome to move it to a more appropriate component.

Ok, well, my squid config is posted there, so if you could inform me what's wrong with what is there then it would be much appreciated.

Comment 12

[Justin Dolske [:Dolske]]

This shouldn't be WORKSFORME, although given my comments #9 I would suggest INVALID / WONTFIX (depending on if it's just a Squid configuration problem or not). But one of the Networking folks can make that determination. Biesi? 

Comment 13

[Henrik Nordstrom]

A couple of problems has recently been fixed in the Squid digest implementation. The most relevant to this report is the sending of stale=false when the nonce has expired and been garbage collected and no longer known to Squid. stale=true is the correct response there.

The patches is pending for inclusion in the next Squid STABLE release, and will propagate down to the STABLE branches in a couple of days (Squid 2.6, 2.7 and 3.0).

From what I can tell this bug is about exactly this, and FF is doing the right think asking for credentials when receiving a stale=false digest challenge. I am not surprised by hearing that the problem is not visible when using MSIE 6 as it does many odd things wrt authentication.

Squid patches:
Squid-2: http://www.squid-cache.org/Versions/v2/HEAD/changesets/11850.patch
Squid-3: http://www.squid-cache.org/Versions/v3/HEAD/changesets/11295.patch

This would probably have been done a lot earlier had there been a bug filed in the Squid bug database.. but I had a vague memory of seeing this bugreport and now found time to run a validation of our Digest implementation.

Comment 14

[RNicoletto]

As per comment 13 can we consider this bug FIXED?

Comment 15

[Jaco Kroon]

I haven't tested this recently, had to switch my squid to basic auth for other reasons (too many silly programs out there that doesn't support digest).  Seeing that this is in any case a squid bug in the end, I'm marking resolved.  Thanks to Henrik.