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,
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.
* 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
--- /dev/null
+ T\bTL\bLS\bS F\bFo\bor\brw\bwa\bar\brd\bd S\bSe\bec\bcr\bre\bec\bcy\by i\bin\bn P\bPo\bos\bst\btf\bfi\bix\bx
+
+-------------------------------------------------------------------------------
+
+B\bBa\bac\bck\bkg\bgr\bro\bou\bun\bnd\bd
+
+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.
+
+W\bWh\bha\bat\bt i\bis\bs F\bFo\bor\brw\bwa\bar\brd\bd S\bSe\bec\bcr\bre\bec\bcy\by
+
+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
+
+F\bFo\bor\brw\bwa\bar\brd\bd S\bSe\bec\bcr\bre\bec\bcy\by i\bin\bn T\bTL\bLS\bS
+
+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.
+
+F\bFo\bor\brw\bwa\bar\brd\bd S\bSe\bec\bcr\bre\bec\bcy\by i\bin\bn t\bth\bhe\be P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP S\bSe\ber\brv\bve\ber\br
+
+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.
+
+F\bFo\bor\brw\bwa\bar\brd\bd S\bSe\bec\bcr\bre\bec\bcy\by i\bin\bn t\bth\bhe\be P\bPo\bos\bst\btf\bfi\bix\bx S\bSM\bMT\bTP\bP C\bCl\bli\bie\ben\bnt\bt
+
+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.
+
+G\bGe\bet\btt\bti\bin\bng\bg s\bst\bta\bar\brt\bte\bed\bd,\b, q\bqu\bui\bic\bck\bk a\ban\bnd\bd d\bdi\bir\brt\bty\by
+
+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
+ ...
+
+C\bCr\bre\bed\bdi\bit\bts\bs
+
+ * 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.
+
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.
$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
$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
--- /dev/null
+<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+
+<head>
+
+<title>TLS Forward Secrecy in Postfix</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+
+</head>
+
+<body>
+
+<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">
+TLS Forward Secrecy in Postfix
+</h1>
+
+<hr>
+
+<h2> Background </h2>
+
+<p> Postfix supports forward secrecy of TLS network communication
+since version 2.2. This support was adopted from Lutz Jänicke's
+"Postfix TLS patch" for earlier Postfix versions. This document
+will focus on TLS Forward Secrecy in the Postfix SMTP client and
+server. See <a href="TLS_README.html">TLS_README</a> for a general
+description of Postfix TLS support. </p>
+
+<h2> What is Forward Secrecy </h2>
+
+<p> The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
+is used to describe security protocols in which the confidentiality
+of past traffic is not compromised when long-term keys used by either
+or both sides are later disclosed. </p>
+
+<p> Forward secrecy is accomplished by negotiating session keys
+using per-session cryptographically-strong random numbers that are
+not saved, and signing the exchange with long-term authentication
+keys. Later disclosure of the long-term keys allows impersonation
+of the key holder from that point on, but not recovery of prior
+traffic, since with forward secrecy, the discarded random key
+agreement inputs are not available to the attacker. </p>
+
+<p> Forward secrecy is only "perfect" when brute-force attacks on
+the key agreement algorithm are impractical even for the best-funded
+adversary and the random-number generators used by both parties are
+sufficiently strong. Otherwise, forward secrecy leaves the attacker
+with the challenge of cracking the key-agreement protocol, which
+is likely quite computationally intensive, but may be feasible for
+sessions of sufficiently high value. Thus forward secrecy places
+cost constraints on the efficacy of bulk surveillance, recovering
+all past traffic is generally infeasible, and even recovery of
+individual sessions may be infeasible given a sufficiently-strong
+key agreement method. </p>
+
+<p> Topics covered in this document: </p>
+
+<ul>
+
+<li><a href="#tls_fs">Forward Secrecy in TLS</a>
+
+<li><a href="#server_fs">Forward Secrecy in the Postfix SMTP Server</a>
+
+<li><a href="#client_fs">Forward Secrecy in the Postfix SMTP Client</a>
+
+<li><a href="#credits"> Credits </a>
+
+</ul>
+
+<p> And last but not least, for the impatient: </p>
+
+<ul>
+
+<li><a href="#quick-start">Configuring forward secrecy, quick and dirty</a>
+
+</ul>
+
+<h2><a name="tls_fs">Forward Secrecy in TLS</a></h2>
+
+<p> Early implementations of the SSL protocol do not provide forward
+secrecy (some provide it only with artificially-weakened "export"
+cipher suites, but we will ignore those 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. </p>
+
+<p> Later revisions to the TLS protocol introduced forward-secrecy
+cipher suites in which the client and server implement a key exchange
+protocol based on ephemeral secrets. Sessions encrypted with one
+of these newer cipher suites are not compromised by future disclosure
+of long-term authentication keys. </p>
+
+<p> The key-exchange algorithms used for forward secrecy require
+the TLS server to designate appropriate "parameters" consisting of a
+mathematical "group" and an element of that group called a "generator".
+There are two flavors of "groups" that work with PFS: </p>
+
+<ul>
+<li> Prime field groups. The server needs to be configured with a
+suitably large prime and a corresponding "generator".
+<li> 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.
+</ul>
+
+<p> 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. </p>
+
+<p> 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). </p>
+
+<p> Elliptic curves used in cryptography are typically identified
+by a "name" that stands for a set of well-known parameter values,
+and it is these "names" (or associated ASN.1 object identifiers)
+that are used in the TLS protocol. On the other hand, with TLS there
+are no specially designated prime field groups, so each server is
+free to select its own suitably-strong prime and generator. </p>
+
+<h2><a name="server_fs">Forward Secrecy in the Postfix SMTP Server</a></h2>
+
+<p> 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 <i>later</i>
+compromised. When the SMTP client is Postfix, it prefers forward
+secrecy cipher suites by default. </p>
+
+<p> 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. </p>
+
+<p> For Postfix 2.6 and 2.7, in which EECDH was supported, but
+disabled by default, one can safely enable EECDH by setting the
+<a href="postconf.5.html">main.cf</a> parameter <a href="postconf.5.html#smtpd_tls_eecdh_grade">smtpd_tls_eecdh_grade</a> to "strong". </p>
+
+<p> 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. </p>
+
+<p> The export EDH parameters are used only with the obsolete
+"export" ciphers. To use a non-default prime, generate a 512-bit
+DH parameter file and set <a href="postconf.5.html#smtpd_tls_dh512_param_file">smtpd_tls_dh512_param_file</a> to the filename. </p>
+
+<p> The non-export EDH parameters are used for all other EDH
+cipher suites. To use a non-default prime, generate a 1024-bit or
+2048-bit DH parameter file and set <a href="postconf.5.html#smtpd_tls_dh1024_param_file">smtpd_tls_dh1024_param_file</a> to
+the filename. Despite the name this is simply the non-export
+parameter file and the prime need not actually be 1024 bits long. </p>
+
+<p> 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 <a href="#quick-start">quick-start</a> section for
+the recommended configuration to work around this issue. </p>
+
+<p> 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. </p>
+
+<p> 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). </p>
+
+<p> 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: </p>
+
+<blockquote>
+<pre>
+ <a href="postconf.5.html#smtpd_tls_eecdh_grade">smtpd_tls_eecdh_grade</a> = strong | ultra
+ <a href="postconf.5.html#tls_eecdh_strong_curve">tls_eecdh_strong_curve</a> = prime256v1
+ <a href="postconf.5.html#tls_eecdh_ultra_curve">tls_eecdh_ultra_curve</a> = secp384r1
+</pre>
+</blockquote>
+
+<p> When it becomes possible in OpenSSL to support a "menu" of
+curves, we will likely extend "<a href="postconf.5.html#tls_eecdh_strong_curve">tls_eecdh_strong_curve</a>" 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
+<a href="postconf.5.html">main.cf</a>. </p>
+
+<h2> <a name="client_fs">Forward Secrecy in the Postfix SMTP Client</a> </h2>
+
+<p> 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 "<a href="postconf.5.html#tls_preempt_cipherlist">tls_preempt_cipherlist</a> = 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. </p>
+
+<p> The default Postfix SMTP client cipher lists are correctly ordered
+to prefer EECDH and EDH cipher suites ahead of similar cipher suites
+that don't implement forward secrecy. Administrators are strongly
+discouraged from changing the cipher list definitions. It is likely
+safe to set "<a href="postconf.5.html#smtp_tls_ciphers">smtp_tls_ciphers</a> = 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 <a
+href="TLS_README.html#client_tls_policy">TLS policy</a> table. </p>
+
+<h2><a name="quick-start">Getting started, quick and dirty</a></h2>
+
+<p> At least one time as root (prime group generation can take a
+few seconds to a few minutes): </p>
+
+<blockquote>
+<pre>
+# 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
+</pre>
+</blockquote>
+
+<p> 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. </p>
+
+<p> Once the parameters are in place, update <a href="postconf.5.html">main.cf</a> as follows: </p>
+
+<blockquote>
+<pre>
+ <a href="postconf.5.html">main.cf</a>:
+ # Postfix ≥ 2.6
+ <a href="postconf.5.html#smtpd_tls_eecdh_grade">smtpd_tls_eecdh_grade</a> = strong
+ # All versions of Postfix:
+ <a href="postconf.5.html#smtpd_tls_dh1024_param_file">smtpd_tls_dh1024_param_file</a> = ${<a href="postconf.5.html#config_directory">config_directory</a>}/dh2048.pem
+ <a href="postconf.5.html#smtpd_tls_dh512_param_file">smtpd_tls_dh512_param_file</a> = ${<a href="postconf.5.html#config_directory">config_directory</a>}/dh512.pem
+</pre>
+</blockquote>
+
+<p> If some of your MSA clients don't support 2048-bit EDH, you may
+need to adjust the submission entry in <a href="master.5.html">master.cf</a> accordingly: </p>
+
+<blockquote>
+<pre>
+<a href="master.5.html">master.cf</a>:
+ 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 <a href="postconf.5.html#smtpd_tls_dh1024_param_file">smtpd_tls_dh1024_param_file</a>=${<a href="postconf.5.html#config_directory">config_directory</a>}/dh1024.pem
+ -o <a href="postconf.5.html#smtpd_tls_security_level">smtpd_tls_security_level</a>=encrypt
+ -o <a href="postconf.5.html#smtpd_sasl_auth_enable">smtpd_sasl_auth_enable</a>=yes
+ ...
+</pre>
+</blockquote>
+
+<h2><a name="credits">Credits </a> </h2>
+
+<ul>
+
+<li> TLS support for Postfix was originally developed by Lutz
+Jänicke at Cottbus Technical University.
+
+<li> Wietse Venema adopted and restructured the code and documentation.
+
+<li> Viktor Dukhovni implemented support for many subsequent TLS
+features, including EECDH, and authored the initial version of this
+document.
+
+</ul>
+
+</body>
+
+</html>
<p> 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. </p>
<blockquote> <p> <a name="client_tls_obs"></a> <a
name="client_tls_harden"></a> NOTE: This document describes a TLS
<li> <a href="TLS_README.html"> TLS Encryption and authentication </a>
-<li> <a href="TLS_LEGACY_README.html"> Legacy TLS support </a>
+<li> <a href="FORWARD_SECRECY_README.html"> TLS Forward Secrecy </a>
<li> <a href="IPV6_README.html"> IP Version 6 Support </a>
The Secure Mailer license must be distributed with this
software.
+<b>HISTORY</b>
+ This service was introduced with Postfix version 2.2.
+
<b>AUTHOR(S)</b>
Lutz Jaenicke
BTU Cottbus
.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
--- /dev/null
+<!doctype html public "-//W3C//DTD HTML 4.01 Transitional//EN"
+ "http://www.w3.org/TR/html4/loose.dtd">
+
+<html>
+
+<head>
+
+<title>TLS Forward Secrecy in Postfix</title>
+
+<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
+
+</head>
+
+<body>
+
+<h1><img src="postfix-logo.jpg" width="203" height="98" ALT="">
+TLS Forward Secrecy in Postfix
+</h1>
+
+<hr>
+
+<h2> Background </h2>
+
+<p> Postfix supports forward secrecy of TLS network communication
+since version 2.2. This support was adopted from Lutz Jänicke's
+"Postfix TLS patch" for earlier Postfix versions. This document
+will focus on TLS Forward Secrecy in the Postfix SMTP client and
+server. See <a href="TLS_README.html">TLS_README</a> for a general
+description of Postfix TLS support. </p>
+
+<h2> What is Forward Secrecy </h2>
+
+<p> The term "Forward Secrecy" (or sometimes "Perfect Forward Secrecy")
+is used to describe security protocols in which the confidentiality
+of past traffic is not compromised when long-term keys used by either
+or both sides are later disclosed. </p>
+
+<p> Forward secrecy is accomplished by negotiating session keys
+using per-session cryptographically-strong random numbers that are
+not saved, and signing the exchange with long-term authentication
+keys. Later disclosure of the long-term keys allows impersonation
+of the key holder from that point on, but not recovery of prior
+traffic, since with forward secrecy, the discarded random key
+agreement inputs are not available to the attacker. </p>
+
+<p> Forward secrecy is only "perfect" when brute-force attacks on
+the key agreement algorithm are impractical even for the best-funded
+adversary and the random-number generators used by both parties are
+sufficiently strong. Otherwise, forward secrecy leaves the attacker
+with the challenge of cracking the key-agreement protocol, which
+is likely quite computationally intensive, but may be feasible for
+sessions of sufficiently high value. Thus forward secrecy places
+cost constraints on the efficacy of bulk surveillance, recovering
+all past traffic is generally infeasible, and even recovery of
+individual sessions may be infeasible given a sufficiently-strong
+key agreement method. </p>
+
+<p> Topics covered in this document: </p>
+
+<ul>
+
+<li><a href="#tls_fs">Forward Secrecy in TLS</a>
+
+<li><a href="#server_fs">Forward Secrecy in the Postfix SMTP Server</a>
+
+<li><a href="#client_fs">Forward Secrecy in the Postfix SMTP Client</a>
+
+<li><a href="#credits"> Credits </a>
+
+</ul>
+
+<p> And last but not least, for the impatient: </p>
+
+<ul>
+
+<li><a href="#quick-start">Configuring forward secrecy, quick and dirty</a>
+
+</ul>
+
+<h2><a name="tls_fs">Forward Secrecy in TLS</a></h2>
+
+<p> Early implementations of the SSL protocol do not provide forward
+secrecy (some provide it only with artificially-weakened "export"
+cipher suites, but we will ignore those 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. </p>
+
+<p> Later revisions to the TLS protocol introduced forward-secrecy
+cipher suites in which the client and server implement a key exchange
+protocol based on ephemeral secrets. Sessions encrypted with one
+of these newer cipher suites are not compromised by future disclosure
+of long-term authentication keys. </p>
+
+<p> The key-exchange algorithms used for forward secrecy require
+the TLS server to designate appropriate "parameters" consisting of a
+mathematical "group" and an element of that group called a "generator".
+There are two flavors of "groups" that work with PFS: </p>
+
+<ul>
+<li> Prime field groups. The server needs to be configured with a
+suitably large prime and a corresponding "generator".
+<li> 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.
+</ul>
+
+<p> 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. </p>
+
+<p> 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). </p>
+
+<p> Elliptic curves used in cryptography are typically identified
+by a "name" that stands for a set of well-known parameter values,
+and it is these "names" (or associated ASN.1 object identifiers)
+that are used in the TLS protocol. On the other hand, with TLS there
+are no specially designated prime field groups, so each server is
+free to select its own suitably-strong prime and generator. </p>
+
+<h2><a name="server_fs">Forward Secrecy in the Postfix SMTP Server</a></h2>
+
+<p> 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 <i>later</i>
+compromised. When the SMTP client is Postfix, it prefers forward
+secrecy cipher suites by default. </p>
+
+<p> 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. </p>
+
+<p> 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". </p>
+
+<p> 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. </p>
+
+<p> The export EDH parameters are used only with the obsolete
+"export" ciphers. To use a non-default prime, generate a 512-bit
+DH parameter file and set smtpd_tls_dh512_param_file to the filename. </p>
+
+<p> The non-export EDH parameters are used for all other EDH
+cipher suites. To use a non-default prime, generate a 1024-bit or
+2048-bit DH parameter file and set smtpd_tls_dh1024_param_file to
+the filename. Despite the name this is simply the non-export
+parameter file and the prime need not actually be 1024 bits long. </p>
+
+<p> 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 <a href="#quick-start">quick-start</a> section for
+the recommended configuration to work around this issue. </p>
+
+<p> 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. </p>
+
+<p> 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). </p>
+
+<p> 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: </p>
+
+<blockquote>
+<pre>
+ smtpd_tls_eecdh_grade = strong | ultra
+ tls_eecdh_strong_curve = prime256v1
+ tls_eecdh_ultra_curve = secp384r1
+</pre>
+</blockquote>
+
+<p> 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. </p>
+
+<h2> <a name="client_fs">Forward Secrecy in the Postfix SMTP Client</a> </h2>
+
+<p> 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. </p>
+
+<p> The default Postfix SMTP client cipher lists are correctly ordered
+to prefer EECDH and EDH cipher suites ahead of similar cipher suites
+that don't implement forward secrecy. Administrators are strongly
+discouraged from changing the cipher list definitions. 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 <a
+href="TLS_README.html#client_tls_policy">TLS policy</a> table. </p>
+
+<h2><a name="quick-start">Getting started, quick and dirty</a></h2>
+
+<p> At least one time as root (prime group generation can take a
+few seconds to a few minutes): </p>
+
+<blockquote>
+<pre>
+# 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
+</pre>
+</blockquote>
+
+<p> 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. </p>
+
+<p> Once the parameters are in place, update main.cf as follows: </p>
+
+<blockquote>
+<pre>
+ 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
+</pre>
+</blockquote>
+
+<p> If some of your MSA clients don't support 2048-bit EDH, you may
+need to adjust the submission entry in master.cf accordingly: </p>
+
+<blockquote>
+<pre>
+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
+ ...
+</pre>
+</blockquote>
+
+<h2><a name="credits">Credits </a> </h2>
+
+<ul>
+
+<li> TLS support for Postfix was originally developed by Lutz
+Jänicke at Cottbus Technical University.
+
+<li> Wietse Venema adopted and restructured the code and documentation.
+
+<li> Viktor Dukhovni implemented support for many subsequent TLS
+features, including EECDH, and authored the initial version of this
+document.
+
+</ul>
+
+</body>
+
+</html>
../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 \
../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 \
../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) >$@
../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) >$@
<p> 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. </p>
<blockquote> <p> <a name="client_tls_obs"></a> <a
name="client_tls_harden"></a> NOTE: This document describes a TLS
TLSA
tafile
VPN
+Dukhovni
+Exim
+NIST
+PFS
+Snowden
+Viktor
+XP
+cron
+dhparam
+inadvisably
* 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
/* .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
projects / thirdparty / postfix.git / commitdiff
