This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 27190 - Add HTTPS state to environment settings objects
Summary: Add HTTPS state to environment settings objects
Status: RESOLVED MOVED
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: https://html.spec.whatwg.org/#environ...
Whiteboard:
Keywords:
Depends on:
Blocks: 27302 27147
  Show dependency treegraph
 
Reported: 2014-10-29 12:38 UTC by contributor
Modified: 2015-09-26 09:47 UTC (History)
5 users (show)

See Also:


Attachments

Description contributor 2014-10-29 12:38:33 UTC
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
Comment 1 Anne 2014-10-30 12:32:27 UTC
We ended up with TLS state as name. This is hopefully less confusing given HTTP authentication.
Comment 2 Mike West 2014-11-20 13:27:43 UTC
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.
Comment 3 Ian 'Hixie' Hickson 2014-11-20 20:57:39 UTC
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?
Comment 4 Anne 2014-11-21 07:08:49 UTC
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.
Comment 5 Ian 'Hixie' Hickson 2014-11-21 23:53:37 UTC
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.
Comment 6 Mike West 2014-11-22 05:47:49 UTC
> 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/.
Comment 7 Anne 2014-11-22 08:59:57 UTC
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 :-(
Comment 8 Mike West 2014-11-22 09:33:06 UTC
(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.
Comment 9 Ian 'Hixie' Hickson 2014-11-24 18:49:51 UTC
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.
Comment 10 Mike West 2014-11-24 19:09:59 UTC
(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?
Comment 11 Ian 'Hixie' Hickson 2014-11-25 07:08:57 UTC
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.
Comment 12 Anne 2014-11-25 10:55:32 UTC
Henri, any ideas how to address comment 11?
Comment 13 Mike West 2015-09-22 13:22:25 UTC
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.