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
Please use DFN-PKI signed certificates on
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.
TLS configuration parameters (work in progress)
- 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
3DESas 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.
SSLv3. If possible provide
MD5ciphers; if possible disable
- When deploying (ephemeral) Diffie-Hellman (
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.
HTTP/2RFC requests that peers refuse to use
CBCciphers, so be careful when preferring
Sadly many clients lack
AES256-GCM-SHA384 support (because they only support
AES128-GCM-SHA256 is the only non-
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:
- BetterCrypto⋅org: Applied Crypto Hardening
- Qualys SSL Labs: Documentation
- Logjam: PFS Deployment Guide
- MozillaWiki: Security/Server Side TLS
- lighty developer blog: GnuTLS Priority Strings
- lighttpd: OpenSSL cipher string recommendation
Please use elliptic curves with at least 255 bits.
NIST curves received a lot of criticism (SafeCurves, BADA55 Crypto). Sadly
Curve448 (RFC 7748) and
edwards448 (RFC 8032) are probably not usable yet with
X.509 nor with mainstream software.
There are various tools to check your
- Online scanners:
Configuration examples for specific applications (work in progress)
SSLEngine on SSLHonorCipherOrder On SSLCipherSuite aRSA+HIGH:!3DES:+kEDH:+kRSA:!kSRP:!kPSK SSLProtocol all -SSLv2 -SSLv3
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.