All users were logged out of Bugzilla on October 13th, 2018

Firefox only sends Proxy-Authorization header with the first request down a persistent socket, when it should send Proxy-Authorization with every request as HTTP is stateless

RESOLVED DUPLICATE of bug 137852

Status

()

RESOLVED DUPLICATE of bug 137852
3 years ago
2 years ago

People

(Reporter: dan, Assigned: xeonchen)

Tracking

45 Branch
x86_64
Windows 10
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [necko-active])

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Firefox/45.0
Build ID: 20160315153207

Steps to reproduce:

Configured Firefox 45.0.1 to use a HTTP/HTTPS proxy server which requires either Negotiate or Basic Proxy-Authorization.



Actual results:

Firefox fails Negotiate proxy auth because the user is not logged into a domain, and so falls back to Basic proxy auth.

However, Firefox only sends the basic Proxy-Authorization header with the first HTTP request down the persistent socket to the proxy server, and so the second request Firefox tries to send to the proxy without the Proxy-Authorization header results in the proxy refusing the second request with a 407 response.

Probably because of the 407 from the second request down a persistent socket, Firefox then goes back to the start and attempts Negotiate proxy auth again, which fails again, and then falls back to basic, which succeeds on the first request, then fails again because Firefox does not send the basic Proxy-Authorization header with the second request down the persistent socket.


Expected results:

Firefox should have kept sending the basic Proxy-Authorization header with every request it sends down a persistent socket. This seems to be the requirement in the HTTP protcol specification.

Firefox should also have realised and remembered that Negotiate does not work, and it should keep using basic Proxy-Authorization as that does succeed. However, this might be a compound issue triggered by Firefox only sending the basic Proxy-Authorization header with the first request down a persistent socket.

So this is indeed a bug in Firefox, confirmed by the squid cache developers.

See: http://bugs.squid-cache.org/show_bug.cgi?id=4473
(Reporter)

Updated

3 years ago
OS: Unspecified → Windows 10
Hardware: Unspecified → x86_64

Updated

3 years ago
Component: Untriaged → Networking: HTTP
Product: Firefox → Core
Note that for NTLM/Kerberos (one of the resulting schemes coming out of Negotiate challenge) are authenticating the _connection_, and not every request.  Hence we don't have to (actually must not) send *Authorization request headers after a successful authorization.

Basic auth on the other hand is authenticating every request, so we have to and we definitely do for server auth.  The same code is used for proxy, so at the moment I cannot say what is exactly broken.

The same I think applies to proxies (cannot find an appropriate documents on it, tho).  Negotiate/NTLM/Kerberos should all be connection based, Basic should be request based.



Can you please provide a public proxy test case so we can check?  Other option would be to provide exact steps to setup a squid proxy to reproduce (I am running one on a linux box, but I'm no expert to set it up).
Flags: needinfo?(dan)
Assignee: nobody → honzab.moz
Whiteboard: [necko-active]
(Reporter)

Comment 2

3 years ago
Hi,

I don't know which Linux distribution you are using, so these instructions are only valid for Ubuntu 14.04's squid3 package. Please let me know if you require help modifying the example minimal squid.conf I've quoted below, as the paths to the authentication helpers will probably need changing for other Linux distributions/squid packages.

Minimal squid.conf for Ubuntu 14.04's squid3 package:

auth_param negotiate program /usr/lib/squid3/negotiate_kerberos_auth -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive off
auth_param basic program /usr/lib/squid3/basic_fake_auth
auth_param basic children 10
auth_param basic realm Squid
auth_param basic credentialsttl 1 hour
acl is_proxy_authed proxy_auth REQUIRED
http_access deny !is_proxy_authed
http_access allow is_proxy_authed
http_access deny all
http_port 8080
always_direct allow all

------END------

If you configure Squid as above, and restart it, then it should be listening on port 8080.

Try configuring Firefox to talk to the Squid proxy box on port 8080, and you should be prompted for Basic authentication (realm: Squid) after Negotiate auth fails, and because Squid's basic authentication is using the "basic_fake_auth" helper it will accept (allow) any username/password pair you provide, so it should not matter what you enter into the Basic proxy auth popup.

I suggest using Wireshark to capture the conversation between Firefox and Squid, and you should see Firefox going round in a loop, first it should try Negotiate, which will fail. Next you should see a new connection with Firefox sending the Basic Proxy-Authorization header in the first request, however, the problem should show it's self by Firefox failing to send the Basic Proxy-Authorization header with the second request Firefox sends down the persistent socket to Squid. Squid should then send a 407 response to the second request without Proxy-Auth header, resulting in Firefox going back to the start of the process, trying Negotiate on a new connection, failing, etc...
Flags: needinfo?(dan)
Dan, thanks very much!

I'm on Fedora 23, sorry to not mention first.  If there are some significant changes to the config, it would make my life easier.  Thanks.
(Reporter)

Comment 4

3 years ago
It looks like Fedora 23's squid package (squid-3.5.3-5.fc23.xxxx.rpm) (where xxxx is your Linux box's architecture, e.g i686) does not include a basic_fake_auth helper, which is unfortunate.

