Skip to content
This repository has been archived by the owner on Jul 21, 2023. It is now read-only.

WebCrypto is locked up in non secure pages (not loaded from HTTPS) #105

Open
daviddias opened this issue Aug 28, 2017 · 8 comments
Open
Labels
need/community-input Needs input from the wider community status/deferred Conscious decision to pause or backlog

Comments

@daviddias
Copy link
Member

After seeing reports on js-ipfs:

I went to investigate to find this https://groups.google.com/a/chromium.org/forum/#!topic/security-dev/DtOFo51WFMo

It seems that WebCrypto does require a secure context to run and that is not granted in non HTTPS loaded pages. It has an exception for localhost though.

We have a couple of options here:

  • a) Accept and notify the users that they should use SSL to load their webpages
  • b) Shim all the libraries for when WebCrypto is not available

I prefer option 2, although it will bloat the size of the bundle (again)..

@dignifiedquire
Copy link
Member

wow webcrypto gets worse with every thing I learn about it. This is incredible..

@dignifiedquire
Copy link
Member

I have some ideas on alternatives, will update here after some experiments

@dignifiedquire
Copy link
Member

In the short term we should adding a warning in any case as the current releases all have this issue

@dignifiedquire
Copy link
Member

I am making good progress with my experiments of using asmcrypto.js. Speedwise it looks pretty good and I believe it has everything we need.

@mitra42
Copy link

mitra42 commented Aug 28, 2017

@dignifiedquire - have you looked at Libsodium ? We've been using that in JS.

@dignifiedquire
Copy link
Member

@mitra42 I haven't given it a thorough try yet as we need more than it provides, but I will recheck again what we can use from it, thanks for the reminder

@daviddias
Copy link
Member Author

libsodium is great but it exists in its own universe of crypto, the djb universe. We need to support what go-ipfs does and that means that libsodium isn't enough.

@Kubuxu
Copy link
Member

Kubuxu commented Sep 1, 2017

Yes, libsodium is an implementation of what NaCl established in this space so it won't be sufficient.

@daviddias daviddias added status/ready Ready to be worked status/deferred Conscious decision to pause or backlog need/community-input Needs input from the wider community and removed status/ready Ready to be worked labels Feb 5, 2018
hapsody added a commit to hapsody/js-ipfs that referenced this issue Jul 2, 2019
This example doesn't work except the case in localhost ( related to ipfs#2153)
This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105)
I add a explanation of a example's restriction to run
alanshaw pushed a commit that referenced this issue Jul 4, 2019
This PR adds `crypto-browserify` to the dependencies and replaces `crypto` with `crypto-browserify` when bundled in the browser.

In files that require webcrypto we check to see if it's available. If it is not we require the Node.js implementation (which has `crypto` replaced with `crypto-browserify`) and if it is available then we use the webcrypto version (so we get fast crypto).

Shipping `crypto-browserify` adds to the bundle size:

Current gzipped size: 142,824 bytes
New gzipped size: 214,499 bytes

Difference: **+71,675 bytes**

It's not an insignificant addition so we need to decide whether this is worth it.

If not accepted, we need to add checks when libp2p-crypto methods are called and callback with an appropriate error message. JS IPFS will continue to have issues opened with confusion around this otherwise! See ipfs/js-ipfs#963 ipfs/js-ipfs#964 ipfs/js-ipfs#2153

resolves #105

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
alanshaw pushed a commit to ipfs/js-ipfs that referenced this issue Jul 4, 2019
This example doesn't work except the case in localhost ( related to #2153)
This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105)
I add a explanation of a example's restriction to run
alanshaw pushed a commit that referenced this issue Jul 9, 2019
Changes `webcrypto.js` to check for native web crypto availability and falls
back to using `window.__crypto` if not available.

If the user wants to bring their own Web Crypto API compatible implementation
then they simply need to assign it to `window.__crypto` before they start using
IPFS.

Checks are done in the functions that require web crypto to give the user the
flexibility to assign to `window.__crypto` before OR after they import
`libp2p-crypto`. It also means that users have the ability to use other exported
functions that do not require web crypto without having to worry about sorting
their own implementation.

We use `window.__crypto` because `window.crypto` is a readonly property in
secure context and always readonly in workers.

If `window.crypto` and `window.__cypto` are unavailable then an appropriate
error message is reported to the user with a `ERR_MISSING_WEB_CRYPTO` code.

I've also added documentation to the README.

This is a backwards compatible change.

closes #149
resolves #105
resolves ipfs/js-ipfs#2017
resolves ipfs/js-ipfs#2153

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
alanshaw added a commit that referenced this issue Jul 17, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message.

This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation.

refs #149
refs #150
refs #105
refs ipfs/js-ipfs#2153
refs ipfs/js-ipfs#2017

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
jacobheun pushed a commit that referenced this issue Jul 22, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message.

This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation.

refs #149
refs #150
refs #105
refs ipfs/js-ipfs#2153
refs ipfs/js-ipfs#2017

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
Mikerah pushed a commit to ChainSafe/js-libp2p-crypto that referenced this issue Aug 29, 2019
This PR simply detects missing web crypto and throws an error with an appropriate message.

This is a stepping stone that will help users understand the problem until we have time to do a refactor of this module and of all the modules that use it to enable optionally passing your own crypto implementation.

refs libp2p#149
refs libp2p#150
refs libp2p#105
refs ipfs/js-ipfs#2153
refs ipfs/js-ipfs#2017

License: MIT
Signed-off-by: Alan Shaw <[email protected]>
oliveriosousa pushed a commit to ipfs-examples/js-ipfs-examples that referenced this issue Jul 26, 2021
This example doesn't work except the case in localhost ( related to ipfs/js-ipfs#2153)
This is known because of a restriction with WebCrypto (libp2p/js-libp2p-crypto#105)
I add a explanation of a example's restriction to run
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
need/community-input Needs input from the wider community status/deferred Conscious decision to pause or backlog
Projects
None yet
4 participants