1857894 - Embedded videos can not be played at video.sina.com.cn with ETP set to STANDARD

Status: VERIFIED FIXED

(Core :: Privacy: Anti-Tracking, defect, P3)

Description

[Raul Bucata]

Attachment: Untitled.png

Environment:
Operating System: Windows 10 PRO x64
Firefox version: Firefox Nightly 120.0a1 (2023-10-08)

Preconditions:
ETP set to STANDARD
Clean profile

Steps to reproduce:

1. Navigate to : https://video.sina.com.cn/p/news/2023-10-09/detail-imzqnhxr8243879.d.html
2. Observe the result inside the embedded video placeholder.

Expected Behavior:
The video plays

Actual Behavior:
An error is shown

Notes:

• Not reproducible with ETP turned OFF(Both Normal and Private Browsing)
• Works as expected using Chrome
• Screenshot attached

Comment 1

[Calin Tanase]

Attachment: sina cn ETP OFF vs Standard ETP.png

Seems to be related with video.sina.cn

Comment 2

[Benjamin VanderSloot [:bvandersloot]]

This appears to be because of the Referer header on the video resource, not because of partitioning.

Specifically the video resource is http://... but the request is being sent as https://. However the Referer header is not being sent for the video resource when ETP is enabled.

Comment 3

[Benjamin VanderSloot [:bvandersloot]]

I think with ETP disabled we aren't enforcing RefererPolicy (which is no-referer-when-downgrade).

Christoph: Should Mixed Content auto-upgrades change the content's security level when considering the RefererPolicy?

Comment 4

[Christoph Kerschbaumer [:ckerschb}]

The resource itself is available over https?

It's very likely that mixed-content-auto-upgrading needs to touch the referrer-policy bits.

Malte, can you take a look at this one?

Comment 5

[Malte Jürgens [:maltejur]]

The issue here seems to be that the site has CSP upgrade-insecure-requests enabled, and the referrer gets calculated before the upgrade is happening. When ETP is disabled this isn't a problem in this case, as the site sets its referrer policy to always/unsafe-url. But once ETP gets enabled Firefox will use strict-origin-when-cross-origin, as it won't consider less secure policies than the default (disallowCrossSiteRelaxing). In that case the referrer of course won't be sent, as when it is calculated the target URL is still http and https->http isn't allowed under strict-origin-when-cross-origin.

This issue seems to be a bit more general though. The referrer for everything that's being upgraded because of NS_ShouldSecureUpgrade seems to be calculated before the actual upgrade is happening. I could reproduce the same behavior on a small test site with HSTS, Mixed content upgrading, CSP upgrade-insecure-requests and HTTPS-Only.

Comment 6

[Malte Jürgens [:maltejur]]

Attachment: Bug 1857894 - Recalculate referrer based on original referrer after non-HSTS HTTPS upgrade r?#necko-reviewers,freddyb!

Comment 7

[Malte Jürgens [:maltejur]]

Upon closer inspection of our code and the fetch spec, this seems to only be an issue with Mixed Content upgrading and CSP Upgrade-Insecure-Requests, and not HSTS. Per spec, we should follow this order:

1. Potentially upgrade a request by means of upgrade-insecure-requests (Main fetch 5.)
2. Potentially upgrade a mixed content request (Main fetch 6.)
3. Determine the referrer of the request (Main fetch 9.)
4. Potentially set the scheme to https if the relevant HSTS conditions apply (Main fetch 10.)

I am not sure where HTTPS-First and HTTPS-Only would fit in there. In the ongoing HTTPS upgrades proposal, which is roughly trying to achieve what HTTPS-First does, the upgrade step is placed before mixed content upgrading. So judging from that, I would also recalculate the referrer for HTTPS-First and HTTPS-Only.

Comment 8

[Malte Jürgens [:maltejur]]

Attachment: Bug 1857894 - Make includesubdomains.preloaded.test available to mochitest r?freddyb

This way we have a domain available that is on the HSTS preload list.

cert9.db, key4.db and mochitest.client have been generated by ./mach python build/pgo/genpgocert.py,
as per https://firefox-source-docs.mozilla.org/build/buildsystem/test_certificates.html.

Comment 9

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

There are some r+ patches which didn't land and no activity in this bug for 2 weeks.
:mjurgens, could you have a look please?
If you still have some work to do, you can add an action "Plan Changes" in Phabricator.
For more information, please visit BugBot documentation.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d291d8ac8124
Make includesubdomains.preloaded.test available to mochitest r=freddyb
https://hg.mozilla.org/integration/autoland/rev/504ffc20d2eb
Recalculate referrer based on original referrer after non-HSTS HTTPS upgrade r=necko-reviewers,freddyb,kershaw

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/d291d8ac8124
https://hg.mozilla.org/mozilla-central/rev/504ffc20d2eb

Comment 12

[Daniel Bodea [:danibodea]]

I can reproduce this issue in Release v122.0.1 and I can confirm the fix in Beta v122.0b8 and v122.0b9 and Nightly v124.0a1.