xpra icon
Bug tracker and wiki

Opened 10 months ago

Last modified 8 months ago

#1252 new enhancement

native ssl support

Reported by: Antoine Martin Owned by: alas
Priority: major Milestone: 1.0
Component: network Version: trunk
Keywords: Cc:

Description

The python ssl module makes it trivial to wrap tcp sockets.

As part of fixing websockify + ssl (#1213), it would be nice to re-use the same code for supporting SSL natively in our TCP sockets and the websockify code.

Something like:

xpra start --bind-ssl=IP:PORT

And client side:

xpra attach ssl:HOST:PORT

Other arguments we will need for configuring SSL, mirroring websockify and the ssl module but with a "ssl" prefix:

  • --ssl-cert=CERT
  • --ssl-key=KEY
  • --ssl-version=VERSION
  • --ssl-cert-reqs=REQS
  • --ssl-ca-certs=FILE
  • --ssl-ciphers=CIPHERS

Attachments (1)

ssl-v4.patch (20.2 KB) - added by Antoine Martin 9 months ago.
work in progress - ugly but working

Download all attachments as: .zip

Change History (11)

comment:1 Changed 10 months ago by Antoine Martin

Status: newassigned

Or maybe we can support ssl on all tcp server sockets with a --ssl=on switch in the same way that we support websockets for --html=on.

comment:2 Changed 10 months ago by Antoine Martin

Milestone: 0.181.0

Milestone renamed

See also: #1255 for smartcard integration which is possible in openssl.

Last edited 10 months ago by Antoine Martin (previous) (diff)

Changed 9 months ago by Antoine Martin

Attachment: ssl-v4.patch added

work in progress - ugly but working

comment:3 Changed 9 months ago by Antoine Martin

The patch above needs work and testing, but kinda works.

  • generate a cert:
    openssl req -new -x509 -nodes -out cert.pem -keyout cert.pem
    
  • start a server with an ssl socket:
    xpra start --start=xterm --bind-ssl=0.0.0.0:10000 --ssl-cert=./cert.pem
    
  • start a client:
    xpra attach ssl:127.0.0.1:10000 --ssl-server-verify-mode=none
    

Still todo:

  • python < 2.7.9 compat (no ciphers argument)
  • xpras://.../ url handler
  • ssl=on flag and divert ssl traffic to ssl handler from tcp sockets (same as html=on for http)
Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:4 Changed 9 months ago by Antoine Martin

Mostly done in r13100 + r13101, this includes the ssl flag (defaults to "auto") for multiplexing ssl traffic through the same tcp socket.
So this is now enough to start a server with both TCP and SSL support on the same port:

xpra start --start=xterm --bind-tcp=0.0.0.0:10000 --ssl-cert=`pwd`/cert.pem

Still todo:

  • url handler
  • testing on osx / win32, centos6 (python 2.6)
  • testing with valid certs and ca chain
  • man page and wiki updates
  • use SSLContext to force compression off, etc..
Last edited 8 months ago by Antoine Martin (previous) (diff)

comment:5 Changed 9 months ago by Antoine Martin

  • minor rpm packaging fix r13105
  • url handler and packaging updates added in r13106 (tested on Fedora and win32)
  • tested ssl/username:password@HOST:PORT client connection string from win32 and osx
  • man page updates in r13112
  • wiki updated: wiki/Encryption

Still todo:

  • sslcontext and handling for extra options
Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:6 Changed 9 months ago by Antoine Martin

Owner: changed from Antoine Martin to alas
Status: assignednew

sslcontext done in r13114.

That's enough for a first round of testing and feedback.

Still todo:

  • win32 / osx and certification authorities: do we ship the ca cert file?
  • better debug logging?
  • auto-upgrade for clients (specify tcp but get ssl if server supports it)
Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:7 Changed 9 months ago by Antoine Martin

Some more minor tweaks: r13151, r13152, r13155, r13156, r13157, r13160.

Tested the latest beta on centos 6.x and 7.x, without problems.
But on centos6, you need one more thing configured to workaround the limitations of the old / narrower API: unless the client provides a certificate, add --ssl-client-verify=none to prevent the server from trying to loading the CA certs used to validate the client connection (and failing).


Some notes on interoperability with stunnel.
You can easily wrap a regular TCP server with stunnel:

xpra start --start=xterm --bind-tcp=0.0.0.0:10000
cat > stunnel.conf <<EOF
[xpra]
accept = 10001
connect = 10000
cert = cert.pem
verify = 0
EOF

You can then connect to the SSL server on port 10001 using the connection string ssl:127.0.0.1:10001
Or you could start another stunnel instance at the client end, and connect to that via TCP.

The SSL wiki page has been moved here: wiki/Encryption/SSL.

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:8 Changed 9 months ago by Antoine Martin

  • more minor updates: r13285 + r13286 allow us to handle cadata using strings
  • r13288 does the same thing for the legacy python ssl module
  • r13287 makes it easier to test the legacy interface: XPRA_USE_SSL_CONTEXT=0 xpra attach ....
  • r13294 + r13295 fix some ssl bugs in the launcher

See wiki/Encryption/SSL.

Last edited 9 months ago by Antoine Martin (previous) (diff)

comment:9 Changed 8 months ago by Antoine Martin

r13544 allows us to use "xor" authentication mode with ssl connections, so now we can also use the "sys" authentication modules (pam / win32) with ssl.

comment:10 Changed 8 months ago by Antoine Martin

The "ssl" config option can now contain the following values: "on", "off", "auto", "tcp", "www". See ticket:1213#comment:5.

Note: See TracTickets for help on using tickets.