Thank you Viktor (and other commenters)

One of the primary reasons I use {ostfix is because of its great track record in security (its stability, performance and feature set are also great too). It would be foolish of me to disregard the devs who have achieved helped give Postfix its recommendation. I'll stick with excluding EXPORT and LOW as you mentioned earlier.

BTW, this whole thing came about from me testing using https://starttls.info/ which scored what I thought was a well secured server quite badly. I see now that the testing site is itself the problem, not my original config.

thanks again,
         Colin










On 20-05-2014 14:25, Viktor Dukhovni wrote:
On Tue, May 20, 2014 at 02:11:34PM +0100, Colin Fowler wrote:

>Opportunistic TLS is sometimes counter-intuitive, attempting to
>make it stronger by removing weaker features actually makes it
>weaker.  Don't give in to the urge to tweak TLS settings, they
>are largely fine as they are.
>

Is it not true though that allowing weak features merely gives the illusion
of security?

Opportunistic TLS, is only secure against passive attacks.  Against
passive attackers, any encryption, even weak is better than no
encryption.  This applies even more strongly to authentication or
lack thereof.  Authentication adds no protection against passive
attacks, once you've negotiated ephemeral keys (ideally with PFS,
see http://www.postfix.org/FORWARD_SECRECY_README.html) you're set.

It could be argued that a weak method is technically no better than no encryption so removing the weak method just removes the illusion (which some
would say was a gain).

All kinds of misguided points of view could be argued. :-)

>Most other "hardening" configuration changes are likely to reduce,
>rather than improve SMTP transport security.

I've heard anecdotes of clients not using the best mutually supported encryption and instead just using whatever's first in the list of methods accepted by the server. I don't have anything to back this up though. Ever heard of this? If this was true, then disabling weak methods might be
beneficial.

This is not how TLS works, the client sends a list of cipher-suites,
and the server chooses exactly one of these.  Depending on server
configuration, this is either the client's most preferred cipher
also supported by the server or else the server's most preferred
cipher supported by the client.

Grossly misconfigured clients or servers might choose weak
cipher-suites, but I've never seen this happen in practice.

If you disable EXPORT and LOW, the rest are substantially better
than cleartext even with the recent statistical anomalies in the
first 256 bytes of RC4 output.  Forcing the client to use cleartext
is not a better option.  However, one might want to use the server's
cipher preferences on the submission port:

    submission inet ... smtpd
      -o tls_preempt_cipherlist=yes
      ...

where it is unlikely to run into friction with remote Exchange 2003
servers (unless you're hosting remote Exchange MTAs as submission
clients).

Reply via email to