W3C home > Mailing lists > Public > public-webappsec@w3.org > November 2014

Re: [MIX] HTTPS -> non-HTTPS redirects

From: Mike West <mkwst@google.com>
Date: Tue, 25 Nov 2014 09:02:32 +0100
Message-ID: <CAKXHy=ey4UAaYaZN5G0L9jDqzf86h9QiF40UN0a=AwfUK=PQgw@mail.gmail.com>
To: Brian Smith <brian@briansmith.org>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>
On Tue, Nov 25, 2014 at 2:28 AM, Brian Smith <brian@briansmith.org> wrote:

> Hi,
>
> In another thread [1], I suggested that all mixed content in iframes
> should be blocked by default, and after receiving some encouragement,
> I offered to propose some text for that. As a refresher, the goal is
> to give some assurance to a page that, even when it frames third-party
> content, there's no way that framed third-party content can cause the
> mixed content indicator for the framing page to "go bad."
>

The feature I thought I was agreeing with was something like an opt-in for
that state; e.g. <iframe mixedcontent="block-without-reporting"> or
whatever made sense. While that makes sense for folks like W3C or NYT who
are working on large migrations, I don't think that's a good default state,
as it makes it less likely that folks will fix mixed content issues during
development of new features.


> This got me thinking about other ways that a page that tries to do the
> right thing could get burned in a similar manner. In particular,
> consider redirects:
>
>      <img src='https://ads.example.com/CREAM.jpg'>
>
> Looks good, right? But, what if https://ads.example.com/CREAM.jpg
> redirects to http://ads.example.com/CREAM.jpg? Then the browser's
> mixed content indicator will go bad, just like the iframe case, even
> though the page is trying to do the right thing. That's not good. This
> makes me think that HTTPS -> non-HTTPS redirects for
> otherwise-optionally-blockable fetches should be blocked.
>

Two things:

1. I think it's perfectly reasonable to add some toggle that allows sites
to opt-into stricter mixed content checking that would treat all
optionally-blockable content as blockable.

2. We already have that toggle, to an extent: `img-src https:` would block
(and report!) this right now, so it's not clear that there's any advantage
in specifying something new.

--
Mike West <mkwst@google.com>
Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91

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.)
Received on Tuesday, 25 November 2014 08:03:20 UTC

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