Closed Bug 1809151 Opened 1 year ago Closed 1 year ago

corporate web proxy no kerberos auth for iframe content since 108.0.1

Categories

(Core :: Networking, defect, P2)

Firefox 108
defect

Tracking

()

RESOLVED FIXED
111 Branch
Tracking Status
relnote-firefox --- 109+
thunderbird_esr102 --- unaffected
firefox-esr102 --- unaffected
firefox109 --- fixed
firefox110 --- fixed
firefox111 --- fixed

People

(Reporter: pidpad, Assigned: edgul)

References

(Regression)

Details

(Keywords: regression, Whiteboard: [necko-triaged][necko-priority-queue][enterprise])

Attachments

(2 files, 1 obsolete file)

Attached image FF_issue.png

Steps to reproduce:

corporate proxy with kerberos authentication (policy, no content without authentification)

Since FF updated to the latest version 108.0.1, we see issues with the kerberos authentication when there is embedded iframe content on a page. FF does not send any authentication for the iframe content, for the rest of the page it does.
We have the issue persistent on different laptops and virtual maschines.
When we download an older FF version the issue is not present, after the update it is.

There was no change on our coporate proxy, only the FF update.
Even in the beta and nightly the problem persists

Actual results:

the web page loads fine, except for the iframe content.
error: proxy server ist refusing the connection (because of no auth, we see it in the web proxy logs)

Expected results:

embedded iframe content should be send with kerberos authentification to the proxy an the content should load fine.

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

Component: Untriaged → Networking
Product: Firefox → Core

Thank you for the report.
Would you be able to use mozregression to determine which change introduced this bug?
Install -> Quickstart Guide

Flags: needinfo?(patrick.kuncke)

Hi Valentin,

i ran the mozregression tool and it seems that the change which intoduced this bug was the following:

app_name: firefox
build_date: 2022-11-11
build_file: C:\Users\XXX.mozilla\mozregression\persist\2022-11-11--mozilla-central--firefox-108.0a1.en-US.win64.zip
build_type: nightly
build_url: https://archive.mozilla.org/pub/firefox/nightly/2022/11/2022-11-11-09-37-17-mozilla-central/firefox-108.0a1.en-US.win64.zip
changeset: b7164776589657b7d7fd40d32268b2a489eed789
pushlog_url: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=df541ee6f62267803ead2b4e966dc2c06a23c58a&tochange=b7164776589657b7d7fd40d32268b2a489eed789
repo_name: mozilla-central
repo_url: https://hg.mozilla.org/mozilla-central

Flags: needinfo?(patrick.kuncke)

Hi Reporter,

Could you please also try to record a http log?
Please send the log to necko@mozilla.com since it may contain some privacy information.

Thanks.

Flags: needinfo?(patrick.kuncke)

Hi Necko,

I sent you the file by e-mail.

Flags: needinfo?(patrick.kuncke)

Thanks for the log.
This looks like to be regressed by bug 1629307.

Sunil, could you take a look?
Thanks.

Flags: needinfo?(smayya)
Duplicate of this bug: 1807718

Thanks Kershaw, I will have a look.

Flags: needinfo?(smayya)
Severity: -- → S2
Priority: -- → P2
Whiteboard: [necko-triaged][necko-priority-review]
Assignee: nobody → smayya

Based on comment #3, this bug contains a bisection range found by mozregression. However, the Regressed by field is still not filled.

:smayya, if possible, could you fill the Regressed by field and investigate this regression?

For more information, please visit auto_nag documentation.

Flags: needinfo?(smayya)
Keywords: regression
Flags: needinfo?(smayya)
Regressed by: 1629307

Since, fix for Bug 1629307 was delivered, we disable auth prompts for requests which does not allow loading of the page via iframes ( for e.g. X-Frame-Options: deny).
The rationale was that there is no point in having auth prompts when the page is not going to be successful due to CSP failures post authentication.

In this bug from the logs it is evident that the CSP policy does not allow loading of the page via iframes.

1710 2023-01-09 15:57:12.589000 UTC - [Parent 22192: Socket Thread]: V/nsHttp ParseContentType [type=text/html]                                              
....        
1716 2023-01-09 15:57:12.589000 UTC - [Parent 22192: Socket Thread]: E/nsHttp nsHttpTransaction::ParseLine [X-Frame-Options: deny]

AFAIU the header X-Frame-Options is added by the proxy and not by the site as it would deny loading the page even before our fix for Bug 1629307 was delivered.

To solve this bug we need to know if the header X-Frame-Options was added by proxy or by the original page. I think this is very difficult/impossible.

