On 25 May 2015, at 15:52, Viktor Dukhovni <[email protected]> wrote:
> On Mon, May 25, 2015 at 02:35:38PM +0200, DTNX Postmaster wrote:
>
>> No, not for submission, where clients will submit their authentication
>> details, allowing them to bypass most of the restrictions that are in
>> place for MTA to MTA communication.
>
> No, even for the MSA, disable all the deprecated choices that are
> no longer used by your clients, and by all means preempt the client
> cipher preference. However, among sufficiently modern ciphersuites,
> do not explicitly hard-code ad-hoc cipherlists. There's no need
> to lock out future progress. Disable "export" and "low" and possibly
> "RC4" if you can get away with that now (otherwise plan to do that
> later).
>
> However, DO NOT freeze today's list of strong ciphers into your
> configuration. This is likely to stay that way until the next
> crisis, and in the mean time not take advantage of progress with
> new bulk ciphers and ECDH curves, ...
>
> We're no going to agree on this, and Postfix deliberately discourages
> delving down to the level of OpenSSL cipherlist specs, which are
> are rather subtle interface that many users don't understand and
> mistconfigure.
>
> Work with Postfix ciphergrades, modulo sensible exclusions. This
> interface can be understood by mortals. Set a floor, and add
> excluions to handle interop issues.
>
> Thus for the MSA
>
> master.cf:
> 587 inet ... smtpd
> -o tls_preempt_cipherlist=yes
> -o smtpd_tls_ciphers=$msa_tls_ciphers
> -o smtpd_tls_exclude_ciphers=$msa_tls_exclude_ciphers
> -o smtpd_tls_protocols=$msa_tls_protocols
> -o smtpd_tls_dh1024_param_file=$msa_tls_dh1024_param_file
>
> main.cf:
> msa_tls_ciphers = medium
> # Adjust as necessary:
> msa_tls_exclude_ciphers = MD5, RC4, 3DES
> msa_tls_protocols = !SSLv2, !SSLv3
> # See FORWARD_SECRECY_README
> smtpd_tls_dh1024_param_file = ${config_directory}/dh2048.pem
>
> Notice the complete lack of an explicit cipherlist, while weak
> options are disabled. Choosing explicit strong ciphers is unnecessary,
> error prone and locks in choices that become stale over time.
Except that the 'tls_medium_cipherlist' setting defaults to
'aNULL:-aNULL:ALL:!EXPORT:!LOW:+RC4:@STRENGTH', and thus leaves
anonymous ciphers enabled for your MSA. As well as PSK, DSS, SEED, SRP,
and quite a few other ciphers very few people will need for client
authentication, making the list of ciphers to exclude longer than an
explicit cipherlist.
Turning on 'tls_preempt_cipherlist' for that cipherlist means that
you're explicitly preferring a chunk of those anonymous ciphers over
the better options available. Oh, so add 'aNULL' to the exclusion list
as well, right?
Plus the "Wait, is the Postfix 'medium' not the same as the 'MEDIUM' I
am reading about in the OpenSSL docs?"
It makes verifying which ciphers are actually active on the MSA harder
for the average user, because there's no easy way for them to test what
they can expect. They have to assemble several bits to generate the
active list, or test a running configuration to be certain.
They can't prefer 128-bit over 256-bit for speed either, with Postfix
defaults and exclusions.
Also, for the average mortal running Postfix, upgrading OpenSSL is
usually a system-level event, the upgrade of the entire OS, which means
that the risk of their configuration becoming stale is very low for the
lifetime of their setup. Their OS upgrade often means an upgrade for
Postfix as well, usually a big step forward warranting a review of the
configuration anyway.
They are therefore better off with an explicit cipherlist they can
compare to recommendations, reasonably easily verify themselves, and
show to others to prove that they are current, whenever a vulnerability
hits.
And no, not everyone gives the wrong recommendations ;-)
Anyway, enough for now :-)
Mvg,
Joni