From 5e61585d76ae77fd5e9e96ebabb57afa4d74880d Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Sat, 27 Apr 2024 14:06:34 +0200 Subject: Adding upstream version 3.5.24. Signed-off-by: Daniel Baumann --- html/FORWARD_SECRECY_README.html | 717 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 717 insertions(+) create mode 100644 html/FORWARD_SECRECY_README.html (limited to 'html/FORWARD_SECRECY_README.html') diff --git a/html/FORWARD_SECRECY_README.html b/html/FORWARD_SECRECY_README.html new file mode 100644 index 0000000..3bdb047 --- /dev/null +++ b/html/FORWARD_SECRECY_README.html @@ -0,0 +1,717 @@ + + + + + + +TLS Forward Secrecy in Postfix + + + + + + + +

+TLS Forward Secrecy in Postfix +

+ +
+ +

Warning

+ +

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.

+ +

Overview

+ +

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 TLS_README for a general +description of Postfix TLS support.

+ +

Topics covered in this document:

+ + + +

What is Forward Secrecy

+ +

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.

+ +

Forward Secrecy in TLS

+ +

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:

+ + + +

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.

+ +

Forward Secrecy in the Postfix SMTP Server

+ +

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.

+ +

EDH Server support

+ +

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 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. +

+ + + +

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.

+ +

EECDH Server support

+ +

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.

+ +

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.

+ +

Forward Secrecy in the Postfix SMTP Client

+ +

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.

+ +

Getting started, quick and dirty

+ +

EECDH Client support (Postfix ≥ 2.2 with OpenSSL ≥ 1.0.0)

+ +

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.

+ +

EECDH Server support (Postfix ≥ 2.6 with OpenSSL ≥ 1.0.0)

+ +

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
+
+
+ +

EDH Client support (Postfix ≥ 2.2, all supported OpenSSL +versions)

+ +

This works "out of the box" without additional configuration.

+ +

EDH Server support (Postfix ≥ 2.2, all supported OpenSSL +versions)

+ +

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.

+ +

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 fine.

+ +

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
+        ...
+
+
+ +

How can I see that a connection has forward +secrecy?

+ +

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.

+ + + +

The next sections will explain what cipher-name, +key-size, and peer verification status information to expect. +

+ +

What ciphers provide forward secrecy?

+ +

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 may they +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 always 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
+
+
+ +

What do "Anonymous", "Untrusted", etc. in +Postfix logging mean?

+ +

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.

+ +
+ +
Anonymous (no peer certificate)
+ +

Postfix SMTP client: 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".

+ +

Postfix SMTP server: 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.

+ +
Untrusted (peer certificate not signed by trusted CA)
+ +
+ +

Postfix SMTP client: 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. +

+ +

Postfix SMTP server: 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).

+ +
+ +
Trusted (peer certificate signed by trusted CA, unverified +peer name)
+ +
+ +

Postfix SMTP client: 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.

+ +

Postfix SMTP server: 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.

+ +
+ +
Verified (peer certificate signed by trusted CA and +verified peer name; or: peer certificate with expected public-key +or certificate fingerprint)
+ +
+ +

Postfix SMTP client: 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". +

+ +

Postfix SMTP client: 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.

+ +

Postfix SMTP server: 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.

+ +
+ +
+ +

Credits

+ + + + + + -- cgit v1.2.3