bug: wakucanary requires key path to test client connections

[felicio]

Problem

The wakucanary requires --websocket-secure-key-path to test client connections.

Expected behavior

The flag should not be required.

Additional context

Why

• https://github.com/status-im/infra-hq/issues/92#issue-1769478385
  • https://github.com/status-im/infra-hq/issues/92#issuecomment-1882637386
  • https://github.com/status-im/infra-hq/issues/92#issuecomment-1883040790

[chair28980]

Related to #1732

[felicio]

@chair28980 please, what's the "Icebox" status and is there any chance to give this a higher prio? Given https://github.com/status-im/infra-hq/issues/92#issue-1769478385.

[chair28980]

Cc @waku-org/nwaku-developers please see above

[gabrielmer]

As discussed, WSS is not defined as a client-server protocol (even more with the P2P case), so it's reasonable that nim-libp2p requires certificates to establish a connection.

The proposed solution is for WakuCanary to generate self signed certificates in case none is provided and establish the connection.

CC @jakubgs @vpavlin

[jakubgs]

WSS is not defined as a client-server protocol

What? I'm sorry but I'm confused. My understanding is that Secure WebSockets, or wss:// protocol is just WebSockets over TLS, right? Which means that the connection starts through a TLS(HTTPS) handshake, which is a client-server protocol, and does not require a certificate on the client side.

If you're saying I can just use any "snakeoil" certificate and key with the Waku canary for wss:// connections then that's fine, we can do that, but I would like to understand what is actually happening here. Clearly the TLS handshake does not require a certificate on the client side, so where does the need for the certificate on client side come in?

[gabrielmer]

If you're saying I can just use any "snakeoil" certificate and key with the Waku canary for wss:// connections then that's fine, we can do that, but I would like to understand what is actually happening here. Clearly the TLS handshake does not require a certificate on the client side, so where does the need for the certificate on client side come in?

Yes, apologies, my previous comment wasn't really accurate 😶

So the way Waku Canary works is creating a Waku node, adding the node we want to check as a peer, connecting to it and verifying which protocols it supports.

If we would try to connect to the node via a "normal" WSS client and not via a libp2p node, then we wouldn't need the certificate. But because we do it via a libp2p node, which requires a certificate in order to use WSS as it's not designed for client-server use cases, we need the certificate. The requirement comes from here: https://github.com/status-im/nim-libp2p/blob/unstable/libp2p/transports/wstransport.nim#L324

[jakubgs]

I see, thanks for explaining the confusion. So we can just generate any certificate and key for the canary host and use that for all canaries checking websocket port status. Cool.