Re: Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

On Fri, Jul 28, 2017 at 10:15 PM, Jonathan Kingston  wrote:
> Hey Tim,
>
> The only questions I have about this our are difference in implementation
> over Chrome the more we increase the use of [SecureContext] the greater risk
> we put on compat bugs.

Good news, the implementation difference was just removed by Kate in
bug 1410364.

Let's move forward with the proposal for Firefox 59.

> Our implementation differs in that we actually abide to the specification on
> window.opener insecure contexts making the openee insecure. This may for
> example cause breakage on payment sites that want to use crypto.
>
> Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
> least for the time being?
>
> The difference is somewhat a technicality anyway as the inverse isn't true a
> SecureContext that opens an !SecureContext is not then treated as insecure
> despite the risk being pretty much the same.
>
> On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert  wrote:
>>
>> Summary: The WebCrypto spec [1] states that window.crypto.subtle
>> should only be usable from a secure origin (i.e. on a domain being
>> served over HTTPS). Currently Gecko's implementation works on insecure
>> origins (i.e. sites served over unencrypted HTTP). To bring our
>> implementation in line with the spec, we're going to remove access to
>> crypto.subtle on non-secure origins.
>>
>> Sites using the WebCrypto API's crypto.subtle interface on a
>> non-secure origin should switch to HTTPS as soon as possible.
>>
>> Chrome too is planning to remove access to crypto.subtle on non-secure
>> origins [2]. Edge seems positive about implementing those restrictions
>> as well [3].
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>>
>> Standard: https://w3c.github.io/webcrypto/Overview.html
>>
>> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>>
>> Estimated target date: This could land as early as Firefox 56, but
>> should in Firefox 57. We probably want to coordinate with Chrome, they
>> seem as ready as we are.
>>
>> Our telemetry [4] indicates that about 9% of crypto.subtle use is
>> still on insecure origins. This was at around 1-2% - that's not the
>> percentage of all users, but only of those that visit pages that use
>> crypto.subtle - but became inflated around two weeks after we started
>> measuring. The blink-dev thread [2] has a good summary and indicates
>> that this is caused by Twitter launching AMP support serving from
>> origins which may be insecure. AMP has a fallback that is lazy-loaded
>> in case crypto.subtle isn't available, so no one's Twitter would break
>> when we ship this.
>>
>>
>> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
>> [2]
>> https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
>> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
>> [4] https://mzl.la/2ttx8aV
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Remove: Insecure use of WebCrypto

[Jonathan Kingston]

Hey Tim,

The only questions I have about this our are difference in implementation
over Chrome the more we increase the use of [SecureContext] the greater
risk we put on compat bugs.

Our implementation differs in that we actually abide to the specification
on window.opener insecure contexts making the openee insecure. This may for
example cause breakage on payment sites that want to use crypto.

Perhaps we should shift to using SecureContextIfOpenerIgnored instead; at
least for the time being?

The difference is somewhat a technicality anyway as the inverse isn't true
a SecureContext that opens an !SecureContext is not then treated as
insecure despite the risk being pretty much the same.

On Thu, Jul 20, 2017 at 3:47 PM, Tim Taubert  wrote:

> Summary: The WebCrypto spec [1] states that window.crypto.subtle
> should only be usable from a secure origin (i.e. on a domain being
> served over HTTPS). Currently Gecko's implementation works on insecure
> origins (i.e. sites served over unencrypted HTTP). To bring our
> implementation in line with the spec, we're going to remove access to
> crypto.subtle on non-secure origins.
>
> Sites using the WebCrypto API's crypto.subtle interface on a
> non-secure origin should switch to HTTPS as soon as possible.
>
> Chrome too is planning to remove access to crypto.subtle on non-secure
> origins [2]. Edge seems positive about implementing those restrictions
> as well [3].
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140
>
> Standard: https://w3c.github.io/webcrypto/Overview.html
>
> Platform coverage: This will affect Windows, MacOS, Linux, and Android.
>
> Estimated target date: This could land as early as Firefox 56, but
> should in Firefox 57. We probably want to coordinate with Chrome, they
> seem as ready as we are.
>
> Our telemetry [4] indicates that about 9% of crypto.subtle use is
> still on insecure origins. This was at around 1-2% - that's not the
> percentage of all users, but only of those that visit pages that use
> crypto.subtle - but became inflated around two weeks after we started
> measuring. The blink-dev thread [2] has a good summary and indicates
> that this is caused by Twitter launching AMP support serving from
> origins which may be insecure. AMP has a fallback that is lazy-loaded
> in case crypto.subtle isn't available, so no one's Twitter would break
> when we ship this.
>
>
> [1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
> [2] https://groups.google.com/a/chromium.org/forum/#!topic/
> blink-dev/ZD3NWqkk-bo/discussion
> [3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
> [4] https://mzl.la/2ttx8aV
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Remove: Insecure use of WebCrypto

[Tim Taubert]

Summary: The WebCrypto spec [1] states that window.crypto.subtle
should only be usable from a secure origin (i.e. on a domain being
served over HTTPS). Currently Gecko's implementation works on insecure
origins (i.e. sites served over unencrypted HTTP). To bring our
implementation in line with the spec, we're going to remove access to
crypto.subtle on non-secure origins.

Sites using the WebCrypto API's crypto.subtle interface on a
non-secure origin should switch to HTTPS as soon as possible.

Chrome too is planning to remove access to crypto.subtle on non-secure
origins [2]. Edge seems positive about implementing those restrictions
as well [3].

Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1333140

Standard: https://w3c.github.io/webcrypto/Overview.html

Platform coverage: This will affect Windows, MacOS, Linux, and Android.

Estimated target date: This could land as early as Firefox 56, but
should in Firefox 57. We probably want to coordinate with Chrome, they
seem as ready as we are.

Our telemetry [4] indicates that about 9% of crypto.subtle use is
still on insecure origins. This was at around 1-2% - that's not the
percentage of all users, but only of those that visit pages that use
crypto.subtle - but became inflated around two weeks after we started
measuring. The blink-dev thread [2] has a good summary and indicates
that this is caused by Twitter launching AMP support serving from
origins which may be insecure. AMP has a fallback that is lazy-loaded
in case crypto.subtle isn't available, so no one's Twitter would break
when we ship this.


[1] https://w3c.github.io/webcrypto/Overview.html#crypto-interface
[2] 
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/ZD3NWqkk-bo/discussion
[3] https://github.com/w3c/webcrypto/issues/28#issuecomment-243243989
[4] https://mzl.la/2ttx8aV
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform