Xpra: Ticket #1213: http / websockify ssl support

Split from #1136, see attachment/ticket/1136/web-ssl.patch.

Could be related to #1211, there's something fishy going on with non-blocking sockets (they're blocking).

Tue, 12 Jul 2016 16:52:22 GMT - Antoine Martin: milestone changed

Milestone renamed

Wed, 10 Aug 2016 04:22:35 GMT - Antoine Martin: status changed

Worth revisiting now that #1252 is done.

Thu, 01 Sep 2016 04:28:35 GMT - Antoine Martin: attachment set

attempts at passing an ssl socket to websockify after we have read from it

Thu, 01 Sep 2016 06:24:55 GMT - Antoine Martin:

AFAICT, the big problem with SSL sockets (#1252) is that we cannot peek at the data:

ValueError: non-zero flags not allowed in calls to recv() on <class 'ssl.SSLSocket'>

That's unfortunate since openssl does have a:

/usr/include/openssl/ssl.h:int SSL_peek(SSL *ssl, void *buf, int num);

And Add support for SSL_peek. But this is not exposed in the python ssl module, and we cannot access the underlying SSL object to use via ctypes. So we cannot decide immediately if the SSL socket is being used by the client for xpra's protocol or for https / wss, we have to read some data from the socket by starting the IO protocol threads first.

If the SSL connection is for xpra's protocol, all is well and we just process it like normal socket data. For https / wss traffic, we have to re-inject the data we've already written into the socket buffers somehow so that websockify and the python http server can process it.

Thu, 01 Sep 2016 06:25:39 GMT - Antoine Martin: attachment set

very hackish patch which sort of works for https but not for wss

Wed, 07 Sep 2016 04:18:00 GMT - Antoine Martin: priority changed

Also a blocker for wss client support: ticket:1271#comment:4.

Thu, 08 Sep 2016 08:34:44 GMT - Antoine Martin: owner, status changed

Workaround in r13606: we look for the protocol string in the ssl header and wrap it again with websockify if we find "http/1.1". r13610 + r13612 also makes it possible to specify what type of ssl traffic we want to handle, for the cases where the initial ssl header does not contain enough information to decide what to do with it, as is the case with the websocket client (#1271).

Examples based on the self signed CA from wiki/Encryption/SSL: The server is started with (replace MODE):

xpra start --start=xterm --bind-tcp= \
    --ssl-cert=`pwd`/server.crt --ssl-key=`pwd`/server.key --ssl=MODE

Clients can then connect with:

Connection Example Command
ssl xpra attach ssl: --ssl-ca-cert=./ca.crt
tcp xpra attach tcp:
ws xpra attach ws:
wss xpra attach ws: --ssl-ca-cert=./ca.crt
http xdg-open
https xdg-open

(with the self signed CA, the browser will complain when opening with https unless you add the ca.crt to your list of certificates)

Results for each MODE:

Fri, 16 Sep 2016 01:48:06 GMT - alas: owner changed

Tested with 1.0 r13673 win32 client against 1.0 r13742 fedora 23 server.

Installed a self-signed cert per instructions at wiki/Encryption/SSL, then grabbed the generated ca.crt to my client windows machine (and ran the wizard to install, just in case).

Server starts as expected with the command line specified there

 xpra --no-daemon --bind-tcp= --start-child=xterm --start-child=xterm --mdns=no --start-new-commands=yes --ssl=on --ssl-cert=/home/jimador/ticket-land/ticket1213/server.crt --ssl-key=/home/jimador/ticket-land/ticket1213/server.key start :13

... and the client errors as expected if not using --ssl-server-verify-mode=none when using the ssl:[IP]:[port]

xpra_cmd.exe attach ssl: --ssl-ca-cert=\Users\hassenpfeffer\Desktop\random-ticket-info-repository\ca.crt


xpra --no-daemon --bind-tcp= --start-child=xterm --start-child=xterm --mdns=no --start-new-commands=yes --ssl=on --ssl-cert=/home/jimador/ticket-land/ticket1213/server.crt --ssl-key=/home/jimador/ticket-land/ticket1213/server.key start :13 --ssl=tcp
xpra_cmd.exe attach tcp: --ssl-ca-cert=\Users\hassenpfeffer\Desktop\random-ticket-info-repository\ca.crt

As does using ssl:[IP]:[port] client side with the --ssl-server-verify-mode=none flag, though using the ssl:[IP]:[port] with the file path still errors out.

Looks like everything's working as expected so far though. I'll pass back to you to take a look and see if there's anything else you need tested.

Fri, 16 Sep 2016 02:01:07 GMT - Antoine Martin: status changed; resolution set

SSL closed at last. Thanks!

As for sha1, see https://security.googleblog.com/2014/09/gradually-sunsetting-sha-1.html - I believe this change should fix things (untested): wiki/Encryption/SSL.

Fri, 21 Apr 2017 07:02:16 GMT - Antoine Martin:

Follow up in #1504

See also r27656

Sat, 23 Jan 2021 05:18:04 GMT - migration script:

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