xpra icon
Bug tracker and wiki

Version 8 (modified by Antoine Martin, 3 years ago) (diff)

--

Encryption


Introduction

Access to Xpra's sessions over TCP and unix domain sockets (see network connection) can be protected using authentication modules but those do not protect the network connection itself from man in the middle attacks.

For that, you need encryption. There are two options supported at present:

  • SSL
  • AES

AES

Use this option if you can securely distribute the AES key to each client.
Xpra's AES encryption layer uses either the pycrypto or the cryptography python library to:

  • encrypt the network packets with AES (Advanced Encryption Standard) CBC mode (Cipher-block chaining)
  • stretch the "passwords" with PBKDF2 (Password-Based Key Derivation Function 2)

The salts used are generated using Python's uuid.uuid4()


The encryption key to use must be specified with the "--encryption-keyfile=FILENAME" command line option or it will fallback to the password from the authentication module in use, which may not be as safe.

The contents of this key are combined with salts to generate the secret used to initialize the AES cipher.


Example for TCP sockets:

  • server
    xpra start --start=xterm \
        --bind-tcp=0.0.0.0:10000 \
        --tcp-encryption=AES --tcp-encryption-keyfile=key.txt
    
  • client:
    xpra attach tcp:$SERVERIP:10000 \
        --tcp-encryption=AES --tcp-encryption-keyfile=./key.txt
    

SSL

New in version 1.0

This option can more easily go through some firewalls and may be required by some network policies. Client certificates can also be used for authentication.

There are a lot more options to configure and certificates to deal with. See https://docs.python.org/2/library/ssl.html, on which this is based.

It is only applicable to TCP sockets, not unix domain sockets. Do not assume that you can just enable SSL to make your connection secure.

For details, see #1252.


Example:

  • server with TCP and SSL support:
    xpra start --start=xterm \
        --bind-tcp=0.0.0.0:10000 --ssl-cert=./cert.pem --ssl=on
    

or for SSL only:

xpra start --start=xterm \
    --bind-ssl=0.0.0.0:10000 --ssl-cert=./cert.pem
  • client:
    xpra attach ssl:127.0.0.1:10001
    

If you are using temporary tests certificates and see this message:

[SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:590)

temporarily add --ssl-server-verify-mode=none to your client command line.

== Securing with self signed certificates ==

See [https://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software] and [https://blog.sucuri.net/2016/03/beware-unverified-tls-certificates-php-python.html Beware of Unverified TLS Certificates in PHP & Python].
See also: [https://lwn.net/Articles/666353/ Fallout from the Python certificate verification change].

Since the server certificate will not be signed by any recognized certificate authorities, you will need to send the ca_cert file to the client via some other means... This will no be handled by xpra, it simply cannot be. (same as the AES key, at which point... you might as well use AES)

See [https://carlo-hamalainen.net/blog/2013/1/24/python-ssl-socket-echo-test-with-self-signed-certificate Python SSL socket echo test with self-signed certificate] for generating this x509 keystore. (''server.crt'' in this example).