diff options
Diffstat (limited to 'README_FILES/FORWARD_SECRECY_README')
| -rw-r--r-- | README_FILES/FORWARD_SECRECY_README | 557 |
1 files changed, 557 insertions, 0 deletions
diff --git a/README_FILES/FORWARD_SECRECY_README b/README_FILES/FORWARD_SECRECY_README new file mode 100644 index 0000000..3eb707c --- /dev/null +++ b/README_FILES/FORWARD_SECRECY_README @@ -0,0 +1,557 @@ + TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx + +------------------------------------------------------------------------------- + +WWaarrnniinngg + +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. + +OOvveerrvviieeww + +Postfix supports forward secrecy of TLS network communication since version +2.2. This support was adopted from Lutz Ja"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 TLS_README for a general description of +Postfix TLS support. + +Topics covered in this document: + + * Give me some background on forward secrecy in Postfix + + o What is Forward Secrecy + o Forward Secrecy in TLS + o Forward Secrecy in the Postfix SMTP Server + o Forward Secrecy in the Postfix SMTP Client + + * Never mind, just show me what it takes to get forward secrecy + + o Getting started, quick and dirty + o How can I see that a connection has forward secrecy? + o What ciphers provide forward secrecy? + o What do "Anonymous", "Untrusted", etc. in Postfix logging mean? + + * Credits + +WWhhaatt iiss FFoorrwwaarrdd SSeeccrreeccyy + +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. + +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. + +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. + +FFoorrwwaarrdd SSeeccrreeccyy iinn TTLLSS + +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. + +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. + +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: + + * PPrriimmee--ffiieelldd ggrroouuppss ((EEDDHH)):: 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). + + * EElllliippttiicc--ccuurrvvee ggrroouuppss ((EEEECCDDHH)):: 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). + +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). + +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. + +FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP SSeerrvveerr + +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 later compromised. + +Some remote SMTP clients may support forward secrecy, but prefer cipher suites +without 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. + +EEDDHH SSeerrvveerr ssuuppppoorrtt + +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 quick- +start section for details. With Postfix >= 3.1 the out of the box (compiled-in) +EDH prime size is 2048 bits. + +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. + + * 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 quick-start + 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. + + * 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 quick-start section for details). + +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 quick-start section for the +recommended configuration to work around this issue. + +EEEECCDDHH SSeerrvveerr ssuuppppoorrtt + +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. + + Note: With Postfix 2.6 and 2.7, enable EECDH by setting the main.cf + parameter smtpd_tls_eecdh_grade to "strong". + +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. + +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": + + smtpd_tls_eecdh_grade = strong | ultra + # Underlying curves, best not changed: + # tls_eecdh_strong_curve = prime256v1 + # tls_eecdh_ultra_curve = secp384r1 + +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. + +FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt + +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 later compromised. + +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. + +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. + +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 TLS policy table. + +GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy + +EEEECCDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22 wwiitthh OOppeennSSSSLL >>== 11..00..00)) + +This works "out of the box" with no need for additional configuration. + +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. + +EEEECCDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..66 wwiitthh OOppeennSSSSLL >>== 11..00..00)) + +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. + + /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 + +EEDDHH CClliieenntt ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss)) + +This works "out of the box" without additional configuration. + +EEDDHH SSeerrvveerr ssuuppppoorrtt ((PPoossttffiixx >>== 22..22,, aallll ssuuppppoorrtteedd OOppeennSSSSLL vveerrssiioonnss)) + +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. + +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 "aauuttoo", 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. + +Otherwise, execute as root (prime group generation can take a few seconds to a +few minutes): + + # 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 + +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. + +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). + +Once the parameters are in place, update main.cf as follows: + + /etc/postfix/main.cf: + smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem + smtpd_tls_dh512_param_file = ${config_directory}/dh512.pem + +If some of your MSA clients don't support 2048-bit EDH, you may need to adjust +the submission entry in master.cf accordingly: + + /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 + ... + +HHooww ccaann II sseeee tthhaatt aa ccoonnnneeccttiioonn hhaass ffoorrwwaarrdd sseeccrreeccyy?? + +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. + + * 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. + + postfix/smtp[process-id]: Untrusted TLS connection established + to host.example.com[192.168.0.2]:25: TLSv1 with cipher cipher-name + (actual-key-size/raw-key-size bits) + + postfix/smtpd[process-id]: Anonymous TLS connection established + from host.example.com[192.168.0.2]: TLSv1 with cipher cipher-name + (actual-key-size/raw-key-size bits) + + * 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. + + Received: from host.example.com (host.example.com [192.168.0.2]) + (using TLSv1 with cipher cipher-name + (actual-key-size/raw-key-size 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 cipher-name + (actual-key-size/raw-key-size bits)) + (No client certificate requested) + + 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. + + 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)) + + o 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. + + o 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. + + o 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. + + o 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. + +The next sections will explain what cipher-name, key-size, and peer +verification status information to expect. + +WWhhaatt cciipphheerrss pprroovviiddee ffoorrwwaarrdd sseeccrreeccyy?? + +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. + + $ 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 + ... + +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. + +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. + +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 aallwwaayyss 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): + + postfix/smtp[process-id]: + 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[process-id]: + 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 + +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. + +Examples of Postfix SMTP server logging: + + postfix/smtpd[process-id]: + 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[process-id]: + 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[process-id]: + 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 + +Note that Postfix >= 3.4 server logging may also include a "to sni-name" +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: + + postfix/smtpd[process-id]: + 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 + +WWhhaatt ddoo ""AAnnoonnyymmoouuss"",, ""UUnnttrruusstteedd"",, eettcc.. iinn PPoossttffiixx llooggggiinngg mmeeaann?? + +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. + +AAnnoonnyymmoouuss (no peer certificate) + PPoossttffiixx SSMMTTPP cclliieenntt:: 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". + + PPoossttffiixx SSMMTTPP sseerrvveerr:: 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 server not sending a certificate. + +UUnnttrruusstteedd (peer certificate not signed by trusted CA) + PPoossttffiixx SSMMTTPP cclliieenntt:: 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. + + PPoossttffiixx SSMMTTPP sseerrvveerr:: 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). + +TTrruusstteedd (peer certificate signed by trusted CA, unverified peer name) + PPoossttffiixx SSMMTTPP cclliieenntt:: 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. + + PPoossttffiixx SSMMTTPP sseerrvveerr:: 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. + +VVeerriiffiieedd (peer certificate signed by trusted CA and verified peer name; or: +peer certificate with expected public-key or certificate fingerprint) + PPoossttffiixx SSMMTTPP cclliieenntt:: 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". + + PPoossttffiixx SSMMTTPP cclliieenntt:: 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. + + PPoossttffiixx SSMMTTPP sseerrvveerr:: 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. + +CCrreeddiittss + + * TLS support for Postfix was originally developed by Lutz Ja"nicke at + Cottbus Technical University. + * Wietse Venema adopted and restructured the code and documentation. + * Viktor Dukhovni implemented support for many subsequent TLS features, + including EECDH, and authored the initial version of this document. + |