1848571 - network.dns.upgrade_with_https_rr blocks mixed display content

Status: NEW

(Core :: Networking, defect, P2)

Description

[jscher2000]

As discussed in: https://support.mozilla.org/questions/1420757

If DNS over HTTPS is enabled, the insecure image on the page at https://archive.wvculture.org/vrr/va_view.aspx?Id=1588309&Type=Death will not load in a regular/non-private window (alt text is displayed). This is true even when

• dom.security.https_only_mode => false [default]
• dom.security.https_first => false [default]
• security.mixed_content.block_display_content => false [default]
• security.mixed_content.upgrade_display_content => false [default]

The lock icon indicates that mixed content has been allowed/loaded, but the image is not retrieved unless network.dns.upgrade_with_https_rr is toggled to false.

While this could be considered the site's DNS provider's "fault" for serving a resource record --

https://developer.mozilla.org/docs/Glossary/HTTPS_RR says "... the presence of an HTTPS RR signals that all useful HTTP resources on the origin are reachable over HTTPS, which in turn means that a browser can safely upgrade connections to the domain from HTTP to HTTPS."

-- it nevertheless is a problem for users. It is frustrating to troubleshoot and there are no relevant console messages explaining why the connect was upgraded that might help the user discover the cause of the problem.

Comment 1

[Valentin Gosu [:valentin] (he/him)]

Attachment: Pasted image 20230814121729.png

I had some trouble reproducing it so I ran a mozregression with DoH turned off and found this:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a9e2544bf84b79f7a734b4de6d975f52223f8b8a&tochange=2d5ad10a5df30d073e97023e3dd8e316d5270f49

It seems security.mixed_content.upgrade_display_content defaults to true on Nightly, so after turning it off I could reliably reproduce this.
The devtools panel does show the failed https request, but indeed it doesn't show why it was upgraded, especially after saying that it's loading it insecurely (see image).

I'm not sure what we should do here:

• Should we skip the HTTPS upgrade if NS_ShouldSecureUpgrade returns false?
• Should we display a devtools panel message that we upgraded it anyway?

Thoughts?

Comment 2

[Valentin Gosu [:valentin] (he/him)]

Extra note:
The image also doesn't load with Chrome without DoH. (please let me know if that's not the case for you)
It sounds like this might be a webcompat issue, and if we were to fix it, we should make sure to do that in a manner that works the same across all browsers. If security.mixed_content.upgrade_display_content is to become the default - then would we still want to fix this bug?

Comment 3

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

Setting Regressed by field after analyzing regression range found by mozregression in comment #1.

Comment 4

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

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

Comment 5

[jscher2000]

Thank you for the analysis!

In a perfect world, the user would be alerted to upgrade-driven failures on the "lock" icon and have the option to allow mixed display content as an exception on the Site Info panel.

Users with the HTTPS Only feature enabled have part of that experience. There is an On/Off/Off Temporarily selector on the Site Info panel which allows loading insecure display content, but the lock isn't marked in a manner that would suggest going to look for it.

I don't know whether we could reuse the https-only-load-insecure permission for display content that would be blocked for other reasons, or whether that would create other problems.

Comment 6

[jscher2000]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #2)

Extra note:
The image also doesn't load with Chrome without DoH. (please let me know if that's not the case for you)
It sounds like this might be a webcompat issue, and if we were to fix it, we should make sure to do that in a manner that works the same across all browsers.

MS Edge/Chrome do not display the image, but show a "broken image" icon next to the Alt Text so it is slightly more obvious what is going on. Their consoles indicate:

Mixed Content: The page at 'https://archive.wvculture.org/vrr/va_view.aspx?Id=1588309&Type=Death' was loaded over HTTPS, but requested an insecure element 'http://images.wvculture.org/1953911/0002943.gif'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html

And then the 404.

I don't see any UI informing the user why the insecure display content didn't load in Edge/Chrome. Their lengthy site permissions panel has the option to allow insecure content, but it would be pure guesswork on a user's part to go change that setting when an image is missing (assuming they don't use the developer tools). Hopefully we can do a bit better.

Comment 7

[Kershaw Chang [:kershaw]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #1)

Created attachment 9348816 [details]
Pasted image 20230814121729.png

I had some trouble reproducing it so I ran a mozregression with DoH turned off and found this:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=a9e2544bf84b79f7a734b4de6d975f52223f8b8a&tochange=2d5ad10a5df30d073e97023e3dd8e316d5270f49

It seems security.mixed_content.upgrade_display_content defaults to true on Nightly, so after turning it off I could reliably reproduce this.
The devtools panel does show the failed https request, but indeed it doesn't show why it was upgraded, especially after saying that it's loading it insecurely (see image).

I'm not sure what we should do here:

• Should we skip the HTTPS upgrade if NS_ShouldSecureUpgrade returns false?

Maybe not. I think we should try HTTPS upgrade as the spec defined. As said in comment#0, I think the problem is at the server side.

• Should we display a devtools panel message that we upgraded it anyway?

Sounds good to me. I agree that showing a message is helpful.

Comment 8

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

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

Comment 9

[Frederik Braun [:freddy]]

AFAIU this is fixed with security.mixed_content.upgrade_display_content set to true, which is hopefully coming soon. Not sure if this needs to fixed in necko then, but I'd lean towards no.

Comment 10

[Valentin Gosu [:valentin] (he/him)]

Let's just add a devtools notice message when we upgrade a request using a HTTPS record then.

Comment 11

[Kershaw Chang [:kershaw]]

(In reply to Valentin Gosu [:valentin] (he/him) from comment #10)

Let's just add a devtools notice message when we upgrade a request using a HTTPS record then.
The console message can be added around here.