You are here: Home » Dokumentation » TLS configuration

Keys and Certificates

RSA keys with less than 2048 bits should be considered unsafe (especially 1024 bits and lower); more than 2048 bits are not of much use right now, as the DFN-PKI certificate chain uses only 2048 bit RSA keys.

Please use DFN-PKI signed certificates on *.uni-stuttgart.de sites.

If you are using ECDSA keys please have a look at the elliptic curves chapter.

Choosing a certificate authority (CA)

We want users to take security warnings seriously, which means all TLS servers should use certificates signed by CAs trusted by most clients. This is especially important for public https servers.

For hostnames related to the university you should be able to get your certificates signed by the DFN-PKI. Otherwise Let’s Encrypt offers free certificates. Self-signed certificates and certificates signed by local or otherwise untrusted CAs should be avoided.

There are many certificate authorities in the standard trust stores of clients. It is quite likely that an attacker might be able to get certificates through one CA of this large list for domains they don’t own. By using the DFN-PKI for university related sites users can increase security by only trusting the DFN-PKI in certain applications.

Certificate signature algorithm

All certificates in the chain apart from the root (CA) certificate should be signed with at least SHA-256. MD5 has been broken a long time ago, and SHA-1 is broken too. Many clients won’t accept certificates signed with deprecated algorithms anymore.

Please check the signature algorithm of the intermediate certificates too. The signature on the root (CA) certificate (or on self-signed certificates) doesn’t matter as it isn’t checked anyway.

Also see FAQ Umstellung SHA-2 and DFN-PKI Blog: SHA-2.

TLS configuration parameters (work in progress)

Basic checklist:

  • On servers you should enable “honor cipher order”, i.e. the server should select the first cipher from its own list a client supports.
  • Disable any cipher suite which uses an effective key size of less than 128 bits. This is especiall true for the null cipher, all export ciphers (40 bits) and DES (56 bits). Although openssl counts 3DES as 168 (3*56) bits, it has an effective size of only 112 bits, and should only be allowed if it is absolutely needed for backward compatibility.
  • Disable RC4 (aka ARCFOUR)
  • Disable SSLv2 and SSLv3. If possible provide TLS1.2 and disable TLS1.0 and TLS1.1.
  • Prefer GCM/CCM over CBC ciphers.
  • Disable MD5 ciphers; if possible disable SHA1 ciphers too.
  • When deploying (ephemeral) Diffie-Hellman (EDH/DHE: without elliptic curves) cipher suites, make sure you use a 2048-bit or stronger Diffie-Hellman group (see https://weakdh.org/sysadmin.html).
  • When deploying (Ephemeral) Elliptic-Curve Diffie-Hellman (ECDHE) cipher suites, make sure to select appropriate elliptic curves chapter.
  • The HTTP/2 RFC requests that peers refuse to use CBC ciphers, so be careful when preferring AES256 over AES128 and HTTP/2 is enabled.

Sadly many clients lack AES256-GCM-SHA384 support (because they only support SHA256, not SHA384), and AES128-GCM-SHA256 is the only non-CBC AES algorithm they support (and CBC ciphers have a bad history).

Here are some sites giving further details for the cipher suite selection, and how to configure various software:

Elliptic curves

Please use elliptic curves with at least 255 bits.

NIST curves received a lot of criticism (SafeCurves, BADA55 Crypto). Sadly Curve25519/Curve448 (RFC 7748) and edwards25519/edwards448 (RFC 8032) are probably not usable yet with X.509 nor with mainstream software.

Verification

There are various tools to check your TLS configuration:

Configuration examples for specific applications (work in progress)

Apache

SSLEngine on
SSLHonorCipherOrder On
SSLCipherSuite aRSA+HIGH:!3DES:+kEDH:+kRSA:!kSRP:!kPSK
SSLProtocol all -SSLv2 -SSLv3

Dovecot

Also see SSL/DovecotConfiguration

# SSL should be mandatory for IMAP/POP/...
ssl = required
ssl_prefer_server_ciphers = yes
# optionally disable kRSA (no PFS) and kEDH with '-' instead of '+'
ssl_cipher_list = aRSA+HIGH:!3DES:+kEDH:+kRSA:!kSRP:!kPSK
# all updated clients should support TLSv1.2
ssl_protocols = !SSLv2,!SSLv3,!TLSv1,!TLSv1.1
# only required if kEDH is enabled
ssl_dh_parameters_length = 2048

Exim with GnuTLS

tls_require_ciphers = NORMAL:-VERS-SSL3.0:-CIPHER-ALL:-SHA1:-MD5:+SHA1:-RSA:+RSA:+AES-256-GCM:+AES-256-CBC:+AES-128-GCM:+AES-128-CBC:%SERVER_PRECEDENCE

# on debian (in conf.d/main/000_somefile for split-config style)
MAIN_TLS_ENABLE = yes
# MAIN_TLS_CERTIFICATE = CONFDIR/exim.crt
# MAIN_TLS_PRIVATEKEY = CONFDIR/exim.key

# plain exim
tls_advertise_hosts = *
tls_certificate = ...
tls_privatekey = ...

If users are going to authenticate you should use a more strict ciphers string, e.g.:

tls_require_ciphers = SECURE256:-VERS-TLS-ALL:+VERS-TLS1.2:-RSA:-SHA1:%SERVER_PRECEDENCE:%LATEST_RECORD_VERSION

Note that although connections between mail servers can be encrypted, the servers usually don’t verify certificates (because there is no user to interactively ask for exceptions and many server use self-signed certificates), so they only protect against passive watchers, not against active Man-in-the-middle attacks.