On 11 Nov 2016, at 6:21, li...@lazygranch.com wrote:
So is this level of encryption something openssl sets up?
Yes and no. The partners in an encrypted session negotiate the details
of a ciphersuite when the session is established, based on both of their
configurations. For Postfix, the configuration(s) determine how Postfix
calls functions in the OpenSSL libraries, while other tools (i.e. client
software, other mail servers, etc.) may use other TLS/SSL
implementations that have analogous runtime configurability or none at
all. Different versions of any one implementation like OpenSSL have
differing capabilities as well. Different programs have different needs
and priorities, so typically the encryption negotiation parameters are
set by an application (e.g. Postfix, Apache, a mail client, a web
browser, etc.) rather than at the shared library (e.g. OpenSSL, GNUTLS,
NSS, etc.) level globally for a system.
So, Yes: OpenSSL code does the negotiation of ciphersuites between
various ostfix programs and the partners they talk to. Also, No: the
configuration of what ciphersuites are preferred and/or allowed is done
within Postfix, not externally by some part of OpenSSL itself.
That is where do I set the parameter?
You probably shouldn't, because it is unlikely to be of any value to
you. The strength difference between AES128 and AES256 transport
encryption is probably only relevant to you if your threat model
includes a major nation-state being able to intercept your email in
transit today and decrypt it sometime before 2025 as a meaningful risk.
If that is a significant concern to you, email transport encryption
would surely be very low on your list of risks and you really shouldn't
be using email for such things AT ALL.
With that said... Postfix has multiple settings that define the ciphers
it supports in the SMTP client (smtp) and server (smtpd) as well as the
priorities of which ciphers to prefer in a negotiation. See Postfix's
TLS_README file for the most cohesive documentation of those parameters.
Which you probably shouldn't change, but I repeat myself...
Two mistakes that people often make (and often bring here) with Postfix
TLS configuration are:
1. Not allowing for the negotiation of theoretically weaker
ciphersuites, resulting in fallback to unencrypted transport or simple
failure when a partner won't do that fallback.
2. Crafting carefully thought out cipher lists specifying individual
ciphersuites in a specific order, neglecting the fact that the "best"
such over-specified cipher list is a moving target even if one assumes
that all participants are using the latest version of OpenSSL as their
TLS implementation.
Exacerbating both of these is the fact that a lot of the searchable
how-tos for TLS configuration are narrowly focused on web and web-like
interactions where the threat model and the practical utility of
transport encryption are both quite different from SMTP transport or
initial mail submission. This has meant in some cases that an
algorithm's weakness which merits discouraging or even prohibiting its
use on a webserver is ultimately meaningless for a MTA because the
attack mode is implausible against a MTA or the vulnerability is one
that is already intrinsic to SMTP.
The bottom line (if you've made it this far...) is that the settings
that involve deep encryption parameters in modern Postfix are best left
at their default values unless you have very specific uncommon security
needs, can accept outright insoluble breakage in place of imperfect
security, and understand every sentence of the TLS_README, the relevant
bits of postconf(5), and everything Viktor Dukhovni has ever written
about encryption on this list.
