No way to restrict to only WSS and exclude WS

[georgyo]

Type: Enhancement

Severity: Medium

Description:

When using IPFS with dht enabled from a address that is not local host, the browser makes it impossible to open connections to not TLS websockets.

As a result, you end up with thousands of failed attempts to contact hosts the browser will reject, flooding the console.

The transports section of js-libp2p takes a module of https://github.com/libp2p/js-libp2p-websockets, which is maybe where this bug report should have ended up.

There also seems to be a heavy performance penalty as throughput plummets, even when directly attached to nodes that have the content. Though I need to debug this further.

Steps to reproduce the error:

Spawn an IPFS node with at least the following config and try visiting it from a website using TLS:

  libp2p: {
    config: {
      dht: {
        enabled: true,
        clientMode: true
      }
    }
  },

This is easily seen here: https://bafybeihxe5lmiyonwlh4yxb7o5wthq7lwrd366orvj5urmcuhfmrlc65ca.ipfs.dweb.link/

[vasco-santos]

Hello @georgyo

Due to browser’s security policies you couldn’t establish unencrypted connection from secure context (e.g. page loaded via HTTPS). You can read about it at MDN Secure Context. There is a lot of work regarding the DHT in the browser that we need to land. We will also be working on Connection Gating which can help us not attempting to connect to such nodes in the browser. This work will be part of the upcoming Connection manager overhaul #744

[jacobheun]

I think the general issue here is that the websocket filter function is too lenient, https://github.com/libp2p/js-libp2p-websockets/blob/v0.14.0/src/index.js#L127-L129. Right now it allows TCP and DNS addresses, and allows them to be ws or wss.

Outside of development we should really be restricting to DNS only. It is possible we could connect to a local TCP loopback peer, but this isn't likely to be a common use case. Right now ws and wss aren't being treated any differently, but they should be, and browsers should be restricting to wss where as Node.js peers could permit ws.

@vasco-santos this ties in a bit to the dial address filtering work you've been doing, but we should also look at restricting websocket filtering more. We may want to look at making the filter configurable, because if we get too strict that could get really annoying for certain environments.

[jacobfriedman]

I'm trying on 0.0.0.0 and getting the following (self-signed)

websocket.js:124 Mixed Content: The page at 'https://0.0.0.0/' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://0.0.0.0:443/socket.io/?EIO=3&transport=websocket'. This request has been blocked; this endpoint must be available over WSS.

I guess it just defaults to ws at any rate, as JH mentions above This is true even if I specify the address ip4/0.0.0.0/tcp/443/wss/, or even the bootstrap list. I hadn't peeked under the hood but it was worth a shot.

Perhaps unrelated: if I visit an IP address other than localhost on a parcel server, it gives me "Error: Missing Web Crypto API" and fails to load as well.

[vasco-santos]

This is now fixed with libp2p-websockets@0.15