On 25 May 2015, at 15:52, Viktor Dukhovni <postfix-us...@dukhovni.org> 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

Reply via email to