TLS

This page describes how use the TLS functionality of CRIU. A good introduction to Public Key Infrastructure (PKI) and the Transport Layer Security (TLS) protocol can be found in the GnuTLS manual.

Overview

CRIU supports an authenticated key exchange using PKI and X.509 certificates to provide encryption and decryption of data transferred via page server.

This functionality is enabled when CRIU is compiled with GnuTLS support. By default, this happens automatically when the development files for the gnutls package are installed. However, this can be disabled by setting the NO_GNUTLS environment variable at build time.

Setup

The default PKI paths are listed in the table below. These locations can be overwritten by the corresponding command-line options.

Description	Default path	CLI option
Certificate authority certificate	/etc/pki/CA/cacert.pem	--tls-cacert
Certificate revocation list	/etc/pki/CA/cacrl.pem	--tls-cacrl
*Client/server certificate	/etc/pki/criu/cert.pem	--tls-cert
*Private key	/etc/pki/criu/private/key.pem	--tls-key

Note: Required files are indicated with an asterisk (*). If GnuTLS fails to load a required or file specified file via command-line option CRIU will exit with an error.

X.509 certificates and private keys can be generated parsed with the certtool. A template file can be used to avoid the interactive questions of this tool.

Generate Certificate Authority certificate

1. Create a template file.

# cat > ca_template.info <<-EOF
cn = criu.org
ca
cert_signing_key
expiration_days = 700
EOF

2. Generate a private key.

# (umask 277 && certtool --generate-privkey > cakey.pem)

3. Generate the CA certificate.

# certtool --generate-self-signed \
           --template ca_template.info \
           --load-privkey cakey.pem \
           --outfile cacert.pem

Generate client/server certificates

1. Create a template file.

# cat > server_template.info <<-EOF
cn = <Host Name>
encryption_key
signing_key
EOF

2. Generate the private key file.

# (umask 277 && certtool --generate-privkey > key.pem)

3. Generate the certificate.

# certtool --generate-certificate \
            --template server_template.info \
            --load-privkey key.pem \
            --load-ca-certificate cacert.pem \
            --load-ca-privkey cakey.pem \
            --outfile cert.pem

Generating certificate revocation list

Generating a CRL that contains revoked certificates can be achieved as follows:

# certtool --generate-crl \
           --load-ca-privkey cakey.pem \
           --load-ca-certificate cacert.pem \
           --load-certificate revoked-certs.pem \
           --outfile cacrl.pem

Where the revoked-certs.pem file contains all revoked certificates. If the --load-certificate is omitted, an empty Certificate Revocation List will be generated.

Certificate verification

The use of a CA certificate and CRL is optional. They are being loaded if present and ignored otherwise. The system's default trusted CAs are used to verify the received client (or server) certificate when the --tls-cacert option is not specified.

Both the client and the server are required to send a certificate during the TLS handshake phase.

The priority string for the TLS session's handshake algorithms and options (ciphers, key exchange methods and MACs) is set to default.

The value specified with the CLI/opt/--address option is expected to match the hostname included in the received certificate. This implies that, for example, if an IP address is used to connect to a server and the server's certificate includes it's domain name, the verification will fail. This feature is very important to mitigate MITM attacks, however, it can be disabled with the --tls-no-cn-verify command-line option.

Usage Example

Page-server

[dst]# criu page-server -D <path> --port <port> --tls

[src]# criu dump --page-server --address <dst> --port <port> -t <pid> -D <path> --tls

Lazy migration

[src]# criu dump --lazy-pages --port <port> -t <pid> -D <path> --tls

[dst]# criu lazy-pages --page-server --address <src> --port <port> -D <path> --tls

[dst]# criu restore -D <PATH> --lazy-pages

Debugging

In cases when things don't go as expected the environment variable GNUTLS_DEBUG_LEVEL can be used to set the GnuTLS log level. The value should be an integer between 0 and 9 (higher values = more verbosity).