On Thu, Sep 4, 2014 at 6:29 PM, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote: > On 2014-09-04, 4:42 AM, Anne van Kesteren wrote: >> >> On Wed, Sep 3, 2014 at 7:36 PM, Tim Taubert <ttaub...@mozilla.com> wrote: >>> >>> Chromium has had the WebCrypto API enabled by default since Crome 37, >>> which was released in late June 2014. Their implementation supports a >>> subset of the algorithms that we do, and has roughly the same level of >>> spec compliance. We expect the two implementations to be mostly >>> interoperable as-is, with some fine points being ironed out as the spec >>> is finalized. >> >> >> In Chromium the methods only work on authenticated origins. What is >> our story? > > > I hope that we are not doing that. I don't think Chromium's reasoning there > makes sense.
I agree with Ehsan. For reference, the Chromium "Intent to Ship" is https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Tn3pfJZDcGg/nUlvUOFKL_QJ and says "This API will only be exposed to secure origins, as security-sensitive operations are inherently dangerous when performed on insecure connections." It doesn't explain how exposing Web Crypto to http origins makes things worse compared to http origins not having Web Crypto and implementing the same algorithms in pure JS. Compared to pure JS, Web Crypto provides potentially closer to constant-time implementations, but that's an improvement and doesn't make things worse. Same for general higher speed. Compared to regular JS storing key material in IndexedDB, Web Crypto makes it possible to make the key material not readable by JS (JS can request operations to be performed with the keys but not read back the keys themselves). That, again, seems like an improvement compared to not having Web Crypto available. There's a possible argument that it's dangerous for people to be confused about what sort of security characteristics Web Crypto can provide on unauthenticated origin, but I think it is futile to try to install clue into would-be users by requiring an authenticated origin: the low-level nature of the API is such a foot gun (the name "subtle" is an euphemism for that), that if someone is confused about what security characteristics Web Crypto can provide on unauthenticated origin, there are plenty of other things about Web Crypto to be confused about in ways that lead to insecure outcomes. On the other hand, if the threat model that's being addressed is a passive eavesdropper (as opposed to an active attacker who changes network traffic), Web Crypto can provide additional confidentiality compared to no crypto being in use. Since in this case, the browser does not make any representations in the UI to the user about the confidentiality, integrity or authenticity of the communications, nothing is being misrepresented to the user. However, a site that considers it worthwhile to hide certain things from passive eavesdroppers can still benefit. As for making new features unavailable without TLS in order to promote the use of TLS, I think the TLS requirement should be motivated by some real security or deployability concerns to avoid unproductive resentment by Web developers. (Otherwise, we should be restricting new CSS to https!) Also, while restricting special-interest features might feel good (by creating a feeling that we are restricting *something*) and be more feasible than restricting features that have broad appeal, restricting special-purpose features is less impactful than restricting features that have broad appeal. In this sense, I think restricting HTTP/2 to TLS is the right call. The restriction to TLS addresses a true deployability concern. Furthermore, better performance has broad appeal and, on the flip side, being denied better performance just makes things slow or instead of preventing stuff altogether. I also think that restricting Service Workers to authenticated origins is right call, because failure to do so would mean that an active MITM could continue to have an effect after the actualy MITMing opportunity has gone (e.g. when the user has left a café with an open Wi-Fi AP). I also think that restricting privacy-sensitive APIs that need per-origin permissions to authenticated origins is the right call, because if the origin isn't authenticated, the browser can't really limit the scope of the permission that has been granted, since an active MITM can inject stuff to any unauthenticated origin that has obtained the permission. (I'm not sure if getUserMedia is restricted along these line, but I think it should be if it isn't already.) Furthermore, APIs whose effects aren't tightly coupled with a particular page are especially poor candidates for being restricted to authenticated origins. If the API doesn't have effects that are visible and coupled to a page (Web Crypto is a data in, data out API), it's possible to serve an iframe from an https origin and offer a postMessage interface that proxies the API to an http-origin parent page. One might argue that this is progress, because then the site has to take the step to serve *something* from an https origin, but that's not really much a win considering how common it is for sites to serve just a login form or a credit card number request form over https and serve the rest of the site over http. For the sort of security and privacy we want from https promotion, sites should go all-in with https and the pattern of using https only for login and credit card numbers shows that sites that aren't sold on "https all the things" will make an effort to use as little TLS as they can. I support the Intent to Ship without a restriction to authenticated origins. -- Henri Sivonen hsivo...@hsivonen.fi https://hsivonen.fi/ _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
