|Main Archive Page > Month Archives > postfix-users archives|
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
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
where it is unlikely to run into friction with remote Exchange 2003
servers (unless you're hosting remote Exchange MTAs as submission