diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-05-06 01:46:30 +0000 |
| commit | b5896ba9f6047e7031e2bdee0622d543e11a6734 (patch) | |
| tree | fd7b460593a2fee1be579bec5697e6d887ea3421 /proto/FORWARD_SECRECY_README.html | |
| parent | Initial commit. (diff) | |
| download | postfix-b5896ba9f6047e7031e2bdee0622d543e11a6734.tar.xz postfix-b5896ba9f6047e7031e2bdee0622d543e11a6734.zip | |
Adding upstream version 3.4.23.upstream/3.4.23upstream
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'proto/FORWARD_SECRECY_README.html')
| -rw-r--r-- | proto/FORWARD_SECRECY_README.html | 717 |
1 files changed, 717 insertions, 0 deletions
diff --git a/proto/FORWARD_SECRECY_README.html b/proto/FORWARD_SECRECY_README.html new file mode 100644 index 0000000..eee8b09 --- /dev/null +++ b/proto/FORWARD_SECRECY_README.html @@ -0,0 +1,717 @@ +<!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=us-ascii"> + +</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 support 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 support 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> 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 fine. </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 may they +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> |