650091 - Multiple Proxy-Authenticate headers order-dependency bug causes login popup with NTLM + Basic (pick auth schema by safety rating)

Status: RESOLVED FIXED

(Core :: Networking: HTTP, defect, P2)

Description

[Adrien de Croy]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.204 Safari/534.16
Build Identifier: 4.0

Firefox supports integrated auth with NTLM.

Our proxy supports several auth methods.  FF behaviour depends on the order of the Proxy-Authenticate headers.  If our proxy sends

HTTP/1.1 407 Please authenticate
Proxy-Authenticate: NTLM
Proxy-Authenticate: Basic realm="/"
etc

then FF logs in fine with no user interaction.

If the proxy sends 


HTTP/1.1 407 Please authenticate
Proxy-Authenticate: Basic realm="/"
Proxy-Authenticate: NTLM
etc

(e.g. swap the order of the auth challenge headers for the different methods)

Then FF pops a login dialog (with message "the server says '/'").  At this point you can hit the cancel button, and after a few more popups (all cancelled) auth succeeds.



Reproducible: Always




order of these headers should not matter, FF should scan all the Proxy-Authenticate headers, and choose the best auth method.  NTLM of course should be chosen in preference to Basic.

This could have security implications if it leads users to use Basic in preference to NTLM (e.g. they enter their user/pass) it goes over the network in cleartext.

Comment 1

[Justin Dolske [:Dolske]]

I'm pretty sure order matters...

Regarding multiple headers with the same name, from http://www.w3.org/Protocols/rfc2616/rfc2616-sec4.html#sec4.2

"The order in which header fields with the same field-name are received is therefore significant to the interpretation of the combined field value, and thus a proxy MUST NOT change the order of these field values when a message is forwarded."

So these two examples would be equivalent to:

Proxy-Authenticate: Basic realm="/", NTLM
Proxy-Authenticate: NTLM, Basic realm="/"

Is there something specific that makes you believe the order shouldn't matter?

Comment 2

[Adrien de Croy]

Hi

It depends on the header itself whether order matters.  I agree proxies must not change order, but this is not the issue here, since this is a proxy-emitted response.

Take a look at

http://datatracker.ietf.org/doc/draft-ietf-httpbis-p7-auth/?include_text=1

Section 2. Access Authentication Framework

"The user agent MUST
   choose to use one of the challenges with the strongest auth-scheme it
   understands and request credentials from the user based upon that
   challenge."

I think it's pretty much common sense that the UA should choose the strongest method it supports.  This will require evaluating all advertised methods - regardless of order.

Regards

Adrien

Comment 3

[George Machitidze]

I confirm. Same problem when using NEGOTIATE and NTLM only and if NTLM is first.

Comment 4

[Patrick McManus [:mcmanus]]

see also bug 650091

Comment 5

[Patrick McManus [:mcmanus]]

