Support for TLS (Transport Layer Security), formerly known as SSL (Secure Sockets Layer), is implemented by making use of the OpenSSL library or the GnuTLS library (Exim requires GnuTLS release 1.0 or later). There is no cryptographic code in the Exim distribution itself for implementing TLS. In order to use this feature you must install OpenSSL or GnuTLS, and then build a version of Exim that includes TLS support (see section 4.6). You also need to understand the basic concepts of encryption at a managerial level, and in particular, the way that public keys, private keys, and certificates are used.
RFC 2487 defines how SMTP connections can make use of encryption. Once a connection is established, the client issues a STARTTLS command. If the server accepts this, the client and the server negotiate an encryption mechanism. If the negotiation succeeds, the data that subsequently passes between them is encrypted.
Exim's ACLs can detect whether the current SMTP session is encrypted or not, and if so, what cipher suite is in use, whether the client supplied a certificate, and whether or not that certificate was verified. This makes it possible for an Exim server to deny or accept certain commands based on the encryption state.
Warning: certain types of firewall and certain anti-virus products can disrupt TLS connections. You need to turn off SMTP scanning for these products in order to get TLS to work.
Early implementations of encrypted SMTP used a different TCP port from normal SMTP, and expected an encryption negotiation to start immediately, instead of waiting for a STARTTLS command from the client using the standard SMTP port. The protocol was called “ssmtp” or “smtps”, and port 465 was allocated for this purpose.
This approach was abandoned when encrypted SMTP was standardised, but there are still some legacy clients that use it. Exim supports these clients by means of the tls_on_connect_ports global option. Its value must be a list of port numbers; the most common use is expected to be:
tls_on_connect_ports = 465
The port numbers specified by this option apply to all SMTP connections, both via the daemon and via inetd. You still need to specify all the ports that the daemon uses (by setting daemon_smtp_ports or local_interfaces or the -oX command line option) because tls_on_connect_ports does not add an extra port – rather, it specifies different behaviour on a port that is defined elsewhere.
There is also a -tls-on-connect command line option. This overrides tls_on_connect_ports; it forces the legacy behaviour for all ports.
The first TLS support in Exim was implemented using OpenSSL. Support for GnuTLS followed later, when the first versions of GnuTLS were released. To build Exim to use GnuTLS, you need to set
USE_GNUTLS=yes
in Local/Makefile, in addition to
SUPPORT_TLS=yes
You must also set TLS_LIBS and TLS_INCLUDE appropriately, so that the include files and libraries for GnuTLS can be found.
There are some differences in usage when using GnuTLS instead of OpenSSL:
The tls_verify_certificates option must contain the name of a file, not the name of a directory (for OpenSSL it can be either).
The tls_dhparam option is ignored, because early versions of GnuTLS had no facility for varying its Diffie-Hellman parameters. I understand that this has changed, but Exim has not been updated to provide this facility.
GnuTLS uses RSA and D-H parameters that take a substantial amount of time to compute. It is unreasonable to re-compute them for every TLS session. Therefore, Exim keeps this data in a file in its spool directory, called gnutls-params. The file is owned by the Exim user and is readable only by its owner. Every Exim process that start up GnuTLS reads the RSA and D-H parameters from this file. If the file does not exist, the first Exim process that needs it computes the data and writes it to a temporary file which is renamed once it is complete. It does not matter if several Exim processes do this simultaneously (apart from wasting a few resources). Once a file is in place, new Exim processes immediately start using it.
For maximum security, the parameters that are stored in this file should be recalculated periodically, the frequency depending on your paranoia level. Arranging this is easy; just delete the file when you want new values to be computed.
Distinguished Name (DN) strings reported by the OpenSSL library use a slash for separating fields; GnuTLS uses commas, in accordance with RFC 2253. This affects the value of the $tls_peerdn variable.
OpenSSL identifies cipher suites using hyphens as separators, for example: DES-CBC3-SHA. GnuTLS uses underscores, for example: RSA_ARCFOUR_SHA. What is more, OpenSSL complains if underscores are present in a cipher list. To make life simpler, Exim changes underscores to hyhens for OpenSSL and hyphens to underscores for GnuTLS when processing lists of cipher suites in the tls_require_ciphers options (the global option and the smtp transport option).
The tls_require_ciphers options operate differently, as described in the following sections.
There is a function in the OpenSSL library that can be passed a list of cipher suites before the cipher negotiation takes place. This specifies which ciphers are acceptable. The list is colon separated and may contain names like DES-CBC3-SHA. Exim passes the expanded value of tls_require_ciphers directly to this function call. The following quotation from the OpenSSL documentation specifies what forms of item are allowed in the cipher string:
It can consist of a single cipher suite such as RC4-SHA.
It can represent a list of cipher suites containing a certain algorithm, or cipher suites of a certain type. For example SHA1 represents all ciphers suites using the digest algorithm SHA1 and SSLv3 represents all SSL v3 algorithms.
Lists of cipher suites can be combined in a single cipher string using the + character. This is used as a logical and operation. For example SHA1+DES represents all cipher suites containing the SHA1 and the DES algorithms.
Each cipher string can be optionally preceded by the characters !, - or +.
If ! is used then the ciphers are permanently deleted from the list. The ciphers deleted can never reappear in the list even if they are explicitly stated.
If - is used then the ciphers are deleted from the list, but some or all of the ciphers can be added again by later options.
If + is used then the ciphers are moved to the end of the list. This option doesn't add any new ciphers it just moves matching existing ones.
If none of these characters is present then the string is just interpreted as a list of ciphers to be appended to the current preference list. If the list includes any ciphers already present they will be ignored: that is, they will not moved to the end of the list.
The GnuTLS library does not have a combined function like OpenSSL. Instead, it allows the caller to specify separate lists of key-exchange methods, main cipher algorithms, and MAC algorithms. Unfortunately, these lists are numerical, and the library does not have a function for turning names into numbers. Consequently, the list of recognized names has to be built into the application.
At present, Exim permits only the list of main cipher algorithms to be changed. The tls_require_ciphers option is in the same format as for OpenSSL. Exim searches each item for the name of available algorithm. For example, if the list contains RSA_AES_SHA then AES is recognized.
The cipher algorithms list starts out with a default set of algorithms. If the first item in tls_require_ciphers does not start with an exclamation mark, all the default items are deleted. Thus, only those specified can be used. If the first item in tls_require_ciphers does start with an exclamation mark, the defaults are left on the list.
Then, any item that starts with an exclamation mark causes the relevent algorithms to be removed from the list, and any item that does not start with an exclamation mark causes the relevant algorithms to be added to the list. Thus,
tls_require_ciphers = !RSA_ARCFOUR_SHA
allows all the defaults except those that use ARCFOUR, whereas
tls_require_ciphers = AES : 3DES
allows only cipher suites that use AES and 3DES. The currently recognized algorithms are: AES_256, AES_128, AES (both of the preceding), 3DES, and ARCFOUR_128. Unrecognized algorithms are ignored. In a server, the order of the list is unimportant; the server will advertise the availability of all the relevant cipher suites. However, in a client, the order of the list specifies a preference order for the algorithms. The first one in the client's list that is also advertised by the server is tried first. The default order is as listed above.
When Exim has been built with TLS support, it advertises the availability of the STARTTLS command to client hosts that match tls_advertise_hosts, but not to any others. The default value of this option is unset, which means that STARTTLS is not advertised at all. This default is chosen because you need to set some other options in order to make TLS avaliable, and also it is sensible for systems that want to use TLS only as a client.
If a client issues a STARTTLS command and there is some configuration problem in the server, the command is rejected with a 454 error. If the client persists in trying to issue SMTP commands, all except QUIT are rejected with the error
554 Security failure
If a STARTTLS command is issued within an existing TLS session, it is rejected with a 554 error code.
To enable TLS operations on a server, you must set tls_advertise_hosts to match some hosts. You can, of course, set it to * to match all hosts. However, this is not all you need to do. TLS sessions to a server won't work without some further configuration at the server end.
It is rumoured that all existing clients that support TLS/SSL use RSA encryption. To make this work you need to set, in the server,
tls_certificate = /some/file/name tls_privatekey = /some/file/name
The first file contains the server's X509 certificate, and the second contains the private key that goes with it. These files need to be readable by the Exim user, and must always be given as full path names. They can be the same file if both the certificate and the key are contained within it. If tls_privatekey is not set, this is assumed to be the case. The certificate file may also contain intermediate certificates that need to be sent to the client to enable it to authenticate the server's certificate.
If you do not understand about certificates and keys, please try to find a source of this background information, which is not Exim-specific. (There are a few comments below in section 38.10.)
Note: These options do not apply when Exim is operating as a client – they apply only in the case of a server. For a client, you must set the options of the same name in an smtp transport.
With just these options, Exim will work as a server with clients such as Netscape. It does not require the client to have a certificate (but see below for how to insist on this). There is one other option that may be needed in other situations. If
tls_dhparam = /some/file/name
is set, the SSL library is initialized for the use of Diffie-Hellman ciphers with the parameters contained in the file. This increases the set of cipher suites that the server supports. See the command
openssl dhparam
for a way of generating this data. At present, tls_dhparam is used only when Exim is linked with OpenSSL. It is ignored if GnuTLS is being used.
The strings supplied for these three options are expanded every time a client host connects. It is therefore possible to use different certificates and keys for different hosts, if you so wish, by making use of the client's IP address in $sender_host_address to control the expansion. If a string expansion is forced to fail, Exim behaves as if the option is not set.
The variable $tls_cipher is set to the cipher suite that was negotiated for an incoming TLS connection. It is included in the Received: header of an incoming message (by default – you can, of course, change this), and it is also included in the log line that records a message's arrival, keyed by “X=”, unless the tls_cipher log selector is turned off. The encrypted condition can be used to test for specific cipher suites in ACLs.
The ACLs that run for subsequent SMTP commands can check the name of the cipher suite and vary their actions accordingly. The cipher suite names are those used by OpenSSL. These may differ from the names used elsewhere. For example, OpenSSL uses the name DES-CBC3-SHA for the cipher suite which in other contexts is known as TLS_RSA_WITH_3DES_EDE_CBC_SHA. Check the OpenSSL documentation for more details.
If you want an Exim server to request a certificate when negotiating a TLS session with a client, you must set either tls_verify_hosts or tls_try_verify_hosts. You can, of course, set either of them to * to apply to all TLS connections. For any host that matches one of these options, Exim requests a certificate as part of the setup of the TLS session. The contents of the certificate are verified by comparing it with a list of expected certificates. These must be available in a file or, for OpenSSL only (not GnuTLS), a directory, identified by tls_verify_certificates.
A file can contain multiple certificates, concatenated end to end. If a directory is used (OpenSSL only), each certificate must be in a separate file, with a name (or a symbolic link) of the form <hash>.0, where <hash> is a hash value constructed from the certificate. You can compute the relevant hash by running the command
openssl x509 -hash -noout -in /cert/file
where /cert/file contains a single certificate.
The difference between tls_verify_hosts and tls_try_verify_hosts is what happens if the client does not supply a certificate, or if the certificate does not match any of the certificates in the collection named by tls_verify_certificates. If the client matches tls_verify_hosts, the attempt to set up a TLS session is aborted, and the incoming connection is dropped. If the client matches tls_try_verify_hosts, the (encrypted) SMTP session continues. ACLs that run for subsequent SMTP commands can detect the fact that no certificate was verified, and vary their actions accordingly. For example, you can insist on a certificate before accepting a message for relaying, but not when the message is destined for local delivery.
When a client supplies a certificate (whether it verifies or not), the value of the Distinguished Name of the certificate is made available in the variable $tls_peerdn during subsequent processing of the message. Because it is often a long text string, it is not included in the log line or Received: header by default. You can arrange for it to be logged, keyed by “DN=”, by setting the tls_peerdn log selector, and you can use received_header_text to change the Received: header. When no certificate is supplied, $tls_peerdn is empty.
Certificate issuing authorities issue Certificate Revocation Lists (CRLs) when certificates are revoked. If you have such a list, you can pass it to an Exim server using the global option called tls_crl and to an Exim client using an identically named option for the smtp transport. In each case, the value of the option is expanded and must then be the name of a file that contains a CRL in PEM format.
The tls_cipher and tls_peerdn log selectors apply to outgoing SMTP deliveries as well as to incoming, the latter one causing logging of the server certificate's DN. The remaining client configuration for TLS is all within the smtp transport.
It is not necessary to set any options to have TLS work in the smtp transport. If Exim is built with TLS support, and TLS is advertised by a server, the smtp transport always tries to start a TLS session. However, this can be prevented by setting hosts_avoid_tls (an option of the transport) to a list of server hosts for which TLS should not be used.
If you do not want Exim to attempt to send messages unencrypted when an attempt to set up an encrypted connection fails in any way, you can set hosts_require_tls to a list of hosts for which encryption is mandatory. For those hosts, delivery is always deferred if an encrypted connection cannot be set up. If there are any other hosts for the address, they are tried in the usual way.
When the server host is not in hosts_require_tls, Exim may try to deliver the message unencrypted. It always does this if the response to STARTTLS is a 5xx code. For a temporary error code, or for a failure to negotiate a TLS session after a success response code, what happens is controlled by the tls_tempfail_tryclear option of the smtp transport. If it is false, delivery to this host is deferred, and other hosts (if available) are tried. If it is true, Exim attempts to deliver unencrypted after a 4xx response to STARTTLS, and if STARTTLS is accepted, but the subsequent TLS negotiation fails, Exim closes the current connection (because it is in an unknown state), opens a new one to the same host, and then tries the delivery unencrypted.
The tls_certificate and tls_privatekey options of the smtp transport provide the client with a certificate, which is passed to the server if it requests it. If the server is Exim, it will request a certificate only if tls_verify_hosts or tls_try_verify_hosts matches the client. Note: these options must be set in the smtp transport for Exim to use TLS when it is operating as a client. Exim does not assume that a server certificate (set by the global options of the same name) should also be used when operating as a client.
If tls_verify_certificates is set, it must name a file or, for OpenSSL only (not GnuTLS), a directory, that contains a collection of expected server certificates. The client verifies the server's certificate against this collection, taking into account any revoked certificates that are in the list defined by tls_crl.
If tls_require_ciphers is set on the smtp transport, it must contain a list of permitted cipher suites. If either of these checks fails, delivery to the current host is abandoned, and the smtp transport tries to deliver to alternative hosts, if any.
All the TLS options in the smtp transport are expanded before use, with $host and $host_address containing the name and address of the server to which the client is connected. Forced failure of an expansion causes Exim to behave as if the relevant option were unset.
Exim sends multiple messages down the same TCP/IP connection by starting up an entirely new delivery process for each message, passing the socket from one process to the next. This implementation does not fit well with the use of TLS, because there is quite a lot of state information associated with a TLS connection, not just a socket identification. Passing all the state information to a new process is not feasible. Consequently, Exim shuts down an existing TLS session before passing the socket to a new process. The new process may then try to start a new TLS session, and if successful, may try to re-authenticate if AUTH is in use, before sending the next message.
The RFC is not clear as to whether or not an SMTP session continues in clear after TLS has been shut down, or whether TLS may be restarted again later, as just described. However, if the server is Exim, this shutdown and reinitialization works. It is not known which (if any) other servers operate successfully if the client closes a TLS session and continues with unencrypted SMTP, but there are certainly some that do not work. For such servers, Exim should not pass the socket to another process, because the failure of the subsequent attempt to use it would cause Exim to record a temporary host error, and delay other deliveries to that host.
To test for this case, Exim sends an EHLO command to the server after closing down the TLS session. If this fails in any way, the connection is closed instead of being passed to a new delivery process, but no retry information is recorded.
There is also a manual override; you can set hosts_nopass_tls on the smtp transport to match those hosts for which Exim should not pass connections to new processes if TLS has been used.
In order to understand fully how TLS works, you need to know about certificates, certificate signing, and certificate authorities. This is not the place to give a tutorial, especially as I do not know very much about it myself. Some helpful introduction can be found in the FAQ for the SSL addition to Apache, currently at
http://www.modssl.org/docs/2.7/ssl_faq.html#ToC24
Other parts of the modssl documentation are also helpful, and have links to further files. Eric Rescorla's book, SSL and TLS, published by Addison-Wesley (ISBN 0-201-61598-3), contains both introductory and more in-depth descriptions. Some sample programs taken from the book are available from
http://www.rtfm.com/openssl-examples/
The file named by tls_certificate may contain more than one certificate. This is useful in the case where the certificate that is being sent is validated by an intermediate certificate which the other end does not have. Multiple certificates must be in the correct order in the file. First the host's certificate itself, then the first intermediate certificate to validate the issuer of the host certificate, then the next intermediate certificate to validate the issuer of the first intermediate certificate, and so on, until finally (optionally) the root certificate. The root certificate must already be trusted by the recipient for validation to succeed, of course, but if it's not preinstalled, sending the root certificate along with the rest makes it available for the user to install if the receiving end is a client MUA that can interact with a user.
You can create a self-signed certificate using the req command provided with OpenSSL, like this:
openssl req -x509 -newkey rsa:1024 -keyout file1 -out file2 \ -days 9999 -nodes
file1 and file2 can be the same file; the key and the certificate are delimited and so can be identified independently. The -days option specifies a period for which the certificate is valid. The -nodes option is important: if you do not set it, the key is encrypted with a passphrase that you are prompted for, and any use that is made of the key causes more prompting for the passphrase. This is not helpful if you are going to use this certificate and key in an MTA, where prompting is not possible.
A self-signed certificate made in this way is sufficient for testing, and may be adequate for all your requirements if you are mainly interested in encrypting transfers, and not in secure identification.
However, many clients require that the certificate presented by the server be a user (also called “leaf” or “site”) certificate, and not a self-signed certificate. In this situation, the self-signed certificate described above must be installed on the client host as a trusted root certification authority (CA), and the certificate used by Exim must be a user certificate signed with that self-signed certificate.
For information on creating self-signed CA certificates and using them to sign user certificates, see the General implementation overview chapter of the Open-source PKI book, available online at http://ospkibook.sourceforge.net/.