New issue
Advanced search Search tips

Issue 753392 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Aug 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug
Team-Security-UX



Sign in to add a comment

Strict-Transport-Security does not suppress Mixed Content, leading to confusing DevTools experience

Reported by potoms....@gmail.com, Aug 8 2017 
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36

Steps to reproduce the problem:
1. navigate to https://codecov.io/
2. open devtools security tab
3. navigate to https://www.npmjs.com/package/url-pattern
4. check that it shows "insecure", look at "non-secure origins", click on "view requests in network panel"

What is the expected behavior?
there are requests in the filtered view

What went wrong?
there are no requests in the filtered view. STS took over on the non-https url http://codecov.io/github/snd/url-pattern/coverage.svg?branch=master

Should the browser even mark this page as insecure if STS kicks in? Technically it's insecure but it was completely circumvented. Also, the reason why this is marked as insecure is hard to debug as the network panel shows nothing for "domain:codecov.io scheme:http".

Did this work before? No 

Chrome version: 59.0.3071.115  Channel: n/a
OS Version: OS X 10.12.6
Flash Version: 

This npm page is not mine, I just stumbled upon it and wondered why it was marked insecure.

Comment 1 by elawrence@chromium.org, Aug 8 2017

Components: Platform>DevTools>Security
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Bug
Summary: Strict-Transport-Security does not suppress Mixed Content, leading to confusing DevTools experience (was: mixed content and strict-transport-security)
The fact that the page is marked as "Not secure" is working as intended. 

Perhaps surprisingly, Strict-Transport-Security checks happen *after* Mixed Content checks, meaning that a page that contains non-secure subresource references will be marked as containing Mixed Content even if no non-secure requests are made (due to STS upgrades).

The Content-Security-Policy token "Upgrade-Insecure-Requests" aims to address this shortcoming; it runs *before* Mixed Content checks and thus non-secure references that upgrade don't get treated as mixed content.

The Network panel *should* should a HTTP/307 upgrade, as in the attached screenshot. Does it not?
InternalRedirect.png
39.6 KB View Download

Comment 2 by potoms....@gmail.com, Aug 8 2017 

I get a 200.
Screen Shot 2017-08-08 at 18.05.37.png
209 KB View Download

Comment 3 by elawrence@chromium.org, Aug 8 2017 

Yeah, you should see both, a HTTP request resulting in a 307 "Internal Redirect" and a 200 from the HTTPS endpoint. 

It's possible that the missing 307 was fixed on a later build.

Comment 4 by potoms....@gmail.com, Aug 8 2017 

Checked in Canary and it works. Should have done that from the start, my apologies. This issue can be closed.

Comment 5 by elawrence@chromium.org, Aug 8 2017

Status: WontFix (was: Unconfirmed)
Thanks for verifying!
►

Sign in to add a comment