Use nwaku's native wss

[D4nte]

Problem

Browsers (Firefox, Chrome) only support secure websocket connections within an https page.
As most traffic nowadays defaults to https, it means we need to support wss.

nim-waku now supports native secure websocket. We need to confirm that js-waku can connect to it.

Definition of Done

• Some/all mocha tests uses wss instead of ws
• Perform testing with nwaku/wss to understand what setup works
• Update nwaku's guide to describe a setup that works with js-waku Update websocket documentation to use domain certificates nwaku#848
  • Link to docs.wakuconnect.dev Add reference to nwaku js.waku.guide#39
• Web-chat example connects to Fleet via native websocket (use DNS discovery) blocked by enrtree's multiaddrs do not match SSL cert status-im/infra-nim-waku#38 Tracked with Use DNS Discovery by default #517

Results

• Waku.dial always assumes store + relay protocols. Hence it fails if the remote node only has relay: Waku.dial accepts protocols expected from the peer. Defaults to Waku Relay only. #516
• Using letsencrypt certificates work with nim-waku (latest master). just need to pass the privkey.pem and fullchain.pem files created by letsencrypt
• There are challenges in testing wss locally as Chrome/Firefox does not allow an wss connection within an http page, even if the page is served on localhost and the errors are unhelpful.
  • I was able to test the wss connection using https://js-waku.wakuconnect.dev/examples/web-chat and the /connect command
  • All our examples use React and serve the page on http. It would be interesting to have at least one example setup to serve the page on https. I was not able to do so by using react-scripts. Not sure what would be the quickest way to achieve this.
  • Firefox and chrome do not mind having a wss in a http page if the http page is served by localhost.
• The go-waku fleet does not have websocket enabled.
• Not sure what is the recommend way to generate a node key for nim-waku so that the peer id does not change between two restarts. Doc: Document how to generate and store a nodekey nwaku#847
• Using a self-signed cert, even when using ip4 multiaddr does not work, Chrome and Firefox reject self-signed certs.
• Note that certificate failure for a wss connection is NOT shown to the user.
• Using a self-signed cert with a SAN ip ([alt_names]\nIP.1) does not work either (Firefox and Chrome reject self-signed certs).
• It is not possible to generate an IP cert with letsencrypt

Notes

1. Test that it actually possible to connect to one of the fleet node over wss in the browser: https://www.piesocket.com/websocket-tester If the browser reject the self-signed cert than we know we need to fix the setup first (e.g. tell operators to use letsencrypt instead)
2. Then, test in node (best browser but node should be fine) whether we can get libp2p-websocket to accept the self-signed ip certificate see Secure WebSockets libp2p/js-libp2p#931 for details

[D4nte]

After review, ws works, however, most likely we want wss too (to be confirmed).
Some info about wss: ipfs/notes#252

[D4nte]

Note that chrome blocks ws (not ssl) connections by default so this is needed to make it connect to remote instances

[D4nte]

Ok so findings:

• It is not possible to connect to an insecure websocket ws loaded in a secure page https in chrome. You can work around it in Firefox by messing around with about:config.

Hence this item needs to be tackle otherwise js-waku is not really useful in the browser.

[D4nte]

Most likely just use https npm package: https://github.com/libp2p/js-libp2p-websockets/blob/67a95cbc0dd964869f7867cf16747263709d0a64/test/node.js#L296

[D4nte]

Blocked by libp2p/js-libp2p#931

[D4nte]

FYI waku-org/go-waku#21

[D4nte]

Removed from milestone as wss is working (just not tested as part of CI).

[D4nte]

Blocked until nim-waku 0.7 with wss support is release.
The test can then be changed to interoperability test against wakunode2.

[D4nte]

nim-waku v0.7 with native wss support is now released and used in the CI.

[D4nte]

Sounds very improbable that self-signed certificates can work.
It seems that most modern browser fails silently on self-signed certs.
cerbot should be used.

[D4nte]

What I learned so far:

• Waku.dial always assumes store + relay protocols. Hence it fails if the remote node only has relay. (fix in progress)
• Using letsencrypt certificates work with nim-waku (latest master). just need to pass the privkey.pem and fullchain.pem files created by letsencrypt
• There are challenges in testing wss locally as Chrome/Firefox does not allow an wss connection within an http page, even if the page is served on localhost and the errors are unhelpful.
  • I was able to test the wss connection using https://js-waku.wakuconnect.dev/examples/web-chat and the /connect command
  • All our examples use React and serve the page on http. It would be interesting to have at least one example setup to serve the page on https. I was not able to do so by using react-scripts. Not sure what would be the quickest way to achieve this.
• the go-waku fleet does not have websocket enabled.
• Not sure what is the recommend way to generate a node key for nim-waku so that the peer id does not change between two restarts.

Further research: Now that I know how to make it work, I can test out self-signed certs.

[D4nte]

Further research:

• Using a self-signed cert, even when using ip4 multiaddr does not work.
• Note that certificate failure in wss is NOT shown to the user.
• Using a self-signed cert with a SAN ip does not work either (Firefox and Chrome reject self-signed certs)
• It is not possible to generate an IP cert with letsencrypt

[D4nte]

Done. Some follow-up actions are tracked in #555