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

On Tue, Feb 03, 2015 at 03:16:19PM +0100, Mike West wrote:
> I put together a tiny strawman to explore how this upgrade mechanism might
> work: https://w3c.github.io/webappsec/specs/upgrade/ I think it has some
> real potential as a CSP directive, especially in combination with the
> pinning draft which is up for review.
> 
> WDYT?

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.

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.

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.

> 
> (Forking the thread, as this diverges a bit from Anne's original intent,
> and I don't want to derail that conversation entirely.)
> 
> --
> 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.)
> 
> On Tue, Feb 3, 2015 at 12:04 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 
> > On Tue, Feb 3, 2015 at 11:53 AM, Mike West <mkwst@google.com> wrote:
> > > My worry is that we're papering over the problem for newer clients,
> > thereby
> > > removing incentive to fix the problem for existing clients.
> >
> > I don't really see this as a big deal. Compatibility with existing
> > clients is not interesting long term. (If it was we would not have had
> > the Host header, we would not have had SNI, etc.)
> >
> >
> > > While I agree
> > > with Peter's earlier assertion that we shouldn't hold up progress, I
> > think
> > > this is a concern we'd need to address in order to ensure that sites and
> > > applications remain as accessible as possible.
> > >
> > > Ensuring that CSP-Report-Only works correctly is important, for example.
> >
> > I'm not really convinced. Why would there be a report if the content
> > is augmented in such a way that ensures successful fetches? The only
> > reason would be legacy clients (which fade away). Perhaps during the
> > transition user agents could issue a warning of sorts.
> >
> > Say we make this upgrade-downgrade part of CSP. That means Fetch has
> > another CSP hook (somewhere as first step) to "upgrade downgrade
> > URLs". CSP could use that opportunity to return an upgraded URL and
> > issue a warning (or store the warning to be reported later at some
> > synchronization point).
> >
> >
> > --
> > https://annevankesteren.nl/
> >

-- 
Peter Eckersley                            pde@eff.org
Technology Projects Director      Tel  +1 415 436 9333 x131
Electronic Frontier Foundation    Fax  +1 415 436 9993

Received on Tuesday, 3 February 2015 18:32:25 UTC