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> 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>, @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.)