XPRA Client should send SNI when using SSL/WSS

[David W Johnston]

Currently on the Windows XPRA client (didn't test Linux), connecting to a remote server using WSS does not send the SNI (server name indication) as part of the SSL handshake.

The SNI is a hostname field which can be sent by the client in clear-text in the SSL handshake. This allows the client to specify which host it intends to connect to.

This is useful when using reverse proxies (Ex. sniproxy), so multiple SSL services/sites can run on the same server IP and port.

Thanks

[Antoine Martin]

As per wiki/ReportingBugs, please specify the exact version that you are using.

SNI should be working in current versions.
Please post the output from the client running with -d ssl, ie:

Xpra_cmd.exe attach wss://HOST:10000/ -d ssl
(..)
get_ssl_wrap_socket_fn('', '', 'default', '', 'TLSv1_2', 'optional', 'required', \
    'X509_STRICT', True, 'localhost', 'ALL,NO_COMPRESSION', 'DEFAULT', False)
 verify_mode for server_side=False : required
 ca_certs=None
 cert_reqs=0x2
 protocol=0x5
 cadata=
 verify_flags=0x20
 options=0x80020054
 cert=, key=
 check_hostname=True, server_hostname=HOST
 load_default_certs(Purpose.SERVER_AUTH)
 using default certs
do_wrap_socket(<socket.socket fd=34, family=AddressFamily.AF_INET, type=SocketKind.SOCK_STREAM, proto=0, laddr=(...), raddr=(...)>)

[David W Johnston]

You are right - With the Windows client 4.1-r28059 SNI works perfectly.

My problem was I had: --ssl-check-hostname=no

I didn't realize that would prevent the client from sending the SNI. I expected that switch to simply not enforce the hostname matching the server's cert.

Dave

[migration script]

this ticket has been moved to: ​https://github.com/Xpra-org/xpra/issues/2962