One of the most common uses of network systems is for e-mail-basedcommunications. As such, a great deal of attention has been given to securing e-mail systems. Howe
ver, most of this focus has been in two areas – security at the message level, using PGP or S/MIME, and confidentiality in the authentication process for mail retrieval, i.e., using APOP or SSL-based IMAP. This still leaves mail server-to-server traversal vulnerable to several attacks.
The introduction of basic cryptography into a mail server-to-server session alleviates most of these risks. Mail transport agents(MTA) and software such as Sendmail or Postfix can be augmented to handle their communications over transaction layer security(TLS) channels. This provides for a number of services, including confidentiality, integrity protection and strong authentication.
This article will introduce the features and use of SMTP over TLS as defined in RFC 2487, as well as illustrate their setup in the Sendmail package. We will cover cryptography basics, though not delve into the mathematics of cryptosystems and simple mail transfer protocol (SMTP) and extended simple mail transfer protocol(ESMTP) basics.
Some Basics of Cryptography
We will outline the basic components of cryptography, which will be useful for understanding the setup and benefits of using TLS in ESMTP transactions. Further information on cryptography is available from the references listed in the Resources section below.
Private key cryptography, or symmetrical cryptography, utilizes a shared secret, the key, for both encryption and decryption of a message. Input data is mathematically processed using the algorithm and the key to produce the ciphertext output, which must be decrypted to be understood by the recipient. Commonly found private key algorithms include DES, Blowfish, AES and IDEA.
Public key algorithms utilize two mathematically related keys to separate the processes of encryption and decryption. By utilizing functions that are easy to perform in one direction, but difficult to do in the reverse, the two keys provide for a high level of security if large enough numbers are used. The relationship between the two keys allows for a variety of appealing functionality, including confidentiality and authentication. Commonly used public key algorithms include RSA, El Gamal and Diffie-Hellman.
Hash algorithms are a set of one-way functions that take a variable length input and, after mathematical processing, produce a fixed length output. The transformations of the data produce a fingerprint of the input, and small changes to the input appear as large scale changes in the output. Popular hash algorithms include SHA-1, MD5 and RIPEMD.
These three components are used by the TLS cryptosystems to provide for a variety of services: integrity checking, authentication and confidentiality. During the establishment of a TLS session, public key cryptography is used to exchange a session key used in a private key algorithm. These public keys can also be used for authentication of the server and, if desired, the client. This is then used to provide session-level encryption and provide confidentiality for the entire session. Lastly, hash algorithms are used for integrity checking to ensure that the data has not been tampered with during transmission. TLS is closely related to SSL, and it is the IETF standards version.
A Brief Introduction to SMTP and ESMTP
SMTP is the basic protocol spoken by Internet e-mail servers. ESMTP is a set of extensions to the protocol to allow for enhanced features, and it is a superset of the SMTP protocol. In their basic form, however, they are fairly similar. At the opening of a session, the greeting determines the session type, SMTP or ESMTP. For an SMTP session, the greeting is HELO (/hostname/), where /(hostname)/ is the name of the client machine connecting. To chose an ESMTP session, enter EHLO (/hostname/), and you are presented with a set of options:
<<< 220 mail.odesk.by ESMTP Sendmail at Tue, 10 May 2013 16:10:36 -0400 >>> EHLO mail <<< 250-mail.odesk.by Hello info@localhost [127.0.0.1], pleased to meet you <<< 250-8BITMIME <<< 250-SIZE 72000000 <<< 250-DSN <<< 250-ONEX <<< 250-XUSR <<< 250 HELP
Unless various ESMTP options are chosen, the MTA then designates the origin of the mail and the recipient (or list of recipients), then begins the data transmission. After completion of the message body delivery, the session is closed. The angled braces indicate the direction of the transmission, either server to client or client to server.
When the MTA supports TLS security, one additional option is presented in the list from the ESMTP notification:/p>
<<< 250-STARTTLS
This is the server’s indication that it is capable of handling TLS sessions. The client then sends the same command, STARTTLS, to the server and the session is negotiated. Secure ESMTP transactions occur over the same channel as normal SMTP connections, port 25/TCP, which means you don’t have to open new holes in your firewall. You can control if connecting MTA systems must, can or must not use STARTTLS in their connections, even down to the specific mail server level.
Secure ESMTP connections utilize TLS almost immediately. After the greeting, when the server presents STARTTLS as an option, the client initiates the TLS setup by issuing the command STARTTLS.
TLS In Sendmail
We will illustrate how to set up a TLS capable SMTP server using Sendmail 8.14. Compiling Sendmail to use TLS security is pretty straight forward. First, make sure that you have OpenSSL installed. We will assume the default installation location, /usr/local/ssl. You should be comfortable with building, configuring and installing Sendmail normally.
The following are additions to the file devtools/OS/Linux:
define(`confSTDIO_TYPE', `portable') APPENDDEF(`conf_sendmail_ENVDEF', `-DSTARTTLS') APPENDDEF(`conf_sendmail_LIBS', `-lssl -lcrypto')
These directives are processed by the Build script to define parameters used in building the Sendmail package. While the Sendmail binary is being built, you should see the -DSTARTTLS directive sent to the compiler.
We also need to edit the configuration file for the build process. The Makefile calls the script devtools/bin/Build, a master configuration and compilation script. We need to teach it where to look for our cryptographic header files and libraries. We will edit these values, which appear near the top:
libdirs="-L/usr/local/ssl/lib" incdirs="-I/usr/local/ssl/include" libsrch="-L/usr/local/ssl/lib" libpath="-L/usr/local/ssl/lib"
At this point you can build the Sendmail package as you would normally. In the top level directory type make. Install it as you would normally.
Configuring the Setup
Sendmail is controlled by a set of configuration files. While they are complex, they are easily set up using the M4 macro scripts, the accompanying .mc files. The following additions to your .mc file (usually found in cf/cf/generic-linux.mc) should get you stated using STARTTLS in the configuration file:
define(`CERT_DIR', `MAIL_SETTINGS_DIR`'certs')dnl define(`confCACERT_PATH', `/etc/mail/certs')dnl define(`confCACERT', `/etc/mail/certs/ca-bundle.pem')dnl define(`confSERVER_CERT', `/etc/mail/certs/sendmail_server_cert.pem')dnl define(`confSERVER_KEY', `/etc/mail/certs/sendmail_server_key.pem')dnl define(`confCLIENT_CERT', `/etc/mail/certs/sendmail_client_cert.pem')dnl define(`confCLIENT_KEY', `/etc/mail/certs/sendmail_client_key.pem')dnl define(`confCRL', `/etc/mail/certs/crl.pem')dnl
You can download list of the CRL from http://www.cacert.org/revoke.crl
We will be using the /etc/mail/certs directory to store our certificates, and the server will use the same certificates both as a client and as a server (when sending and receiving mail, respectively,to another MTA).
Having made these additions, you can restart service to build the new .cf files. Be sure to install this new configuration file.
Key and Certificate Generation
Generating certificates and keys is readily done with OpenSSL accessory programs. We will modify the CA.pl script a bit in two places to prevent our certificates from being DES-encrypted. This new script, which we will call CA1.pl, has the following differences (in “patch” format). Before you will do this, you need install openssl-perl package.
[root@odesk.by mail]# yum install openssl-perl [root@odesk.by mail]# cp -v /etc/pki/tls/misc/CA.pl /etc/pki/tls/misc/CA1.pl `/etc/pki/tls/misc/CA.pl' -> `/etc/pki/tls/misc/CA1.pl' [root@odesk.by mail]#
[root@odesk.by mail]# diff -ur /etc/pki/tls/misc/CA.pl /etc/pki/tls/misc/CA1.pl
--- /etc/pki/tls/misc/CA.pl 2013-03-05 08:21:52.000000000 +1000
+++ /etc/pki/tls/misc/CA1.pl 2013-09-23 07:50:57.904166350 +1000
@@ -68,12 +68,12 @@
exit 0;
} elsif (/^-newcert$/) {
# create a certificate
- system ("$REQ -new -x509 -keyout newkey.pem -out newcert.pem $DAYS");
+ system ("$REQ -new -x509 -nodes -keyout newkey.pem -out newcert.pem $DAYS");
$RET=$?;
print "Certificate is in newcert.pem, private key is in newkey.pem\n"
} elsif (/^-newreq$/) {
# create a certificate request
- system ("$REQ -new -keyout newkey.pem -out newreq.pem $DAYS");
+ system ("$REQ -new -nodes -keyout newkey.pem -out newreq.pem $DAYS");
$RET=$?;
print "Request is in newreq.pem, private key is in newkey.pem\n";
} elsif (/^-newreq-nodes$/) {
[root@odesk.by mail]#
The -nodes option to the certificate generation is the change, otherwise Sendmail will complain it cannot load the (encrypted) key at startup:
Now we will begin the generation of our own certificate authority (CA), generate a client certificate and use this CA to sign it.
[root@websemble misc]# cd /etc/pki/tls/misc/
[root@websemble misc]# ./CA1.pl -newca
CA certificate filename (or enter to create)
Making CA certificate ...
Generating a 2048 bit RSA private key
....................................+++
..........+++
writing new private key to '/etc/pki/CA/private/cakey.pem'
Enter PEM pass phrase:
Verifying - Enter PEM pass phrase:
-----
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]:BY
State or Province Name (full name) []:QLD
Locality Name (eg, city) [Default City]:QLD
Organization Name (eg, company) [Default Company Ltd]:
Organizational Unit Name (eg, section) []:
Common Name (eg, your name or your server's hostname) []:odesk.by
Email Address []:postmaster@odesk.by
Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
b4:ff:ed:75:ae:91:3b:78
Validity
Not Before: Sep 22 22:17:21 2013 GMT
Not After : Sep 21 22:17:21 2016 GMT
Subject:
countryName = AU
stateOrProvinceName = QLD
organizationName = Default Company Ltd
commonName = odesk.by
emailAddress = postmaster@odesk.by
X509v3 extensions:
X509v3 Subject Key Identifier:
DE:2F:E5:43:05:E5:00:50:56:F8:FE:1C:50:28:5D:B9:6E:CF:90:59
X509v3 Authority Key Identifier:
keyid:DE:2F:E5:43:05:E5:00:50:56:F8:FE:1C:50:28:5D:B9:6E:CF:90:59
X509v3 Basic Constraints:
CA:TRUE
Certificate is to be certified until Sep 21 22:17:21 2016 GMT (1095 days)
Write out database with 1 new entries
Data Base Updated
[root@odesk.by misc]#
Answer the questions presented to you, such as your organization, your location and your name. Choose a decent passphrase for the CA certificate so no one can abuse your CA and sign any certificate. Copy the CA file, which is in /etc/pki/CA/cacert.pem, to /etc/mail/certs/ca-bundle.pem, as we have it configured in the above Sendmail configuration file:
[root@odesk.by misc]# cp -av /etc/pki/CA/cacert.pem /etc/mail/certs/ca-bundle.pem `/etc/pki/CA/cacert.pem' -> `/etc/mail/certs/ca-bundle.pem' [root@odesk.by misc]#
Now we generate the server’s private key, which we will want signed by this CA:
[root@odesk.by misc]# ./CA1.pl -newreq Generating a 2048 bit RSA private key .............................................................+++ ...................+++ writing new private key to 'newkey.pem' ----- 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]:BY State or Province Name (full name) []:QLD Locality Name (eg, city) [Default City]:QLD Organization Name (eg, company) [Default Company Ltd]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:odesk.by Email Address []:postmaster@odesk.by Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: Request is in newreq.pem, private key is in newkey.pem [root@odesk.by misc]#
This will generate a private key and certificate request that we want our CA to sign (ourselves really). This is a more sane and flexible method to use when compared to self-signed certificates. We can recycle the CA for other certificates and not have to install multiple CAs, only one for each group. The private key will be in the file newkey.pem. Copy this file to /etc/mail/certs/sendmail_server_key.pem, based on the naming scheme we used above in our .mc configuration:
[root@odesk.by misc]# cp -av newkey.pem /etc/mail/certs/sendmail_server_key.pem `newkey.pem' -> `/etc/mail/certs/sendmail_server_key.pem' [root@odesk.by misc]#
Then we use our CA certificate to sign this request:
[root@odesk.by misc]# ./CA1.pl -sign
Using configuration from /etc/pki/tls/openssl.cnf
Enter pass phrase for /etc/pki/CA/private/cakey.pem:
Check that the request matches the signature
Signature ok
Certificate Details:
Serial Number:
b4:ff:ed:75:ae:91:3b:79
Validity
Not Before: Sep 22 22:35:38 2013 GMT
Not After : Sep 22 22:35:38 2014 GMT
Subject:
countryName = AU
stateOrProvinceName = QLD
localityName = QLD
organizationName = Default Company Ltd
commonName = websemble.com
emailAddress = postmaster@websemble.com
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
OpenSSL Generated Certificate
X509v3 Subject Key Identifier:
FA:78:D8:18:56:AF:68:D4:05:3E:E2:F0:12:A5:B4:BC:ED:C7:8A:38
X509v3 Authority Key Identifier:
keyid:DE:2F:E5:43:05:E5:00:50:56:F8:FE:1C:50:28:5D:B9:6E:CF:90:59
Certificate is to be certified until Sep 22 22:35:38 2014 GMT (365 days)
Sign the certificate? [y/n]:y
1 out of 1 certificate requests certified, commit? [y/n]y
Write out database with 1 new entries
Data Base Updated
Signed certificate is in newcert.pem
[root@odesk.by misc]#
This will generate the third component of our server’s configuration, the signed public certificate. This will be in the file newcert.pem, which we copy to /etc/mail/certs/sendmail_server_cert.pem.
[root@odesk.by misc]# cp -av newcert.pem /etc/mail/certs/sendmail_server_cert.pem `newcert.pem' -> `/etc/mail/certs/sendmail_server_cert.pem' [root@odesk.by misc]#
Sendmail is, understandably, quite picky about using tight permissions on those files, so remove group and world readability for them:
chmod -R go-rwx /etc/mail/certs
The private keys and the CA file amount to the keys to our cryptographic kingdom, and we don’t want just anyone being able to see them.
Testing Your Installation
To test the installation, restart Sendmail and begin a manual ESMTP session to the server:
[root@odesk.by misc]# telnet localhost 25 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 odesk.by ESMTP Sendmail Mon, 23 Sep 2013 08:49:20 +1000 ehlo localhost 250-odesk.by Hello localhost [127.0.0.1], pleased to meet you 250-ENHANCEDSTATUSCODES 250-PIPELINING 250-8BITMIME 250-SIZE 52428800 250-DSN 250-ETRN 250-AUTH DIGEST-MD5 CRAM-MD5 LOGIN PLAIN 250-STARTTLS 250-DELIVERBY 250 HELP quit 221 2.0.0 odesk.by closing connection Connection closed by foreign host. [root@odesk.by misc]#
While you could, at this time, issue the command *STARTTLS*, and the server would respond with a reply like 220 2.0.0 Ready to start TLS, you probably could not negotiate a secure connection by hand. A simple test to perform is to point an SSL-compatible e-mail client, such as the Mozilla Thunderbird mail client, at this new Sendmail server. Chose to attempt a secure connection if possible and send a mail message through this server. After accepting the new site certificate, a log line like the following should appear in your Sendmail logs:
Sep 23 08:59:39 odesk.by sendmail[15241]: STARTTLS=server, get_verify: 0 get_peer: 0x0 Sep 23 08:59:39 odesk.by sendmail[15241]: STARTTLS=server, ....
This tells you that the server is capable of negotiating a TLS session with a client, indicating a successful installation.
Uses for TLS-Equipped Sendmail
The most obvious use of a cryptographically enabled Sendmail installation is for confidentiality of the electronic mail transaction and the integrity checking provided by the cipher suite. Everything between the two mail servers is encrypted, including the sender and recipient addresses. TLS also allows for authentication of either or both systems in the transaction.
One excellent use of public key cryptography is for strong authentication. We can use this authentication to selectively relay clients, including other mail servers and mobile clients like laptops. However, there have been some problems getting the Outlook mail client working using certificate-based authentication. Note that your clients will have to generate certificates and have them signed (for trust validation) by a CA you also trust, if you configure your server to do client certificate checking.
The use of the access map (usually held in /etc/mail/access), which is normally used to determine connections and relaying, can also be extended to give server level control for the use of TLS. Two new entries are available for TLS options: VERIFY, which contains the status of the level of verification (held in the macro {verify}; and ENCR, the strength of the encryption in the macro {cipher_bits}. VERIFY can also accept the argument for {cipher_bits}. Here are a few example entries that illustrate these features, and the role based granularity as well:
Force strong (112 bit) encryption for communications for this server:
server1.example.net ENCR:112
For a TLS client, force string verification depths to at least 80 bits:
TLS_Clt:desktop.example:net VERIFY:80
Much more complicated access maps are possible, and error conditions (such as permanent or temporary, PERM+ or TEMP+) can be set on the basis of various criteria. This allows you fine-grained control over the types of connections you can allow. Documentation is emerging for these features, and the newsgroup comp.mail.sendmail is also a great place to get questions answered.
Note that it is unwise to force all SMTP clients to use TLS, as it is not yet widespread. The RFC document notes that publicly referenced SMTP servers, such as the MX servers for a domain, must not refuse non-TLS connections. However, restricted access SMTP servers, such as those for a corporate intranet, can use TLS as an access control mechanism.
Limitations of Sendmail with TLS
While all of this work may seem to be a total security solution for e-mail, it cannot totally secure your e-mail system. One often forgotten limitation of using TLS on your mail servers is the payload of the mail message and the resulting security there. Many virus and worm files are now distributed using electronic mail. While the mail maybe encrypted and the servers authenticated, the payload will still be malicious. Using a good content protection program on the desktop will be of great value even with TLS at the MTA level.
Because Sendmail with TLS only can authenticate at the server level, true end-to-end authentication of the mail message cannot be performed with only the use of Sendmail Secure Switch. By including the use of S/MIME or PGP e-mail and trustworthy key hierarchies, full confidentiality and integrity can be accomplished from end-to-end of the mail message path.
Furthermore, if a mail message traverses more than the starting and ending servers, there is no way to control interactions between the additional mail servers, which may use non-secure connections. This introduces a point of vulnerability in the chain.
Additionally, SMTP over TLS is not yet widely implemented. The standard, in fact, doesn’t force it, leaving it only as an option, though specific sites can configure their servers to force it for specific clients. As such, it is difficult to see the widespread use of SMTP using TLS, despite the fact that the standard is over two years old.
Resources
RFC 2487, “SMTP Service Extension for Secure SMTP over TLS”
RFC 1869, “SMTP Service Extensions”
RFC 2246, “The TLS Protocol Version 1.0”
See IETF for RFC documents.
Sendmail,source and documentation
Sendmail Secure Switch, commercial version
SSL and TLS Essentials by Stephen Thomas