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[edit]
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[edit]
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[edit]
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[edit]
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[edit]
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[edit]
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[edit]
Page-server[edit]
[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[edit]
[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[edit]
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).