1729807 - [https-first] view-source always uses https in private browsing: nested URIs don't get fallback logic

Status: RESOLVED FIXED

(Core :: DOM: Security, defect, P3)

Description

[pokechu022]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Firefox/91.0

Steps to reproduce:

The site http://www.dkc-atlas.com/ does not load over https. Load that site in private browsing (which should load correctly), and then press control+U. Alternatively, attempt to visit view-source:http://www.dkc-atlas.com/

I have Firefox's HTTPS-Only mode disabled, as I normally use the HTTPS Everywhere extension (I disabled it for this test, though). dom.security.https_first_pbm is true and dom.security.https_first is false.

Note that this issue doesn't happen with http://http.badssl.com/ - maybe it's special-cased?

Actual results:

Attempting to load view-source:http://www.dkc-atlas.com/ instead loads view-source:https://www.dkc-atlas.com/ which fails with an unable to connect message as the site does not support https.

Expected results:

The site's source should have shown up.

Comment 1

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

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

Comment 2

[Wruktarr]

Same issue on Firefox 92.0
view-source forces https from http on all sites in Private Browsing (Does not matter if website uses or does not use SSL certificate).

Comment 3

[pokechu022]

The reason why this doesn't happen with http://http.badssl.com/ is that that page responds to HTTPS with a redirect to HTTP (another example of such a site is http://uk.codejunkies.com/support/index.aspx). This issue only happens with sites where the HTTPS connection is refused (e.g. http://www.dkc-atlas.com/) or times out (e.g. http://www.metrorex.ro/). I've created a feature request for badssl.com to add subdomains that do this.

Comment 4

[Wruktarr]

Still bugged.

To reproduce bug go to website which do NOT have SSL certificate > right-click > show source code. Then it shows warning with potential risk. Firefox still forces non-https from to "view-source:https://<DOMAIN>", you cannot do "view-source:http://<DOMAIN>" as it will be redirected to "view-source:https://<DOMAIN>". There is no problem with doing so with domains which have SSL certificate.

Please fix this ASAP as for developers this very frustrating.

Comment 5

[pokechu022]

