Trying https first

[Ken Russell]

Hi fellow Chromium developers,

Oculus ships a Chromium-based browser that supports WebXR. It's really neat to be able to browse to web pages in-device and try immersive experiences without installing full-blown applications!

Several sites I've tried offer up their content over both http and https. https is required for the page to use the WebXR API, a powerful web feature. On these sites, typing the URL without a scheme goes to the http version. Then the URL has to be manually edited to change it to "https".

A couple of examples:

playcanv.as/p/VmHVW3Wb/

www.ibiblio.org/e-notes/webxr/mini.htm

(Try copy/pasting the text of these links into Chromium's Omnibox so that they don't include a URL scheme - they use http, even though the servers offer https.)

It would be great if Chromium could try https first, though I'm sure there are pitfalls.

The Oculus Browser engineers recall that this behavior (try https first, fall back to http under circumstances like certificate errors) was proposed at one point but concerns were raised. Does anyone remember the context of that conversation? I couldn't easily find it via email or web searches.

Thanks,

-Ken

[Christopher Thompson]

Are these pages not able to serve 30X redirects to HTTPS? That is generally the recommended practice for pages that need HTTPS (well, all pages). For pages with stronger security requirements there is HSTS.

crbug.com/451295 has most of our historical discussion on how we might try to default Omnibox navigation to HTTPS. crbug.com/542484 covers the work we did to "remember" HTTP->HTTPS redirects and have the Omnibox prefer HTTPS in those cases.

- Chris

--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMYvS2cx3aEBP1AkfzGU8Qg5N40%2BfR6-tigB1xOnRW%2Bj6XsekA%40mail.gmail.com.

[Rik Cabanier]

Hi Chris,

crbug.com/542484 is not viewable. Is it possible to remove the restrictions?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALMy46Q7%2BzJ7TaoEQOpuh0jy6c%3Drz8RFrFQW0j0i_iYq%3DrNHJQ%40mail.gmail.com.

[Christopher Thompson]

Ah apologies, I thought that both bugs were public and didn't double check. I'll see if we can open it up, but in the meantime, here's the summary:

• Previously, the Omnibox was very difficult to retrain so that if a site started supporting HTTPS (or you started using the HTTPS version) after using the HTTP version for a while, it would continue to suggest only the HTTP version.
• Sites can add 301 redirects from HTTP to HTTPS, but this is inefficient (latency of a redirect) and slightly less secure than navigating to the HTTPS version directly.
• We updated the scoring rules for the Omnibox so that if a page redirects HTTP to HTTPS, we don't count the initial HTTP navigation and add the weight for the HTTPS version.
• The practical effect is that users who type a bare domain and get a 301 redirect from HTTP to HTTPS will have the HTTPS version of the URL added as the higher weighted item in the Omnibox suggestions database. Then the next time the user types the bare domain, the top URL suggestion will be the HTTPS page.
• This had substantial effects on reducing latency for typed navigations in the Omnibox.

Hope that helps!

- Chris

[Brad Lassey]

+Dan McArdle

The new HTTPSSVC DNS record may also be an opportunity for origins to signal that they should be loaded over a secure transport.

https://chromestatus.com/feature/5948056459542528 

-Brad

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CALMy46SHcMM-0SMAq%3DuuuDFxUtJHjhLa%3DhxmdkFQRpVRw6JJLw%40mail.gmail.com.

[Ken Russell]

Thanks for the feedback. I'll reach out to the site administrators, pointing to this discussion, and ask them whether they can serve up redirects.

-Ken

[Dan McArdle]

TL;DR: The best way to get https:// by default is to put the domain on the HSTS Preload List. When a domain is on the HSTS Preload List, Chrome will use https:// on the first connection. See https://hstspreload.org/.

If Chrome's policy were to try secure connections first (falling back to insecure connections on failure), it would be vulnerable to downgrade attacks. That is, attackers could keep users on insecure connections by blocking the attempted secure connections. Relying solely on 300 redirects from insecure to secure is similarly vulnerable.

Chrome needs a signal that the domain definitely supports https://, and that we shouldn't bother with http://.  To my knowledge, the HSTS Preload List is the best way to send that signal.

While HTTPSSVC (now known as "HTTPS Records") can send the same signal, it won't reach the same number of users as the HSTS Preload List unless 100% of users are using secure DNS. In the beginning, we will only query for HTTPS records over secure DNS, which limits the number of users that can receive the signal. If we relax the secure DNS requirement, we will again be vulnerable to downgrade attacks; adversaries on the network path can modify cleartext DNS responses and omit the HTTPS records.  +Eric Orth

Hope that helps!

--Dan

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMYvS2fSzghjWefdJNzA4v%2Bu_ByuRtP6qW-inX%3D64f96%3DROXbw%40mail.gmail.com.

[Ken Russell]

Thanks Dan for that input. Some of the sites (ibiblio.org) seem to let their clients decide whether they want HTTPS, but others should certainly submit to the HSTS Preload List.

By the way, both of the sites I asked about this already set up redirects to HTTPS. Thanks for that tip!

-Ken

[Fredrik Hubinette]

From a website owner perspective though, I don't need the security, and the only reason I use https is because chrome says I should.

I don't actually want a way to tell the browser "always use https instead of http", I want to say "an https version of this is available, use it if you want to".

      /Hubbe

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAMYvS2frgewn6oy1zGMRQTq%2BRwVMMxaA-fcoNZreDCY5-BeQBQ%40mail.gmail.com.

[Ken Russell]

Certain powerful web features like WebXR are gated on HTTPS per specification - not just in Chrome.

The web site owners I contacted were happy to add the needed redirects so that this content worked more easily.

-Ken

[Fredrik Hubinette]

Sure, that makes sense - for them.

I don't use any of those features on my website, and since https can be completely blocked in some parts of the world, I still want the http version of my website to work. I don't want to add redirects, and I don't want a "MUST USE HTTPS" switch for my site. However, I would like it very much if people got the https:// version if they typed in the name of my site without a protocol, especially since chrome shows a big "Not Secure" warning otherwise.

In general, I don't see any reason not to try https:// first if the user didn't specify a protocol.

[Fredrik Hubinette]

Or to phrase it more radically: HTTPS is great, but do we have to kill HTTP to get it?

[Christian Biesinger]

Which parts of the world completely block HTTPS?

Christian

> To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAEVbG5oxPZuqsVmnjOTxbsHhY4WG_rF9xQ9D54dA81H29CVNWw%40mail.gmail.com.

[Emily Stark]

We are planning to make the omnibox default to https if the user doesn't type a scheme, and fall back to http if the https request doesn't succeed. This change is currently in the design stage, so it may take a while to be implemented and launched. It has somewhat limited impact for the reasons already discussed in this thread (attackers can cause the request to fail and fall back to http; plus, most navigations to sites that redirect to https will already get rewritten to https via either HSTS or the omnibox scoring changes that Chris mentioned). However, we still think this is a worthwhile change to make -- since Chrome prefers https in the sense that it will show a warning on http, it makes sense to try https for the initial navigation, and is also protective against passive eavesdroppers.

+Shweta Panditrao +Eric Mill 

Emily

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CAPTJ0XFh%3D%2B4bfrYQh7PzDOQS-28BuWLrSXj%2BPQY5ygVwuH-8GA%40mail.gmail.com.