On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote:
> > This is counter-productive. You get TLSv1 whenever the client supports
> > it, so rejecting SSLv3 at the server does not improve security.
>
> It rejects the systems that only support SSLv3, does it not? Or am I
> understanding it incorrectly?
>
> The reasoning was that accepting SSLv3/RC4-MD5 connections from systems
> for which that is apparently the maximum they can support, even today,
> constitutes a false sense of security. It being the low-hanging fruit,
> and the most likely to be brute-forcable by the Powers That Be, if they
> indeed have that capability. And even if they don't, systems which have
> that as the maximum would be more likely to have backdoors or
> vulnerabilities that would allow for the recovery of private keys.
Forcing the traffic to be sent clear-text is not an improvement.
People also have a false sense of security about mail they send in
the clear. Pedantry is counter-productive in security. Think
about the practical results of proposed policy changes.
> Also, I think it was like five servers that had this as their maximum,
> in the entire month. Given those numbers, we figured we could run some
> tests and see what happens with those rare connections.
There is little to gain by breaking TLS from those 5 servers unless
they are spammers, and you would reject their traffic anyway.
> > In a couple of years time, when OpenSSL 1.0.2 is out, and Postfix
> > 2.12 or 2.13 ships, I think we can safely turn off SSLv3 by default
> > in the Postfix SMTP *client*. The rationale is improved EECDH
> > support (servers can offer more trust-worthy curves when clients
> > support them) and a negligible and diminishing set of servers that
> > only support SSLv3.
> >
> > At this time, the only plausibly useful TLS extension for the client
> > to send is session ticket support, and this mostly breaks session
> > caching in Postfix SMTP servers other than the just released 2.10.2,
> > 2.9.8, 2.8.16 and 2.7.15.
> >
> > So it is premature to disable SSLv3. The Postfix default TLS
> > settings are chosen with care, most efforts to "improve" them
> > are counter-productive.
>
> I am aware of this, and we generally do not override the defaults
> unless it is to solve problems. Had to disable 'DES-CBC3-SHA' as a
> cipher in the client because it was bugging out vs. an Exchange 2003
> server that should be phased out before year's end, for example.
That's a very old problem! Historically the Microsoft systems with
this problem selected RC4 in preference to 3DES. I am surprised
to hear that the problem is still not fixed, and that the server
selected 3DES.
> > The only change justified by recent events is perhaps forcing the
> > non-export EDH prime to 2048-bits as described in recent threads.
>
> That was the problem with certain versions of Exim, was it not?
Yes, current Exim on Debian "squeeze" (6.0) or stale Exim (before
4.80-3) on Debian "wheezy" (7.x). The road to hell is paved with
good intentions. In this case one of the Debian maintainers wanted
to "improve" Exim security, as a result of which a lot more mail
was sent in the clear as Exim TLS stopped interoperating with most
other MTAs.
Avoid counter-productive knee-jerk designs. If you want better
email security, consider deploying to DNSSEC and publishing DANE
TLSA RRs. When you deploy Postfix 2.11, consider making "dane"
the default client TLS security level:
smtp_dns_support_level = dnssec
smtp_tls_security_level = dane
With DANE you take advantage of ECDSA self-signed certificates in
parallel with RSA self-signed certificates. Clients that support
EECDH and ECDSA will be able to authenticate your server via stronger
high-performance public keys and DH groups.
At some point in the not too distant future there will be specifications
for new EC curves with TLS that are not tainted by the mystery
seeds of the NIST curves, making use of these will require OpenSSL
1.0.2 or later, so it will be some time before the state of the
art moves beyond what is best-practice today. Stay tuned, but
don't expect things to get much better very fast.
--
Viktor.
