W3C home > Mailing lists > Public > www-tag@w3.org > January 2015

Re: Draft finding - "Transitioning the Web to HTTPS"

From: David Sheets <kosmo.zb@gmail.com>
Date: Fri, 9 Jan 2015 17:33:29 +0000
Message-ID: <CAAWM5Twwv+YarvzLH6-iNFYcjEyOmK_eX9E_syXVAP8iggwvPQ@mail.gmail.com>
To: Henri Sivonen <hsivonen@hsivonen.fi>
Cc: Marc Fawzi <marc.fawzi@gmail.com>, "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 Fri, Jan 9, 2015 at 4:52 PM, Henri Sivonen <hsivonen@hsivonen.fi> wrote:
> 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.

Web Crypto over http + SRI with digests delivered over a certified
transport (e.g. TLS) should be secure.

> 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 17:33:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:57:09 UTC