On Sep 11, 2013, at 17:24, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Wed, Sep 11, 2013 at 04:57:01PM +0200, DTNX Postmaster wrote: > >>> SSLv3 is already disabled in Postfix 2.11 when the remote server >>> is authenticated via DNSSEC DANE TLSA records, because in this case >>> the Postfix SMTP client needs to send the SNI extension to the >>> server (just in case the right certificate is contingent on SNI). >> >> I was looking at this yesterday, and this already answers some of the >> questions I had, thanks Victor :-) The cry to drop RC4 as quick as >> possible seems to be getting stronger again this week, but of course in >> SMTP interop it's never that simple. And then there's the BEAST attack, >> which RC4 seems to be immune to? > > The BEAST, CRIME, ... attacks are HTTPS specific, and do not > generally apply to other TLS applications, in particular they are > not relevant to SMTP. Ah, I thought I had read that it affected other applications as well, must have misunderstood, thanks. >> One could in theory disable only the MD5 based RC4 ciphers for now, as >> they are not used by the ECDHE based options? > > SMTP servers don't know whether the client is doing opportunistic > TLS or authenticating the server. They should generally allow all > ciphersuites on port 25 (they can if desired switch from client > cipher order to server cipher order). Shrinking the server cipherlist > increases the odds of plaintext re-transmission with little gain. > Port 25 TLS security is in the hands of the client. On 587, servers > can be more selective. > >> We did disable SSLv3 for incoming connections yesterday, as TLS >> connection statistics over August suggest that they make up only 0,005% >> of the total. > > 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. 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. It may simply turn out to be misguided paranoia, however ;-) >> May do the same for outgoing connections. > > This is more reasonable, provided systems you send mail to all > support TLSv1 and up. What fraction of outbound handshakes end up > with SSLv3? I'll have a look, I only checked for incoming connections yesterday. > 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. > 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? Mvg, Joni
