↑ arvau

ArchWiki / Transport Layer Security

ja:Transport Layer Security According to Wikipedia:

  1. Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP (VoIP). Websites can use TLS to secure all communications between their servers and web browsers.

Implementations

There are multiple TLS implementations available. OpenSSL should already be installed on your system as it is an indirect dependency of the base meta package (base > coreutils > openssl). GnuTLS might already be installed on your system as it is required by many packages.

Certificate authorities

With TLS one of a set of certificate authorities (CAs) checks and signs for the authenticity of a public key certificate from a server. A client connecting to the server via TLS may verify its certificate's authenticity by relying on a digital signature of CA. To check the digital signature a client must have a public key of CA, obtained via a separate path and stored as a self-signed certificate. On Arch Linux the default set of CA certificates is provided by the ca-certificates package.

Arch Linux uses CA certificates from the Mozilla CA Certificate Store as a default set.

Arch Linux provides a centralized system-wide interface for managing CA certificates. This interface is the library /usr/lib/pkcs11/p11-kit-trust.so from the libp11-kit package, which provides PKCS #11 API for certificates, stored in /usr/share/ca-certificates/trust-source/ (the token "Default Trust") and /etc/ca-certificates/trust-source/ (the token "System Trust").

For using the interface from a command line, the p11-kit package provides the trust(1) utility.

For libraries, that have not been ported to PKCS #11 and use a custom logic for managing CA certificates, the package ca-certificates-utils provides the update-ca-trust(8) script. It copies CA certificates obtained through the centralized interface to /etc/ca-certificates/extracted/ and /etc/ssl/certs/.

An overview of mechanisms for loading a default set of CA certificates

Currently LibreSSL uses its own set of CA certificates. See archlinux/packaging/packages/libressl#1.

Trust management

For trust management the trust(1) utility is provided. The utility operates on a list of PKCS #11 modules with the trust-policy: yes setting, sorted by the priority: setting. See pkcs11.conf(5) for details about configuration of modules.

You should always run update-ca-trust(8) after changing a trust store to make the changes visible to libraries that do not support PKCS #11 interface.

You can also use universal tools for working with PKCS #11 modules, such as p11tool(1) or pkcs11-tool(1).

List trust store items

$ trust list

Add a certificate to a trust store

# trust anchor certificate.crt

The certificate should be in the persistence, DER or PEM format (including the OpenSSL-specific trusted certificate format). This command stores the certificate in the first writable token found by querying the list of modules.

This allows anyone with access to the private key to intercept all of your TLS traffic. See HTTPS MITM proxy.

Remove a certificate from a trust store

$ trust anchor --remove 'pkcs11:id=%00%11%22%33%44%55%66%77%88%99%AA%BB%CC%DD%EE%FF%00%11%22%33;type=cert'

Override default trust

The default trust store p11-kit-trust.so includes a blocklist directory at /etc/ca-certificates/trust-source/blocklist/ and certificates in it will be treated as distrusted for all purposes.

The token representing certificates in /usr/share/ca-certificates/trust-source/ is always write-protected. To distrust a default certificate authority it can be extracted to the system's blocklist:

$ trust extract --format=pem-bundle --filter='pkcs11:id=%00%11%22%33%44%55%66%77%88%99%AA%BB%CC%DD%EE%FF%00%11%22%33;type=cert' /etc/ca-certificates/trust-source/blocklist/untrusted_authority.pem

Alternatively, an already extracted certificate may also be copied to the blocklist from the /etc/ca-certificates/extracted/cadir/ path. See update-ca-trust(8) for further information.

Obtaining a certificate

The first step is to generate a private key. Before generating the key, set a restrictive file mode creation mask with umask (for example 077). This ensures that the keys written by openssl are read-protected.

Unlike in other Linux distributions, the openssl package in Arch does not properly safeguard the /etc/ssl/private directory, so a umask is needed. See archlinux/packaging/packages/openssl#1.

Keys can use either elliptic curve or RSA algorithms.

Elliptic curves are newer algorithms and are becoming increasingly adopted for modern systems. A 256-bit elliptic curve key is expected to provide sufficient security through the year 2030 https://www.keylength.com/en/compare/. Curve25519 is an elliptic curve algorithm which has good security and performance properties.

RSA is an older cryptosystem and has higher compatibility, especially with clients that do not support recent versions of TLS. However, RSA relies on factorization, which is an area of cryptography which may be becoming weaker due to the development of faster factorization algorithms https://blog.cloudflare.com/a-relatively-easy-to-understand-primer-on-elliptic-curve-cryptography/. A 2048-bit RSA private key is expected to provide security through most of the 2020s https://www.keylength.com/en/compare/. A 4096-bit RSA private key is expected to provide security for longer (barring major advancements in factorization), but has a very large performance impact. The performance difference can be benchmarked with openssl speed rsa2048 rsa4096 https://webmasters.stackexchange.com/questions/84838/performance-4096-bit-rsa-key-compared-to-2048-bit-rsa-key.

After the key is generated, a certificate can be obtained from a certificate authority with a Certificate Signing Request (CSR), or a certificate may be self-signed. While self-signed certificates can be generated easily, clients will reject them by default, meaning that every client needs to be configured to trust the self-signed certificate.

For the actual generation commands refer to the article of the used implementation:

* You can get free trusted certificates from the Let's Encrypt certificate authority with ACME. * You can make locally trusted development certificates with the mkcert tool. See also Certificates for localhost.

Server-side recommendations

Because there are various attacks against TLS the best practices should be considered:

Checking TLS

Programs to check TLS:

Websites to check TLS:

  • https://dev.ssllabs.com/ssltest/ (only HTTPS)

  • https://www.checktls.com/ (only email)

  • https://www.immuniweb.com/ssl/ (any port)

  • https://tls.imirhil.fr/tls (any port)

Miscellaneous

ACME clients

The Automated Certificate Management Environment (ACME) protocol lets you request valid X.509 certificates from certificate authorities, like Let's Encrypt.

See also List of ACME clients.

OCSP

The Online Certificate Status Protocol (OCSP) is supported by Firefox. Chromium has its own mechanismhttps://dev.chromium.org/Home/chromium-security/crlsets.

See also ocsptool(1) by GnuTLS and ocsp(1ssl) by OpenSSL.

HSTS

The HTTP Strict Transport Security (HSTS) mechanism is supported by Firefox, Chromium and wget (~/.wget-hsts).

DNS CAA

See Wikipedia:DNS Certification Authority Authorization.

See also