-
Notifications
You must be signed in to change notification settings - Fork 835
Description
Hello,
I'm using websockify/python3-websockify 0.12.0+dfsg1-4+b1 on Debian 13 ("trixie") with a command line on the form:
/usr/bin/python3 /usr/bin/websockify --heartbeat=20 --ssl-ciphers=DEFAULT:!kPSK:!kRSA:!kRSAPSK:!SHA1:!SHA256:!SHA384:!SSLv3:!TLSv1.0 --ssl-version=tlsv1_2 -v --cert=/path/to/fullchain.pem --key=/path/to/privkey.pem --ssl-only [::]:61123 127.0.0.1:61023
Debian has a sysctl(8) setting net.ipv6.bindv6only = 0 by default, so this should accept both IPv6 and IPv4 connections, for "future-proofing".
On incoming IPv4 (but probably also for IPv6) connections, the log shows:
aug 25 22:32:41 glimmer websockify@61123[304824]: ::ffff:213.100.209.85 - - [25/Aug/2025 22:32:41] ::ffff:213.100.209.85: Plain non-SSL (ws://) WebSocket connection
OpenSSL s_client connections and tcpdump appear to indicate that WSS is indeed used, despite the log message.
Trying to connect using Telnet will correctly log "non-SSL connection received but disallowed" and close the conection.
So it appears that this only affects the log message on incoming (WSS) connections.
It might be the case that handle_websocket() (https://github.com/novnc/websockify/blob/master/websockify/websockifyserver.py#L231) cannot correctly identify SSL connections the way it does?
Some AI searches indicate that this might be caused by the different tuples returned for different address families (https://docs.python.org/3/library/socket.html#socket-families), AF_INET6 in this case, but you know those things better than I do.
I just wanted to share this observation with you, for any possible future adjustments.
Many thanks in advance!
Kind regards
Björn