A workaround seems to be to set dom.security.https_first_pbm to false (and dom.security.https_first but that defaults to false). I think that disables the default-to-HTTPS behavior in private browsing mode, which is less secure; I use HTTPS everywhere (and have sites that I know don't support HTTPS configured so that HTTPS everywhere allows it) so it shouldn't be an issue for me.

Comment 6

[c2iab6pgflr3]

This bug exists on Firefox 92.0 on Ubuntu 20.04. My HTTPS settings are "Don’t enable HTTPS-Only Mode" but it still redirects to HTTPS when trying to view source.

I think this one is urgent, because if Firefox is unusable for developers, they might start using other browsers.

Comment 7

[Wruktarr]

Issue same on Firefox 92.0.1 (Windows).

Comment 8

[Wruktarr]

Attachment: view-sorce https force

You can see that on website where is not HTTPS (no SSL) it defaulty uses HTTP as expected but as soon as you open view-source it is automatically reconnected to https and website cannot be reached in this case in other cases it shows missing SSL certificate Firefox window (but as described we want to see source code on HTTP, no on HTTPS/SSL).

Comment 9

[Daniel Veditz [:dveditz]]

When we do this upgrade do we know the http URL is part of a nsINestedURI? If we did we should probably not try to upgrade view-source innerURIs. Whether the page upgraded or not, if we show the source of what the user is looking at we'll be doing the right thing. That would leave manually-entered (or pasted) view-source: urls potentially risky, but as a power-user feature I don't feel too bad about that.

Why doesn't the error page kick in? Are we comparing top-level schemes? If something is an nsINestedURI we need to look at the innermost URI instead. All nested schemes would probably have this problem, but it doesn't look like we have many anymore. jar: still exists, but is no longer allowed to fetch remote (http/https) files. NestedAboutRedirector shouldn't be an issue? That's used to track the real origin for about:blank contexts.

Comment 10

[Daniel Veditz [:dveditz]]

meant to put in a needinfo? for Tomer on comment 9

Comment 11

[Tomer Yavor]

Thank you. That is interesting.
We are upgrading it which I think could be okay for Https-first. But in the fallback we are only downgrading https request and not include "view-source:" which leads to that error and should be fixed.

In https-first we don't have an error page like in https-only that is why nothing occurs here. Yes, we are looking at the top-level schemes. We aren't checking if it is an nsINestedURI. You have a point that would be the correct way.

Thank you again!

Comment 12

[Daniel Veditz [:dveditz]]

We aren't checking if it is an nsINestedURI. You have a point that would be the correct way.

Another approach could be to consider view-source: a power-user feature and never upgrade those. Web content "view-source" links won't load so we don't have to worry about those. If the user selects the menu item (or Ctrl-U shortcut) and the current page is http: despite https-first then obviously it's the correct thing. And if someone knows about manually typing view-source: then trust them to know what they're doing. Might be easier said than done though -- if the upgrading happens deep in the http code it might know know the request was spawned from a nested URL. Or it might -- sorry, been a while since I've played with network code.

This bug is certainly annoying, but unfortunately there are higher priority https-first bugs. As a power-user feature the affected folks will have more ability to find and use various workarounds. Top of the pile for the backlog though.

Comment 13

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

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

Comment 14

[Christoph Kerschbaumer [:ckerschb]]

Attachment: Bug 1729807: HTTPS-First should support fallback of view-source URIs from https to http

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/9de4d948790d
HTTPS-First should support fallback of view-source URIs from https to http r=valentin

Comment 17

[Norisz Fay [:noriszfay]]

Backed out for causing mochitest failures on browser_downgrade_view_source.js

Backout link: https://hg.mozilla.org/integration/autoland/rev/5e374578524b5b7fb27c38f0eaf92e66437869ec
Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&selectedTaskRun=F6rDIujSSDqsn7lpgmH-1A.0&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=9de4d948790d39e9788c00004bb71359fc6d0c99
Failure log: https://treeherder.mozilla.org/logviewer?job_id=359112210&repo=autoland&lineNumber=2932
Failure line: TEST-UNEXPECTED-FAIL | dom/security/test/https-first/browser_downgrade_view_source.js | URL with query 'downgrade' should be http: - "<html> <head><title>404 Not Found</title></head> <body> <h1>404 Not Found</h1> <p> <span style='font-family: monospace;'>

Comment 18

[Christoph Kerschbaumer [:ckerschb]]

Huh, wonder what that problem is! Looking into it ...

Comment 19

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/62b53b028f7d
HTTPS-First should support fallback of view-source URIs from https to http r=valentin

Comment 20

[Robert Kissel]

I was about to report this as a bug, but I think I'm just confirming it in 94.0.2 (64-bit) Windoze.

Reproduction:

1. Visit http://www.stats.gov.cn/tjsj/tjbz/tjyqhdmhcxhfdm/2020/35/3505.html in a private browser window.

(http, not https)

2. Press Ctrl-U for view source

3. Observe that firefox tries to use view-source:https://www.stats.gov.cn/tjsj/tjbz/tjyqhdmhcxhfdm/2020/35/3505.html
   and reports "Secure Connection Failed

An error occurred during a connection to www.stats.gov.cn. Cannot communicate securely with peer: no common encryption algorithm(s).

Error code: SSL_ERROR_NO_CYPHER_OVERLAP

The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.

One may not view the source within Firefox at all.

Comment 21

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/62b53b028f7d

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Should we backport this to ESR? It grafts cleanly.

Comment 23

[Christoph Kerschbaumer [:ckerschb]]

Comment on attachment 9252166 [details]
Bug 1729807: HTTPS-First should support fallback of view-source URIs from https to http

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: The feature HTTPS-First is enabled in Private Browsing Mode and upgrades top-level resource loads from http to https. If a resource is not available over https, then this feature causes an automatic fallback to http. Apparently that automatic fallback to http did not happen for nested resources, like e.g in that case view-source. It's an easy fix and we should consider uplifting.
• User impact if declined: see above
• Fix Landed on Version: 96
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): It's a very self-contained fix for https-first mode, hence I consider the risk of uplifting as low.
• String or UUID changes made by this patch: no

Comment 25

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9252166 [details]
Bug 1729807: HTTPS-First should support fallback of view-source URIs from https to http

Approved for 91.5esr.

Comment 26

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/releases/mozilla-esr91/rev/2e12bb19f866