W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2015

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

From: Jacob Hoffman-Andrews <jsha@eff.org>
Date: Wed, 04 Feb 2015 11:20:00 -0800
Message-ID: <54D270E0.3080001@eff.org>
To: Mike West <mkwst@google.com>, Eric Mill <eric@konklone.com>
CC: Tom Ritter <tom@ritter.vg>, Peter Eckersley <pde@eff.org>, "public-webappsec@w3.org" <public-webappsec@w3.org>, technologists@eff.org

On 02/04/2015 12:10 AM, Mike West wrote:
> On Wed, Feb 4, 2015 at 8:42 AM, Eric Mill <eric@konklone.com
> <mailto: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.
FWIW, this is exactly how we detected mixed content at Twitter, and it
worked great. I wrote this up on Stack Overflow ages ago, but I've been
meaning to write a proper blog post about it:
http://stackoverflow.com/questions/4129496/detect-broken-lock-icon-mixed-secure-insecure-content-from-javascript.

What we did in practice: The CSP header for mixed content detection was
sent only on HTTPS requests and only to 1% of live users, to avoid
flooding the endpoint. Also, the same header was set in enforce mode for
100% of employee accounts, so engineers who introduced mixed content
would see it right away (this was before mixed content blocking, though
it continued to be useful for mixed passive content).
Received on Wednesday, 4 February 2015 19:20:33 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 14:54:10 UTC