New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 731615 link

Starred by 3 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Jan 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug


Show other hotlists

Hotlists containing this issue:
EnamelAndFriendsFixIt


Sign in to add a comment

Mixed content marked as secure when restored from session

Project Member Reported by ha...@opera.com, Jun 9 2017

Issue description

Chrome Version: 61.0.3119.0 
OS: Win7

This is the same issue reported in 348952 but can be reproduced in Canary 61.0.3119.0 

Steps to reproduce the problem:
1. In preferences set "Continue where I left off" on startup
2. Load https://people.opera.com/joleksy/https_insecure_data_content.html
3. Use the shield icon to Load Unsafe Script
4. The content in the frame should update itself, page security is downgraded
5. Exit the browser
6. Open Chrome, the same page is loaded, but marked as secure

What is the expected result?
When unsafe content was loaded, the page security was reduced to insecure, the same status should be shown when page is loaded from session. 

What happens instead?
Page is marked secure.

 

Comment 1 by palmer@chromium.org, Jun 12 2017

Cc: -palmer@chromium.org lgar...@chromium.org elawrence@chromium.org est...@chromium.org
Labels: Team-Security-UX
Possibly/probably not Windows-specific.
Components: UI>Browser>Omnibox>SecurityIndicators
Oddly, I couldn't get this to reproduce on 61.3125 or 61.3128 (unblocking the non-secure frame results in the network request, but the loading spinner just spins endlessly at "Processing request...". I did get to repro on ToT and in 58.3029.

The expected content of that frame contains a script that navigates to a Data URI. If the "Continue where I left off feature" serializes that data URI rather than the original HTTP URI, then it seems understandable how we could make this mistake, because data URIs are not inherently secure or non-secure, but instead determine that bit based on their context. 

This comment in the original bug looks a bit suspicious: https://bugs.chromium.org/p/chromium/issues/detail?id=348952#c20
58Repro.png
16.6 KB View Download

Comment 3 by kinuko@chromium.org, Jun 13 2017

Components: UI>Browser>Sessions
Owner: creis@chromium.org
Status: Assigned (was: Untriaged)
Tentatively assigning creis@, who seems to have made the related changes in the original bug context:

https://chromium.googlesource.com/chromium/src/+/1909e832326794bd74265f93d32407aeeb131253

creis- would you be able to help triage this one?

Comment 4 by est...@chromium.org, Nov 10 2017

Labels: Hotlist-EnamelAndFriendsFixIt

Comment 5 by est...@chromium.org, Nov 10 2017

Cc: creis@chromium.org
Labels: Needs-Feedback
Owner: ----
Status: Unconfirmed (was: Assigned)
Hmm, looks like this slipped through our triage process, sorry about that. The proof of concept no longer loads and my naive attempts to reproduce this with https://mixed-script.badssl.com didn't work. We'll need an updated proof-of-concept to investigate.
harig@opera.com, could you update your repro steps?
Status: WontFix (was: Unconfirmed)
Closing due to lack of feedback, but happy to reopen if we can get a repro.

Sign in to add a comment