This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Specification: https://html.spec.whatwg.org/multipage/webappapis.html Multipage: https://html.spec.whatwg.org/multipage/#environment-settings-object Complete: https://html.spec.whatwg.org/#environment-settings-object Referrer: https://html.spec.whatwg.org/multipage/workers.html Comment: Add authentication state to environment settings objects. This is needed for Fetch and Mixed Content. You can derive it from https://fetch.spec.whatwg.org/#concept-response which you will get hold of when creating an environment. Posted from: 46.127.136.57 by annevk@annevk.nl User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:36.0) Gecko/20100101 Firefox/36.0
We ended up with TLS state as name. This is hopefully less confusing given HTTP authentication.
In discussion with Anne, the following came up: In order to define behavior for mixed content and "powerful features", we need a mechanism by which we can check the ancestor chain of arbitrary Documents and Workers to verify certain properties. Anne suggested doing so via the incumbent settings object. We apparently can do that just fine for Documents, but the link between Workers and Documents has been broken. Can we have that link back please? Anne will probably have opinions about this; I'm willing to do whatever you two decide is the right way to represent this sort of thing.
Mike: Is comment 2 related to comment 0? It seems orthogonal. I suggest filing a new bug for that. Anne: How do I determine the TLS state? e.g. suppose you open a new page on about:blank. What's the TLS state? How about window.open()? Does it inherit the TLS state from the opener somehow? Does the TLS state ever change? What about if the page becomes mixed-content?
Ian, Mike was raising that point because we want to use something like "TLS state" to implement the checks for features such as EME, Web Crypto, and that requires a complete ancestor chain to participate. So either we propagate an additional bit ourselves ("ancestors TLS state"?), or we expose the ancestor chain again... TLS state comes from a response initially and then it should be propagated. Fetch already propagates it for fetches to about, blob, and data URLs. If window.open() starts out as about:blank it should be covered.
EME shouldn't exist, so that's not a use case. Can you elaborate on hte Web Crypto use case? What are they trying to determine? What's the "ancestor chain", exactly? e.g. in a shared worker? or a nested dedicated worker? window.open() and a new tab don't involve any fetch.
> Can you elaborate on hte Web Crypto use case? What > are they trying to determine? What's the "ancestor > chain", exactly? e.g. in a shared worker? or a > nested dedicated worker? Web Crypto is restricted to secure contexts (in Chrome) because of some of it's properties. Folks who don't want to deploy TLS work around this restriction by framing an HTTPS page, and building a postMessage-based API to call into the HTTPS page and pull data out (Netflix in particular has built more or less a 1:1 API wrapper). When defining the restrictions placed upon such APIs, we'd like to ensure that such scenarios are disallowed. That is, API X should be available on https://example.com/ (and same-origin workers). API X should not be available on https://example.com/ if it's framed by http://insecure.com/.
Replace EME with service workers then. https://wiki.whatwg.org/wiki/TLS has more examples of features we'd like to restrict over time. To find out whether a feature is allowed to use TLS. We'd like to look at a document and its ancestors to see whether they all have the correct TLS state. Insecure embedding a secure environment that uses the feature should not work. For dedicated workers this means looking at the associated document and its ancestors. For shared workers this seems a bit trickier. I'm not sure how to guarantee this for shared workers since that could change over time :-(
(In reply to Anne from comment #7) > For dedicated workers this means looking at the associated document and its > ancestors. For shared workers this seems a bit trickier. I'm not sure how to > guarantee this for shared workers since that could change over time :-( For shared/service workers, it's probably enough to ensure that the worker script itself comes from a secure origin, and that the worker is registered in a secure context. I suppose if we wanted to, we could restrict messages to documents that are secure contexts? But that seems overly draconian.
How would you catch e.g. a non-TLS page talking to a TLS iframe talking to a shared worker talking to a top-level browsing context, or some such similar ridiculous chain of communication, where one end is "TLS approved" and the other end is not? I don't understand how we can ever stop this completely, and if people are willing to work around this with iframes, I don't see why they wouldn't walk around it with more complicated mechanisms.
(In reply to Ian 'Hixie' Hickson from comment #9) > How would you catch e.g. a non-TLS page talking to a TLS iframe talking to a > shared worker talking to a top-level browsing context, or some such similar > ridiculous chain of communication, where one end is "TLS approved" and the > other end is not? I don't understand how we can ever stop this completely, > and if people are willing to work around this with iframes, I don't see why > they wouldn't walk around it with more complicated mechanisms. I'm sure we can come up with strange examples of bypass mechanisms. As long as the bypass is sufficiently obscure and user-visible (your example requires two distinct top-level browsing contexts and a shared worker, for instance), I think they're worth pursuing. Mitigating abuse within the context of a single window seems imminently doable, however. Do you disagree with the merits of doing so?
Well I would have said that talking to a cross-origin iframe to bypass a TLS restriction was already sufficiently obscure, personally. How would we prevent this from working with a shared worker contacted via a hidden iframe? That's not user-visible. I don't really see much point in us trying to put barriers in the way of authors if the barriers can't be complete. It just makes authors think we're trying to be their nanny. If we do this, I need a clear definition of what we want to do, because I have no way personally of determining what is a reasonable design.
Henri, any ideas how to address comment 11?
I think we've hammered out compromises on the various kinds of chaining that we care to block, and the kinds of leakage that we're not planning to lock down at the moment. These compromises are captured in the examples at the top of https://w3c.github.io/webappsec/specs/powerfulfeatures/, and in https://w3c.github.io/webappsec/specs/powerfulfeatures/#isolation. The thing that's still missing is some indication on a settings object that it was generated from a Response with a particular "HTTPS State". I think we need something like that if we wish to be able to distinguish between "modern" and "deprecated" encryption. I suppose we could also just check the URL's scheme if we don't care about that. I'd like to care about it, I suppose.
https://github.com/whatwg/html/pull/178