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

David,

Thank you for the information. 

Where does this put the Chrome's team assertion that https is needed for Web Crypto? Since they baked that into the browser what does that mean about their process? Are they making decisions based on false assumption? What is the likelihood that the Chrome team would allow the use of Web Crypto without https? For the kind of scenarios that TimBL had described (somewhere in this thread)

Don't expect you to be able to answer all of these questions but I feel like Google needs to evaluate whether they have the right expertise in security on the Chrome team or if the web's most popular browser is driven by false assumptions in this area. 

It's kind of crazy.

Sent from my iPhone

> On Jan 9, 2015, at 9:33 AM, David Sheets <kosmo.zb@gmail.com> wrote:
> 
>> 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 21:07:18 UTC