1924654 - SAML SPNEGO fails since release 128

Status: RESOLVED WONTFIX

(Firefox for Android :: General, defect)

Description

[Nicolas ROBLIN]

Steps to reproduce:

Our IT installed on some computers the Firefox 128 release to test it.
We use Shibboleth as IDP
We use a custom java lib on top of opensaml lib for SP (lots of internal and external web sites)
Trace logger has been activated on SP and IDP.
Dev console has been activated during test
Checked negociation key in about:config, does not seem related according to some manual tests.

Actual results:

The negotiation is closed by client (Firefox?)

Here is IDP log (we can see the client is closing negociation)

2024-10-10 16:06:33,052 - WARN [net.shibboleth.idp.authn.spnego.impl.SPNEGOAuthnController:224] - SPNEGO authentication problem signaled by client
2024-10-10 16:06:33,065 - INFO [net.shibboleth.idp.authn.impl.ValidateExternalAuthentication:129] - Profile Action ValidateExternalAuthentication: External authentication produced error message: SPNEGONotAvailable
2024-10-10 16:06:33,066 - INFO [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:129] - Profile Action SelectAuthenticationFlow: Moving incomplete flow authn/SPNEGO to intermediate set
2024-10-10 16:06:33,066 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:255] - Profile Action SelectAuthenticationFlow: No specific Principals requested
2024-10-10 16:06:33,067 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:290] - Profile Action SelectAuthenticationFlow: No usable active results available, selecting an inactive flow
2024-10-10 16:06:33,067 - DEBUG [net.shibboleth.idp.authn.impl.SelectAuthenticationFlow:338] - Profile Action SelectAuthenticationFlow: Selecting inactive authentication flow authn/Password

As we have no default flow defined in IDP for this case, it redirect to login/passwd which is normal.

On SP side, nothing relevant about the error.

Expected results:

As before 128, that spnegociation is ok and the

Comment 1

[Nicolas ROBLIN]

Maybe a regression of https://bugzilla.mozilla.org/show_bug.cgi?id=1805666
It seems it was included in 128 and was not in 115 (which worked well)

Comment 2

[Valentin Gosu [:valentin]]

Hi Nicolas,

Would you mind capturing some HTTP logs for us?
https://firefox-source-docs.mozilla.org/networking/http/logging.html

If you have any private info (paswords, cookies) in the logs, please send the logs to [e-mail]

Thanks!

Comment 3

[Nicolas ROBLIN]

Hello, Valentin,

Sent log. Too long to post here I think.

I forgot to add something.

After the client closed connection, we can see that /idp/profile/Authn/SPNEGO/e4s1/error?conversation=e4s1 is called.

Is it called by Mozilla? Cause I tried to debug our java SP but can not find where this url is called.

Thanks.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Fenix::General' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Comment 5

[Valentin Gosu [:valentin]]

