From: Wietse Venema Date: Wed, 18 Dec 2013 05:00:00 +0000 (-0500) Subject: postfix-2.11-20131218 X-Git-Tag: v2.11.0-RC1~5 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=606fe29d270922e14405695a1d52cc93c1b73cf2;p=thirdparty%2Fpostfix.git postfix-2.11-20131218 --- diff --git a/postfix/HISTORY b/postfix/HISTORY index da9e4c2b1..0d978725d 100644 --- a/postfix/HISTORY +++ b/postfix/HISTORY @@ -19241,7 +19241,7 @@ Apologies for any names omitted. 20131122 - Feature: "postcon -Fe service/type/attribute = value" edits + Feature: "postconf -Fe service/type/attribute = value" edits master.cf attribute values. The -e is optional. Example: use "postconf -F "*/*/chroot = n" to turn off chroot on all master.cf services. Files: postconf/postconf.h, @@ -19397,3 +19397,10 @@ Apologies for any names omitted. Enforce that this function will be used only for creating a 512-bit ephemeral RSA key. Viktor Dukhovni. File: tls/tls_rsa.c. + +20131218 + + Documentation: new document FORWARD_SECRECY_README that + describes how Postfix implements forward secrecy since + Postfix 2.2, and how that support has evolved. Viktor + Dukhovni. File: proto/FORWARD_SECRECY_README.html. diff --git a/postfix/README_FILES/AAAREADME b/postfix/README_FILES/AAAREADME index 0017b3d81..ad05cfe13 100644 --- a/postfix/README_FILES/AAAREADME +++ b/postfix/README_FILES/AAAREADME @@ -10,7 +10,7 @@ GGeenneerraall ccoonnffiigguurraattiioonn * VIRTUAL_README: Virtual domain hosting * SASL_README: SASL Authentication * TLS_README: TLS Encryption and authentication - * TLS_LEGACY_README: Legacy TLS support + * FORWARD_SECRECY_README: TLS Forward Secrecy * IPV6_README: IP Version 6 Support * MULTI_INSTANCE_README: Multiple-instance management * INSTALL: Installation from source code diff --git a/postfix/README_FILES/FORWARD_SECRECY_README b/postfix/README_FILES/FORWARD_SECRECY_README new file mode 100644 index 000000000..66f8e6ded --- /dev/null +++ b/postfix/README_FILES/FORWARD_SECRECY_README @@ -0,0 +1,225 @@ + TTLLSS FFoorrwwaarrdd SSeeccrreeccyy iinn PPoossttffiixx + +------------------------------------------------------------------------------- + +BBaacckkggrroouunndd + +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. + +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. + +Topics covered in this document: + + * Forward Secrecy in TLS + * Forward Secrecy in the Postfix SMTP Server + * Forward Secrecy in the Postfix SMTP Client + * Credits + +And last but not least, for the impatient: + + * Configuring forward secrecy, quick and dirty + +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 cases 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". There are two flavors of "groups" +that work with PFS: + + * Prime field groups. The server needs to be configured with a suitably large + prime and a corresponding "generator". + * Elliptic curve groups. 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 forward secrecy over prime fields is EDH or Ephemeral Diffie- +Hellman (sometimes also abbreviated as DHE). The acronym for the elliptic curve +version is EECDH which is short for Ephemeral Elliptic Curve Diffie-Hellman. + +It is not essential to know what these are, but one does need to know that +OpenSSL only supports EECDH as of version 1.0.0. Thus the configuration +parameters related to Elliptic Curve forward secrecy are only available when +Postfix is linked with OpenSSL 1.0.0 or later (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 + +First the good news: The Postfix SMTP server supports forward secrecy in its +default configuration. If the SMTP client also supports and prefers TLS 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. When the SMTP client is Postfix, it prefers forward secrecy +cipher suites by default. + +Postfix >= 2.8 when compiled with OpenSSL >= 1.0.0 supports EECDH key exchange +by default (via the most widely supported NIST P-256 curve). So when the SMTP +client also supports EECDH and implements the P-256 curve, forward secrecy just +works. + +For Postfix 2.6 and 2.7, in which EECDH was supported, but disabled by default, +one can safely enable EECDH by setting the main.cf parameter +smtpd_tls_eecdh_grade to "strong". + +For Postfix 2.2-2.5, or for interoperability with clients that do not support +EECDH, you need the older prime-field EDH, and here 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. + +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. + +It turns out that (inadvisably patched in some Debian releases) Exim SMTP +clients enforce a minimum of 2048 bits for the non-export prime. See the quick- +start section for the recommended configuration to work around this issue. + +So, in summary, Postfix 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. It also supports NIST P-256 EECDH out of the box with Postfix +2.8 or later, but this is disabled in Postfix 2.6 and 2.7 when the feature was +too new to enable by default. In retrospect it turned out to work reliably, and +is now on by default. + +The elliptic curve situation is evolving, with new curves being introduced to +augment or replace the NIST curves tarnished by the Snowden revelations. +Fortunately, TLS clients advertise the list of supported curves to the server +so that servers can in principle choose newer stronger curves when mutually +supported. The OpenSSL code for making this possible is not yet released as of +late 2013 (it is available only in OpenSSL development snapshots). + +At some point Postfix will need to adjust to the new API for setting the +elliptic curve options. Fortunately, when EECDH support was added to Postfix, +it introduced a layer of indirection: + + smtpd_tls_eecdh_grade = strong | ultra + tls_eecdh_strong_curve = prime256v1 + tls_eecdh_ultra_curve = secp384r1 + +When it becomes possible in OpenSSL to support a "menu" of curves, we will +likely extend "tls_eecdh_strong_curve" to be an ordered list of curves and +likewise with the "ultra" version, where the two might now overlap, and differ +mostly in the preference order. As a result most existing configurations will +then support more curves at the desired security level without any changes to +main.cf. + +FFoorrwwaarrdd SSeeccrreeccyy iinn tthhee PPoossttffiixx SSMMTTPP CClliieenntt + +EDH and EECDH use depends on SMTP client support and preference for the +corresponding TLS cipher suites. If the client prefers ciphers without forward +secrecy, these will be used instead. Though Postfix >= 2.8 supports setting +"tls_preempt_cipherlist = yes" to select the use of the server's, rather than +the client's, most preferred cipher suite, this setting will likely cause +interoperability issues with older Exchange servers and is not recommended for +now. + +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. It is likely safe to set "smtp_tls_ciphers = medium" +if you wish to disable the obsolete "export" and "low" grade ciphers even with +opportunistic TLS. Setting a minimum strength does not change the preference +order. Note that strengths higher than "medium" exclude Exchange 2003 and +likely other widely used MTAs, thus "high" grade ciphers should only be used on +a case-by-case basis via the TLS policy table. + +GGeettttiinngg ssttaarrtteedd,, qquuiicckk aanndd ddiirrttyy + +At least one time as root (prime group generation can take a few seconds to a +few minutes): + + # cd /etc/postfix + # 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 + +Note: greater security against "pre-computation" attacks against EDH can be +obtained by periodically regenerating the EDH parameters as above (an hourly or +daily cron job running as root can automate this task). The parameter files are +not secret, after all these are sent to all SMTP clients in the clear. Mode +0644 is fine. + +Once the parameters are in place, update main.cf as follows: + + main.cf: + # Postfix >= 2.6 + smtpd_tls_eecdh_grade = strong + # All versions of Postfix: + 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: + + 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: + -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem + -o smtpd_tls_security_level=encrypt + -o smtpd_sasl_auth_enable=yes + ... + +CCrreeddiittss + + * TLS support for Postfix was originally developed by Lutz Jä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. + diff --git a/postfix/WISHLIST b/postfix/WISHLIST index e9192387a..7bd7461da 100644 --- a/postfix/WISHLIST +++ b/postfix/WISHLIST @@ -4,8 +4,8 @@ Wish list: Make been_here flag BH_FLAG_FOLD configurable for masochists. - Allow LMDB-based caches to be shared. This requires a new - flag that says a database is concurrency-safe. + Replace some redundant TLS_README sections with pointers to + FORWARD_SECRECY_README. Preserve case in smtpd_resolve_addr() and add a structure member for the case-folded address. diff --git a/postfix/conf/postfix-files b/postfix/conf/postfix-files index 3304edf9d..9e1804a6d 100644 --- a/postfix/conf/postfix-files +++ b/postfix/conf/postfix-files @@ -259,6 +259,7 @@ $readme_directory/DEBUG_README:f:root:-:644 $readme_directory/DSN_README:f:root:-:644 $readme_directory/ETRN_README:f:root:-:644 $readme_directory/FILTER_README:f:root:-:644 +$readme_directory/FORWARD_SECRECY_README:f:root:-:644 $readme_directory/HOSTING_README:f:root:-:644:o $readme_directory/INSTALL:f:root:-:644 $readme_directory/IPV6_README:f:root:-:644 @@ -316,6 +317,7 @@ $html_directory/DEBUG_README.html:f:root:-:644 $html_directory/DSN_README.html:f:root:-:644 $html_directory/ETRN_README.html:f:root:-:644 $html_directory/FILTER_README.html:f:root:-:644 +$html_directory/FORWARD_SECRECY_README.html:f:root:-:644 $html_directory/INSTALL.html:f:root:-:644 $html_directory/IPV6_README.html:f:root:-:644 $html_directory/LDAP_README.html:f:root:-:644 diff --git a/postfix/html/FORWARD_SECRECY_README.html b/postfix/html/FORWARD_SECRECY_README.html new file mode 100644 index 000000000..9b2a08540 --- /dev/null +++ b/postfix/html/FORWARD_SECRECY_README.html @@ -0,0 +1,299 @@ + + + + + + +TLS Forward Secrecy in Postfix + + + + + + + +

+TLS Forward Secrecy in Postfix +

+ +
+ +

Background

+ +

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.

+ +

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.

+ +

Topics covered in this document:

+ + + +

And last but not least, for the impatient:

+ + + +

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 cases 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". +There are two flavors of "groups" that work with PFS:

+ + + +

The acronym for forward secrecy over prime fields is EDH or +Ephemeral Diffie-Hellman (sometimes also abbreviated as DHE). The +acronym for the elliptic curve version is EECDH which is short for +Ephemeral Elliptic Curve Diffie-Hellman.

+ +

It is not essential to know what these are, but one does need +to know that OpenSSL only supports EECDH as of version 1.0.0. Thus +the configuration parameters related to Elliptic Curve forward secrecy +are only available when Postfix is linked with OpenSSL 1.0.0 or +later (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

+ +

First the good news: The Postfix SMTP server supports forward +secrecy in its default configuration. If the SMTP client also +supports and prefers TLS 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. When the SMTP client is Postfix, it prefers forward +secrecy cipher suites by default.

+ +

Postfix ≥ 2.8 when compiled with OpenSSL ≥ 1.0.0 supports +EECDH key exchange by default (via the most widely supported NIST +P-256 curve). So when the SMTP client also supports EECDH and +implements the P-256 curve, forward secrecy just works.

+ +

For Postfix 2.6 and 2.7, in which EECDH was supported, but +disabled by default, one can safely enable EECDH by setting the +main.cf parameter smtpd_tls_eecdh_grade to "strong".

+ +

For Postfix 2.2-2.5, or for interoperability with clients +that do not support EECDH, you need the older prime-field EDH, and +here 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.

+ +

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.

+ +

It turns out that (inadvisably patched in some Debian releases) +Exim SMTP clients enforce a minimum of 2048 bits for the non-export +prime. See the quick-start section for +the recommended configuration to work around this issue.

+ +

So, in summary, Postfix 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. It also supports NIST P-256 +EECDH out of the box with Postfix 2.8 or later, but this is disabled +in Postfix 2.6 and 2.7 when the feature was too new to enable by +default. In retrospect it turned out to work reliably, and is now +on by default.

+ +

The elliptic curve situation is evolving, with new curves being +introduced to augment or replace the NIST curves tarnished by the +Snowden revelations. Fortunately, TLS clients advertise the list +of supported curves to the server so that servers can in principle +choose newer stronger curves when mutually supported. The OpenSSL +code for making this possible is not yet released as of late 2013 +(it is available only in OpenSSL development snapshots).

+ +

At some point Postfix will need to adjust to the new API for +setting the elliptic curve options. Fortunately, when EECDH support +was added to Postfix, it introduced a layer of indirection:

+ +
+
+    smtpd_tls_eecdh_grade = strong | ultra
+    tls_eecdh_strong_curve = prime256v1
+    tls_eecdh_ultra_curve = secp384r1
+
+
+ +

When it becomes possible in OpenSSL to support a "menu" of +curves, we will likely extend "tls_eecdh_strong_curve" to be an +ordered list of curves and likewise with the "ultra" version, where +the two might now overlap, and differ mostly in the preference +order. As a result most existing configurations will then support +more curves at the desired security level without any changes to +main.cf.

+ +

Forward Secrecy in the Postfix SMTP Client

+ +

EDH and EECDH use depends on SMTP client support and preference +for the corresponding TLS cipher suites. If the client prefers +ciphers without forward secrecy, these will be used instead. Though +Postfix ≥ 2.8 supports setting "tls_preempt_cipherlist = yes" +to select the use of the server's, rather than the client's, most +preferred cipher suite, this setting will likely cause interoperability +issues with older Exchange servers and is not recommended for now.

+ +

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. It is likely +safe to set "smtp_tls_ciphers = medium" if you wish to disable the +obsolete "export" and "low" grade ciphers even with opportunistic +TLS. Setting a minimum strength does not change the preference +order. Note that strengths higher than "medium" exclude Exchange +2003 and likely other widely used MTAs, thus "high" grade ciphers +should only be used on a case-by-case basis via the TLS policy table.

+ +

Getting started, quick and dirty

+ +

At least one time as root (prime group generation can take a +few seconds to a few minutes):

+ +
+
+# cd /etc/postfix
+# 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
+
+
+ +

Note: greater security against "pre-computation" attacks against +EDH can be obtained by periodically regenerating the EDH parameters +as above (an hourly or daily cron job running as root can automate +this task). The parameter files are not secret, after all these are +sent to all SMTP clients in the clear. Mode 0644 is fine.

+ +

Once the parameters are in place, update main.cf as follows:

+ +
+
+ main.cf:
+   # Postfix ≥ 2.6
+   smtpd_tls_eecdh_grade = strong
+   # All versions of Postfix:
+   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:

+ +
+
+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:
+    -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
+    -o smtpd_tls_security_level=encrypt
+    -o smtpd_sasl_auth_enable=yes
+    ...
+
+
+ +

Credits

+ + + + + + diff --git a/postfix/html/TLS_README.html b/postfix/html/TLS_README.html index cd75ee8ab..25f01af61 100644 --- a/postfix/html/TLS_README.html +++ b/postfix/html/TLS_README.html @@ -32,7 +32,7 @@ Postfix.

Transport Layer Security (TLS, formerly called SSL) provides certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with -SMTP mail or with SASL authentication. +SMTP mail or with SASL authentication.

NOTE: This document describes a TLS diff --git a/postfix/html/index.html b/postfix/html/index.html index 57c6f78b1..f758afdb3 100644 --- a/postfix/html/index.html +++ b/postfix/html/index.html @@ -42,7 +42,7 @@ configuration examples

  • TLS Encryption and authentication -
  • Legacy TLS support +
  • TLS Forward Secrecy
  • IP Version 6 Support diff --git a/postfix/html/tlsmgr.8.html b/postfix/html/tlsmgr.8.html index 8866ea8eb..12e43777e 100644 --- a/postfix/html/tlsmgr.8.html +++ b/postfix/html/tlsmgr.8.html @@ -178,6 +178,9 @@ TLSMGR(8) TLSMGR(8) The Secure Mailer license must be distributed with this software. +HISTORY + This service was introduced with Postfix version 2.2. + AUTHOR(S) Lutz Jaenicke BTU Cottbus diff --git a/postfix/man/man8/tlsmgr.8 b/postfix/man/man8/tlsmgr.8 index a6ec299e1..da3a5bd8b 100644 --- a/postfix/man/man8/tlsmgr.8 +++ b/postfix/man/man8/tlsmgr.8 @@ -177,6 +177,10 @@ TLS_README, Postfix TLS configuration and operation .ad .fi The Secure Mailer license must be distributed with this software. +.SH "HISTORY" +.na +.nf +This service was introduced with Postfix version 2.2. .SH "AUTHOR(S)" .na .nf diff --git a/postfix/proto/FORWARD_SECRECY_README.html b/postfix/proto/FORWARD_SECRECY_README.html new file mode 100644 index 000000000..bee95c3a2 --- /dev/null +++ b/postfix/proto/FORWARD_SECRECY_README.html @@ -0,0 +1,299 @@ + + + + + + +TLS Forward Secrecy in Postfix + + + + + + + +

    +TLS Forward Secrecy in Postfix +

    + +
    + +

    Background

    + +

    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.

    + +

    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.

    + +

    Topics covered in this document:

    + + + +

    And last but not least, for the impatient:

    + + + +

    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 cases 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". +There are two flavors of "groups" that work with PFS:

    + +
      +
    • Prime field groups. The server needs to be configured with a +suitably large prime and a corresponding "generator". +
    • Elliptic curve groups. 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 forward secrecy over prime fields is EDH or +Ephemeral Diffie-Hellman (sometimes also abbreviated as DHE). The +acronym for the elliptic curve version is EECDH which is short for +Ephemeral Elliptic Curve Diffie-Hellman.

    + +

    It is not essential to know what these are, but one does need +to know that OpenSSL only supports EECDH as of version 1.0.0. Thus +the configuration parameters related to Elliptic Curve forward secrecy +are only available when Postfix is linked with OpenSSL 1.0.0 or +later (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

    + +

    First the good news: The Postfix SMTP server supports forward +secrecy in its default configuration. If the SMTP client also +supports and prefers TLS 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. When the SMTP client is Postfix, it prefers forward +secrecy cipher suites by default.

    + +

    Postfix ≥ 2.8 when compiled with OpenSSL ≥ 1.0.0 supports +EECDH key exchange by default (via the most widely supported NIST +P-256 curve). So when the SMTP client also supports EECDH and +implements the P-256 curve, forward secrecy just works.

    + +

    For Postfix 2.6 and 2.7, in which EECDH was supported, but +disabled by default, one can safely enable EECDH by setting the +main.cf parameter smtpd_tls_eecdh_grade to "strong".

    + +

    For Postfix 2.2-2.5, or for interoperability with clients +that do not support EECDH, you need the older prime-field EDH, and +here 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.

    + +

    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.

    + +

    It turns out that (inadvisably patched in some Debian releases) +Exim SMTP clients enforce a minimum of 2048 bits for the non-export +prime. See the quick-start section for +the recommended configuration to work around this issue.

    + +

    So, in summary, Postfix 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. It also supports NIST P-256 +EECDH out of the box with Postfix 2.8 or later, but this is disabled +in Postfix 2.6 and 2.7 when the feature was too new to enable by +default. In retrospect it turned out to work reliably, and is now +on by default.

    + +

    The elliptic curve situation is evolving, with new curves being +introduced to augment or replace the NIST curves tarnished by the +Snowden revelations. Fortunately, TLS clients advertise the list +of supported curves to the server so that servers can in principle +choose newer stronger curves when mutually supported. The OpenSSL +code for making this possible is not yet released as of late 2013 +(it is available only in OpenSSL development snapshots).

    + +

    At some point Postfix will need to adjust to the new API for +setting the elliptic curve options. Fortunately, when EECDH support +was added to Postfix, it introduced a layer of indirection:

    + +
    +
    +    smtpd_tls_eecdh_grade = strong | ultra
+    tls_eecdh_strong_curve = prime256v1
+    tls_eecdh_ultra_curve = secp384r1
+
    +
    + +

    When it becomes possible in OpenSSL to support a "menu" of +curves, we will likely extend "tls_eecdh_strong_curve" to be an +ordered list of curves and likewise with the "ultra" version, where +the two might now overlap, and differ mostly in the preference +order. As a result most existing configurations will then support +more curves at the desired security level without any changes to +main.cf.

    + +

    Forward Secrecy in the Postfix SMTP Client

    + +

    EDH and EECDH use depends on SMTP client support and preference +for the corresponding TLS cipher suites. If the client prefers +ciphers without forward secrecy, these will be used instead. Though +Postfix ≥ 2.8 supports setting "tls_preempt_cipherlist = yes" +to select the use of the server's, rather than the client's, most +preferred cipher suite, this setting will likely cause interoperability +issues with older Exchange servers and is not recommended for now.

    + +

    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. It is likely +safe to set "smtp_tls_ciphers = medium" if you wish to disable the +obsolete "export" and "low" grade ciphers even with opportunistic +TLS. Setting a minimum strength does not change the preference +order. Note that strengths higher than "medium" exclude Exchange +2003 and likely other widely used MTAs, thus "high" grade ciphers +should only be used on a case-by-case basis via the TLS policy table.

    + +

    Getting started, quick and dirty

    + +

    At least one time as root (prime group generation can take a +few seconds to a few minutes):

    + +
    +
    +# cd /etc/postfix
+# 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
+
    +
    + +

    Note: greater security against "pre-computation" attacks against +EDH can be obtained by periodically regenerating the EDH parameters +as above (an hourly or daily cron job running as root can automate +this task). The parameter files are not secret, after all these are +sent to all SMTP clients in the clear. Mode 0644 is fine.

    + +

    Once the parameters are in place, update main.cf as follows:

    + +
    +
    + main.cf:
+   # Postfix ≥ 2.6
+   smtpd_tls_eecdh_grade = strong
+   # All versions of Postfix:
+   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:

    + +
    +
    +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:
+    -o smtpd_tls_dh1024_param_file=${config_directory}/dh1024.pem
+    -o smtpd_tls_security_level=encrypt
+    -o smtpd_sasl_auth_enable=yes
+    ...
+
    +
    + +

    Credits

    + +
      + +
    • TLS support for Postfix was originally developed by Lutz +Jä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. + +
    + + + + diff --git a/postfix/proto/Makefile.in b/postfix/proto/Makefile.in index 8b110ae12..b22e0a958 100644 --- a/postfix/proto/Makefile.in +++ b/postfix/proto/Makefile.in @@ -19,6 +19,7 @@ HTML = ../html/ADDRESS_CLASS_README.html \ ../html/DEBUG_README.html \ ../html/DSN_README.html \ ../html/ETRN_README.html ../html/FILTER_README.html \ + ../html/FORWARD_SECRECY_README.html \ ../html/INSTALL.html ../html/IPV6_README.html \ ../html/LDAP_README.html \ ../html/LINUX_README.html \ @@ -61,6 +62,7 @@ README = ../README_FILES/ADDRESS_CLASS_README \ ../README_FILES/DEBUG_README \ ../README_FILES/DSN_README \ ../README_FILES/ETRN_README ../README_FILES/FILTER_README \ + ../README_FILES/FORWARD_SECRECY_README \ ../README_FILES/INSTALL ../README_FILES/IPV6_README \ ../README_FILES/LDAP_README \ ../README_FILES/LINUX_README \ @@ -187,6 +189,9 @@ clobber: ../html/FILTER_README.html: FILTER_README.html $(DETAB) $? | $(POSTLINK) >$@ +../html/FORWARD_SECRECY_README.html: FORWARD_SECRECY_README.html + $(DETAB) $? | $(POSTLINK) >$@ + ../html/INSTALL.html: INSTALL.html $(DETAB) $? | $(POSTLINK) >$@ @@ -349,6 +354,9 @@ clobber: ../README_FILES/FILTER_README: FILTER_README.html $(DETAB) $? | $(HT2READ) >$@ +../README_FILES/FORWARD_SECRECY_README: FORWARD_SECRECY_README.html + $(DETAB) $? | $(HT2READ) >$@ + ../README_FILES/INSTALL: INSTALL.html $(DETAB) $? | $(HT2READ) >$@ diff --git a/postfix/proto/TLS_README.html b/postfix/proto/TLS_README.html index 0e538d47b..9f6ed19bb 100644 --- a/postfix/proto/TLS_README.html +++ b/postfix/proto/TLS_README.html @@ -32,7 +32,7 @@ Postfix.

    Transport Layer Security (TLS, formerly called SSL) provides certificate-based authentication and encrypted sessions. An encrypted session protects the information that is transmitted with -SMTP mail or with SASL authentication. +SMTP mail or with SASL authentication.

    NOTE: This document describes a TLS diff --git a/postfix/proto/stop b/postfix/proto/stop index 2d1867267..dde1a5227 100644 --- a/postfix/proto/stop +++ b/postfix/proto/stop @@ -1259,3 +1259,13 @@ xpostconf TLSA tafile VPN +Dukhovni +Exim +NIST +PFS +Snowden +Viktor +XP +cron +dhparam +inadvisably diff --git a/postfix/src/global/mail_version.h b/postfix/src/global/mail_version.h index 191ad5318..81c2d203f 100644 --- a/postfix/src/global/mail_version.h +++ b/postfix/src/global/mail_version.h @@ -20,7 +20,7 @@ * Patches change both the patchlevel and the release date. Snapshots have no * patchlevel; they change the release date only. */ -#define MAIL_RELEASE_DATE "20131217" +#define MAIL_RELEASE_DATE "20131218" #define MAIL_VERSION_NUMBER "2.11" #ifdef SNAPSHOT diff --git a/postfix/src/tlsmgr/tlsmgr.c b/postfix/src/tlsmgr/tlsmgr.c index 83fd8eda8..c2113b891 100644 --- a/postfix/src/tlsmgr/tlsmgr.c +++ b/postfix/src/tlsmgr/tlsmgr.c @@ -151,6 +151,8 @@ /* .ad /* .fi /* The Secure Mailer license must be distributed with this software. +/* HISTORY +/* This service was introduced with Postfix version 2.2. /* AUTHOR(S) /* Lutz Jaenicke /* BTU Cottbus