xref: /openbsd/share/man/man8/starttls.8 (revision d415bd75)
1.\" $OpenBSD: starttls.8,v 1.28 2022/03/31 17:27:23 naddy Exp $
2.\"
3.\" Copyright (c) 2001 Jose Nazario <jose@monkey.org>
4.\" All rights reserved.
5.\"
6.\" Redistribution and use in source and binary forms, with or without
7.\" modification, are permitted provided that the following conditions
8.\" are met:
9.\" 1. Redistributions of source code must retain the above copyright
10.\"    notice, this list of conditions and the following disclaimer.
11.\" 2. Redistributions in binary form must reproduce the above copyright
12.\"    notice, this list of conditions and the following disclaimer in the
13.\"    documentation and/or other materials provided with the distribution.
14.\"
15.\" THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES,
16.\" INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY
17.\" AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL
18.\" THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
19.\" EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
20.\" PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS;
21.\" OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
22.\" WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
23.\" OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF
24.\" ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
25.\"
26.Dd $Mdocdate: March 31 2022 $
27.Dt STARTTLS 8
28.Os
29.Sh NAME
30.Nm starttls
31.Nd ESMTP over TLS/SSL
32.Sh DESCRIPTION
33STARTTLS is an ESMTP option, defined in RFC 3207, which is used to conduct
34ESMTP transactions over TLS circuits.
35This is used to increase the security of mail server transactions.
36.Pp
37STARTTLS allows for the combination of several security solutions for MTA
38(mail transport agent) level services through the TLS suite.
39These security features include:
40.Bl -tag -width Ds
41.It Confidentiality
42Encryption is used to protect data from passive monitoring.
43An attacker would have to recover the encryption key used to
44decode the transmitted data.
45.It Integrity
46Hash algorithms are used to ensure the integrity of the
47transmitted data, and alternatively the timestamp, protecting against a
48replay attack.
49This protects data from modification in transit.
50.It Authentication
51The use of public key encryption allows for the strong authentication of
52either, or both, communicating parties.
53This can be used to allow for select features, such as relaying,
54to be controlled more securely.
55.El
56.Pp
57A new ESMTP option, STARTTLS, has been added.
58This is presented by the server when an ESMTP session is initiated.
59The client then begins the TLS portion of the ESMTP session by issuing
60the command
61.Dq STARTTLS .
62The remaining portion of the ESMTP session occurs over a TLS channel.
63.Ss Creating a private key and certificate for an MTA
64This example assumes you are creating your own self-signed certificates
65for use with
66.Xr smtpd 8
67and STARTTLS.
68If you have an existing private key and you simply wish to generate
69a new certificate (for example, if your old certificate has expired),
70see the section entitled
71.Sx Creating a certificate with an existing private key .
72.Pp
73For the purposes of this example the certificates will be stored in
74.Pa /etc/ssl ,
75though it is possible to use a different directory if needed.
76.Pp
77Next, you must generate an
78.Ar RSA
79private key:
80.Pp
81.Dl # openssl genrsa -out /etc/ssl/private/mail.example.com.key 4096
82.Pp
83This would generate a 4096-bit
84.Ar RSA
85key stored in the file
86.Pa mail.example.com.key .
87.Pp
88Once you have generated the
89.Ar RSA
90key, you can generate a certificate from it using the command:
91.Bd -literal -offset indent
92# openssl req -x509 -new -key /etc/ssl/private/mail.example.com.key \e
93  -out /etc/ssl/mail.example.com.crt -days 365
94.Ed
95.Pp
96You may adjust the lifetime of the certificate via the
97.Fl days
98parameter (one year in this example).
99.Pp
100You can verify that the newly-generated certificate has correct information
101with the following command:
102.Pp
103.Dl # openssl x509 -in /etc/ssl/mail.example.com.crt -text
104.Pp
105Because the private key files are unencrypted,
106MTAs can be picky about using tight permissions on those files.
107The certificate directory and the files therein should be
108readable and writable only by the owner (root).
109A simple way to ensure this is to run the following:
110.Pp
111.Dl # chmod -R go-rwx /etc/ssl/private
112.Ss Creating a certificate with an existing private key
113This example assumes you already have an existing private key,
114.Pa /etc/ssl/private/mail.example.com.key .
115You can generate a new certificate based on this key using the command:
116.Bd -literal -offset indent
117# openssl req -x509 -new -key /etc/ssl/private/mail.example.com.key \e
118  -out /etc/ssl/mail.example.com.crt -days 365
119# chmod 600 /etc/ssl/mail.example.com.crt
120.Ed
121.Pp
122You may adjust the lifetime of the certificate via the
123.Fl days
124parameter (one year in this example).
125.Pp
126After having installed the certificates,
127the mail server needs to be configured to accept TLS sessions
128and use the key and certificate.
129For
130.Xr smtpd 8 ,
131it's as simple as adding pki configuration to
132.Xr smtpd.conf 5 :
133.Bd -literal -offset indent
134pki mail.example.com cert "/etc/ssl/mail.example.com.crt"
135pki mail.example.com key "/etc/ssl/private/mail.example.com.key"
136
137listen on [...] tls pki mail.example.com auth
138.Ed
139.Pp
140After restarting the mail server, a new option should be presented for ESMTP
141transactions, STARTTLS.
142You can test this by connecting to the local host and issuing the
143.Dq EHLO
144command.
145.Bd -literal -offset indent
146# telnet localhost 25
147Trying 127.0.0.1...
148Connected to localhost.
149Escape character is '^]'.
150220 localhost ESMTP OpenSMTPD
151EHLO localhost
152.Ed
153.Pp
154After typing
155.Em EHLO localhost ,
156you should receive something like the following back.
157.Bd -literal -offset indent
158250-localhost Hello localhost [127.0.0.1], pleased to meet you
159250-8BITMIME
160250-ENHANCEDSTATUSCODES
161250-SIZE 36700160
162250-DSN
163250-STARTTLS
164250 HELP
165.Ed
166.Pp
167You should see
168.Dq STARTTLS
169listed along with the other options.
170If so, congratulations, the MTA will now use TLS to encrypt your mail
171traffic when the remote server supports it.
172If not, check
173.Pa /var/log/maillog
174to see whether the MTA has reported any security problems or other errors.
175.Ss Uses for TLS equipped MTAs
176The most obvious use of a cryptographically enabled MTA
177is for confidentiality of the electronic mail transaction and the
178integrity checking provided by the cipher suite.
179All traffic between the two mail servers is encrypted, including the
180sender and recipient addresses.
181TLS also allows for authentication of either or both systems in the transaction.
182.Pp
183One use of public key cryptography is for strong authentication.
184We can use this authentication to selectively relay clients, including
185other mail servers and mobile clients like laptops.
186However, there have been some problems getting some mail clients to work using
187certificate-based authentication.
188Clients will have to generate certificates and have them
189signed (for trust validation) by a trusted CA (certificate authority).
190.Pp
191Note that it is unwise to force all SMTP clients to use TLS, as it is not
192yet widespread.
193The RFC document notes that publicly referenced SMTP servers, such as the
194MX servers for a domain, must not refuse non-TLS connections.
195However, restricted access SMTP servers, such as those for a corporate
196intranet, can use TLS as an access control mechanism.
197.Sh SEE ALSO
198.Xr mail 1 ,
199.Xr openssl 1 ,
200.Xr smtpd 8 ,
201.Xr ssl 8
202.Sh STANDARDS
203.Rs
204.%A P. Hoffman
205.%D February 2002
206.%R RFC 3207
207.%T SMTP Service Extension for Secure SMTP over Transport Layer Security
208.Re
209.Sh CAVEATS
210One often forgotten limitation of using TLS on a mail server is the
211payload of the mail message and the resulting security there.
212Many virus and worm files are now distributed via electronic mail.
213While the mail may be encrypted and the servers authenticated, the payload
214can still be malicious.
215The use of a good content protection program on the desktop is
216therefore still of value even with TLS at the MTA level.
217.Pp
218Because TLS can only authenticate at the server level, true
219end-to-end authentication of the mail message cannot be performed with
220only the use of STARTTLS on the server.
221The use of S/MIME or PGP email and trustworthy key hierarchies can guarantee
222full confidentiality and integrity of the entire message path.
223.Pp
224Furthermore, if a mail message traverses more than just the starting and
225ending servers, there is no way to control interactions between the intervening
226mail servers, which may use non-secure connections.
227This introduces a point of vulnerability in the chain.
228.Pp
229Additionally, SMTP over TLS is not yet widely implemented.
230The standard, in fact, doesn't require it, leaving it only as an option, though
231specific sites can configure their servers to force it for specific clients.
232As such, it is difficult to foresee the widespread use of SMTP using TLS,
233despite the fact that the standard is, at the date of this writing,
234over two years old.
235.Pp
236Lastly, interoperability problems can appear between different implementations.
237