Websocket library discussion

[haerdib]

our current ws libray is not maintained anymore due to its owner being retired (see the issue).

Substrate itself seems to be using its own fork of this library, atleast for the json rpc interface.

it might be worth a thought to switch to this library. Or another maintained fork of ws-rs, which still seems to be the best choice for simple ws connections. If we switch to TLS completely, rustls will be another option, but it does not offer a ws connection without tls.

[murerfel]

I believe @clangenb uses https://github.com/paritytech/jsonrpsee in some parts of the untrusted worker. In light of #202 , where we want to have a secure websocket server directly in the enclave, we'd need another library still, because https://github.com/paritytech/jsonrpsee cannot be run inside the enclave, afaik (it uses tokio, which cannot be run in no_std)? That would mean we might need more than 1 WebSocket library?

Moreover, we have several security issues reported by cargo audit that originate in the ws library (see #189 ), because it's not being maintained anymore. So it would be a good step for sure to replace the ws library.

[haerdib]

I only quickly glanced over https://github.com/paritytech/jsonrpsee but it does not seem to be a simple ws but a ws optimized for jsonrpc. I don't think that's what we will be able to use for #202 because the ws-server, if implemented on std side, will only be forwarding the received messages, it will not handle them as rpc calls. If implemented within the enclave, ws-rs as well as jsonrpsee are not an option, because of no-std, yes.

As I said - I only quickly glanced over it, so I'd love to stand corrected here.

[clangenb]

1. For connections that reach inside the enclave, the sgx rustls fork is probably the only option. Which is fine, we don't need websockets inside the enclave without tls.

2. I suppose we only use the ws-rs crate on the untrusted side. There, I recommend using jsonrpsee, which will automatically get rid of the ws dependency. (If we even need untrusted websockets in case we have tls setup in the enclave)

[haerdib]

I guess this depends alot on the decision of issue #202. If it's okay for you, I'd like to keep this issue open until we've decided what to go for.. (I'd like to keep the links here)

[clangenb]

Fine with me as a memo. But I think I'd adjust the issue name to something that reflects the below:

After implementing #202

• If a websocket is going to be maintained on the untrusted side, we switch that part completely to jsonrpsee.
• If not, we don't use any websocket at all.

[haerdib]

I'm not sure if I can agree to this comment. Because there might be usecases where a simple ws is necessary, without jsonrpc response handling. An example would be the current, untrusted ws to client side. It just forwards the received message, it doesn't read it.

[haerdib]

I'm closing this issue, as it's not an issue any more.