- From: Henri Sivonen <hsivonen@hsivonen.fi>
- Date: Fri, 9 Jan 2015 18:52:55 +0200
- To: Marc Fawzi <marc.fawzi@gmail.com>
- Cc: "Eric J. Bowman" <eric@bisonsystems.net>, Domenic Denicola <d@domenic.me>, Tim Berners-Lee <timbl@w3.org>, Chris Palmer <palmer@google.com>, Melvin Carvalho <melvincarvalho@gmail.com>, Mark Nottingham <mnot@mnot.net>, Public TAG List <www-tag@w3.org>
On Sat, Dec 20, 2014 at 3:50 PM, Marc Fawzi <marc.fawzi@gmail.com> wrote: > Mozilla still allows web crypto to be used over http and > I hope they see that if the script transfer security can > be solved via download from their extension store and > therefore no need to limit web crypto functionality to > https as the chrome team has done. I was one of the people arguing that Mozilla should allow Web Crypto on http origins. In short, my thinking was: 1) There exists a use case, albeit a very specialized one, that made plausible sense: https://www.w3.org/Bugs/Public/show_bug.cgi?id=25972#c8 (Note that the case is *very* specialized. Usually https makes the most sense for this. It's the particular ramifications of the size of video data, MSE and mixed content blocking that are exceptional here.) 2) Web Crypto on http origins doesn't enable any new attacks (other than potentially exploitable memory safety bugs in the Web Crypto back end code itself as is the case with any C++-backed feature) on the Web Platform compared to pure-JS crypto and, therefore, there weren't any new special powers granted that'd need restricting to https and I worried about Web authors reacting badly to just generally restricting new features to https to force https as opposed to restricting new features to https only when allowing them on unauthenticated origins would introduce a new problem. However, this thread makes me regret my position. Clearly, the issue is not just whether in technical actuality Web Crypto enables something that pure-JS crypto doesn't but about what sort of misconceptions Web developers' minds make up about the difference in capability. The notion that Web Crypto can give you meaningful new security/privacy properties when the JS code on the page calling Web Crypto arrived (from outside localhost) over http transport is false and harmful if relied upon as if it was true. So kudos to the Chrome team here for rubbing it into Web developers' faces that Web Crypto on a (non-localhost) http origin (*almost* always) makes no sense. We tend to name specs "Web Foo" these days, but in the case of Web Crypto, the API makes *relatively* little sense *on the Web* and much more sense for uses of Web technologies where the JS code doesn't actually come on-demand from the Web (e.g. packaged Firefox OS apps). (So what *does* Web Crypto enable, then, compared to pure-JS crypto? It enables constant-time behavior of algorithms that are hard to make constant-time in a high-level language and it enables some disaster mitigation in the event of XSS by enabling keys to not to be exfiltrable by XSS even if XSS enables operations to be performed with the keys.) -- Henri Sivonen hsivonen@hsivonen.fi https://hsivonen.fi/
Received on Friday, 9 January 2015 16:53:22 UTC