Re: Pitch to prefer secure origins in Chrome

[Ryan Sleevi]

+security-dev

On Fri, Jul 22, 2016 at 10:03 AM, Josh Karlin <jka...@chromium.org> wrote:

Hi all, I'd appreciate any early feedback that you have on this proposal for Chrome to prefer secure origins over insecure. 

Thanks!

Josh

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To post to this group, send email to net...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/CAANMuaOB%2Bc5wsuCD1spDD%2BH75-e2smiPBxB4wvMNtvYdC2Yi2g%40mail.gmail.com.

[Lucas Garron]

While the goal of making secure users is good, and trying to increase the amount of visits to secure origins is a good idea, I strongly caution against the propose solution in its current form. From what I can tell, the proposal is basically to introduce a softer level of HSTS and preload a list of sites with this soft HSTS setting.

I see a few major problems with this proposal as-is:

1. The HSTS preload list may soon run into serious scaling problems. Regardless of whether this proposal would integrate with the existing preload list (not that hard) or try to introduce a new mechanism (:-/), this could compound the problem of shipping a fast-growing list of sites with chrome.

Now, for HSTS, preloading is necessary to prevent MitM attacks in fresh profiles, with a hard fail. But in this proposal, the goal just seems to be to improve the amount of time spent on HTTPS. I think this is a less justifiable use of bytes in the Chromium binary.

2. By preloading similar to HSTS, this proposal opts for a centralized approach. I think we should avoid centralized approaches wherever possible.

3. There proposal has no stats to show how much this would increase time/navigations on HTTPS. Anecdotally, the biggest hurdle for sites is to get HTTPS working on the first place – once HTTPS is working, they often move quickly to implement secure redirects and HSTS. At that point, this proposal becomes redundant for those sites.

4. You may be opting sites into HTTPS when they are not ready yet. Even if a site appears ready, you can break functionality that is visible only in certain circumstances or to certain users. This can be obvious and frustrating to those users, or it could be subtle and even more frustrating. The most reliable way to tell if a site is ready is if they already redirect to HTTPS and/or use HSTS, in which case the proposed mechanism is redundant.

If a user is willing to risk some breakage for more proactive security, they can already use the HTTPS Everywhere extension (on desktop).

The motivation section also starts off with some things that I don't think are directly relevant. The core of the motivation seems to be "we should connect users over HTTPS as much as we can", even if it's just opportunistic.

However, I think that that browser should not upgrade to HTTPS without consent from either the site or the user. Safer approaches are:

• double down on driving HSTS adoption for sites that users visit a lot (e.g. the Rey 200 as part of MOAR TLS), and
• focus on some of the omnibox suggestions under "Related Work" (e.g. Issue 451295, make it easier to input/default to HTTPS, and/or race HTTPS against HTTP).
  

It may be the case that a handful of important sites would be interested in/okay with a soft upgrade mechanism but not full HSTS. However:

• I think we should not introduce a softer level of HSTS unless we understand why it's not sufficient to drive them towards normal HSTS. (Dynamic HSTS is already pretty flexible, if they need to do a staged rollout.)
  
• This would add yet another confusing step on the road to HTTPS adoption.
• The non-strict philosophy in this proposal sounds similar to opportunistic TLS. I believe we declined to implement that because it doesn't provide the full security you should expect from TLS, and we were concerned that site operators would consider it "good enough" even though it still leaves users at risk.

However, I'm glad you're thinking about this. And once we get to a place where the web is ready for HTTPS by default (which seems like it may very well happen, but not very soon), I think we will need to think about a soft upgrade mechanism.

Happy to talk more about it,

»Lucas