STARTTLS(8)             OpenBSD System Manager's Manual            STARTTLS(8)

NAME
     starttls - ESMTP over TLS

DESCRIPTION
     STARTTLS is an ESMTP option, defined in RFC 2487, which is used to con-
     duct ESMTP transactions over TLS circuits.  This is used to increase the
     security of mail server transactions.  Since version 8.11, sendmail(8)
     has supported the use of TLS to protect ESMTP communications.

     STARTTLS allows for the combination of several security solutions for MTA
     (mail transport agent) level services through the TLS suite.  These secu-
     rity features include:

     Confidentiality
             Encryption is used to protect data from passive monitoring.  An
             attacker would have to recover the encryption key used to decode
             the transmitted data.

     Integrity
             Hash algorithms are used to ensure the integrity of the transmit-
             ted data, and alternatively the timestamp, protecting against a
             replay attack.  This protects data from modification in transit.

     Authentication
             The use of public key encryption allows for the strong authenti-
             cation of either, or both, communicating parties.  This can be
             used to allow for select features, such as relaying, to be con-
             trolled more securely.

     A new ESMTP option, STARTTLS, has been added.  This is presented by the
     server when an ESMTP session is initiated.  The client then begins the
     TLS portion of the ESMTP session by issuing the command ``STARTTLS''. The
     remaining portion of the ESMTP session occurs over a TLS channel.

   Configuring sendmail to utilize TLS
     The global sendmail configuration file, /etc/mail/sendmail.cf, must be
     modified to support TLS functionality.  An example .mc file which has en-
     tries for TLS options, such as certificates, is available as
     /usr/share/sendmail/cf/knecht.mc.

     The pertinent options are:

     o   CERT_DIR

     o   confCACERT_PATH

     o   confCACERT

     o   confSERVER_CERT

     o   confSERVER_KEY

     o   confCLIENT_CERT

     o   confCLIENT_KEY

     By default, the directory /etc/mail/certs, defined in CERT_DIR, is used
     to store certificates, and the server will use the same certificates both
     as a client and as a server (when sending and receiving mail, respective-
     ly, to another MTA).  This can be changed by having different entries for
     the respective roles.

     These certificates can be generated using the openssl(1) utility as de-
     scribed in ssl(8). Make sure to leave the private key files unencrypted,
     using the -nodes option.  Otherwise, sendmail(8) will be unable to initi-
     ate TLS server functions.  Also be sure to name the files as they are de-
     fined in the above macros and store them in PEM format.

     Because the private key files are unencrypted, sendmail(8) is picky about
     using tight permissions on those files.  The certificate directory and
     the files therein should be readable and writable only by the owner
     (root).  A simple way to ensure this is to run the following:

           # chmod -R go-rwx /etc/mail/certs

     Having installed this configuration file and the certificates and
     restarted the sendmail daemon, a new option should be presented for ESMTP
     transactions, STARTTLS.  This can be tested using a mail client which is
     TLS capable, or by using a TLS capable server.

   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 in-
     tegrity checking provided by the cipher suite.  All traffic between the
     two mail servers is encrypted, including the sender and recipient ad-
     dresses.  TLS also allows for authentication of either or both systems in
     the transaction.

     One 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 some mail clients to work using certificate-based
     authentication.  Note that your clients will have to generate certifi-
     cates and have them signed (for trust validation) by a CA (certificate
     authority) you also trust, if you configure your server to do client cer-
     tificate checking.

     The use of the access map (usually /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  contains the status of the level of verification (held in
                   the macro {verify})

           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 granu-
     larity 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.

     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
     One often forgotten limitation of using TLS on a mail server is the pay-
     load of the mail message and the resulting security there.  Many virus
     and worm files are now distributed via electronic mail.  While the mail
     may be encrypted and the servers authenticated, the payload can still be
     malicious.  The use of a good content protection program on the desktop
     is therefore still of value even with TLS at the MTA level.

     Because sendmail with TLS can only authenticate at the server level, true
     end-to-end authentication of the mail message cannot be performed with
     only the use of STARTLS on the server.  The use of S/MIME or PGP e-mail
     and trustworthy key hierarchies can guarantee full confidentiality and
     integrity of the entire message path.

     Furthermore, if a mail message traverses more than just the starting and
     ending servers, there is no way to control interactions between the in-
     tervening mail servers, which may use non-secure connections.  This in-
     troduces a point of vulnerability in the chain.

     Additionally, SMTP over TLS is not yet widely implemented.  The standard,
     in fact, doesn't require it, leaving it only as an option, though specif-
     ic sites can configure their servers to force it for specific clients.
     As such, it is difficult to forsee the widespread use of SMTP using TLS,
     despite the fact that the standard is, at the date of this writing, over
     two years old.

     Lastly, interoperability problems can appear between different implemen-
     tations.

SEE ALSO
     openssl(1), afterboot(8), sendmail(8), ssl(8)

     DARPA Internet Request for Comments RFC2487

     http://www.sendmail.org/

HISTORY
     TLS features first appeared in sendmail 8.11.

                                August 20, 2001                              3
