lisk-sdk: SSL breaks Websocket connection

Expected behavior

With SSL enabled incoming websocket connections should work.

Actual behavior

With SSL enabled incoming Websocket connections fail.

Since no incoming Websocket connections are being established the broadhash consensus can only be established every 30 seconds (when peer.rpc.status is called) as no updateMyself broadcasts can reach the node. See #2083

The problems are the following:

SocketCluster enables the secure flag when https is enabled. Therefore incoming connections need to use wss as protocol. Currently the peer headers don’t contain a flag signaling whether the node has secure websocket connections enabled which is why other peers can’t know whether they have to connect via ws or wss => The connection fails with secure peers.

Peer connections are established using the IP address and not hostnames. Therefore the certificate validation fails when a secure WebSocket connection is being established. If cert checking should be disabled the rejectUnauthorized flag would have to be set. However this would essentially make the secure connection pointless.

Steps to reproduce

Launch a Lisk Core node with HTTPS enabled in the config.

Proposed solution

Disable HTTPs for WebSocket connections as certificate validation is not really possible without hostnames/domains and implement a better encryption mechanism post-1.0.0.

Completely remove the SSL options from Lisk Core. It just adds unnecessary complexity and is not as performant as using a reverse proxy like nginx to do SSL Termination. I’d rather recommend to add a guide on how to setup the Lisk core in conjunction with nginx/etc.

Which version(s) does this affect? (Environment, OS, etc…)

1.0.0+

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 9
  • Comments: 15 (7 by maintainers)

Commits related to this issue

Most upvoted comments

@jondubois, @abelboldu and I discussed this. The way forward depends a little on when this would get resolved. At the moment, this issue is in the 1.1.0 milestone. In that case, it would make more sense to pull this out completely and use a proxy for ssl termination, since by that point, everyone will be doing that anyway in the interim (my personal choice). If this is to be resolved in 1.0 before mainnet launch, it makes more sense to keep it in and have it working for the api and not do ssl for p2p.

It’s worth noting that people are using this feature as it was an issue for a number of people when they did the testnet migration. There are certainly delegates using this on mainnet and perhaps even some exchanges

Maybe we should have two separate SSL/TLS on/off config options for the public HTTP API and for the WebSocket P2P API?

A node might want to serve its public API over https:// but it might still want to use regular ws:// for the P2P layer (to be compatible with the rest of the network).

Supporting both ws:// and wss:// protocols within the same network would add a lot of complexity to the P2P layer.

I agree with @Gr33nDrag0n69 that it’s probably not worth it for Lisk to have TLS between peers because all data that passes through the network is public (and signed) anyway.

For 1.0, we should not enable this TLS feature on the node itself; instead, a terminating TLS proxy should be run alongside the Lisk node as recommended above (if HTTPS support is necessary).