Difference between revisions of "TLS"
(Created page with "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...")
Revision as of 18:46, 8 June 2019
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.
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.
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||
|Certificate revocation list||
|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.|
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
revoked-certs.pem file contains all revoked certificates. If the
--load-certificate is omitted, an empty Certificate Revocation List will be generated.
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.
[dst]# criu page-server -D <path> --port <port> --tls [src]# criu dump --page-server --address <dst> --port <port> -t <pid> -D <path> --tls
[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