Secure Contexts and Cross-Origin-Embedder-Policy

[annevk]

Related to #4921 by @shhnjk, @mystor pointed out that in addition to computing the origin way before we are ready to create a document, we also need to have the secure context state way before we are ready to have a settings object. This is particularly relevant for Cross-Origin-Embedder-Policy, which can work in a framed context, provided that frame is a secure context.

cc @mikewest

[yutakahirano]

We can check whether the url of the response is trustworthy. We can also check if the environment settings object is (or, will be) contextually secure. Which do you prefer?

Chrome implements the former.

[annevk]

@yutakahirano I suspect we want to emulate the COOP check which checks both the URL and response's HTTP state (in case it's deprecated). (And perhaps we want to abstract it to make it clear they share the same logic.)

[yutakahirano]

Something like this?

• A response response is called trustworthy when
  1. response's URL's scheme is 'https', and response's URL is trustworthy, and response's HTTPS state is 'modern', or
  2. response's URL's scheme is not 'https', and response's URL is trustworthy.
• To obtain a cross-origin opener policy given a response response and an environment reservedEnvironment:
  1. If reservedEnvironment is a non-secure context, then return "unsafe-none".
  2. If response is not trustworthy, then return "unsafe-none".
  3. ...
• To obtain an embedder policy from a response response:
  1. If response is not trustworthy, then return "unsafe-none".
  2. ...

[annevk]

Hmm, I see the dilemma. COEP doesn't always have an environment settings object at hand currently. I would suggest we try to find one though and use that to decide. Basing it solely on the response would seem to miss some cross-window-named targeting scenarios, although maybe they are ruled out and that's unclear due to #313?

[yutakahirano]

The TrustedType bypass problem discussed at w3c/trusted-types#259 is pretty interesting. COEP would have the same problem, and I think it's good to rely only on the response, not the parent contexts.

[annevk]

Could you elaborate?

[yutakahirano]

When a frame asserts COEP: require-corp, it requires COEP and CORP for nested frames. Breaking that expectation when the frame is embedded in an (unencrypted) HTTP frame is confusing I think.

[annevk]

I'm not sure, allowing yourself to be embedded in that way is insecure so I'm not sure we have to cater to it. frame-ancestors can be used to prevent that from happening, though it might be somewhat neater if you could still allow localhost somehow.

[yutakahirano]

Do you mean frame-ancestors: https:? That doesn't work because it is possible for http://malicious/ to embed https://malicious/ which embeds https://victim/.

[yutakahirano]

Ah sorry I misunderstood frame-ancestors. It's checked for every ancestor. https://w3c.github.io/webappsec-csp/#frame-ancestors-navigation-response

[yutakahirano]

Hmm, I see the dilemma. COEP doesn't always have an environment settings object at hand currently. I would suggest we try to find one though and use that to decide. Basing it solely on the response would seem to miss some cross-window-named targeting scenarios, although maybe they are ruled out and that's unclear due to #313?

Can we use request's reserved client? We don't have it for service workers but it is not a problem.

[annevk]

I think we have to use that for top-level. For nested we can just look at the parent.

[yutakahirano]

Currently https://html.spec.whatwg.org/multipage/webappapis.html#secure-context doesn't check if parent is a secure context for documents, and giving the parent environment just checks one-level. We want to check it recursively, right?

[annevk]

No, that algorithm is fine. No need for recursion. The problem is that a reserved client won't have an HTTPS state so you'd have to check that manually. That's why a "full" environment settings object is preferable.

[yutakahirano]

Let's assume we have nested documents D1, D2 and D3. D1 is the parent of D2, D2 is the parent of D3. All have COEP: require-corp HTTP header.

D1: http://www.example.com/D1
D2: https://www.example.com/D2
D3: https://www.example.com/D3

D1 is not a secure context, so the COEP value is unsafe-none.
D2 is got from secure transport but its parent is not a secure context so the COEP value is unsafe-none, but D2 itself is a secure context.
D3 is got from secure transport and its parent is secure context so the COEP value is require-corp, and D3 itself is a secure context.

Is this behavior expected?

[annevk]

How would D2 end up being a secure context? (Note how it uses "top-level creation URL".)

[yutakahirano]

Oh thanks you're right, but we still can create a similar example I think.

D1: https://www.example.com/D1 (HTTPS state is "deprecated")
D2: https://www.example.com/D2 (HTTPS state is "modern")
D3: https://www.example.com/D3 (HTTPS state is "modern")

[annevk]

That seems like something we overlooked in #5659, indeed.

There's a deeper issue with HTTPS state though in that an embedded document could have it set to "deprecated", but the top-level document would still be considered a secure context. Perhaps that's not something that should impact secure contexts to begin with. Only Chrome implements it so it's not even clear if it carries its weight standards-wise.

[yutakahirano]

IIUC your intention is to enable COEP settings only for environments that will be secure contexts, right?

Then I think giving the parent context is confusing because parent's URL and parent's HTTPS state is not taken into account for document's secure context calculation.

Does it make sense to split https://html.spec.whatwg.org/multipage/webappapis.html#secure-context to two algorithms, one[A] takes an environment settings object, another[B] takes an environment and a response?

I'm considering migrating existing callers to [A] by default, and migrating the COOP use-case to [B]. COEP will use [B] for documents. It may make sense for COEP to use [A] for dedicated workers.

[annevk]

I guess it really depends on whether Chrome wants to keep around HTTPS state for secure contexts as it can lead to cases where the document tree is not consistent secure-context-wise.

[yutakahirano]

@domenic @mikewest Do you have opinions? I don't know who has strong opinions on this topic...

[domenic]

I don't have an opinion, sorry to say; I just carried over HTTPS state from previous revisions of the secure context definition. I've also not had any success in getting @mikewest's help with secure context stuff. Maybe we should put a meeting on his calendar.

[zcorpan]

If/when this is fixed, html/cross-origin-embedder-policy/shared-workers.html introduced in web-platform-tests/wpt#20899 should be renamed to shared-workers.https.html

[annevk]

This has been fixed as HTTPS state is gone so secure contexts is now based purely on the URL.