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

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

From: Henri Sivonen <hsivonen@hsivonen.fi>
Date: Fri, 9 Jan 2015 18:52:55 +0200
Message-ID: <CAJQvAucFBi=XVZNEwZLOYJDbsFhjB5x8EGQGE3LjDTLjizTqfw@mail.gmail.com>
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

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