Unable to connect with wss

[temclaugh]

I can't manage to establish wss connections using message-io version 0.14.2 on macOS Big Sur. Example:

use message_io::network::{NetEvent, RemoteAddr, Transport};
use message_io::node::{self, NodeEvent};

fn main() {
    connect("ws://echo.websocket.org".to_string());
    connect("wss://echo.websocket.org".to_string());
}

fn connect(url: String) {
    let (handler, listener) = node::split::<()>();
    handler
        .network()
        .connect(Transport::Ws, RemoteAddr::Str(url.clone()))
        .unwrap();
    listener.for_each(move |event| match event {
        NodeEvent::Network(NetEvent::Connected(e, success)) => {
            println!("{} success={} {:?}", url, success, e);
            handler.stop();
        }
        _ => panic!(),
    });
}

Output:

ws://echo.websocket.org success=true Endpoint { resource_id: [3.R.0], addr: 174.129.224.73:80 }
wss://echo.websocket.org success=false Endpoint { resource_id: [3.R.0], addr: 174.129.224.73:443 }

However, I can connect with wss using websocat from the same machine:

$ echo foo | websocat wss://echo.websocket.org
foo

It looks like it's hitting this code path in the ws adapter:

WS client handshake error: WebSocket protocol error: Handshake not finished

Would appreciate guidance if I'm doing something incorrectly. Thanks!

[lemunozm]

Hi @temclaugh,

It seems a bug, I will investigate it.

Thanks for notifying!

[lemunozm]

I look more deeply into the use case. The problem is that message-io uses WebSocket in binary mode and the echo.websocket.org expected in text mode. At this moment there is no way to configure it to use the text mode. This configuration property would depend on #54

Sorry for the inconvenience, I will notify it in the README.

[temclaugh]

Hi @lemunozm, thanks for looking into this!

I’m wondering if it’s possible that this is related to TLS specifically? ws connections seem to work fine on the same host where wss does not. Example:

use message_io::network::{NetEvent, Transport, RemoteAddr};
use message_io::node::{self, NodeEvent};

fn main() {
    connect("wss://echo.websocket.org".to_string());
    connect("ws://echo.websocket.org".to_string());
}

fn connect(url: String) {
    let (handler, listener) = node::split::<()>();
    handler.network().connect(Transport::Ws, RemoteAddr::Str(url.clone())).unwrap();
    listener.for_each(move |event| match event {
        NodeEvent::Network(NetEvent::Connected(e, success)) => {
            if success {
                println!("{} successfully connected", url);
                handler.network().send(e, b"foo");
            } else {
                println!("{} failed to connect", url);
                handler.stop();
            }
        }
        NodeEvent::Network(NetEvent::Message(_, x)) => {
            println!("{} received message: {}", url, String::from_utf8_lossy(x));
            handler.stop();
        }
        _ => (),
    });
}

Output:

wss://echo.websocket.org failed to connect
ws://echo.websocket.org successfully connected
ws://echo.websocket.org received message: foo

It looks like something might be going wrong during the handshake.
Or, if I'm understanding this incorrectly, is the issue that text mode is causing the handshake to fail, and that would be fixed in binary mode?
Just as a point of reference, I'm able to communicate with echo.websocket.org using websocat with all combinations of ws, wss --binary and --text

[lemunozm]

Thanks for the detailing the error. You are right, it's a problem to the whole wss indendently of the text/binary modes.

I was looking into it and after making the TCP connection, it sends a HTTP request (used for plain WS) instead of a TLS hello (used for WSS). So it tries to connect a normal socket to the tipical WSS port 443 and the server refused the connection.

It's a bug, and I think it is not fast fordward to resolve, because seems that tungstenite do not add the TLS layer automatically for you when connect with wss schema and use the non-blocking handshake mode. It's a pity because for blocking mode tungstenite adds this TLS layer automatically, but message-io works uses only the non-blocking mode.

I hope to fix it in the future, but I cannot promise in a near future. For now, I will remove it as a feature of message-io

So sorry the inconvenience :( and thanks to notify the error

[markusmoenig]

Is this something which will still be addressed ?

[lemunozm]

I'm currently in maintenance mode on this repo. By now, I'm not developing new features. Sorry!
Nevertheless, if anyone wants/can do it I'm open to it.

[TechnoPorg]

Tungstenite has the client_tls() method, which automatically adds a TLS layer if needed. Could that be used to solve the issue?

[lemunozm]

Maybe that can be used to implement the adapter with TLS support 👍🏻