1259411 - 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

Status: RESOLVED DUPLICATE of bug 137852

(Core :: Networking: HTTP, defect)

Description

[dan]

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

Comment 1

[Honza Bambas (:mayhemer)]

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).

Comment 2

[dan]

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...

Comment 3

[Honza Bambas (:mayhemer)]

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.

Comment 4

[dan]

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------

Comment 5

[Gary Chen [:xeonchen]]

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

Comment 6

[dan]

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?

Comment 7

[Gary Chen [:xeonchen]]

(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?

Comment 8

[Gary Chen [:xeonchen]]

(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

Comment 9

[Honza Bambas (:mayhemer)]

(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.

Comment 10

[dan]

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.

Comment 11

[Gary Chen [:xeonchen]]

I think this has been fixed in bug 137852.

Comment 12

[Gary Chen [:xeonchen]]

Hi Dan, if you have any further issue about turning keep alive on, please open another bug to discuss. Thank you.

Comment 13

[Honza Bambas (:mayhemer)]

(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?

Comment 14

[Gary Chen [:xeonchen]]

(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

Comment 15

[Honza Bambas (:mayhemer)]

(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