Re: [MIX] 4 possible solutions to the problem of Mixed Content Blocking stalling HTTPS deployment

On Wed, Feb 4, 2015 at 8:42 AM, Eric Mill <eric@konklone.com> wrote:
>
> This means that CSP would need to be delivered over HTTP, and not by Let's
> Encrypt (unless LE had a mode explicitly meant for sites to triage HTTPS
> work).
>

This is something that can certainly be done now. That is, sending
`Content-Security-Policy-Report-Only: default-src https:; report-uri
/reporting/endpoint` will flood you with the insecure requests your site is
making, regardless of whether the site itself is delivered over HTTP/HTTPS.
CSP checks happen before mixed content checks for exactly this use case.


>
> > 3. Add a new directive to the HSTS header, which sites (and the Let's
>> > Encrypt agent working on behalf of sites) can set.  It could be called
>> > the "easy" or "helpful" bit.  In slogan form, the semantics of this
>> > would be "if you're a modern client that knows how to do Helpful HSTS,
>> > this site should be entirely HTTPS; if you're an old client that has
>> > MCB/HSTS but doesn't know about Helpful HSTS, leave the site on HTTP".
>>
>
> This is helpful, but is also quite a long game -- while it may get more
> traffic encrypted in the short term, it doesn't contribute to helping
> browsers deprecate HTTP until Helpful-HSTS-enabled clients are
> overwhelmingly in use. And during all that time, there's little pressure on
> site owners to move their site fully over to HTTPS.
>

Just to join threads (as I didn't CC the eff.org list directly, sorry!),
I've put up a CSP-based strawman proposal for this at
https://w3c.github.io/webappsec/specs/upgrade/. There's a bit of discussion
at https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0037.html.

I do worry that it reduces the incentive for authors to fully move to
HTTPS. I think that worry is outweighed by the fact that it would allow
some subset of sites to migrate significantly sooner than they'd otherwise
manage.

Deprecating HTTP, a la
http://www.chromium.org/Home/chromium-security/marking-http-as-non-secure,
is something that folks can (and will) be working on in parallel to
whatever we end up with here. If anything, this kind of upgrade mechanism
would enable us to move faster on that front by removing one barrier to
entry.

I wonder if the simpler solution here is to push the HSTS preload list even
> harder, and to give inclusion in that list the added benefit that you don't
> need to go around fixing mixed content warnings, because the browser is
> willing to glance at the preload list first before making a MCB
> determination.
>

Daniel's suggestion at
https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0051.html
seems on point here for blockable mixed content. It's something I think
user agents can and should experiment with.

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