Hands-on: implementing DANE in Exim
Cryptographic security for mail transport
This hands-on guide describes the installation and configuration of the DANE internet security standard in the Exim mail server. DANE is designed to frustrate mail traffic snooping by requiring the use of TLS encryption wherever possible during transport. The set-up described in this guide involves a CentOS 8.2 Linux server running a fully functional standard installation of the mail server, and a straightforward zone file for the DNSSEC-enabled domain example.nl. We describe how to extend that set-up with the following: • Configuration of (Start)TLS • Publication of TLSA records • Specification of cryptographic algorithms • Validation of DANE for mail For the basic set-up of the mail servers themselves, see our hands-on guides to the implementation of SPF, DKIM and DMARC in Exim. Like those guides, this hands-on guide combines specimen configurations with explanations of how the DANE standard works.
Contents
Part I — Introduction
1.1 Modern internet standards
DANE is designed to frustrate mail traffic snooping by requiring the use of TLS encryption wherever possible during transport. Although we strongly recommend the implementation of SPF, DKIM and DMARC — indeed, implementation is mandatory for government organisations in the Netherlands — DANE is entirely separate from those three standards. While SPF, DKIM and DMARC provide for the authentication and authorisation of an e-mail message's sender and sending host (at the SMTP-protocol level), DANE focuses on the security (confidentiality) of the transport (at the StartTLS-connection level). There is no interdependency between the SPF-DKIM-DMARC trio and DANE for mail. It doesn't therefore matter whether the trio is implemented first, or DANE for mail. However, the use of DNSSEC is mandatory with DANE, whereas it's merely recommended with SPF, DKIM and DMARC. On our DNSSEC page you'll find hands-on guides to the implementation of DNSSEC signing and validation in Unbound, Infoblox, PowerDNS and BIND. If you prefer to configure SPF, DKIM and DMARC first, see our hands-on guides to implementation in Exim, respectively. This hands-on guide assumes a set-up as described in the latter two guides.
1.2 How DANE works
DANE, short for DNS-based Authentication of Named Entities, is a protocol for the secure publication of public keys and certificates. The standard utilises the cryptographically secured DNS infrastructure provided by DNSSEC. Although DANE therefore has various possible applications, the main growth in the standard's use is currently in mail transport (SMTP). DANE's use in connection with web certificates (HTTPS) has yet to catch on, partly because of the boom in the popularity of (free) Let's Encrypt certificates, and partly because DNSSEC is not always available everywhere. To enable DANE, the DNS protocol has been extended by the addition of a TLSA record. That can be used to link key information — in the form of a hash code (digital extract) — to an address-protocol-port combination. In principle, the authenticity of any encrypted internet service's server certificate can then be verified (validated) via the DNS. If the hash code of the server certificate doesn't match the hash code in the TLSA record, the client knows that the connection is not trustworthy, despite the encryption. DANE is standardised in RFC 6698, with clarifications in RFC 7671 and RFC 7673. DANE for mail is separately specified in RFC 7672.
1.3 E-mail clients and servers
In order to understand how the exchange of e-mail works, it's important to distinguish between, on the one hand, communication between end user and mail server, and, on the other, communication between mail servers. User-server communication primarily involves the user fetching mail from the server and reading it. The user's mail client (Mail User Agent, MUA) handles that by using the POP and IMAP protocols to communicate with the server (the Mail Delivery Agent, MDA). The conventional TCP ports for those two protocols are 110 and 143, respectively. For TLS-secured connections, the respective port numbers are 995 (POP3S) and 993 (IMAPS). The client can upgrade connections to non-secure ports (110/pop and 143/imap) to encrypted connections by using the STARTTLS command. However, the normal approach nowadays is to state explicitly in the client configuration that you want to use IMAPS on port 993. To send messages, the mail client uses the SMTP protocol. Nowadays, that normally involves the use of a private SMTP gateway for the server's own users on TCP port 587, with password-controlled access to exclude spammers. Port number 465 used to be reserved for TLS-secured gateways (SMTPS), but has since been assigned to another protocol. Cryptographic security of those SMTP connections is therefore always based on StartTLS (following authentication).
1.4 Mail transport
In order to deliver the user's messages, the SMTP gateway (now acting as a client) similarly uses the SMTP protocol. That's done on the mail server's TCP port 25, which is specified as the input port in the receiving domain's MX record. Again, no separate port is available for TLS-secured connections. And, like a user's mail client, a client mail server can upgrade its connection with an MX gateway by using the STARTTLS command. Despite the many similarities, there is a crucial difference between the SMTP connection used by an end user's mail client to send mail and the SMTP connection used by a mail server to transmit mail to another mail server (Message Transfer Agent or MTA). Whereas SMTP gateway operators can require their own users to use StartTLS when sending mail, MX gateways cannot require other servers to use the protocol. Because an MX gateway is a public message delivery portal, it currently has to be accessible to SMTP clients (mail servers) that don't support StartTLS. In that sense, the SMTP service is like the web, where visitors can generally choose whether to access a server via TCP port 80 (HTTP) or port 443 (HTTPS). However, for a web user who enters a URL starting 'https', there is no automatic fallback from the secure port 443 to the insecure port 80. Whereas an SMTP client that attempts to deliver a message to port 25 can be 'forced' to use an insecure port instead, simply by disabling StartTLS capability on the server. The problem is that a man-in-the-middle (MITM) can also disable secure transport by filtering out the StartTLS capability during the insecure SMTP handshake (StartTLS stripping). In fact, it seems that downgrade (STRIPTLS) attacks are often performed by internet access providers on users who opt to utilise their own SMTP gateways.
1.5 Opportunistic TLS
Whereas a web user explicitly states a preference for TLS ('https') and is notified if an attempted TLS connection fails, a mail client can't (yet) insist on the use of secure transport and no provision exists for providing feedback to the client (except in the form of a bounce message). Neither the mail address used nor the associated MX records indicate anything about the security of transport. Nevertheless, the presence of a TLSA record does imply that the MX gateway supports TLS, so a downgrade attack on the gateway's StartTLS capability is prevented. Not all mail clients support TLS, however. Its use by a client is therefore optional, meaning that DANE for mail is a so-called 'opportunistic protocol'. In other words, an SMTP client that supports DNSSEC, DANE and StartTLS is 'required' to encrypt its connections with a server for which DNSSEC-signed TLSA records have been published (indicating that it offers StartTLS). However, if any of those elements is missing, client and server fall back to TLS without DANE or even to insecure transport. The system works that way to ensure that message delivery can proceed without human intervention wherever possible. However, since the publication of RFC 8314 in 2018, unencrypted transport by means of SMTP, POP and IMAP has been formally classed as 'obsolete'.
1.6 The TLSA record
A TLSA record does not contain much more than a hash and information about the cryptographic protocols used. The only parameter that requires some explanation is the so-called 'usage'. The 'usage' parameter indicates how the hash should be interpreted:
0: PKIX-TA: Certificate Authority Constraint: anchors a particular CA certificate in the chain of trust (in addition to conventional PKI validation)
1: PKIX-EE: Service Certificate Constraint: anchors a particular server certificate (in addition to conventional PKI validation)
2: DANE-TA: Trust Anchor Assertion: anchors a particular CA certificate in the chain of trust, which then acts as a trust anchor
3: DANE-EE: Domain Issued Certificate: anchors a particular server certificate, which has to match the certificate offered by the server
Usages 0 and 1 anchor the certificate of, respectively, a CA and a server, to supplement conventional PKI anchoring on the basis of trust anchors provided in the client (or, on the web, the browser). The effect of usage 0 is to localise a hacked CA problem, while usage 1 completely neutralises it. Both usages also highlight any discrepancies between the two chains of trust. However, as explained below, that should be regarded as a bug rather than a feature: DANE was really developed to supersede and replace the existing PKI anchor system, and usages 0 and 1 were intended merely to accommodate that legacy. Usages 2 and 3 operate entirely independently from conventional PKI anchoring, making them suitable for self-signed certificates. They also make it possible to serve clients without installed trust anchors, such as SMTP clients (mail servers).
1.7 DANE for mail
The DANE standard stipulates that, with usages 0 and 1, both chains of trust must be validated. That can be problematic if one chain can be validated but the other cannot. In a web browser, the problem can be resolved the same way as the problem of a conventional PKI certificate that can't be validated for whatever reason: a pop-up that warns the user and asks whether they want to proceed. However, SMTP clients have never had PKI trust anchors installed, which is why the standard says usages 0 and 1 are inappropriate with DANE for mail. After all, the client's (browser's) built-in PKI certificates, which we still use for the web, are now regarded as an outdated and demonstrably insecure legacy. Although it would be better to replace them with self-signed certificates plus TLSA records for local assurance, that solution depends on the use of DNSSEC, whose adoption in many parts of the world lags far behind that in the Netherlands [1, 2].
Part II — Configuration of (Start)TLS
Before your mail server can offer StartTLS as an option (SMTP capability), the server needs to be provided with a cryptographic key pair. The key pair can then be used for the certificate (self-signed public key) that is offered to clients for encryption of the connection (following a StartTLS request).
2.1 A TLS key pair for Exim
With Exim, a TLS key pair is generated when the software package is installed. The public and private keys are recorded in the files '/etc/pki/tls/certs/exim.pem' and '/etc/pki/tls/private/exim.pem', respectively. In the Exim configuration file '/etc/exim/exim.conf', the locations are specified using the following two options:
tls_certificate = /etc/pki/tls/certs/exim.pem tls_privatekey = /etc/pki/tls/private/exim.pem
However, we prefer to use our own key pair. Another consideration is that we want to support not only the RSA-based encryption algorithms, but also the efficient ECDSA-based algorithms. The advantages of the latter modern cryptographic algorithm are explained here in relation to DNSSEC. We therefore need to delete the existing keys, and then generate two new key pairs, as follows:
trash /etc/pki/tls/certs/exim.pem /etc/pki/tls/private/exim.pem
[root@mail ~]# cd /etc/pki/tls/private/
[root@mail private]# openssl req -newkey rsa:4096 -sha512 -x509 -nodes -days 3650 \
-keyout exim-rsa.key -out exim-rsa.cert
Generating a RSA private key
......................................................++++
...........................++++
writing new private key to 'exim-rsa.key'
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:NL
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:Gepermuiden
Organization Name (eg, company) [Default Company Ltd]:Acme Corporation
Organizational Unit Name (eg, section) []:Exim TLS key
Common Name (eg, your name or your server's hostname) []:mail.example.nl
Email Address []:postmaster@example.nl
[root@mail private]# chmod 640 exim-rsa.key exim-rsa.cert
[root@mail private]# chown root:exim exim-rsa.key exim-rsa.cert
[root@mail private]# mv exim-rsa.cert ../certs/
[root@mail ~]# cd /etc/pki/tls/private/
[root@mail private]# openssl ecparam -out exim-ecdsa.key -name prime256v1 -genkey
[root@mail private]# openssl req -new -sha512 -key exim-ecdsa.key -out exim-ecdsa.csr
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [XX]:NL
State or Province Name (full name) []:
Locality Name (eg, city) [Default City]:Gepermuiden
Organization Name (eg, company) [Default Company Ltd]:Acme Corporation
Organizational Unit Name (eg, section) []:Exim TLS key
Common Name (eg, your name or your server's hostname) []:mail.example.nl
Email Address []:postmaster@example.nl
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
[root@mail private]# openssl req -x509 -sha512 -days 3650 -key exim-ecdsa.key \
-in exim-ecdsa.csr -out exim-ecdsa.cert
[root@mail private]# chmod 640 exim-ecdsa.key exim-ecdsa.cert
[root@mail private]# chown root:exim exim-ecdsa.key exim-ecdsa.cert
[root@mail private]# mv exim-ecdsa.cert ../certs/Once that's done, we can add the new key files to the Exim configuration (in the file '/etc/exim/exim.conf'):
tls_certificate = /etc/pki/tls/certs/exim-ecdsa.cert:/etc/pki/tls/certs/exim-rsa.cert tls_privatekey = /etc/pki/tls/private/exim-ecdsa.key:/etc/pki/tls/private/exim-rsa.key
Note that the various keys must be included in the options in the same paired order.
2.2 TLS configuration for Exim
Next, we need to verify that TLS is otherwise properly configured. The file '/etc/exim/exim.conf' now contains the following TLS-related options:
# Allow any client to use TLS.
tls_advertise_hosts = *
# For OpenSSL, prefer EC- over RSA-authenticated ciphers
tls_require_ciphers = ECDSA:RSA:!COMPLEMENTOFDEFAULT
# In order to support roaming users who wish to send email from anywhere,
# you may want to make Exim listen on other ports as well as port 25, in
# case these users need to send email from a network that blocks port 25.
# The standard port for this purpose is port 587, the "message submission"
# port. See RFC 4409 for details. Microsoft MUAs cannot be configured to
# talk the message submission protocol correctly, so if you need to support
# them you should also allow TLS-on-connect on the traditional but
# non-standard port 465.
daemon_smtp_ports = 25 : 587
# This setting, if uncommented, allows users to authenticate using
# their system passwords against saslauthd if they connect over a
# secure connection. If you have network logins such as NIS or
# Kerberos rather than only local users, then you possibly also want
# to configure /etc/sysconfig/saslauthd to use the 'pam' mechanism
# too. Once a user is authenticated, the acl_check_rcpt ACL then
# allows them to relay through the system.
#
auth_advertise_hosts = ${if eq {$tls_cipher}{}{}{*}}
# Unless you run a high-volume site you probably want more logging
# detail than the default. Adjust to suit.
log_selector = +smtp_protocol_error +smtp_syntax_error \
+tls_certificate_verifiedThe option 'auth_advertise_hosts' specifies the clients to which AUTH capability is ascribed by the Exim gateway. In this case, AUTH capability is ascribed to all clients, for all SMTP ports (if TLS is actually configured). Further on, in the 'acl_check_auth' Access Control List (ACL), authentication itself is restricted to TLS-encrypted connections established on port 587:
acl_check_auth:
# deny authentication on unencrypted links
deny !encrypted = *
message = encryption before AUTH is required
# deny if AUTH isn't on submission port (autolist enabled)
deny !condition = ${if eq {$interface_port}{587}}
message = AUTH only via submission port
# accept if encrypted (should not get here if unencrypted)
accept encrypted = *Hence, authenticated connections (for relay) can be established only on port 587 and must be encrypted. Requiring encryption is important for the protection of login data. You may also have noticed that unauthorised connections to port 587 are handled in the same way as connections on port 25 (which cannot be authorised). Furthermore, the default configuration does not distinguish between local accounts, hosts/networks for which we perform a mail relay role ('relay_from_hosts'), and authenticated clients. If you look at the 'acl_check_rcpt' ACL, you'll see that DKIM and DMARC validation is disabled for all three:
control = dkim_disable_verify
control = dmarc_disable_verify2.3 Testing the TLS configuration
After restarting, the Exim server, with the new key pairs installed, will be on standby for inbound connections. The new configuration can be tested using the 'ssltest' command. In the following example, you can see that our mail server does indeed now offer two self-signed certificates: one based on RSA, the other on ECDSA.
systemctl restart exim.service systemctl status exim.service
testssl -t smtp localhost:25
The SMTP gateway on port 587 can be checked in a similar way:
testssl -t smtp localhost:587
By sending another telnet command to port 587, we can verify that login is not permitted until the connection has been upgraded using StartTLS:
[root@system ~]# telnet localhost 587 Trying ::1... Connected to localhost. Escape character is '^]'. 220 mail.example.nl ESMTP Exim 4.94 Wed, 20 Jan 2021 12:37:54 +0100 ehlo verzender.example.nl 250-mail.example.nl Hello verzender.example.nl [::1] 250-SIZE 52428800 250-PIPELINING 250-X_PIPE_CONNECT 250-CHUNKING 250-STARTTLS 250-PRDR 250 HELP auth 503 AUTH command used when not advertised quit 221 mail.example.nl closing connection Connection closed by foreign host.
The following command can be used to test interaction with the mail server via a TLS connection:
openssl s_client -connect localhost:587 -tls1_3
We will return to the configuration of TLS shortly, when we give detailed consideration to the cryptographic algorithms we do and don't want to use to encrypt our traffic.
Part III — Publication of a TLSA record
3.1 Generating a TSLA record
There are various ways of generating a TLSA record for your MX gateway. One is to use an OpenSSL command, with your server certificate as the basis. Where an RSA-based certificate is concerned, that approach results in the following:
[root@mail exim]$ openssl x509 -in /etc/pki/tls/certs/exim-rsa.cert -outform DER |
openssl sha256
(stdin)= f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032fThe output is the hash (based on the SHA-256 algorithm) of the (self-signed) certificate that your mail server offers to clients for connection encryption (following a StartTLS request). The alternative to SHA-256 is the much stronger SHA-512 algorithm. SHA-512 was developed for use on 64-bit systems, but has also become the norm on mobile devices. The hash value given above can be incorporated directly into your TLSA records:
# DANE for mail
_25._tcp.mx.example.nl IN TLSA 3 0 1
f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032f
_587._tcp.smtp.example.nl IN TLSA 3 0 1
f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032f
_465._tcp.smtp.example.nl IN TLSA 3 0 1
f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032fThe first field above (whose value is 3 in our example) specifies the usage, as described earlier. The second field (whose value is 0) specifies the selector: when the value is 0, the hash is taken from the entire certificate (as a blob); when it's 1 the DER format is used. And the final field (the matching type, which has the value 1 in our example) indicates which hash algorithm is used: 0 for an exact match, 1 for the SHA-256 hash, and 2 for the SHA-512 hash. As you'll see, in the interest of completeness, the TLSA records for TCP ports 587 and 465 are included. However, to the best of our knowledge, no mail clients currently perform DANE validation on the SMTP gateway (or on the POP/IMAP/POPS/IMAPS ports). We do exactly the same for the ECDSA-based certificate, resulting in a second set of TLSA records.
3.2 Tools: hash-slinger
Various tools are also available for generating TLSA records. One is hash-slinger, developed by Paul Wouters. The package is no longer included in the Fedora/CentOS/RHEL distributions. Nevertheless, once manually installed, the software (and the 'python3-m2crypto' package) can be used to generate TLSA records on the basis of the offered certificate as follows:
[root@mail hash-slinger-master]# ./tlsa --create --port 25 --starttls smtp --output rfc mail.example.nl
Got a certificate with Subject: /C=NL/ST=/L=Gepermuiden/O=Acme Corporation/OU=Exim TLS key/
CN=mail.example.nl/emailAddress=postmaster@example.nl
_25._tcp.mail.example.nl. IN TLSA 3 0 1 f61bf58d20d9a3898a02a2ff031e6103d267c9e86e05fccba73b5de109b1032fNote that the hash value has to be generated using the certificate offered online by the mail server via TCP port 25. That normally involves running the hash-slinger on the same system that the server is running on, or on another trusted network. Otherwise, you run the (very small) risk of a man-in-the-middle (MITM) replacing the server's real certificate with a fake certificate. A better option (which does require you to be on the same system) is to specify the certificate yourself using the following option statement:
--certificate /etc/pki/tls/certs/exim-rsa.cert
3.3 An online tool
Anyone who prefers to use an online tool to generate a TLSA record is likely to find Shumon Huque's tool handy.
On this page, you can also check that your TLSA record does indeed match the certificate being offered.
3.4 TLSRPT reports
TLSRPT (defined in RFC 8460) is a mechanism that enables a mail domain operator to receive error messages from clients (sending mail servers) in the event of TLS encryption failures when connecting to the operator's MX gateway. The TLSRPT mechanism works in a similar way to the DMARC mechanism.
Although TLSRPT was defined together with MTA-STS and by the same actors, it works just as well with DANE for mail.
In order to receive TLSRPT reports, a mail domain operator publishes a special TXT record (in parallel with the MX records), as follows:
_smtp._tls.example.nl IN TXT "v=TLSRPTv1; rua=mailto:tls-rua@example.nl"
As you can see, the record consists of little more than an e-mail address to which standardised error messages can be sent for automated processing.
Automated TLSRPT report processing services are provided by the same organisations that offer DMARC report processing.
Part IV — Cryptographic algorithms
4.1 NCSC guidelines
Having a fully functional and properly anchored TLS configuration doesn't necessarily mean that your connections are adequately secured. The reason being that, to a significant extent, security depends on the version of the TLS protocol used and on the associated cryptographic algorithms. If outdated protocols and/or algorithms are used, security will be inadequate by modern standards. However, if only the latest and most secure options are supported, some older SMTP clients may not be able to interact securely with the server and will be obliged to fall back on an insecure connection. The NCSC has drawn up guidelines for both TLS connections in general and for the encryption of mail transport in particular. Their recommendations relate not only to the TLS protocol itself, but also to the various cryptographic primitives (which together form the cipher suite). In the latest update to the 'ICT Security Guidelines for Transport Layer Security (TLS)' (dated 19 January 2021), the NCSC downgraded TLS version 1.2 from 'Good' to 'Satisfactory'. This article has been revised in line with the update.
4.2 Cryptographic algorithms
The various cryptographic algorithms that can be used for TLS (amongst other things) are listed below, grouped by function.
Algorithms for the exchange of private keys: ECDHE, DHE, RSA
Public key algorithms (asymmetric cryptography algorithms) for X.509 certificates (chains of signed public keys): RSA, ECDSA
(Symmetric) cryptography for the bulk encryption of traffic (for which public key cryptography is too slow/inefficient): 3DES, AES
Hash function algorithms for use in connection with the creation of digital signatures: SHA-1, SHA-256, SHA-512
4.3 Recommended protocols and algorithms
In chapter 4 of the ICT Security Guidelines for Transport Layer Security (TLS), the NCSC advises using only TLS version 1.2 or 1.3, preferably the latter. The recommended cryptographic algorithms are listed in the following table; the support situation differs from one version of TLS to another.
For the certificates, EdDSA can also be used, but that algorithm isn't yet supported by the certificate authorities. Be aware that the SHA-1 hash function algorithm is suitable for use only in the context of bulk encryption (MAC); it should definitely not be used for hashes in digital signatures. Where the encryption algorithms are concerned, it's also worth noting that RSA keys should be at least 2048 bits, and preferably 3072 or 4096 bits. Also, the Elliptic-Curve Cryptography (ECC)-based algorithms (ECDHE, ECDSA and EdDSA) should use only the secp384r1, secp256r1, x448 and x25519 curves as their underlying mathematical functions. Similarly, if you want to continue supporting the (less efficient) DHE algorithm, use only the variants based on the finite field groups ffdhe4096 and ffdhe3072 (as discussed in RFC 7919). Later in this guide we'll explain how to set the parameters for such algorithms.
4.4 Cryptography settings for Exim
Having decided which of the (dozens of) available algorithms we want to use, a corresponding specification string has to be inserted into our mail server's configuration. The mail server then communicates the specification (in this case literally) to the underlying cryptographic library (typically OpenSSL). The settings that we use for Exim (in the file '/etc/exim/exim.conf') are set out below. The string is forwarded to OpenSSL in exactly the same form when OpenSSL is called up. For details, therefore, see the OpenSSL documentation. Later in this article, we explain how you can use the command line to ask OpenSSL what valid cipher suites remain available when a given specification is used.
# Disable SSLv2, SSLv3, TLSv1, TLSv1.1, leaving only TLSv1.2 and TLSv1.3
openssl_options = +no_sslv2 +no_sslv3 +no_tlsv1 +no_tlsv1_1
+single_dh_use +single_ecdh_use
+cipher_server_preference +no_compression +no_session_resumption_on_renegotiation# For OpenSSL, prefer EC- over RSA-authenticated ciphers
#tls_require_ciphers = ECDSA:RSA:!COMPLEMENTOFDEFAULT
tls_require_ciphers = HIGH:!SSLv2:!SSLv3:!TLSv1:!TLSv1.1:
!EXP:!LOW:!MEDIUM:!aNULL:!eNULL:
!SRP:!PSK:!kDH:!DH:!kRSA:!DHE:!DSS:!RC4:!DES:!IDEA:!SEED:!ARIA:!CAMELLIA:!AESCCM8:!3DES:
!ECDHE-ECDSA-AES256-SHA384:!ECDHE-ECDSA-AES128-SHA256:!ECDHE-RSA-AES256-SHA384:!ECDHE-RSA-AES128-SHA256:
!MD5:!SHAtls_dhparam = /etc/exim/dh4096.pem
Note, however, that the variable 'tls_require_ciphers' is currently used only for TLS version 1.2. According to the Exim documentation, the cipher suites for version 1.3 are currently (January 2021) still hard-configured on:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
A little later in this guide, we'll consider exactly which cipher suites are omitted.
4.5 Cryptographic protocols and algorithms
Let's now consider the configuration itself. First of all, we use only TLS versions 1.2 and 1.3, and we explicitly exclude the outdated SSL protocols and TLS versions 1 and 1.1. However, it should be noted that the remaining protocols should always result in a series of consecutive versions. The option 'HIGH' is used to make a preliminary selection from the available cryptographic algorithms. Its effect is to permit only the strongest algorithms (with a security level of at least 128 bits). Also, because we want to use only TLS versions 1.2 and 1.3, we explicitly exclude the outdated SSL protocols and TLS versions 1 and 1.1. Finally, in the remainder of the string, we specify the algorithms we definitely don't want to use. That involves first repeating everything under the gradation 'HIGH'. Other algorithms that we explicitly exclude are:
SRP, PSK, (k)DH, (k)RSA and DHE for key exchange (aRSA can, however, be used for certificates; DHE may be used, but only if based on the ffdhe4096 or ffdhe3072 functions)
RC4, DES, IDEA, SEED, ARIA, CAMELLIA, AES/CCM8, 3DES and AES/CBC for bulk encryption (AES/GCM is permitted)
As you'll see, our settings are quite strict: we support only the algorithms that the NCSC has rated 'Good', not those that are rated 'Adequate'. Note also that the list of exceptions presented above includes algorithms (e.g. RC4, DES and MD5) that have already been excluded. The reason for nevertheless explicitly specifying them at this point is to prevent their accidental activation in the event of combinations of crypto-primitives being added at a later date. For the same reason, our configuration includes an aNULL and an eNULL (NULL operators for authentication and encryption, respectively).
4.6 Checking which cipher suites are offered
Now, if we re-run the 'testssl' command, we see that our mail server offers eight cipher suites, all based on the 'ECDHE-ECDSA-' and 'ECDHE-RSA-' algorithms. The most recent versions of testssl list four additional cipher suites, but they are merely abbreviated notations for the combinations entered with TLS version 1.3.
By revising our crypto-configuration string slightly, we can also ask OpenSSL what valid cipher suites remain:
[user@system ~]$ openssl ciphers -s -tls1_2 \
'HIGH, !EXP, !LOW, !MEDIUM, !aNULL, !eNULL, \
!SRP, !PSK, !kDH, !DH, !kRSA, !DHE, !DSS, !RC4, !DES, !IDEA, !SEED, !ARIA, !CAMELLIA, !AESCCM8, !3DES, \
!ECDHE-ECDSA-AES256-SHA384, !ECDHE-ECDSA-AES128-SHA256, !ECDHE-RSA-AES256-SHA384, !ECDHE-RSA-AES128-SHA256, \
!MD5, !SHA'
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-CCM
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-CCM4.7 Cipher suites classed as 'Adequate' by the NCSC
If you want to additionally allow the combinations that the NCSC classes as 'Adequate', the crypto-specification string needs to be as follows:
smtpd_tls_exclude_ciphers =
EXP, LOW, MEDIUM,
aNULL, eNULL, SRP, PSK, kDH, ADH, AECDH, kRSA, DSS, RC4, DES, IDEA, SEED, ARIA, AESCCM8, 3DES, MD5Checking with OpenSSL then yields the following list:
[user@system ~]# openssl ciphers -s -tls1_2 \
'HIGH, !EXP, !LOW, !MEDIUM, !aNULL, !eNULL, \
!SRP, !PSK, !kDH, !ADH, !AECDH, !kRSA, !DSS, !RC4, !DES, !IDEA, !SEED, !ARIA, !AESCCM8, !3DES, !MD5'
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
DHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
DHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES256-CCM
DHE-RSA-AES256-CCM
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256
DHE-RSA-AES128-GCM-SHA256
ECDHE-ECDSA-AES128-CCM
DHE-RSA-AES128-CCM
ECDHE-ECDSA-AES256-SHA384
ECDHE-RSA-AES256-SHA384
DHE-RSA-AES256-SHA256
ECDHE-ECDSA-CAMELLIA256-SHA384
ECDHE-RSA-CAMELLIA256-SHA384
DHE-RSA-CAMELLIA256-SHA256
ECDHE-ECDSA-AES128-SHA256
ECDHE-RSA-AES128-SHA256
DHE-RSA-AES128-SHA256
ECDHE-ECDSA-CAMELLIA128-SHA256
ECDHE-RSA-CAMELLIA128-SHA256
DHE-RSA-CAMELLIA128-SHA256
ECDHE-ECDSA-AES256-SHA
ECDHE-RSA-AES256-SHA
DHE-RSA-AES256-SHA
DHE-RSA-CAMELLIA256-SHA
ECDHE-ECDSA-AES128-SHA
ECDHE-RSA-AES128-SHA
DHE-RSA-AES128-SHA
DHE-RSA-CAMELLIA128-SHAIn addition to the 'Good' cipher suites, the list now includes suites based on DHE, AES/CCM(16), CAMELLIA and SHA(-1) (for HMAC).
4.8 TLS version 1.3 only
As discussed above, the cipher suites for version 1.3 are currently still hard-configured on:
TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
As you will see below, OpenSSL for TLS 1.3 supports only four cipher suites, the last of which (utilising CCM) is not included in the list above:
user@system ~]$ openssl ciphers -s -tls1_3 TLS_AES_256_GCM_SHA384 TLS_CHACHA20_POLY1305_SHA256 TLS_AES_128_GCM_SHA256 TLS_AES_128_CCM_SHA256
If we combine our earlier selection for cipher suites classed as 'Good' with TLS version 1.3 – recommended as the most secure option in the latest NCSC guidance – you will see that all four suites are selected:
[user@system ~]$ openssl ciphers -s -tls1_3 \
'HIGH, !EXP, !LOW, !MEDIUM, !aNULL, !eNULL, \
!SRP, !PSK, !kDH, !DH, !kRSA, !DHE, !DSS, !RC4, !DES, !IDEA, !SEED, !ARIA, !CAMELLIA, !AESCCM8, !3DES, \
!ECDHE-ECDSA-AES256-SHA384, !ECDHE-ECDSA-AES128-SHA256, !ECDHE-RSA-AES256-SHA384, !ECDHE-RSA-AES128-SHA256, \
!MD5, !SHA'
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_GCM_SHA256
TLS_AES_128_CCM_SHA2564.9 Forward secrecy
The reason why we (NCSC) restrict approval to ECDHE and DHE for key exchange is that those two algorithms provide 'forward secrecy'. A completely new (symmetrical) session key is exchanged for each message — hence the 'E' for 'ephemeral' in the algorithms' names — with the result that other encrypted information remains secure in the event of a session key being leaked. The option 'smtpd_tls_eecdh_grade = ultra' is used to set the parameters for the EECDH algorithm so that its security level is 192 bits (128 bits being the current minimum security requirement). The option 'tls_dhparam = /etc/exim/dh4096.pem' refers to a file containing the parameters for strong encryption on the basis of the (less efficient) DHE algorithm. The file is generated as follows:
openssl dhparam -out /etc/exim/dh4096.pem 4096
4.10 Other options
The 'openssl' flag '+no_compression' has the effect that labour-intensive (and sometimes insecure) compression of data traffic is disabled. The effect of the flag '+no_session_resumption_on_renegotiation' is that, once a particular cryptographic protocol has been negotiated, the choice cannot be changed midway through the message exchange. Finally, the flag '+cipher_server_preference' has the effect that (from SSL version 3) the SMTP server enforces its own cryptographic algorithm sequence instead of accepting the sequence of algorithms preferred by the remote client.
4.11 Certificate rollover
Of course, when you change your key pair and therefore your certificate, the hash in the TLSA record needs to be changed as well. Consequently, when you make a change, you have to perform a minor rollover, as described in Appendix A.4 to RFC 6698. The new TLSA record has to be published alongside the old one before the certificate is replaced. The new certificate cannot be activated on the server until the TTL has expired and the old TLSA information has been flushed from all DNS caches. If the new certificate is activated too soon, you run the risk that validating clients will not accept it due to a mismatch with the old information. As soon as you've activated the new server certificate, the old TLSA record can be deleted.
4.12 Operational aspects
Our emphasis on cryptographic algorithms and settings is in line with what the NCSC, the Forum for Standardisation and the Platform for Internet Standards recommend: implementation of DANE as soon as possible and in the most secure manner possible, on the basis of the latest technical insights. The drawback of this approach is that, if an older client does not support the latest standards, it will fall back on a completely unencrypted connection because continued mail delivery must be enabled. An alternative school of thought therefore favours the principle that "something is better than nothing". An encrypted connection always offers some degree of protection, even if server authentication isn't performed or if an outdated cryptographic cipher suite is used. That pragmatic interpretation of opportunistic security is described in RFC 7435. According to Viktor Dukhovni, author of RFC 7435 and a strong advocate of STARTTLS and DANE, the client and server will normally select the best possible security protocol for their connection, meaning that there is no need to tweak the cryptographic settings. Outdated and insecure algorithms disappear from the internet organically, as software and hardware are upgraded. Dukhovni takes the view that it's much more important to focus on the operational aspects: using up-to-date software and setting up an effective monitoring system and a smooth rollover process. While we agree on the importance of such operational aspects, they are outside the scope of this article. We also maintain the view that structural support for weak cypher suites is inadvisable. Poorly secured connections provide a misleading semblance of security against active attacks.
Part V — DANE validation
Just as other sending mail servers can check our DANE record and thus validate our certificate (self-signed public TLS key), our server (when acting as a client) can validate other servers' TLS certificates when initiating mail transport.
5.1 DANE validation by Exim
If you want Exim to use TLS (STARTTLS) on an opportunistic basis, you don't need to do anything: When delivering mail, Exim will always begin by trying to set up a STARTTLS session. DANE validation is formally supported by Exim from version 4.91. As explained above, DNSSEC is required for the implementation of DANE. The reason being that, if your DNS records are not signed, there is no cryptographic chain of trust to anchor your TLSA records. It's therefore best to first check whether the general option 'dns_dnssec_ok' is enabled (in the file '/etc/exim/exim.conf'):
# The setting below causes Exim to try to initialize the system resolver # library with DNSSEC support. It has no effect if your library lacks # DNSSEC support.
dns_dnssec_ok = 1
Next, add the modifier 'hosts_try_dane = *' to your 'remote_smtp' transport:
# This transport is used for delivering messages over SMTP connections. # Refuse to send any message with over-long lines, which could have # been received other than via SMTP. The use of message_size_limit to # enforce this is a red herring.
remote_smtp:
driver = smtp
message_size_limit = ${if > {$max_received_linelength}{998} {1}{0}}
hosts_try_dane = *Your connections will then be protected against MITM downgrade attacks as described above. An even higher level of security can be achieved by using the 'hosts_require_dane' modifier, which makes DANE-validated authentication mandatory. No mail is then delivered if the would-be recipient's MX gateway can't be positively validated with DANE. However, use of the 'dane-only' option is impractical for general mail delivery on the internet. Finally, you have the option of using the 'dane_require_tls_ciphers' modifier to separately specify the cipher suites for DANE-validated connections. If no such specification is made, the series listed in 'tls_require_ciphers' will be used.
Make sure that the system running your sending mail server is actually performing DNSSEC validation independently. If your server relies on a validating resolver on a different/external system for validation (utilising AD flag), then the final link in the chain of trust is not cryptographically secured. That unprotected 'last mile', as it is known, makes you vulnerable to downgrade attacks and TLSA certificate falsification by a man in the middle.
Our DANE set-up is now complete! You can test your mail configuration on internet.nl.
6 Conclusion
In combination with the EPEL repository, CentOS version 8.2 provides everything needed to support a fully featured, scalable and secure Exim-based mail infrastructure. As described in an earlier hands-on guide, the implementation of SPF, DKIM and DMARC does nevertheless involve a significant amount of extension and integration work. The implementation of DANE described in this guide is much less involved. In this hands-on guide, we have explained how to realise the comprehensive implementation of the DANE mail security standard. Combining the set-up described with support for IPv6 and SPF/DKIM/DMARC should ensure a 100 per cent score on internet.nl, implying that your mail systems are completely up-to-date and consistent with the latest requirements and guidance of the Forum for Standardisation, the NCSC and others. What's more, domain-level mail security is an important enabler for transitioning from IPv4 to IPv6, because IP address-based filtering isn't possible with IPv6. If and when new DANE functionality for Exim becomes available, we will update this guide accordingly. In the meantime, we're pleased to hear any feedback you may have on this guide.
For anyone who's already using Postfix, there's a companion hands-on guide to the configuration of DANE on that platform.