However, you can use the following PHP script to achieve what we need...

#!/usr/bin/php
<?php

set_time_limit(0);
error_reporting(0);

while(!feof(STDIN)) {
  $buffer = fgets(STDIN);
  if($buffer === FALSE) {
    if(!feof(STDIN)) {
      continue;
    }
    break;
  }

  echo "OK\n";
}
?>

--------END---------

You will need the php-cli RPM installed to provide /usr/bin/php. Or you can re-write this simple script in another language if you want.

After writing the above PHP script (including the #!/usr/bin/php on the first line), you must chmod oug+rx the script file, then change the squid.conf config file to set the "auth_param basic program ...." at the script.

Test the script from the shell by executing it, then anything entered (any line passed to the script's STDIN) should result in the script echoing back "OK" with a new line.

If for example your custom basic fake auth script is located "/usr/lib/squid/my_basic_fake_auth", then for Fedora 23 squid 3.5 RPM, the squid.conf should look like:

auth_param negotiate program /usr/lib/squid/negotiate_kerberos_auth -s GSS_C_NO_NAME
auth_param negotiate children 10
auth_param negotiate keep_alive off
auth_param basic program /usr/lib/squid/my_basic_fake_auth
auth_param basic children 10
auth_param basic realm Squid
auth_param basic credentialsttl 1 hour
acl is_proxy_authed proxy_auth REQUIRED
http_access deny !is_proxy_authed
http_access allow is_proxy_authed
http_access deny all
http_port 8080
always_direct allow all

------END------
Assignee: honzab.moz → xeonchen
(Assignee)

Updated

2 years ago
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
(Assignee)

Comment 5

2 years ago
I can reproduce this on 46.0.1, but not on beta (47.0b6) and later channels.
(Reporter)

Comment 6

2 years ago
Hi Gary, does this mean we can expect a fix for this issue when version 47 gets released?

If so, when can we expect version 47 to be released?
(Assignee)

Comment 7

2 years ago
(In reply to dan from comment #6)
> Hi Gary, does this mean we can expect a fix for this issue when version 47
> gets released?
> 
> If so, when can we expect version 47 to be released?

Hi Dan, would you please try this bug on beta or newer version?

Hi Honza, I can't find related bugs may fix this issue, do you have any comment on this?
(Assignee)

Updated

2 years ago
Flags: needinfo?(honzab.moz)
Flags: needinfo?(dan)
(Assignee)

Comment 8

2 years ago
(In reply to dan from comment #6)
> Hi Gary, does this mean we can expect a fix for this issue when version 47
> gets released?

Yes, if it is really solved.

> If so, when can we expect version 47 to be released?

According to our schedule ([1]), v47 will be released on June. 7.

[1] https://wiki.mozilla.org/RapidRelease/Calendar
(In reply to Gary Chen [:xeonchen] from comment #7)
> Hi Honza, I can't find related bugs may fix this issue, do you have any
> comment on this?

honestly I never tried to reproduce myself.  If it's not reproducible with beta, then I'm not sure with which bug this could already be fixed.

Please also see the squid issue (http://bugs.squid-cache.org/show_bug.cgi?id=4473).  Maybe comment there to retest with current beta.  It would be good to find the change and duplicate this bug to/make dep on it.
Flags: needinfo?(honzab.moz)
(Reporter)

Comment 10

2 years ago
With squid configured as above Firefox 47b seems to work a lot better and remembers that Negotiate fails and keeps using basic proxy auth as it should.

However, there are still issues if "auth_param negotiate keep_alive" squid config is set to "on", i.e. "auth_param negotiate keep_alive on" instead of "auth_param negotiate keep_alive off", however, this might be a squid bug. I need to do more tests.

This is unfortunate because I think we need to configure squid with "auth_param negotiate keep_alive on" for IE and Chrome to work in this case, and now it seems we must have "auth_param negotiate keep_alive off" for the new Firefox 47b to work.

But again needs more testing. Seems like a bit of a mess getting all browsers working with squid if both Negotiate and Basic auth are configured at the same time.
(Assignee)

Updated

2 years ago
Flags: needinfo?(dan)
(Assignee)

Comment 11

2 years ago
I think this has been fixed in bug 137852.
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 137852
(Assignee)

Comment 12

2 years ago
Hi Dan, if you have any further issue about turning keep alive on, please open another bug to discuss. Thank you.
(In reply to Gary Chen [:xeonchen] from comment #11)
> I think this has been fixed in bug 137852.
> 
> *** This bug has been marked as a duplicate of bug 137852 ***

That bug just reorders how we send cached credentials (before that bug we were sending the oldest first, now we send the newest first).

This bug issue is a bit different and I would not expect bug 137852 fixing it.

Can you please explain/support your conclusion here?
Flags: needinfo?(xeonchen)
(Assignee)

Comment 14

2 years ago
(In reply to Honza Bambas (:mayhemer) from comment #13)
> (In reply to Gary Chen [:xeonchen] from comment #11)
> > I think this has been fixed in bug 137852.
> > 
> > *** This bug has been marked as a duplicate of bug 137852 ***
> 
> That bug just reorders how we send cached credentials (before that bug we
> were sending the oldest first, now we send the newest first).
> 
> This bug issue is a bit different and I would not expect bug 137852 fixing
> it.
> 
> Can you please explain/support your conclusion here?

In [1], Amos indicated that it's Firefox's bug.

For the case that keep-alive is disabled:

In comment 10, Dan mentioned that Firefox 47 beta can remember the correct
authentication order to negotiate with Squid server.

Based on comment 2, I set up a proxy server and check which revision changed
the behavior, and I found that it was changed by the bug (using git-bisect).

For the case that keep-alive is enabled:

I cannot connect to the proxy server just like [2] itself.
Got 407 error even when the Authorization header is sent.

For the first case, I think it's fixed by bug 137852, but the second case
is more likely an authentication error reported from server-side.

[1] http://bugs.squid-cache.org/show_bug.cgi?id=4473#c4
[2] http://bugs.squid-cache.org/show_bug.cgi?id=4473
Flags: needinfo?(xeonchen)
(In reply to Gary Chen [:xeonchen] from comment #14)
> (In reply to Honza Bambas (:mayhemer) from comment #13)
> > (In reply to Gary Chen [:xeonchen] from comment #11)
> > > I think this has been fixed in bug 137852.
> > > 
> > > *** This bug has been marked as a duplicate of bug 137852 ***
> > 
> > That bug just reorders how we send cached credentials (before that bug we
> > were sending the oldest first, now we send the newest first).
> > 
> > This bug issue is a bit different and I would not expect bug 137852 fixing
> > it.
> > 
> > Can you please explain/support your conclusion here?
> 
> In [1], Amos indicated that it's Firefox's bug.
> 
> For the case that keep-alive is disabled:
> 
> In comment 10, Dan mentioned that Firefox 47 beta can remember the correct
> authentication order to negotiate with Squid server.
> 
> Based on comment 2, I set up a proxy server and check which revision changed
> the behavior, and I found that it was changed by the bug (using git-bisect).

Thanks!

> 
> For the case that keep-alive is enabled:
> 
> I cannot connect to the proxy server just like [2] itself.
> Got 407 error even when the Authorization header is sent.
> 
> For the first case, I think it's fixed by bug 137852, but the second case
> is more likely an authentication error reported from server-side.
> 
> [1] http://bugs.squid-cache.org/show_bug.cgi?id=4473#c4
> [2] http://bugs.squid-cache.org/show_bug.cgi?id=4473
You need to log in before you can comment on or make changes to this bug.