:Valentin
Please correct me if I my observations are wrong.

I propose to remove the check we introduced in 1629307 via pref until we are sure we cannot solve the auth prompt problem.

Flags: needinfo?(valentin.gosu)

Dear Reporter,

Thank you taking time to file this bug and providing all the required information.
As mentioned in the previous comment, we strongly suspect that the header X-Frame-Options: deny was added by the proxy and not the original website.

I visited the website https://www.golem.de/ with devtools opened.
I could not see the X-Frame-Options header.
Could you please confirm this header was added by the proxy and not by the original site? If this is the case you could try disabling it as temporary fix.
Thanks

Flags: needinfo?(patrick.kuncke)

Hi Sunil,

i guess the X-Frame-Options: deny you are seeing in the logs is the answer from the coporate proxy, because no authentication was sent for kerberos the proxy answers with a ntlm negotiate as a fallback.

I found no option to disable any X-Frame-Options.
We do not manipulate any content of the website with the proxy, we only search for malicious content.

best regards
pidpad

Flags: needinfo?(patrick.kuncke)

Backout the regressing patch and reopen regressing bug. Uplift backout to beta. Moving to priority queue.

Whiteboard: [necko-triaged][necko-priority-review] → [necko-triaged][necko-priority-queue]
Assignee: smayya → edgul

Comment on attachment 9313818 [details]
Bug 1809151 - corporate web proxy no kerberos auth for iframe content by backout 1629307 r=#necko-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined:
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is just a backout.
  • String changes made/needed:
  • Is Android affected?: Unknown
Attachment #9313818 - Flags: approval-mozilla-beta?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [necko-triaged][necko-priority-queue] → [necko-triaged][necko-priority-queue][enterprise]

Will we also want to back out on the release branch? Thanks

Set release status flags based on info from the regressing bug 1629307

(In reply to Pascal Chevrel:pascalc from comment #16)

Will we also want to back out on the release branch? Thanks

Flags: needinfo?(edgul)

Yes, I think we should.
Ed, could you request release and beta uplift? Thanks.

Pushed by eguloien@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8d52a2806191
corporate web proxy no kerberos auth for iframe content by backout 1629307 r=necko-reviewers,valentin,jesup

Comment on attachment 9313818 [details]
Bug 1809151 - corporate web proxy no kerberos auth for iframe content by backout 1629307 r=#necko-reviewers

Beta/Release Uplift Approval Request

  • User impact if declined:
  • Is this code covered by automated tests?: No
  • Has the fix been verified in Nightly?: No
  • Needs manual test from QE?: No
  • If yes, steps to reproduce:
  • List of other uplifts needed: None
  • Risk to taking this patch: Low
  • Why is the change risky/not risky? (and alternatives if risky): This is just a backout
  • String changes made/needed:
  • Is Android affected?: Unknown
Flags: needinfo?(edgul)
Attachment #9313818 - Flags: approval-mozilla-release?

Yes, thanks.

corporate web proxy no kerberos auth for iframe content by backout 1629307 r=necko-reviewers,valentin,jesup
https://hg.mozilla.org/integration/autoland/rev/8d52a2806191493bd57f68590f09059bf6986c5f
https://hg.mozilla.org/mozilla-central/rev/8d52a2806191

Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → 111 Branch

Does the last post from Sebastian means that I can test if the problem is gone in the latest nightly build?

I can confirm, the issue is resolved in the nightly build from today.
The page is now loading without any issues again!

Comment on attachment 9313818 [details]
Bug 1809151 - corporate web proxy no kerberos auth for iframe content by backout 1629307 r=#necko-reviewers

Approved for 110.0b6.

Attachment #9313818 - Flags: approval-mozilla-beta? → approval-mozilla-beta+

Comment on attachment 9313818 [details]
Bug 1809151 - corporate web proxy no kerberos auth for iframe content by backout 1629307 r=#necko-reviewers

Approved for 109.0.1

Attachment #9313818 - Flags: approval-mozilla-release? → approval-mozilla-release+

Added to the 109.0.1 relnotes:

Fixed an issue causing authentication prompts to not appear when loading pages in some enterprise environments

A patch has been attached on this bug, which was already closed. Filing a separate bug will ensure better tracking. If this was not by mistake and further action is needed, please alert the appropriate party. (Or: if the patch doesn't change behavior -- e.g. landing a test case, or fixing a typo -- then feel free to disregard this message)

Attachment #9316056 - Attachment is obsolete: true
Flags: needinfo?(valentin.gosu)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: