summaryrefslogtreecommitdiffstats
path: root/html/FORWARD_SECRECY_README.html
diff options
context:
space:
mode:
Diffstat (limited to 'html/FORWARD_SECRECY_README.html')
-rw-r--r--html/FORWARD_SECRECY_README.html614
1 files changed, 614 insertions, 0 deletions
diff --git a/html/FORWARD_SECRECY_README.html b/html/FORWARD_SECRECY_README.html
new file mode 100644
index 0000000..98f9f97
--- /dev/null
+++ b/html/FORWARD_SECRECY_README.html
@@ -0,0 +1,614 @@
+<!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">
+<link rel='stylesheet' type='text/css' href='postfix-doc.css'>
+
+</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&auml;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. </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>FFDHE:</b> Finite-field Diffie-Hellman ephemeral key
+exchange groups (also EDH or DHE). The server needs to be configured
+with a suitably-large prime and a corresponding "generator". Standard
+choices of the prime and generator are specified in <a href="https://tools.ietf.org/html/rfc7919">RFC7919</a>, and can be
+used in the TLS 1.3 protocol with the server and client negotiating a
+mutually supported choice. In earlier versions of TLS (1.0 through
+1.2), when FFDHE key exchange is performed, the server chooses the prime
+and generator unilaterally. </p>
+
+<li> <p> <b>EECDH:</b> This is short for Ephemeral Elliptic Curve
+Diffie-Hellman (also abbreviated as ECDHE). EECDH offers better
+security at lower computational cost than FFDHE. 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 "named curves" (or,
+in certificates, associated ASN.1 object identifiers) that are used in
+the TLS protocol. When EECDH key exchange is used, a mutually supported
+named curve is negotiated as part of the TLS handshake. </p>
+
+</ul>
+
+<h2><a name="server_fs">Forward Secrecy in the Postfix SMTP Server</a></h2>
+
+<p> The Postfix &ge; 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> Most remote SMTP clients now support forward secrecy (the only
+choice as of TLS 1.3), but some may prefer cipher suites <i>without</i>
+forward secrecy. Postfix &ge; 2.8 servers can be configured to override
+the client's preference by setting "<a href="postconf.5.html#tls_preempt_cipherlist">tls_preempt_cipherlist</a> = yes". </p>
+
+<h3> FFDHE Server support </h3>
+
+<p> Postfix &ge; 3.1 supports 2048-bit-prime FFDHE out of the box, with
+no additional configuration. You can also generate your own FFDHE
+parameters, but this is not necessary and no longer recommended. See
+the <a href="#quick-start">quick-start</a> section for details. </p>
+
+<p> Postfix &ge; 3.8 supports the finite-field Diffie-Hellman ephemeral
+(FFDHE) key exchange group negotiation API of OpenSSL &ge; 3.0. FFDHE
+groups are explicitly negotiated between client and server starting with
+TLS 1.3. In earlier TLS versions, the server chooses the group
+unilaterally. The list of candidate FFDHE groups can be configured via
+"<a href="postconf.5.html#tls_ffdhe_auto_groups">tls_ffdhe_auto_groups</a>", which can be used to select a prioritized list
+of supported groups (most preferred first) on both the server and
+client. The default list is suitable for most users. Either, but not
+both of "<a href="postconf.5.html#tls_eecdh_auto_curves">tls_eecdh_auto_curves</a>" and "<a href="postconf.5.html#tls_ffdhe_auto_groups">tls_ffdhe_auto_groups</a>" may be set
+empty, disabling either EC or FFDHE key exchange in OpenSSL 3.0 with TLS
+1.3. That said, interoperability will be poor if the EC curves are
+all disabled or don't include the most widely used curves. </p>
+
+<h3> EECDH Server support </h3>
+
+<p> As of Postfix 3.2 and OpenSSL 1.0.2, a range of supported EECDH
+curves is enabled in the server and client, and a suitable mutually
+supported curve is negotiated as part of the TLS handshake. The list of
+supported curves is configurable via the "<a href="postconf.5.html#tls_eecdh_auto_curves">tls_eecdh_auto_curves</a>"
+parameter. With TLS 1.2 the server needs to leave its setting of
+"<a href="postconf.5.html#smtpd_tls_eecdh_grade">smtpd_tls_eecdh_grade</a>" at the default value of "auto" (earlier choices
+of an explicit single curve grade are deprecated). With TLS 1.3, the
+"<a href="postconf.5.html#smtpd_tls_eecdh_grade">smtpd_tls_eecdh_grade</a>" parameter is not used, and curve selection is
+unconditionally negotiated. </p>
+
+<h2> <a name="client_fs">Forward Secrecy in the Postfix SMTP Client</a> </h2>
+
+<p> The Postfix &ge; 2.2 SMTP client supports forward secrecy in its
+default configuration. All supported OpenSSL releases support both
+FFDHE and EECDH key exchange. 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. Forward secrecy is always on in TLS 1.3. </p>
+
+<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
+&ge; 1.0.2. The list of candidate curves can be changed via the
+"<a href="postconf.5.html#tls_eecdh_auto_curves">tls_eecdh_auto_curves</a>" 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> Postfix &ge; 3.8 supports the finite-field Diffie-Hellman ephemeral
+(FFDHE) key exchange group negotiation API of OpenSSL &ge; 3.0.
+The list of candidate FFDHE groups can be configured via
+"<a href="postconf.5.html#tls_ffdhe_auto_groups">tls_ffdhe_auto_groups</a>", which can be used to select a prioritized list
+of supported groups (most preferred first) on both the server and
+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 FFDHE cipher suites ahead of similar cipher suites
+that don't implement forward secrecy. Administrators are strongly
+discouraged from changing the cipher list definitions. </p>
+
+<h2><a name="quick-start">Getting started, quick and dirty</a></h2>
+
+<h3> EECDH Client support (Postfix &ge; 3.2 with OpenSSL &ge; 1.1.1) </h3>
+
+<p> This works "out of the box" with no need for additional
+configuration. </p>
+
+<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
+&ge; 1.0.2. The list of candidate curves can be changed via the
+"<a href="postconf.5.html#tls_eecdh_auto_curves">tls_eecdh_auto_curves</a>" 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 &ge; 3.2 with OpenSSL &ge; 1.1.1) </h3>
+
+<p> This works "out of the box" with no need for additional
+configuration. </p>
+
+<p> Postfix &ge; 3.2 supports the curve negotiation API of OpenSSL
+&ge; 1.0.2. The list of candidate curves can be changed via the
+"<a href="postconf.5.html#tls_eecdh_auto_curves">tls_eecdh_auto_curves</a>" 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> FFDHE Client support (Postfix &ge; 3.2, OpenSSL &ge; 1.1.1) </h3>
+
+<p> In Postfix &lt; 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or
+below works "out of the box", no additional configuration is necessary.
+The most one can do is (not advisable) disable all "kDHE" ciphers, which
+would then disable FFDHE key exchange in TLS 1.2 and below. </p>
+
+<p> With OpenSSL 1.1.1, FFDHE is not supported for TLS 1.3, which uses
+only EECDH key exchange. Support for FFDHE with TLS 1.3 was added in
+OpenSSL 3.0. With OpenSSL 3.0 and Postfix 3.8 the list of supported TLS
+1.3 FFDHE groups becomes configurable via the "<a href="postconf.5.html#tls_ffdhe_auto_groups">tls_ffdhe_auto_groups</a>"
+parameter, which can be set empty to disable FFDHE in TLS 1.3, or
+conversely expanded to support more groups. The default should work
+well for most users. </p>
+
+<h3> FFDHE Server support (Postfix &ge; 2.2, all supported OpenSSL
+versions) </h3>
+
+<p> In Postfix &lt; 3.8, or OpenSSL prior to 3.0, FFDHE for TLS 1.2 or
+below works "out of the box", no additional configuration is necessary.
+One can of course (not advisable) disable all "kDHE" ciphers, which
+would then disable FFDHE key exchange in TLS 1.2 and below. </p>
+
+<p> The built-in default Postfix FFDHE group is a 2048-bit group as of
+Postfix 3.1. You can optionally generate non-default Postfix SMTP
+server FFDHE parameters for possibly improved security against
+pre-computation attacks, but this is not necessary or recommended. Just
+leave "<a href="postconf.5.html#smtpd_tls_dh1024_param_file">smtpd_tls_dh1024_param_file</a>" at its default empty value. </p>
+
+<p> The set of FFDHE groups enabled for use with TLS 1.3 becomes
+configurable with Postfix &ge; 3.8 and OpenSSL &ge; 3.0. The default
+setting of "<a href="postconf.5.html#tls_ffdhe_auto_groups">tls_ffdhe_auto_groups</a>" enables the <a href="https://tools.ietf.org/html/rfc7919">RFC7919</a> 2048 and 3072-bit
+groups. If you need more security, you should probably be using EECDH.
+</p>
+
+<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 "<a href="postconf.5.html#smtp_tls_loglevel">smtp_tls_loglevel</a> = 1" and "<a href="postconf.5.html#smtpd_tls_loglevel">smtpd_tls_loglevel</a> = 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 "<a href="postconf.5.html#smtpd_tls_received_header">smtpd_tls_received_header</a> = 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 <a href="postconf.5.html#smtpd_tls_ask_ccert">smtpd_tls_ask_ccert</a> 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 "<a href="postconf.5.html#smtpd_tls_ask_ccert">smtpd_tls_ask_ccert</a>" 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 &ge; 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 <a href="postconf.5.html#smtpd_tls_ask_ccert">smtpd_tls_ask_ccert</a>).
+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 <a href="postconf.5.html#smtpd_tls_ask_ccert">smtpd_tls_ask_ccert</a>). </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
+(<a href="postconf.5.html#smtp_tls_security_level">smtp_tls_security_level</a> 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 <a href="postconf.5.html#smtp_tls_policy_maps">smtp_tls_policy_maps</a> 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&auml;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>