(In reply to Nicolas ROBLIN from comment #3)

Hello, Valentin,

Sent log. Too long to post here I think.

I forgot to add something.

After the client closed connection, we can see that /idp/profile/Authn/SPNEGO/e4s1/error?conversation=e4s1 is called.

At first glance I can't see e4s1 being called from Firefox.

2024-10-15 09:30:46.084 ⁃ nsHttpChannel ⁃ 1f80ef37000 ⁃ on-stop ⁃ status=804b0003 ⁃ http-status=302 ⁃ url=[domain]/idp/profile/SAML2/Redirect/SSO?SAMLRequest=...
2024-10-15 09:30:46.231 ⁃ nsHttpChannel ⁃ 1f80ef33400 ⁃ on-stop ⁃ status=804b0003 ⁃ http-status=302 ⁃ url=[domain]/idp/profile/SAML2/Redirect/SSO?execution=e3s1
2024-10-15 09:30:46.264 ⁃ nsHttpChannel ⁃ 1f80ef34c00 ⁃ finished ⁃ status=0 ⁃ http-status=401 ⁃ url=[domain]/idp/profile/Authn/SPNEGO/e3s1?conversation=e3s1
2024-10-15 09:30:46.407 ⁃ nsHttpChannel ⁃ 1f80ef39400 ⁃ finished ⁃ status=0 ⁃ http-status=n/a ⁃ url=[domain]/idp/images/dummylogo.png
2024-10-15 09:30:46.425 ⁃ nsHttpChannel ⁃ 1f80fee4800 ⁃ open ⁃ status=n/a ⁃ http-status=n/a ⁃ url=[domain]/favicon.ico
2024-10-15 09:30:46.555 ⁃ nsHttpChannel ⁃ 1f80fed8800 ⁃ on-stop ⁃ status=804b0003 ⁃ http-status=302 ⁃ url=[domain]/idp/profile/Authn/SPNEGO/e3s1/error?conversation=e3s1
2024-10-15 09:30:46.633 ⁃ nsHttpChannel ⁃ 1f80fed9400 ⁃ on-stop ⁃ status=804b0003 ⁃ http-status=302 ⁃ url=[domain]/idp/profile/SAML2/Redirect/SSO?execution=e3s1&_eventId_proceed=1
2024-10-15 09:30:46.791 ⁃ nsHttpChannel ⁃ 1f80feda000 ⁃ finished ⁃ status=0 ⁃ http-status=200 ⁃ url=[domain]/idp/profile/SAML2/Redirect/SSO?execution=e3s2
2024-10-15 09:30:47.046 ⁃ nsHttpChannel ⁃ 1f8120dd000 ⁃ finished ⁃ status=0 ⁃ http-status=n/a ⁃ url=[domain]/favicon.ico

I'll have a closer look at at the logs to figure out why we fail.

Comment 6

[Nicolas ROBLIN]

Sorry the conversation number was en example from a previous test.

Do you want me to reroll a complete test with all information?

Comment 7

[Valentin Gosu [:valentin]]

Nicolas, I see in the logs the following line:
`2024-10-15 09:30:46.309000 UTC - [Parent 10212: Main Thread]: D/nsHttp ProcessAuthentication failed [rv=804b002a]
804b002a is NS_ERROR_UNKNOWN_PROXY_HOST which is returned from here.

I wonder if it's bug 1741375 that is causing these issues. Can you check if going to about:preferences > Network settings and uncheck Proxy DNS when using SOCKS v5 ?

Otherwise, could you use mozregression to find the bug that caused the issue?
https://mozilla.github.io/mozregression/quickstart.html

This should allow us to pinpoint the regressing changeset.
Thanks!

Comment 8

[Nicolas ROBLIN]

As soon as Proxy DNS when using SOCKS v6 is unchecked, it work. (Tried multiple time).

Do you think it is a bug, or our IT did not parameterized Firefox well?

Thanks for information about debugging Firefox, it will be really usefull.

Comment 9

[Valentin Gosu [:valentin]]

Assuming your company is using enterprise policies for Firefox, they can set this option to false using UseProxyForDNS

https://mozilla.github.io/policy-templates/#proxy
https://searchfox.org/mozilla-central/rev/754074e05178e017ef6c3d8e30428ffa8f1b794d/browser/components/enterprisepolicies/helpers/ProxyPolicies.sys.mjs#59-62

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

:manuel, since you are the author of the regressor, bug 1741375, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 11

[Manuel Bucher [:manuel]]

I've updated the enterprise policy doc. @Niklas were you able to resolve your issue with this information? If so, I think there is no more to do from our side and we could close this bug as such setups are relatively rare.

Comment 12

[Nicolas ROBLIN]

Yep, thank you, you can close it.

IT updated the package to take the new sock5 key into account:

network.proxy.socks_remote_dns is dedicated to socks4 default value false.
network.proxy.socks5_remote_dns is dedicated to socks5, default value true.

Comment 13

[Manuel Bucher [:manuel]]

Thank you for confirming! Resolving as WONTFIX, because it kinda is a valid regression (other option would be to close as INVALID). The bug origins from a side-effect of changes in default behavior, which we want to keep. If there are more reports we might want to consider doing more to aid affected setups, but this is the first regression observed.