(In reply to Patrick McManus [:mcmanus] from comment #4)
> see also bug 650091

duh - I mean see also bug 318253

Comment 8

[Honza Bambas (:mayhemer)]

removing from the [ntlm] list, the fix, if we want it, is in http channel.

Comment 9

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 10

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 12

[alexurbanac]

How can it happen that such a bug is known but not fixed for seven years? When can we expect a fix on this?

Comment 13

[Alberto Soverchia]

I can confirm this bug with firefox 64 on windows 10.
proxy: squid 4.4

if auth scheme in proxy configuration is listed as BASIC first NTLM second, firefox use basic, all other browsers (i tried chrome, Internet explorer, Edge) use NTLM.
if auth scheme in proxy configuration is NTLM first, BASIC second, firefox use correctly NTLM and ask no password (no change in the behaviour of other browsers).

Tried different settings for proxy in firefox: direct, via wpad, system proxy, but results are all the same: basic is the auth scheme used if listed first on the proxy configuration.
I also tried changing settings on about:config, with no results.

As stated above, from https://datatracker.ietf.org/doc/rfc7235/?include_text=1 :

the user agent ought to do so by selecting the challenge with what it
considers to be the most secure auth-scheme that it understands,
obtaining credentials from the user as appropriate

Comment 14

[alexurbanac]

How can it happen that such a bug is known but not fixed for eight years? When can we expect a fix on this?

Comment 16

[Honza Bambas (:mayhemer)]

To keep in parity with Chrome(ium), see https://www.chromium.org/developers/design-documents/http-authentication

In a nut shell, use the safest first, regardless of the order we receive it. It's also a good opportunity to rewrite the challenge parsing code with mozilla::Tokenizer to clean it up a bit.

I believe a preference to revert to the previous behavior (respect the server order) might be in place, just in case.

Comment 18

[alexander.veit]

Is there a chance that this bug will be fixed?

Recently we switched web sites in our corporate network to mixed Integrated Windows and Basic Authentication to allow access for mobile clients.
Now I'm being asked by users if they could switch their desktop browsers to Chrome to enable smooth login, and I don't know what to answer.

Comment 19

[Honza Bambas (:mayhemer)]

Dragana, what was the motivation to put this to P5? I think we want to fix this. It's not a small amount of work, though, the whole parser needs to be rewritten.

Comment 20

[Honza Bambas (:mayhemer)]

(In reply to alexander.veit from comment #18)

Is there a chance that this bug will be fixed?

Recently we switched web sites in our corporate network to mixed Integrated Windows and Basic Authentication to allow access for mobile clients.
Now I'm being asked by users if they could switch their desktop browsers to Chrome to enable smooth login, and I don't know what to answer.

Note that the authentication header ordering can be changed on the server side.

Comment 21

[alexander.veit]

(In reply to Honza Bambas (:mayhemer) from comment #20)

Note that the authentication header ordering can be changed on the server side.

As far as I know there's no way to configure the ordering of authentication headers in IIS.

By default Firefox should probably use the most secure authentication scheme, and only use the less secure methods as a fallback (security by default).

Chromium (see https://www.chromium.org/developers/design-documents/http-authentication) does the following:

Choosing an authentication scheme

When a server or proxy accepts multiple authentication schemes, our network stack selects the authentication scheme with the highest score:
* Basic: 1
* Digest: 2
* NTLM: 3
* Negotiate: 4
The Basic scheme has the lowest score because it sends the username/password unencrypted to the server or proxy.

So we choose the most secure scheme, and we ignore the server or proxy's preference, indicated by the order in which the schemes are listed in the WWW-Authenticate or Proxy-Authenticate response headers. This could be a source of compatibility problems because MSDN documents that "WinInet chooses the first method it recognizes." Note: In IE7 or later, WinInet chooses the first non-Basic method it recognizes.

Comment 22

[alexurbanac]

(In reply to alexander.veit from comment #21)

(In reply to Honza Bambas (:mayhemer) from comment #20)

Note that the authentication header ordering can be changed on the server side.

As far as I know there's no way to configure the ordering of authentication headers in IIS.

In my experience, IIS even seems to randomize the order in which authentication headers the are returned. This means that for some requests, the Basic authentication popup is shown, for some it is not (as reported in 1041465 closed as duplicate).

As the bug is already nine years old, our recommendation to our customers is to migrate away from FF, as this behaviour will probably not change in the foreseeable future.

Comment 24

[Valentin Gosu [:valentin] (he/him)]

Attachment: Bug 650091 - Sort authentication challenges by safety rating r=#necko

Comment 25

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de7aadc244b8
Sort authentication challenges by safety rating r=necko-reviewers,kershaw

Comment 26

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/de7aadc244b8

Comment 28

[Mike Kaply [:mkaply]]

I'd love to get this on the ESR once we're confident.

Comment 29

[Valentin Gosu [:valentin] (he/him)]

The patch builds on top of bug 1705659 which landed in 93. I am unsure if we'd be able to uplift that to 91 (if we're interested I could look into it - no regressions from that change AFAIK)

Comment 30

[Mike Kaply [:mkaply]]

That's a pretty huge patch. I doubt Ryan would go for that :).

Comment 31

[Ryan VanderMeulen [:RyanVM]]

Yeah, I think we'll need to let this go out in the ESR102 release.