New issue
Advanced search Search tips

Issue 700110 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Mar 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Feature
Team-Security-UX



Sign in to add a comment

Make whitelist for local adresses

Reported by ivan...@live.ru, Mar 9 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3031.0 Safari/537.36

Steps to reproduce the problem:
1. Opened any local HTTP address which contains password entry.
2. The browser warns that the page and password entry are not secure.

What is the expected behavior?

What went wrong?
I think need make an exception for the local zones of network. For example, I attached a screenshot of the address belonging to the router. Of course risks of vulnerabilities in this interaction still remain, but I do not think that all manufacturers will update the firmware and certificates in the consumer devices. In most cases the routers do not have the HTTPS login interface, since it does not make much sense.

When the icon will change in the warning (https://security.googleblog.com/2016/09/moving-towards-more-secure-web.html), this can cause a great misconception for novice and inexperienced users who will think that their devices is completely unsafe.

Did this work before? N/A 

Chrome version: 59.0.3031.0  Channel: n/a
OS Version: 10.0
Flash Version:

 
Labels: Needs-Triage-M59

Comment 2 by mmenke@chromium.org, Mar 10 2017

Components: Blink>SecurityFeature Internals>Network>SSL
Labels: -Pri-2 Pri-3
Not sure the correct label for this.  Note that the local network is not always trusted (Think an open wifi network at Starbucks, or an airport), so this is probably desired behavior.
Cc: est...@chromium.org
+estark

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

Cc: emilyschechter@chromium.org
Components: -Internals>Network>SSL -Blink>SecurityFeature UI>Browser>Omnibox>SecurityIndicators
Labels: Hotlist-HttpBad
Status: WontFix (was: Unconfirmed)
Thanks for the report. I don't think we'll change this behavior: as comment 2 pointed out, local network addresses are not trusted. We already have an exception for localhost names (a password field on http://localhost does not get the Not Secure badge). So, I think this is working as intended. Ideally it would be easier for devices on the local network to to set up valid HTTPS connections to avoid this.

Comment 5 by ivan...@live.ru, Mar 10 2017

I agree with these reasons, big thanks for attention.

Sign in to add a comment