New issue
Advanced search Search tips

Issue 777153 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 451295
Owner:
Closed: Oct 2017
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Feature



Sign in to add a comment

Default to HTTPS for uncached domains entered in the address bar.

Reported by skuldw...@gmail.com, Oct 22 2017

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.62 Safari/537.36

Steps to reproduce the problem:
This is a feature request!

What is the expected behavior?
The user enters a url or domain in the address bar and the browser tries it as https first.

If it fails it should ask the user what to do, load the page anyway (un-securely) or abort loading the page.

This feature should be introduced in stages, initially default to off but let users enable "Try HTTPS first if protocol not specified". Later releases should default to enabled but allow the user to turn the feature off.

What went wrong?
Currently the browser tries the request as http. Unless the domain happens to be in the HSTS preload list a MITM attack could provide a fake site to the browser and user.

Did this work before? N/A 

Chrome version: 62.0.3202.62  Channel: stable
OS Version: 10.0
Flash Version: 

Started out as a discussion in the comments on https://www.troyhunt.com/the-6-step-happy-path-to-https

The HSTS preload list can not continue to grow indefinitely to hold all sites in the world. Ideally a HSTS DNS record should be provided via DNSSEC which would make this feature request obsolete, but that is unlikely to happen anytime soon.
 
Cc: ojan@chromium.org
Components: UI>Browser>Omnibox
Labels: -Type-Bug-Security -Restrict-View-SecurityTeam Type-Feature
Status: Untriaged (was: Unconfirmed)
The best bug that captures this is Issue 451295, specifically comment 18. Other relevant bugs include  Issue 396087  and Issue 542484.
Components: UI>Browser>Navigation
Owner: est...@chromium.org
Status: Assigned (was: Untriaged)
Assigning to estark for triage. Is this something you've considered for https adoption?

Comment 3 by est...@chromium.org, Oct 23 2017

Mergedinto: 451295
Status: Duplicate (was: Assigned)
Yes, I think this falls in to issue 451295. There are lots of ideas floating around for how the omnibox can guide users to https instead of http, but some challenges to work out (mostly in the realm of usability and performance). Stay tuned!

Sign in to add a comment