1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
|
<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>TLS Forward Secrecy in Postfix</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">
TLS Forward Secrecy in Postfix
</h1>
<hr>
<h2> Warning </h2>
<p> Forward secrecy does not protect against active attacks such
as forged DNS replies or forged TLS server certificates. If such
attacks are a concern, then the SMTP client will need to authenticate
the remote SMTP server in a sufficiently-secure manner. For example,
by the fingerprint of a (CA or leaf) public key or certificate.
Conventional PKI relies on many trusted parties and is easily
subverted by a state-funded adversary. </p>
<h2> Overview </h2>
<p> Postfix supports forward secrecy of TLS network communication
since version 2.2. This support was adopted from Lutz Jänicke's
"Postfix TLS patch" for earlier Postfix versions. This document
will focus on TLS Forward Secrecy in the Postfix SMTP client and
server. See <a href="TLS_README.html">TLS_README</a> for a general
description of Postfix TLS support. </p>
<p> Topics covered in this document: </p>
<ul>
<li> <p> Give me some background on forward secrecy in Postfix </p>
<ul>
<li><a href="#dfn_fs">What is Forward Secrecy</a>
<li><a href="#tls_fs">Forward Secrecy in TLS</a>
<li><a href="#server_fs">Forward Secrecy in the Postfix SMTP Server</a>
<li><a href="#client_fs">Forward Secrecy in the Postfix SMTP Client</a>
</ul>
<li> <p> Never mind, just show me what it takes to get forward
secrecy </p>
<ul>
<li><a href="#quick-start">Getting started, quick and dirty</a>
<li><a href="#test">How can I see that a connection has forward secrecy?</a>
<li><a href="#ciphers"> What ciphers provide forward secrecy? </a>
<li><a href="#status"> What do "Anonymous", "Untrusted", etc. in
Postfix logging mean? </a>
</ul>
<li> <p> <a href="#credits"> Credits </a> </p>
</ul>
<h2><a name="dfn_fs">What is Forward Secrecy</a></h2>
<p> The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
is used to describe security protocols in which the confidentiality
of past traffic is not compromised when long-term keys used by either
or both sides are later disclosed. </p>
<p> Forward secrecy is accomplished by negotiating session keys
using per-session cryptographically-strong random numbers that are
not saved, and signing the exchange with long-term authentication
keys. Later disclosure of the long-term keys allows impersonation
of the key holder from that point on, but not recovery of prior
traffic, since with forward secrecy, the discarded random key
agreement inputs are not available to the attacker. </p>
<p> Forward secrecy is only "perfect" when brute-force attacks on
the key agreement algorithm are impractical even for the best-funded
adversary and the random-number generators used by both parties are
sufficiently strong. Otherwise, forward secrecy leaves the attacker
with the challenge of cracking the key-agreement protocol, which
is likely quite computationally intensive, but may be feasible for
sessions of sufficiently high value. Thus forward secrecy places
cost constraints on the efficacy of bulk surveillance, recovering
all past traffic is generally infeasible, and even recovery of
individual sessions may be infeasible given a sufficiently-strong
key agreement method. </p>
<h2><a name="tls_fs">Forward Secrecy in TLS</a></h2>
<p> Early implementations of the SSL protocol do not provide forward
secrecy (some provide it only with artificially-weakened "export"
cipher suites, but we will ignore those here). The client
sends a random "pre-master secret" to the server encrypted with the
server's RSA public key. The server decrypts this with its private
key, and uses it together with other data exchanged in the clear
to generate the session key. An attacker with access to the server's
private key can perform the same computation at any later time.
The TLS library in Windows XP and Windows Server 2003 only supported
cipher suites of this type, and Exchange 2003 servers largely do
not support forward secrecy. </p>
<p> Later revisions to the TLS protocol introduced forward-secrecy
cipher suites in which the client and server implement a key exchange
protocol based on ephemeral secrets. Sessions encrypted with one
of these newer cipher suites are not compromised by future disclosure
of long-term authentication keys. </p>
<p> The key-exchange algorithms used for forward secrecy require
the TLS server to designate appropriate "parameters" consisting of a
mathematical "group" and an element of that group called a "generator".
Presently, there are two flavors of "groups" that work with PFS: </p>
<ul>
<li> <p> <b> Prime-field groups (EDH):</b> The server needs to be
configured with a suitably-large prime and a corresponding "generator".
The acronym for forward secrecy over prime fields is EDH for Ephemeral
Diffie-Hellman (also abbreviated as DHE).
</p>
<li> <p> <b> Elliptic-curve groups (EECDH): </b> The server needs
to be configured with a "named curve". These offer better security
at lower computational cost than prime field groups, but are not
as widely implemented. The acronym for the elliptic curve version
is EECDH which is short for Ephemeral Elliptic Curve Diffie-Hellman
(also abbreviated as ECDHE). </p>
</ul>
<p> It is not essential to know what these are, but one does need
to know that OpenSSL supports EECDH with version 1.0.0 or later.
Thus the configuration parameters related to Elliptic-Curve forward
secrecy are available when Postfix is linked with OpenSSL ≥ 1.0.0
(provided EC support has not been disabled by the vendor, as in
some versions of RedHat Linux). </p>
<p> Elliptic curves used in cryptography are typically identified
by a "name" that stands for a set of well-known parameter values,
and it is these "names" (or associated ASN.1 object identifiers)
that are used in the TLS protocol. On the other hand, with TLS there
are no specially designated prime field groups, so each server is
free to select its own suitably-strong prime and generator. </p>
<h2><a name="server_fs">Forward Secrecy in the Postfix SMTP Server</a></h2>
<p> The Postfix ≥ 2.2 SMTP server supports forward secrecy in
its default configuration. If the remote SMTP client prefers cipher
suites with forward secrecy, then the traffic between the server
and client will resist decryption even if the server's long-term
authentication keys are <i>later</i> compromised. </p>
<p> Some remote SMTP clients may support forward secrecy, but prefer
cipher suites <i>without</i> forward secrecy. In that case, Postfix
≥ 2.8 could be configured to ignore the client's preference with
the main.cf setting "tls_preempt_cipherlist = yes". However, this
will likely cause interoperability issues with older Exchange servers
and is not recommended for now. </p>
<h3> EDH Server support </h3>
<p> Postfix ≥ 2.2 supports 1024-bit-prime EDH out of the box,
with no additional configuration, but you may want to override the
default prime to be 2048 bits long, and you may want to regenerate
your primes periodically. See the <a href="#quick-start">quick-start</a>
section for details. With Postfix ≥ 3.1 the out of the box
(compiled-in) EDH prime size is 2048 bits. </p>
<p> With prime-field EDH, OpenSSL wants the server to provide
two explicitly-selected (prime, generator) combinations. One for
the now long-obsolete "export" cipher suites, and another for
non-export cipher suites. Postfix has two such default combinations
compiled in, but also supports explicitly-configured overrides.
</p>
<ul>
<li> <p> The "export" EDH parameters are used only with the obsolete
"export" ciphers. To use a non-default prime, generate a 512-bit
DH parameter file and set smtpd_tls_dh512_param_file to the filename
(see the <a href="#quick-start">quick-start</a> section for details).
With Postfix releases after the middle of 2015 the default opportunistic
TLS cipher grade (smtpd_tls_ciphers) is "medium" or stronger, and
export ciphers are no longer used. </p>
<li> <p> The non-export EDH parameters are used for all other EDH
cipher suites. To use a non-default prime, generate a 1024-bit or
2048-bit DH parameter file and set smtpd_tls_dh1024_param_file to
the filename. Despite the name this is simply the non-export
parameter file and the prime need not actually be 1024 bits long
(see the <a href="#quick-start">quick-start</a> section for details).
</p>
</ul>
<p> As of mid-2015, SMTP clients are starting to reject TLS
handshakes with primes smaller than 2048 bits. Each site needs to
determine which prime size works best for the majority of its
clients. See the <a href="#quick-start">quick-start</a> section
for the recommended configuration to work around this issue. </p>
<h3> EECDH Server support </h3>
<p> Postfix ≥ 2.6 supports NIST P-256 EECDH when built with OpenSSL
≥ 1.0.0. When the remote SMTP client also supports EECDH and
implements the P-256 curve, forward secrecy just works. </p>
<blockquote> <p> Note: With Postfix 2.6 and 2.7, enable EECDH by
setting the main.cf parameter smtpd_tls_eecdh_grade to "strong".
</p> </blockquote>
<p> The elliptic curve standards are evolving, with new curves
introduced in RFC 8031 to augment or replace the NIST curves tarnished
by the Snowden revelations. Fortunately, TLS clients advertise
their list of supported curves to the server so that servers can
choose newer stronger curves when mutually supported. OpenSSL 1.0.2
released in January 2015 was the first release to implement negotiation
of supported curves in TLS servers. In older OpenSSL releases, the
server is limited to selecting a single widely supported curve. </p>
<p> With Postfix prior to 3.2 or OpenSSL prior to 1.0.2, only a
single server-side curve can be configured, by specifying a suitable
EECDH "grade": </p>
<blockquote>
<pre>
smtpd_tls_eecdh_grade = strong | ultra
# Underlying curves, best not changed:
# tls_eecdh_strong_curve = prime256v1
# tls_eecdh_ultra_curve = secp384r1
</pre>
</blockquote>
<p> Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL
≥ 1.0.2. When using this software combination, the default setting
of "smtpd_tls_eecdh_grade" changes to "auto", which selects a curve
that is supported by both the server and client. The list of
candidate curves can be configured via "tls_eecdh_auto_curves",
which can be used to configure a prioritized list of supported
curves (most preferred first) on both the server and client.
The default list is suitable for most users. </p>
<h2> <a name="client_fs">Forward Secrecy in the Postfix SMTP Client</a> </h2>
<p> The Postfix ≥ 2.2 SMTP client supports forward secrecy in
its default configuration. All supported OpenSSL releases support
EDH key exchange. OpenSSL releases ≥ 1.0.0 also support EECDH
key exchange (provided elliptic-curve support has not been disabled
by the vendor as in some versions of RedHat Linux). If the
remote SMTP server supports cipher suites with forward secrecy (and
does not override the SMTP client's cipher preference), then the
traffic between the server and client will resist decryption even
if the server's long-term authentication keys are <i>later</i>
compromised. </p>
<p> Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL
≥ 1.0.2. The list of candidate curves can be changed via the
"tls_eecdh_auto_curves" configuration parameter, which can be used
to select a prioritized list of supported curves (most preferred
first) on both the Postfix SMTP server and SMTP client. The default
list is suitable for most users. </p>
<p> The default Postfix SMTP client cipher lists are correctly
ordered to prefer EECDH and EDH cipher suites ahead of similar
cipher suites that don't implement forward secrecy. Administrators
are strongly discouraged from changing the cipher list definitions. </p>
<p> The default minimum cipher grade for opportunistic TLS is
"medium" for Postfix releases after the middle of 2015, "export"
for older releases. Changing the minimum cipher grade does not
change the cipher preference order. Note that cipher grades higher
than "medium" exclude Exchange 2003 and likely other MTAs, thus a
"high" cipher grade should be chosen only on a case-by-case basis
via the <a href="TLS_README.html#client_tls_policy">TLS policy</a>
table. </p>
<h2><a name="quick-start">Getting started, quick and dirty</a></h2>
<h3> EECDH Client support (Postfix ≥ 2.2 with OpenSSL ≥ 1.0.0) </h3>
<p> This works "out of the box" with no need for additional
configuration. </p>
<p> Postfix ≥ 3.2 supports the curve negotiation API of OpenSSL
≥ 1.0.2. The list of candidate curves can be changed via the
"tls_eecdh_auto_curves" configuration parameter, which can be used
to select a prioritized list of supported curves (most preferred
first) on both the Postfix SMTP server and SMTP client. The default
list is suitable for most users. </p>
<h3> EECDH Server support (Postfix ≥ 2.6 with OpenSSL ≥ 1.0.0) </h3>
<p> With Postfix 2.6 and 2.7, enable elliptic-curve support in the
Postfix SMTP server. This is the default with Postfix
≥ 2.8. Note, however, that elliptic-curve support may be disabled
by the vendor, as in some versions of RedHat Linux. </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
# Postfix 2.6 & 2.7 only. EECDH is on by default with Postfix ≥ 2.8.
# The default grade is "auto" with Postfix ≥ 3.2.
smtpd_tls_eecdh_grade = strong
</pre>
</blockquote>
<h3> EDH Client support (Postfix ≥ 2.2, all supported OpenSSL
versions) </h3>
<p> This works "out of the box" without additional configuration. </p>
<h3> EDH Server support (Postfix ≥ 2.2, all supported OpenSSL
versions) </h3>
<p> Optionally generate non-default Postfix SMTP server EDH parameters
for improved security against pre-computation attacks and for
compatibility with Debian-patched Exim SMTP clients that require a
≥ 2048-bit length for the non-export prime. </p>
<p> With Postfix ≥ 3.7 built against OpenSSL version is 3.0.0 or later, when
the value of smtpd_tls_dh1024_param_file is either empty or "<b>auto</b>", the
EDH parameter selection is delegated to the OpenSSL library, which selects
appropriate parameters based on the TLS handshake. This choice is likely to be
the most interoperable with SMTP clients using various TLS libraries, and
custom local parameters are no longer recommended when using Postfix ≥ 3.7
built against OpenSSL 3.0.0. Just leave smtpd_tls_dh1024_param_file at its
default value (both in main.cf(5) and any master.cf(5) overrides, and let
OpenSSL do the work. </p>
<p> Otherwise, execute as root (prime group generation can take a
few seconds to a few minutes): </p>
<blockquote>
<pre>
# cd /etc/postfix
# umask 022
# openssl dhparam -out dh512.tmp 512 && mv dh512.tmp dh512.pem
# openssl dhparam -out dh1024.tmp 1024 && mv dh1024.tmp dh1024.pem
# openssl dhparam -out dh2048.tmp 2048 && mv dh2048.tmp dh2048.pem
# chmod 644 dh512.pem dh1024.pem dh2048.pem
</pre>
</blockquote>
<p> The Postfix SMTP server EDH parameter files are not secret,
after all these parameters are sent to all remote SMTP clients in
the clear. Mode 0644 is appropriate. </p>
<p> You can improve security against pre-computation attacks further
by regenerating the Postfix SMTP server EDH parameters periodically
(an hourly or daily cron job running the above commands as root can
automate this task). </p>
<p> Once the parameters are in place, update main.cf as follows: </p>
<blockquote>
<pre>
/etc/postfix/main.cf:
smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem
</pre>
</blockquote>
<p> If some of your MSA clients don't support 2048-bit EDH, you may
need to adjust the submission entry in master.cf accordingly: </p>
<blockquote>
<pre>
/etc/postfix/master.cf:
submission inet n - n - - smtpd
# Some submission clients may not yet do 2048-bit EDH, if such
# clients use your MSA, configure 1024-bit EDH instead. However,
# as of mid-2015, many submission clients no longer accept primes
# with less than 2048-bits. Each site needs to determine which
# type of client is more important to support.
-o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
-o smtpd_tls_security_level=encrypt
-o smtpd_sasl_auth_enable=yes
...
</pre>
</blockquote>
<h2><a name="test">How can I see that a connection has forward
secrecy? </a> </h2>
<p> Postfix can be configured to report information about the
negotiated cipher, the corresponding key lengths, and the remote
peer certificate or public-key verification status. </p>
<ul>
<li> <p> With "smtp_tls_loglevel = 1" and "smtpd_tls_loglevel = 1",
the Postfix SMTP client and server will log TLS connection information
to the maillog file. The general logfile format is shown below.
With TLS 1.3 there may be additional properties logged after the
cipher name and bits. </p>
<blockquote>
<pre>
postfix/smtp[<i>process-id</i>]: Untrusted TLS connection established
to host.example.com[192.168.0.2]:25: TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits)
postfix/smtpd[<i>process-id</i>]: Anonymous TLS connection established
from host.example.com[192.168.0.2]: TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits)
</pre>
</blockquote>
<li> <p> With "smtpd_tls_received_header = yes", the Postfix SMTP
server will record TLS connection information in the Received:
header in the form of comments (text inside parentheses). The general
format depends on the smtpd_tls_ask_ccert setting. With TLS 1.3 there
may be additional properties logged after the cipher name and bits. </p>
<blockquote>
<pre>
Received: from host.example.com (host.example.com [192.168.0.2])
(using TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits))
(Client CN "host.example.com", Issuer "John Doe" (not verified))
Received: from host.example.com (host.example.com [192.168.0.2])
(using TLSv1 with cipher <i>cipher-name</i>
(<i>actual-key-size</i>/<i>raw-key-size</i> bits))
(No client certificate requested)
</pre>
</blockquote>
<p> TLS 1.3 examples. Some of the new attributes may not appear when not
applicable or not available in older versions of the OpenSSL library. </p>
<blockquote>
<pre>
Received: from localhost (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
Received: from localhost (localhost [127.0.0.1])
(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256)
(Client CN "example.org", Issuer "example.org" (not verified))
</pre>
</blockquote>
<ul>
<li> <p> The "key-exchange" attribute records the type of "Diffie-Hellman"
group used for key agreement. Possible values include "DHE", "ECDHE", "X25519"
and "X448". With "DHE", the bit size of the prime will be reported in
parentheses after the algorithm name, with "ECDHE", the curve name. </p>
<li> <p> The "server-signature" attribute shows the public key signature
algorithm used by the server. With "RSA-PSS", the bit size of the modulus will
be reported in parentheses. With "ECDSA", the curve name. If, for example,
the server has both an RSA and an ECDSA private key and certificate, it will be
possible to track which one was used for a given connection. </p>
<li> <p> The new "server-digest" attribute records the digest algorithm used by
the server to prepare handshake messages for signing. The Ed25519 and Ed448
signature algorithms do not make use of such a digest, so no "server-digest"
will be shown for these signature algorithms. </p>
<li> <p> When a client certificate is requested with "smtpd_tls_ask_ccert" and
the client uses a TLS client-certificate, the "client-signature" and
"client-digest" attributes will record the corresponding properties of the
client's TLS handshake signature. </p> </ul>
</ul>
<p> The next sections will explain what <i>cipher-name</i>,
<i>key-size</i>, and peer verification status information to expect.
</p>
<h2><a name="ciphers"> What ciphers provide forward secrecy? </a> </h2>
<p> There are dozens of ciphers that support forward secrecy. What
follows is the beginning of a list of 51 ciphers available with
OpenSSL 1.0.1e. The list is sorted in the default Postfix preference
order. It excludes null ciphers that only authenticate and don't
encrypt, together with export and low-grade ciphers whose encryption
is too weak to offer meaningful secrecy. The first column shows the
cipher name, and the second shows the key exchange method. </p>
<blockquote>
<pre>
$ openssl ciphers -v \
'aNULL:-aNULL:kEECDH:kEDH:+RC4:!eNULL:!EXPORT:!LOW:@STRENGTH' |
awk '{printf "%-32s %s\n", $1, $3}'
AECDH-AES256-SHA Kx=ECDH
ECDHE-RSA-AES256-GCM-SHA384 Kx=ECDH
ECDHE-ECDSA-AES256-GCM-SHA384 Kx=ECDH
ECDHE-RSA-AES256-SHA384 Kx=ECDH
ECDHE-ECDSA-AES256-SHA384 Kx=ECDH
ECDHE-RSA-AES256-SHA Kx=ECDH
ECDHE-ECDSA-AES256-SHA Kx=ECDH
ADH-AES256-GCM-SHA384 Kx=DH
ADH-AES256-SHA256 Kx=DH
ADH-AES256-SHA Kx=DH
ADH-CAMELLIA256-SHA Kx=DH
DHE-DSS-AES256-GCM-SHA384 Kx=DH
DHE-RSA-AES256-GCM-SHA384 Kx=DH
DHE-RSA-AES256-SHA256 Kx=DH
...
</pre>
</blockquote>
<p> To date, all ciphers that support forward secrecy have one of
five values for the first component of their OpenSSL name: "AECDH",
"ECDHE", "ADH", "EDH" or "DHE". Ciphers that don't implement forward
secrecy have names that don't start with one of these prefixes.
This pattern is likely to persist until some new key-exchange
mechanism is invented that also supports forward secrecy. </p>
<p> The actual key length and raw algorithm key length
are generally the same with non-export ciphers, but they may
differ for the legacy export ciphers where the actual key
is artificially shortened. </p>
<p> Starting with TLS 1.3 the cipher name no longer contains enough
information to determine which forward-secrecy scheme was employed,
but TLS 1.3 <b>always</b> uses forward-secrecy. On the client side,
up-to-date Postfix releases log additional information for TLS 1.3
connections, reporting the signature and key exchange algorithms.
Two examples below (the long single line messages are folded across
multiple lines for readability): </p>
<blockquote>
<pre>
postfix/smtp[<i>process-id</i>]:
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
postfix/smtp[<i>process-id</i>]:
Untrusted TLS connection established to 127.0.0.1[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange ECDHE (P-256) server-signature ECDSA (P-256) server-digest SHA256
</pre>
</blockquote>
<p> In the above connections, the "key-exchange" value records the
"Diffie-Hellman" algorithm used for key agreement. The "server-signature" value
records the public key algorithm used by the server to sign the key exchange.
The "server-digest" value records any hash algorithm used to prepare the data
for signing. With "ED25519" and "ED448", no separate hash algorithm is used.
</p>
<p> Examples of Postfix SMTP server logging: </p>
<blockquote>
<pre>
postfix/smtpd[<i>process-id</i>]:
Untrusted TLS connection established from localhost[127.0.0.1]:25:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
postfix/smtpd[<i>process-id</i>]:
Anonymous TLS connection established from localhost[127.0.0.1]:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
server-signature RSA-PSS (2048 bits) server-digest SHA256
postfix/smtpd[<i>process-id</i>]:
Anonymous TLS connection established from localhost[127.0.0.1]:
TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
server-signature ED25519
</pre>
</blockquote>
<p> Note that Postfix ≥ 3.4 server logging may also include a
"to <i>sni-name</i>" element to record the use of an alternate
server certificate chain for the connection in question. This happens
when the client uses the TLS SNI extension, and the server selects
a non-default certificate chain based on the client's SNI value:
</p>
<blockquote>
<pre>
postfix/smtpd[<i>process-id</i>]:
Untrusted TLS connection established from client.example[192.0.2.1]
to server.example: TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256
client-signature ECDSA (P-256) client-digest SHA256
</pre>
</blockquote>
<h2><a name="status"> What do "Anonymous", "Untrusted", etc. in
Postfix logging mean? </a> </h2>
<p> The verification levels below are subject to man-in-the-middle
attacks to different degrees. If such attacks are a concern, then
the SMTP client will need to authenticate the remote SMTP server
in a sufficiently-secure manner. For example, by the fingerprint
of a (CA or leaf) public key or certificate. Remember that
conventional PKI relies on many trusted parties and is easily
subverted by a state-funded adversary. </p>
<dl>
<dt><b>Anonymous</b> (no peer certificate)</dt>
<dd> <p> <b> Postfix SMTP client:</b> With opportunistic TLS (the "may" security level) the Postfix
SMTP client does not verify any information in the peer certificate.
In this case it enables and prefers anonymous cipher suites in which
the remote SMTP server does not present a certificate (these ciphers
offer forward secrecy of necessity). When the remote SMTP server
also supports anonymous TLS, and agrees to such a cipher suite, the
verification status will be logged as "Anonymous". </p> </dd>
<dd> <p> <b> Postfix SMTP server:</b> This is by far most common,
as client certificates are optional, and the Postfix SMTP server
does not request client certificates by default (see smtpd_tls_ask_ccert).
Even when client certificates are requested, the remote SMTP client
might not send a certificate. Unlike the Postfix SMTP client, the
Postfix SMTP server "anonymous" verification status does not imply
that the cipher suite is anonymous, which corresponds to the
<i>server</i> not sending a certificate. </p> </dd>
<dt><b>Untrusted</b> (peer certificate not signed by trusted CA)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server presented
a certificate, but the Postfix SMTP client was unable to check the
issuing CA signature. With opportunistic TLS this is common with
remote SMTP servers that don't support anonymous cipher suites.
</p>
<p> <b> Postfix SMTP server:</b> The remote SMTP client presented
a certificate, but the Postfix SMTP server was unable to check the
issuing CA signature. This can happen when the server is configured
to request client certificates (see smtpd_tls_ask_ccert). </p>
</dd>
<dt><b>Trusted</b> (peer certificate signed by trusted CA, unverified
peer name)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server's certificate
was signed by a CA that the Postfix SMTP client trusts, but either
the client was not configured to verify the destination server name
against the certificate, or the server certificate did not contain
any matching names. This is common with opportunistic TLS
(smtp_tls_security_level is "may" or else "dane" with no usable
TLSA DNS records) when the Postfix SMTP client's trusted CAs can
verify the authenticity of the remote SMTP server's certificate,
but the client is not configured or unable to verify the server
name. </p>
<p> <b> Postfix SMTP server:</b> The remote SMTP client certificate
was signed by a CA that the Postfix SMTP server trusts. The Postfix
SMTP server never verifies the remote SMTP client name against the
names in the client certificate. Since the client chooses to connect
to the server, the Postfix SMTP server has no expectation of a
particular client hostname. </p>
</dd>
<dt><b>Verified</b> (peer certificate signed by trusted CA and
verified peer name; or: peer certificate with expected public-key
or certificate fingerprint)</dt>
<dd>
<p> <b> Postfix SMTP client:</b> The remote SMTP server's certificate
was signed by a CA that the Postfix SMTP client trusts, and the
certificate name matches the destination or server name(s). The
Postfix SMTP client was configured to require a verified name,
otherwise the verification status would have been just "Trusted".
</p>
<p> <b> Postfix SMTP client:</b> The "Verified" status may also
mean that the Postfix SMTP client successfully matched the expected
fingerprint against the remote SMTP server public key or certificate.
The expected fingerprint may come from smtp_tls_policy_maps or from
TLSA (secure) DNS records. The Postfix SMTP client ignores the CA
signature. </p>
<p> <b> Postfix SMTP server:</b> The status is never "Verified",
because the Postfix SMTP server never verifies the remote SMTP
client name against the names in the client certificate, and because
the Postfix SMTP server does not expect a specific fingerprint in
the client public key or certificate. </p>
</dd>
</dl>
<h2><a name="credits">Credits </a> </h2>
<ul>
<li> TLS support for Postfix was originally developed by Lutz
Jänicke at Cottbus Technical University.
<li> Wietse Venema adopted and restructured the code and documentation.
<li> Viktor Dukhovni implemented support for many subsequent TLS
features, including EECDH, and authored the initial version of this
document.
</ul>
</body>
</html>
|
