WebCrypto currently is restricted to pages delivered over HTTPS; however, they do not do ancestral checks, resulting in the ability to have an HTTP page iframe an HTTPS webcrypto page.
This is different than other features, which are restricted according to https://w3c.github.io/webappsec-secure-contexts/ (as explained on https://sites.google.com/a/chromium.org/dev/Home/chromium-security/deprecating-powerful-features-on-insecure-origins )
There are two possible ways to think about this:
- The current behaviour is 'secure', because the embedding HTTP page cannot interfere with the iframe'd HTTPS page except through postMessage, which the iframe'd page can then do source-origin checks on messages and simply treat as 'untrusted content'. This is conceptually similar to a secure/trusted process (e.g. a browser process, a system process) communicating with an insecure/untrusted process (e.g. a renderer process, a user application)
- The current behaviour is 'complex', because it is the one exception to the Secure Contexts specification. Developers who develop WebCrypto apps will expect the Web Platform to behave one way (e.g. allowing HTTP-framing-HTTPS), but will find all the other APIs (geolocation, gUM, etc) do not.
At fundamental question is whether WebCrypto represents a 'powerful feature'. Because a number of objectionable parts were removed from the specification (such as persistent key storage), it may not itself represent an intrinsic privileged primitive over the base Web platform. Alternatively, because it is inherently a security feature, it could be argued that there is a duty to preserve users' expectations regarding security as best we can, and that would involve avoiding footguns.
Given that it came up in discussion this week ("What are we doing about WebCrypto?"), I'm filing this bug so that we can have a clear resource/response to users.
We're at an early enough time in WebCrypto's deployment that the next steps would be to quantify how many applications rely on the 'ignore ancestry' aspect of WebCrypto, to determine if it's viable to change.
Comment 1 by eroman@chromium.org
, Jul 14 2016