On Sep 11, 2013, at 21:37, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Wed, Sep 11, 2013 at 09:12:40PM +0200, DTNX Postmaster wrote: > >> 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. Aye, true. Change has been reversed. Misguided paranoia ;-) >> 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. It is possible to install AES extensions on Windows 2003 servers and upgrade the encryption support that way, but given that this server is the last Exchange 2003 server we have to support, on its way out, and Microsoft gives you a gazillion warnings, we decided that it was just not worth the hassle. Supposedly you can disable that particular cipher via registry settings, too, but that didn't work either. In other words, after spending two hours trying to figure out where it was going wrong, we decided that all parties involved would be better off speeding up migration to the new Exchange server instead. >>> 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. We generally love Debian, but sadly, these things are one of the drawbacks of using the distribution. They too are misguided at times, heh :-( We haven't seen the issue yet, though, so perhaps we'll stay lucky and be able to avoid the workaround for it. > 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. I will keep it in mind. Thanks for the valuable feedback, Victor :-) Mvg, Joni
