mkwst: Is this intended behavior?

+MoarTLS crew for further thoughts, including severity rating.

upgrade-insecure-requests is primarily a convenience mechanism; a site which wishes to block HTTP entirely can do so using source rules.

The issue around upgrade of redirection sounds like  Issue 615885 .

Ah, it is indeed very similar to 615885. I didn't see that when searching, my apologies. If you wish to close this report as a duplicate, I'll understand.

Reading the comments of that bug, I'd like to add ... block-all-mixed-content successfully detects the HTTPS->HTTP redirect and blocks the content. So Chrome has the required support in there for said CSP.

Also, I understand upgrade-insecure-requests is for convenience, but none of the available documentation on the web that I could find indicates that Chrome's behavior here is possible. Anyone using this to prevent mixed content will be in for a surprise, as I was.

https://www.w3.org/TR/upgrade-insecure-requests/

https://developers.google.com/web/fundamentals/security/prevent-mixed-content/fixing-mixed-content

https://googlechrome.github.io/samples/csp-upgrade-insecure-requests/

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests

It's not a critical security vulnerability, but it's unpleasant when our website visitors suddenly see a warning from Chrome that the webpage they are viewing is now insecure, and it's potentially hiding an actual real security alert if it trains people to dismiss these as false positives.

> it's unpleasant when our visitors suddenly see a warning from Chrome 

Re #3: For sure, I believe this is indeed a bug. If you're concerned about the lock going missing in this scenario, the most straightforward workaround for the moment is to use both upgrade-insecure-requests AND block-all-mixed-content.

(Test Page: https://bayden.com/test/CSP/UIRAndBlockAllMixedOnRedirects.aspx)

> https://bayden.com/test/CSP/UIRAndBlockAllMixedOnRedirects.aspx

... wow! Although exactly the behavior I would hope for, this is a very unexpected result. Please see:

https://www.w3.org/TR/upgrade-insecure-requests/#mix

"This ordering means that upgraded requests will not be flagged as mixed content. Moreover, it means that upgrade-insecure-requests’s effect takes place before the block-all-mixed-content directive would have a chance to block the request. If the former is set, the latter is effectively a no-op. We recommend that authors set one directive or the other, as outlined in §1.3 Recommendations."

Of course, I understand that browsers and the W3C don't always align in implementation details.

I will definitely update my site to use "upgrade-insecure-requests; block-all-mixed-content" for the time being, thank you!!

Side note: it appears my Firefox was indeed outdated, my apologies. After grabbing 55.0.3, I found that Firefox loads your page's image in both "only UIR" + "UIR+block-all-mixed-content" modes ... and neither show any indicator of a mixed content error o_O'  I suppose I need to submit a bug report to them, too.

Re #5: Yes, the expectation is that UIR would happen before BAMC; it isn't today (bug) but the BAMC is still effective in preventing the non-secure request.

Regarding Firefox: In Firefox 57.0b2 (64-bit) at least, Firefox does load the page's image in UIR and UIR+block-all-mixed-content modes, but it has correctly applied the UIR so that the image request is HTTPS (both for the redirector and the final image).

Re: #6, ah I see. With my example https://vgmrips.net/forum/download/file.php?avatar=44.png link, the server is bouncing the exact resource to HTTP, only dropping the 's' from the protocol. If you bounce that back to HTTPS again, it still won't serve you an HTTPS image, and that'll cause an infinite loop until it errors out. Which seems to be? what Safari does (error: too many redirects.) Sorry, you're much better than me at the network side of things. I didn't even realize Firefox was bouncing the image back to HTTPS again.

I can now confirm your workaround (upgrade-insecure-requests; block-all-mixed-content) works perfectly in all browsers.

Here's my test page: https://board.byuu.org/viewtopic.php?p=47010#p47010

The HTTPS->HTTP redirect image is blocked, the other HTTP image is properly redirected to HTTPS and shown, and there is no mixed content warning in any browser.

Thank you again for the workaround! This will correct hundreds of broken image links and dozens of broken avatars that using only block-all-mixed-content had caused me, without downgrading my site's security rating. Cheers! :D

Unfortunately it's a rather large project to fix this behavior of UIR (requires moving the implementation from Blink into the net stack) but it's definitely a bug we need to fix. :(

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot