1805666 - Error 401 with SPNEGO authent in private browsing mode on Firefox ESR 102

Status: RESOLVED FIXED

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

Description

[Marius Tarlo]

Attachment: WAM-KO.png

Steps to reproduce:

When we try to reach an internal URL using SPNEGO authentication, using private browsing mode, we've got an error 401 "Unauthorized", since Firefox ESR 102 (was OK on Firefox ESR 91.x)
If we refresh the page immediately, it authenticates well

I've used mozregression to narrow down to the corresponding Nightly builds :
Last known good Nightly version : 97.0a1 buildid 20211207040938
First known bad Nightly version : 97.0a1 buildid 20211207155117

Pushlog between these versions : https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=edcfdb2bbe36f9c40c96ac5b8201aaa1e956eca6&tochange=cd413a8401785169b480b8643b6e3880043c5093

We have also seen that if we activate the option "Delete cookies and site data when the browser is closed", it fixes the issue

Comment 1

[Marius Tarlo]

Attachment: WAM-OK.png

Comment 2

[Monica Chiorean]

Mark as new since the pushlog was given.

Comment 3

[Mike Kaply [:mkaply]]

My guess is this is related to:

https://bugzilla.mozilla.org/show_bug.cgi?id=650091

But that should have made things better.

Comment 4

[Mike Kaply [:mkaply]]

Valentin, do you have any thoughts on this?

Comment 5

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

Thank you for the report. It's not entirely clear to me if this is a Firefox bug, or bug 650091 triggers a server side bug.

(In reply to Marius Tarlo from comment #0)

If we refresh the page immediately, it authenticates well

We have also seen that if we activate the option "Delete cookies and site data when the browser is closed", it fixes the issue

So, this makes me think it's either connected to the HTTP cache or cookies.
Could you check if disabling the HTTP cache fixes the issue? (Either by opening the developer tools - Ctrl-Shift-E and click Disable cache - or by pref browser.cache.disk.enable=false & browser.cache.memory.enable=false)

Also consider capturing some HTTP logs and send them to [e-mail]

Comment 6

[Marius Tarlo]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #5)

Could you check if disabling the HTTP cache fixes the issue? (Either by opening the developer tools - Ctrl-Shift-E and click Disable cache - or by pref browser.cache.disk.enable=false & browser.cache.memory.enable=false)

Hello, sorry for the late answer
Disabling the HTTP cache does not seem to fix the issue

Also consider capturing some HTTP logs and send them to [e-mail]

We'll try to capture some HTTP logs and send them

Thank you !

Comment 7

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

Thank you for the logs. Indeed, the bug does occur because of Bug 650091 - Sort authentication challenges by safety rating, but not how I actually expected.

The server responds with:

2023-01-27 14:34:35.019000 UTC - [Parent 16232: Socket Thread]: E/nsHttp   WWW-Authenticate: Negotiate
2023-01-27 14:34:35.019000 UTC - [Parent 16232: Socket Thread]: E/nsHttp   WWW-Authenticate: NTLM

This is the proper order, so we don't actually sort them.

We try Negotiate, then move on to NTLM, get the credentials, and set the proper authorization header.
The server responds with:

2023-01-27 14:34:35.053000 UTC - [Parent 16232: Socket Thread]: E/nsHttp nsHttpTransaction::ParseLine [WWW-Authenticate: NTLM <token>]
2023-01-27 14:34:35.053000 UTC - [Parent 16232: Socket Thread]: E/nsHttp nsHttpTransaction::ParseLine [WWW-Authenticate: Negotiate]

This is where the problem happens. I wouldn't expect a WWW-Authenticate: Negotiate header from the header once NTLM authentication has happened. But it does, and when we reorder to choose the most secure authentication type we go back to Negotiate so we loose the NLTM bit. I'm not sure if there's any guidance about this in any standard.

You can bypass this issue by setting network.auth.choose_most_secure_challenge to false, or by making sure the authentication server doesn't set WWW-Authenticate: Negotiate when sending the NTLM challenge.

We can probably try to mitigate this on the client side too by not sorting challenges that contain a token.

Comment 8

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

We can probably try to mitigate this on the client side too by not sorting challenges that contain a token.

So once the negotiation has started, we should no longer sort the requests.

Comment 9

[Valentin Gosu [:valentin] (he/him) {{ AFK in July }}]

Attachment: Bug 1805666 - Do not sort challenges if authentication is already in progress r=#necko

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/0a9775371235
Do not sort challenges if authentication is already in progress r=necko-reviewers,kershaw

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/0a9775371235