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

Re: "Mixed Content" draft up for review.

From: Mike West <mkwst@google.com>
Date: Mon, 2 Jun 2014 15:30:28 +0200
Message-ID: <CAKXHy=fUuxKfMuzgVf7WVTb-HfVUCVQwnQFs3f2mg8L6v57-4Q@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: "public-webappsec@w3.org" <public-webappsec@w3.org>, Tanvi Vyas <tanvi@mozilla.com>, Brad Hill <bhill@paypal.com>, Dan Veditz <dveditz@mozilla.com>, Ryan Sleevi <rsleevi@chromium.org>, palmer@chromium.org
On Mon, Jun 2, 2014 at 2:55 PM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Mon, Jun 2, 2014 at 2:35 PM, Mike West <mkwst@google.com> wrote:
> > On Mon, Jun 2, 2014 at 12:32 PM, Anne van Kesteren <annevk@annevk.nl>
> wrote:
> >> You want to talk about something broader than document in the
> >> introduction and maybe elsewhere. In particular service workers can
> >> run without an associated document. If a service workers runs over TLS
> >> (and there might be no alternative) it should not be able to get to
> >> non-TLS resources.
> >
> > That makes sense. Does "execution context" capture "Document or Global
> > Scope"? Or is there some term that's more applicable?
> HTML uses "JavaScript global environment" and then has "document
> environment", "dedicated worker environment", "shared worker
> environment", and "worker environment" (former two combined) as
> classifications.

Thanks, I'll run with that.



> Right, so if the environment is non-TLS, the blob is not secure.

Right. But it also wouldn't load due to origin restrictions.

> > Chrome certain allows HTTPS pages to load 'data:' URLs at the moment. I
> > think there's been some discussion around whether or not we need to do
> some
> > sort of taint checking before doing so (similar to Canvas). I'm hoping to
> > avoid that entirely by simply blocking the mechanisms currently available
> > for grabbing insecure data (XHR, EventSource, WebSockets, etc).
> I see what you mean. But that means blob/data inherit the security.
> They are not secure by themselves. E.g. if I navigate to a data URL,
> that does not mean the environment it creates is secure.

Indeed. Navigating to a 'data:' (or 'blob:') URL would not be
"TLS-protected", and wouldn't create a "secure context" as currently
defined in the spec. We wouldn't do mixed content checking on resources
loaded from those URLs (unless they are nested in a secure context, in
which case we would, because they are secure by transitivity).

> > I disagree. Links don't have a mechanism for soliciting information from
> the
> > user that the page doesn't already know, nor do they generally (assuming
> > sanity...) contain capability-bearing nonces.
> http://www.w3.org/TR/capability-urls/ (very bad without TLS though)

I'd prefer to imagine that those don't exist.

I'd also prefer to treat navigations as mixed content, but I think it would
break the web. Scoping the breakage to forms seems more reasonable. :)

> > That said, I don't think we need to traverse the entire chain if each
> > resource load checks its parent. The child frames should then be
> > transitively secure.
> True, and the same goes for only checking top. However, the current
> algorithm does not do that. It returns as soon it verifies the current
> document.

I think we need both. Consider http://a.com -> https://b.com -> data: ->

Before loading c, we check the parent, which is a secure context because of
b.com. If we only checked a.com, we'd allow c.com to load. I don't think we
want that.

Received on Monday, 2 June 2014 13:31:16 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:38 UTC