Transport Layer Security

From ArchWiki
Jump to navigation Jump to search

According to Wikipedia:

Transport Layer Security (TLS), and its now-deprecated[1] 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

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Mention that NSS in contrast to the other implementations uses databases. (Discuss in Talk:Transport Layer Security#)

There are five TLS implementations available in the official repositories. 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, OpenPGP 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/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: Currently Arch Linux uses CA certificates from 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/ and /etc/ca-certificates/trust-source/.

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 (like OpenSSL, LibreSSL), the package ca-certificates-utils provides the update-ca-trust(8) script, that copies CA certificates obtained through the centralized interface to /etc/ca-certificates/extracted/ and /etc/ssl/certs.

Trust management

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: How to distrust a certificate authority? Where to cover CRL? (Discuss in Talk:Transport Layer Security#)

See Security#Managing SSL certificates on how to blacklist a certificate authority.

Trust a certificate authority system-wide

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Without the anchor you can trust regular certificates. Does it need to be in PEM format? (Discuss in Talk:Transport Layer Security#)
Warning: This allows anyone with access to the private key to intercept all of your TLS traffic.
# trust anchor certificate.crt

This is for example required to allow a HTTPS MITM proxy to intercept traffic.

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.

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 [2]. 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 [3]. A 2048-bit RSA private key is expected to provide security through most of the 2020s [4]. 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 [5].

Note: The openssl package does not properly safeguard the /etc/ssl/private directory like most other distributions do, see FS#43059.

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:

Tip:

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:

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-client — Secure Let's Encrypt client, written in C.
https://kristaps.bsd.lv/acme-client/ || acme-client-portableAUR
  • 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 || acmetoolAUR, acmetool-gitAUR
  • Certbot — ACME client recommended by Let's Encrypt, written in Python.
https://github.com/certbot/certbot || certbot
  • dehydrated — ACME client, written in Bash.
https://github.com/lukas2511/dehydrated || dehydrated, dehydrated-gitAUR
  • getssl — ACME client, written in Bash.
https://github.com/srvrco/getssl || getsslAUR, getssl-gitAUR
  • lego — Lets Encrypt client and ACME library, written in Go.
https://github.com/xenolf/lego || lego-gitAUR
  • letsencrypt-cli — Yet another Letsencrypt (ACME) client using Ruby.
https://github.com/zealot128/ruby-acme-cli || letsencrypt-cliAUR
  • manuale — A fully manual Let's Encrypt client, written in Python.
https://github.com/veeti/manuale || manualeAUR
  • ruby-acme-client — A Ruby client for the letsencrypt's ACME protocol.
https://github.com/unixcharles/acme-client || ruby-acme-clientAUR
  • simp_le — Simple Let's Encrypt client, written in Python.
https://github.com/zenhack/simp_le || simp_le-gitAUR

With the online, interactive, https://gethttpsforfree.com client you will need about 10 copy paste from the web page to a shell command line, and back. Running the suggested command in between. You will also have to do manual renewals, possibly at that page. Or other wise take care of renewals. On the other hand, you will see at every step whether it succeeded, or not. Will not have to install software just to request for a certificate. And will be able to keep the private keys, or the server software, touched only fully consciously.

OCSP

The Online Certificate Status Protocol (OCSP) is supported by Firefox. Chromium has its own mechanism[6].

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