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).
Milestone renamed
Worth revisiting now that #1252 is done.
attempts at passing an ssl socket to websockify after we have read from it
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.
very hackish patch which sort of works for https but not for wss
Also a blocker for wss client support: ticket:1271#comment:4.
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=0.0.0.0:10000 \ --ssl-cert=`pwd`/server.crt --ssl-key=`pwd`/server.key --ssl=MODE
Clients can then connect with:
Connection | Example Command |
---|---|
ssl | xpra attach ssl:127.0.0.1:10000 --ssl-ca-cert=./ca.crt
|
tcp | xpra attach tcp:127.0.0.1:10000
|
ws | xpra attach ws:127.0.0.1:10000
|
wss | xpra attach ws:127.0.0.1:10000 --ssl-ca-cert=./ca.crt
|
http | xdg-open http://127.0.0.1:10000
|
https | xdg-open https://127.0.0.1:10000
|
(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:
auto
: all work except for wss (as we cannot determine from the ssl header that the connection is websocket / https traffic)
tcp
: only tcp and ssl connections can be used, for the other connection types the server shows an error, ie for ws: Error: tcp connection failed: invalid packet header, HTTP GET request
www
: all work except for ssl (both the client and server log a large error message)
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=0.0.0.0:1203 --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:10.0.32.134:1203 --ssl-ca-cert=\Users\hassenpfeffer\Desktop\random-ticket-info-repository\ca.crt
...
--ssl-ca-cert=
file path, however, works as expected.
xpra --no-daemon --bind-tcp=0.0.0.0:1203 --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:10.0.32.134:1203 --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.
--ssl-server-verify-mode=none
flag (and with the same behavior when trying to pass the cert path on the client).
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.
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.
Follow up in #1504
See also r27656
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/1213