1727419 - Unable to navigate to http site when https request returns 307 Temporary Redirect

Status: RESOLVED DUPLICATE of bug 1725646

(Core :: DOM: Security, defect)

Description

[Arturo Mejia [:amejia]]

Steps to reproduce:

1. Open a private tab (with a new profile)
2. Navigate to http://www.bom.gov.au

Expected behavior.

The user should be able to see some information about why can't access the site,
maybe mentioning that it's because HTTPS only mode it's active in private mode by default

Actual behavior.

The user is not able to navigate to the site without any information why.

I think the issue it's related to this pref dom.security.https_first_pbm to be true by default but there is none UI to inform users what is happening unless dom.security.https_only_mode_* are true, this only happens when the user goes and manually turn the feature on.

Comment 1

[Arturo Mejia [:amejia]]

We are experiencing some issue with this pref (dom.security.https_first_pbm) in Android (Focus and Fenix) as we haven't implement UI for HTTPS only mode, users that are not able to navigate to HTTP site on private mode (related ticket), and we can't control this pref via GeckoView, as it's only exposed dom.security.https_only_mode.

Comment 2

[Daniel Veditz [:dveditz]]

If you don't have the UI to handle errors and exceptions then Fenix and Focus (or GeckoView) should turn it off. Or maybe the right thing to do is to turn it off in the main Gecko StaticPrefs and turn it on in the firefox.js specific overrides

I'll move this to "DOM: Security" for now, but the fix might end up being in mobile code instead.

Is there a tracking issue for this in Github? I imagine this might end up a blocker.

FWIW I can get to this site on Fenix nightly so maybe there was another bug tracking this problem?

Comment 3

[Arturo Mejia [:amejia]]

If you don't have the UI to handle errors and exceptions then Fenix and Focus (or GeckoView) should turn it off. Or maybe the right thing to do is to turn it off in the main Gecko StaticPrefs and turn it on in the firefox.js specific overrides.

From Java/Kotlin (AC,Fenix, Focus) we don't have a way to turn it off, as GeckoView doesn't expose the dom.security.https_first_pbm pref.

Is there a tracking issue for this in Github? I imagine this might end up a blocker.

Yes we have https://github.com/mozilla-mobile/focus-android/issues/5199.

FWIW I can get to this site on Fenix nightly so maybe there was another bug tracking this problem?

The problem is only visible on private mode, and it's not exclusive for this site only http://www.bom.gov.au, if you navigate to any http site on private mode you will be redirect to the https version try (http://permission.site/) the problem with http://www.bom.gov.au it's more noticeable as the site doesn't have a https version.

Comment 4

[Arturo Mejia [:amejia]]

The only pref that we have access from Geckoview are dom.security.https_only_mode and dom.security.https_only_mode_pbm, but they are off by default, I'm not able to access any http site, unless I manually turn off dom.security.https_first_pbm in about:config.

It looks like dom.security.https_first and dom.security.https_first_pbm were created to override the values of dom.security.https_only_mode and dom.security.https_only_mode_pbm, as the same issue is visible in desktop. If you turn off HTTPS only mode you are not able to navigate to any http site in private mode even when the feature is turned off until you manually turn it off dom.security.https_first_pbm, try with http://www.bom.gov.au and flipping the pref.

Comment 5

[Arturo Mejia [:amejia]]

Judging by how the dom.security.https_first_pbm and dom.security.https_only_mode_pbm preferences are configured, it looks like as we wanted avoid users accessing http sites in private mode unless they have HTTPS ONLY mode active. I'm not sure if it's a bug or it was an intentional feature?

Comment 6

[[ex-Mozilla] Agi Sferro | :agi]

I guess this is a weird edge case of https_first_pbm. What's happening in www.bom.gov.au is this:

• User navigates to www.bom.gov.au
• https_first upgrades the request to HTTPS
• www.bom.gov.au actually responds to the HTTPS saying "sorry we don't support https" 🤦‍♂️ so Gecko doesn't know it needs to reject the https page and load the http one instead

I see the same behavior on desktop when navigating to the page in private browsing (with HTTPS only turned off).

Comment 7

[Arturo Mejia [:amejia]]

You are right, Agi I'm not able to reproduce on http://www.columbia.edu/~fdc/sample.html

Comment 8

[Daniel Veditz [:dveditz]]

FWIW I can get to this site on Fenix nightly so maybe there was another bug tracking this problem?
The problem is only visible on private mode

Yes, I used a private tab in Fenix since I didn't see any other way to turn on https_only/https_first.

https-first tries to be a smarter http-only, and tries to fall back seamlessly. It doesn't always work, though (example: this bug), so without any kind of override UI you definitely shouldn't ship it. There are a bunch of edge cases that we can make work better, but it's never going to be 100% right.

Passing the overrides through to the engine is probably more important than passing the pref. Although we do have an about:config pref in Firefox for HTTP-first that could be turned off in an emergency, it's not exposed to users as an option in the regular "HTTP Only" preference UI. Until GeckoView supports passing through the necessary information GeckoView should override the prefs to turn this off.

I'd like to be clear that Christoph Kerschbaumer owns and is driving this feature; I'm sharing my (educated) opinion but I haven't been closely involved in this feature. Although I hope it's helpful while Christoph is on vacation, I'm not speaking for him.

Tomer has been working on many edge-case bugs related to https-only/https-first. It would definitely be good to get his feedback on this.

Comment 9

[Tomer Yavor]

Thanks for reporting!

I guess that bug might be a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=1725646.
We have a fix in the pipeline for it.
It is an endless-downgrade-upgrade loop that occurs because of the odd behavior of the website as Agi described above. I would guess that is an edge case. But as I said above we have a fix in the pipeline.

@comment 5
We shipped dom.security.https_first_pbm = true as default. So https-first is always enabled in private browsing. You can only disabled it by "about:config" and then switching dom.security.https_first_pbm.

If there is anything I missed to address, I would be glad to clarify it.

Comment 10

[Arturo Mejia [:amejia]]

Thanks Tomer!
Marking as dup of 1725646