RTCCertificate security boundary

[annevk]

In whatwg/html#4939 I've been exploring infrastructure for objects which we'd like to limit to the same-origin. The only real security boundary we have for objects is agents and their container, agent clusters, and they are per site+scheme (so contain multiple origins).

That is, while we could make deserializing X fail on B if serializing X happened on A, we cannot necessarily prevent A from sharing X with B, if A and B are same-site and same-scheme.

This means, that if step 4.2 of https://w3c.github.io/webrtc-pc/#constructor is crucial for some reason not related to the ability for B to "read" X, we cannot really simplify RTCCertificate much. [Serializable=SameOrigin] might still be good to signal intent, but it would not allow removing [[Origin]] as A can still share X with B using document.domain.

(I should note that in general it's a little weird for objects to carry around an origin as messaging is supposed to be about object capabilities, but I think I can see how for a certificate that might be different.)

cc @jan-ivar

[steely-glint]

I'm not sure I understand the broader context, but the thing with RTCCertificate is that it is opaque to the javascript - it can be created, stored (in indexdb) and used (by PeerConnection) - but it can't be inspected ,written, edited or (I think) sent as a message.

[annevk]

"Read" was mostly referring to Spectre.

I basically have two questions:

1. What's the design goal behind [[Origin]]?
2. Would it be preferable if when messaging RTCCertificate to another origin, that other origin got a messageerror event rather than a message event? (More clearly indicating it's inability to be useful there and consistent with how we do that when an object isn't available in some environment, for instance.)

[steely-glint]

For full certainty, you should probably ask @martinthomson - but my understanding is that the origin is used to provide what you might think of as a weak PKI - i.e. RTCertificates can only be generated within a single origin - which ties them back to a given https certificate. They can only be used within the same origin. So a webRTC peer receiving a P2P call with a certificate it has seen before can be reasonably certain that the peer's origin is the same as it was the previous times. If you add this to the fact that the RTCertificate isn't movable, then the peer also knows that this is from the same user agent as before. - These properties are useful in constructing an identity system.

In my view it is wrong to attempt to send an RTCCertificate to a different origin, so the error should be on the send side.

[annevk]

The sending side doesn't necessarily know where it'll end up, so that doesn't work.

[martinthomson]

For 1., the goal is to make the object serializable for the purposes of passivation, but not for reuse by other origins. This matches what you surmised already.

Passing the certificate is harmless and could be useful for informational purposes if the intent was to access the DER (or a fingerprint, which is an actual method that we currently support). It's use of the certificate for authentication that is problematic in the sense that we aren't comfortable with the idea of the same credential being used across origins. I'm not aware of a concrete security issue that cross-origin use of this credential might create, but caution suggests that we apply the constraint.

So for 2., whether the constraint manifests as failure during messaging or failure when an origin attempts to use the object isn't that important in this case. The informational uses for passing RTCCertificate can be achieved by accessing the necessary functions and passing the resulting data.

In conclusion, I don't see why we couldn't replace the check in SS4.4.1.1s4.2 with a reliance on the proposed mechanism. We still need the expiration check though.

[annevk]

@martinthomson is it problematic if someone were to access the underlying certificate data through Spectre? This would require someone accidentally sharing the object with a rogue origin, but postMessage() is a rather poor API, so who knows.

[martinthomson]

My bad, I had the wrong hat on. 'll try again.

There are two piece of information here that we might care about: the certificate and a private key. The certificate is harmless (in fact, it's intended to be public), so we don't really care about that leaking out any more than we care about arbitrary data on sites - it's bad, but it's not a particularly valuable secret.

The private key is what we might want to concern ourselves with. The requirement is that the private key is only usable by the origin that minted it. The value should be protected from reading, from ALL web content, including that origin.

In practice, the object in question likely only holds a handle to the secret. Furthermore, the value is generally only used in cryptographic functions that are generally implemented with special attention paid to the potential for side-channels. Those operations might occur in other processes.

@nils-ohlmeier might be able to say how gecko is currently managing WebRTC connections, but I understand that there are plans to move connection establishment out of the content process, which would make these private keys safe from Spectres, Ghosts, Banshees, and the other creatures that haunt the web. Other engines might need to consider this also.

[nils-ohlmeier]

Yes Firefox Nightly does connection establishment and all it's crypto operations outside of the content process. We want to roll this out to release, but exact dates are still TBD.
Last time I spoke to other browser engines about this it sounded to me like were not following this approach. But that information might be outdated.

[annevk]

Okay, so there's two takeaways here:

1. Adding Serializable=SameOrigin to RTCCertificate is worth exploring, but it won't replace the need for the [[Origin]]`` internal slot as document.domain` would allow cross-origin sharing otherwise, which is problematic.
2. The specification should probably note that private keys need to be isolated from the processes that have access to RTCCertificate objects.