Firefox sends wrong proxy auth data (formerly entered) after proxy-connection:close




10 years ago
7 years ago


(Reporter: arne.handtmann, Unassigned)


Firefox Tracking Flags

(Not tracked)



(6 attachments)



10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/2009032609 Firefox/3.0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv: Gecko/2009032609 Firefox/3.0.8

With basic proxy authentication: If the user entered wrong credentials before submitting the correct ones, Firefox continues to send some (not all) HTTP-Requests with the formerly entered wrong credentials. This leads to blocked accounts if the proxy authenticates to RADIUS or IAS and a Windows Domain. This behaviour seems to occur only if the proxy sends a "Proxy-Connection: close" with the "407 - Proxy Authorization required".

Reproducible: Always

Steps to Reproduce:
1. Use a proxy which answers wrong auth requests with "407 - Proxy Authorization required" and "Proxy-Connection: close"
2. Provide wrong credentials (e.g. wrong password) when first authentication window appears after entering URL
3. Provide correct credentials
4. Either dump the network traffic to/from the proxy-server or check the proxy logfile for subsequent "407 - Proxy authorization required" answers to the client
Actual Results:  
The user sees no difference in the browsing experience, all content is retrieved correctly. With authentication to security-sensitive backends (e.g. RADIUS/IAS with Windows Domain) there are numerous "wrong username or password" logon attempts which lead to blocked user accounts (and users are unable to request further web content through the proxy or even logon to their Windows Domain account). Within a company of approx. 40-50 active users the account blocking occurs about 10-20 times a day.

Expected Results:  
Firefox should use the last supplied (and correct) proxy authentication credentials in all further requests.

Tested with older versions (3.0.4) and other OSes (Win 2003 x64). Bug does not occur with proxy-servers (e.g. older squid) which do not send the "Proxy-Connection: close".
Component: General → Networking
Product: Firefox → Core
QA Contact: general → networking

Comment 1

10 years ago

Can you give us your exact proxy server setup (name/version of proxy server and OS).  A network trace showing the behavior would be great, too.

We may need to copy your proxy setup.  I at least haven't set up Raduis/IAS, so any pointers/description appreciated.


Comment 2

10 years ago

sorry for the delay - here some more information:

1) Proxy-Servers

1.1: Working setup: Squid Cache: Version 2.3.STABLE4-hno.CVS running on Linux (old SuSE 7.3 distribution with manual patches)

1.2: Not working setup: Astaro Security Gateway V7, Release 7.402 (recent), built-in http-proxy (unknown source/version)

2) Network trace

I will attach five packet traces (four against the Astaro proxy and one against the squid-proxy):

Before and after each test the browser (Firefox und IE) have been closed completely. The requested URL was "" in each case. "Remember my password" was not selected (in neither case).

- ifmsv03-inftest64-ff-correct-pw: Firefox - Initial connect with the correct password
- ifmsv03-inftest64-ff-wrong-pw: Firefox - Initial connect with wrong password, second username/password question with the correct password (please notice the subsequent duplicated http-requests, once with the wrong password and the second with the correct one for nearly _all_ following requests), this is what produces the locked windows accounts
- ifmsv03-inftest64-ie-correct-pw: Internet Explorer - Initial connect with the correct password
- ifmsv03-inftest64-ie-wrong-pw: Internet-Explorer - Initial connect with the wrong password, second username/password question with the correct values (please note that there are no duplicated requests with the wrong password)

- wap02-ff-working-proxy-wrong-pw: Same test (other client and server and also other credentials) against the working proxy-server (Squid), first request with wrong username/password, afterwards with the correct credentials

It seems to me that Firefox caches the wrong credentials and uses them in each following http-request.

Best regards,

Comment 3

10 years ago
Created attachment 374925 [details]
Packet-Trace against Astaro with correct credentials

Comment 4

10 years ago
Created attachment 374926 [details]
Packet-Trace against Astaro with (first try) wrong credentials

Comment 5

10 years ago
Created attachment 374927 [details]
Packet-Trace IE against Astaro with correct credentials

Comment 6

10 years ago
Created attachment 374928 [details]
Packet-Trace IE against Astaro with (first try) wrong credentials

Comment 7

10 years ago
Created attachment 374929 [details]
Packet-Trace against Squid with (first try) wrong credentials
The problem isn't that the proxy sends "Proxy-Connection: close" on 407 error, but that ep-httpproxy (the one in Astaro Security Gateway) returns invalid Proxy-Authenticate header.

Response to unauthenticated request is:
  HTTP/1.1 407 Proxy Authorization Required

  Proxy-Authenticate: Basic realm="httpproxy"

And response to request with bad credentials is:
  HTTP/1.1 407 Proxy Authorization Required

  Proxy-Authenticate: Basic

There must be at least 1 realm specified in the challenge according to RFC2617. We treat no realm as empty realm. Because of this bug the correct credentials as well as the wrong credentials are stored in the auth cache. First the wrong credentials are used in every HTTP request and the correct credentials are used when 407 error is received.

As a workaround we could insert auth entry in front of the list instead of appending it in nsHttpAuthNode::SetAuthEntry(). With this change we would use always the last entered auth entry for proxy authentication.
Created attachment 412194 [details] [diff] [review]
possible workaround
Attachment #412194 - Flags: review?(jduell.mcbugs)
In my understanding of the RFC the realm isn't required for Basic Auth, but i'll add that in the Astaro HTTP-Proxy, as it probably won't hurt.

Comment 11

7 years ago
My read of RFC 2617 (see section 2, esp "There are no optional authentication parameters") is the same as Michal's, so I think the right fix was to change the server behavior.
Last Resolved: 7 years ago
Resolution: --- → INVALID


7 years ago
Attachment #412194 - Flags: review?(jduell.mcbugs)
You need to log in before you can comment on or make changes to this bug.