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.

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.

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).

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.

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.

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.

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

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!

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.

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

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;'>

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

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.

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

Should we backport this to ESR? It grafts cleanly.

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 on attachment 9252166 [details]
Bug 1729807: HTTPS-First should support fallback of view-source URIs from https to http

Approved for 91.5esr.

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