diff options
| author | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-10 19:59:03 +0000 |
|---|---|---|
| committer | Daniel Baumann <daniel.baumann@progress-linux.org> | 2024-04-10 19:59:03 +0000 |
| commit | a848231ae0f346dc7cc000973fbeb65b0894ee92 (patch) | |
| tree | 44b60b367c86723cc78383ef247885d72b388afe /html/FORWARD_SECRECY_README.html | |
| parent | Initial commit. (diff) | |
| download | postfix-a848231ae0f346dc7cc000973fbeb65b0894ee92.tar.xz postfix-a848231ae0f346dc7cc000973fbeb65b0894ee92.zip | |
Adding upstream version 3.8.5.upstream/3.8.5
Signed-off-by: Daniel Baumann <daniel.baumann@progress-linux.org>
Diffstat (limited to 'html/FORWARD_SECRECY_README.html')
| -rw-r--r-- | html/FORWARD_SECRECY_README.html | 614 |
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ä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 ≥ 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 ≥ 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 ≥ 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 ≥ 3.8 supports the finite-field Diffie-Hellman ephemeral +(FFDHE) key exchange group negotiation API of OpenSSL ≥ 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 ≥ 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 ≥ 3.2 supports the curve negotiation API of OpenSSL +≥ 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 ≥ 3.8 supports the finite-field Diffie-Hellman ephemeral +(FFDHE) key exchange group negotiation API of OpenSSL ≥ 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 ≥ 3.2 with OpenSSL ≥ 1.1.1) </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 +"<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 ≥ 3.2 with OpenSSL ≥ 1.1.1) </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 +"<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 ≥ 3.2, OpenSSL ≥ 1.1.1) </h3> + +<p> In Postfix < 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 ≥ 2.2, all supported OpenSSL +versions) </h3> + +<p> In Postfix < 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 ≥ 3.8 and OpenSSL ≥ 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 ≥ 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ä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> |