RE: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

Newbie alert: I might be about to propose something silly ☺

It seems to me that there are 2 big scenarios that server admins are likely to want:

·         Strict: e.g. I’m a bank, I don’t ever want cleartext anything floating around, so every byte should be HSTS.

·         Opportunistic: I’m a mashup, so I want to make a best effort by having all the bytes from my site be encrypted, but don’t know or control what protocols are going on with sites that are mashed into mine.

So we can easily support these two modes by specifying hsts-strict and hsts-opportunistic (or “local”, or some such that isn’t “strict”).

There may be other, more involved scenarios, but I don’t understand them well enough to specify how they should work. I might also argue that I don’t care very much; if you want some elaborate mix of HTTP and HTTPS, then go fix your code until you get there.

WDYT?

From: Mike West [mailto:mkwst@google.com]
Sent: Tuesday, February 3, 2015 11:46 AM
To: Peter Eckersley
Cc: Anne van Kesteren; Ryan Sleevi; Eduardo' Vela; Wendy Seltzer; Adam Langley; WebAppSec WG
Subject: Re: An HTTP->HTTPS upgrading strawman. (was Re: Upgrade mixed content URLs through HTTP header)

On Tue, Feb 3, 2015 at 7:31 PM, Peter Eckersley <pde@eff.org<mailto:pde@eff.org>> wrote:
Why exclude navigational requests from the rewriting mechanism?  That's
going to force sites to enable HSTS if they want that behaviour, with
the associated problems from other forms of strictness.  Instead
consider a "subresourcesOnly" option for sites that want to stay in HTTP
by default but behave as well as possible if the top-level request is
HTTPS.

1. I excluded navigations from the strawman on my vague assumption that navigations often go to third-party sites for which the first-party can't make the same guarantees as it can for its own content. This might be another argument for the source list discussion at the bottom.

2. It's not clear to me that the HSTS strictness you're trying to avoid is something we actually want developers to avoid. Don't we want to encourage folks to use HSTS?

The report-only mode should have a setting -- perhaps the default --
where the site operator gets reports only about upgrades that fail (TLS
connection error, cert warning, or an HTTP error code).  In a typical
deployment case, there will be an *enormous* number of successful
upgrades and the thing people will want to track most will be the failures.

Hrm. Ok. What is the use case that you think reporting ought to address?

I would like it to be a mechanism by which admistrators/authors can prioritize the small amount of time they want to spend making their sites work in legacy clients. If one resource causes X% of upgrades, maybe it's worth `sed`ing around to fix it.

It sounds like you wish to address a different case, allowing administrators/authors to prioritize the time they spend fixing SSL errors. I'd suggest that this case is better dealt with via something like https://w3c.github.io/navigation-error-logging/. WDYT?

It would be ideal to support a blacklist of origins for which the
upgrade mechanism does not apply.  That way, if you have N third parties
on a site, and (say) two of them provide images only, and don't support
HTTPS at all, you can use the upgrade mechanism for scripts on the other
N - 2 origins.

Blacklists are the opposite of how the rest of CSP works. Turning the directive into a source list could certainly address a whitelist, however, which was also Eduardo's first comment. The currently specified behavior would hide behind `upgrade-insecure-requests *`, and you could get more granular from there.

That makes the inheritance story more difficult to explain, but I'm sure we could work something out.

-mike

--
Mike West <mkwst@google.com<mailto:mkwst@google.com>>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)