Transport Layer Security

According to
Wikipedia
:
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
This article or section needs expansion.
Reason:
Mention that NSS in contrast to the other implementations uses databases. (Discuss in
Talk:Transport Layer Security
)
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.
OpenSSL
— A robust, commercial-grade, and full-featured toolkit for the TLS and SSL protocols; also a general-purpose cryptography library.
https://www.openssl.org/
||
openssl
GnuTLS
— A free software implementation of the TLS, SSL and DTLS protocols. Offers APIs for X.509, PKCS #12 and other structures.
https://www.gnutls.org/
||
gnutls
Network Security Services
(NSS)
— Implementation of cryptographic libraries supporting TLS/SSL and
S/MIME
. Also supports TLS acceleration and smart cards.
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS
||
nss
mbed TLS
— Portable SSL/TLS implementation, aka PolarSSL.
https://tls.mbed.org/
||
mbedtls
LibreSSL
— A version of the TLS/crypto stack forked from OpenSSL in 2014 by the OpenBSD project, with goals of modernizing the codebase and improving security.
https://www.libressl.org/
||
libressl
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.
Note
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
Implementation
Mechanism
Arch Linux configuration
OpenSSL
Provides API functions that load the certificates from a hardcoded directory or file.
SSL_CTX_set_default_verify_paths(3)
.
A default file is
/etc/ssl/cert.pem
, a default directory is
/etc/ssl/certs/
.
GnuTLS
Provides an API function that loads the certificates from a hardcoded directory, file, or
configured
PKCS #11
modules. In the last case, a hardcoded
URL
allows to load either an arbitrary trusted certificate, or trusted CA certificates on modules, marked with
trust-policy: yes
, optionally with additional filtration criteria.
[1]
,
[2]
.
Loads all trusted CA certificates from
configured
PKCS #11
modules, marked with
trust-policy: yes
.
Network Security Services
Automatically loads the certificates from a dynamically configured list of
PKCS #11
modules, managed with a dedicated API. Configuration can be stored in any directory, pointed by a user. The list always contains the built-in module that stores objects in the same user-provided directory.
[3]
,
modutil(1)
.
mbed TLS
A user should load the certificates.
[4]
.
LibreSSL
Provides an API function that loads the certificates from a hardcoded directory or file.
libressl-SSL_CTX_load_verify_locations(3)
.
A default file is
/etc/libressl/cert.pem
, a default directory is
/etc/libressl/certs/
.
Note
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.
Note
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.
Tip
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.
Warning
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) § SOURCE CONFIGURATION
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.
Note
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
[5]
.
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
[6]
.  A 2048-bit RSA private key is expected to provide security through most of the 2020s
[7]
. 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
[8]
.
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:
OpenSSL#Usage
GnuTLS#Usage
Network Security Services#Usage
mbed TLS#Usage
Tip
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:
Disable SSLv3
to prevent the
POODLE
attack.
weakdh.org's Guide to Deploying Diffie-Hellman for TLS
Mozilla's Server Side TLS article
SSL Labs' SSL and TLS Deployment Best Practices
Recommended TLS/SSL configurations for popular services
Checking TLS
Programs to check TLS:
testssl.sh
Nmap
OpenSSL
cipherscan
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
.
acme-cli
— Yet another Letsencrypt (ACME) client using Ruby.
https://github.com/zealot128/ruby-acme-cli
||
acme-cli
AUR
acme-tiny
— A 200-line Python script to issue and renew TLS certs from Let's Encrypt.
https://github.com/diafygi/acme-tiny
||
acme-tiny
acme.sh
— A pure Unix shell script ACME client.
https://github.com/acmesh-official/acme.sh
||
acme.sh
acmetool
— An easy-to-use ACME CLI, written in Go.
https://github.com/hlandau/acme
||
acmetool
AUR
Certbot
— ACME client recommended by Let's Encrypt, written in Python.
https://github.com/certbot/certbot
||
certbot
dehydrated
— ACME client, including support for wildcard certificates! Written in Bash.
https://github.com/lukas2511/dehydrated
||
dehydrated
getssl
— ACME client, written in Bash.
https://github.com/srvrco/getssl
||
getssl
AUR
lego
— Lets Encrypt client and ACME library, written in Go.
https://github.com/go-acme/lego
||
lego
manuale
— A fully manual Let's Encrypt client, written in Python.
https://github.com/veeti/manuale
||
manuale
AUR
ruby-acme-client
— A Ruby client for the letsencrypt's ACME protocol.
https://github.com/unixcharles/acme-client
||
ruby-acme-client
AUR
simp_le
— Simple Let's Encrypt client, written in Python.
https://github.com/zenhack/simp_le
||
simp_le-git
AUR
OCSP
The
Online Certificate Status Protocol
(OCSP) is supported by
Firefox
.
Chromium
has its own mechanism
[9]
.
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
Gentoo:Certificates
A note about SSL/TLS trusted certificate stores, and platforms (OpenSSL and GnuTLS)
PKCS #11 Cryptographic Token Interface Usage Guide