On Sep 11, 2013, at 16:34, Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
> On Wed, Sep 11, 2013 at 01:26:25PM +0200, Ralf Hildebrandt wrote: > >>> Anyone has tested such server in real life ? >>> >>> http://sealedabstract.com/code/nsa-proof-your-e-mail-in-2-hours/ >> >> I finally got around reading this. >> >> I wonder if it should be more strict regaring the used ciphers (both >> in Postfix and Dovecot), given that it's for self-hosting only. > > With opportunistic TLS, reducing the set of ciphers available always > reduces security, since when the handshake fails mail is subsequently > sent in the clear. The Postfix SMTP client and server cipherlists > are *ordered* sensibly, and with SSLv2 disabled (default), there > should be no downgrade attacks. > > It only makes sense to restrict the cipherlist to a more secure > subset when TLS is mandatory. The default cipher grade for mandatory > TLS is "medium". The "medium" grade is essentially just 128-bit RC4: > > AECDH-RC4-SHA SSLv3 Kx=ECDH Au=None Enc=RC4(128) Mac=SHA1 > ADH-RC4-MD5 SSLv3 Kx=DH Au=None Enc=RC4(128) Mac=MD5 > IDEA-CBC-SHA SSLv3 Kx=RSA Au=RSA Enc=IDEA(128) Mac=SHA1 > IDEA-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=IDEA(128) Mac=MD5 > RC2-CBC-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC2(128) Mac=MD5 > ECDHE-RSA-RC4-SHA SSLv3 Kx=ECDH Au=RSA Enc=RC4(128) Mac=SHA1 > ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 > ECDH-RSA-RC4-SHA SSLv3 Kx=ECDH/RSA Au=ECDH Enc=RC4(128) Mac=SHA1 > ECDH-ECDSA-RC4-SHA SSLv3 Kx=ECDH/ECDSA Au=ECDH Enc=RC4(128) Mac=SHA1 > RC4-SHA SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=SHA1 > RC4-MD5 SSLv3 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 > RC4-MD5 SSLv2 Kx=RSA Au=RSA Enc=RC4(128) Mac=MD5 > > so if not using RC4 is a requirement, raising the mandatory grade to > high can be tried with care, but the effect is not always necessarily for > the better: > > $ posttls-finger -c -L summary gmail.com > posttls-finger: Untrusted TLS connection established to > gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher > ECDHE-RSA-RC4-SHA (128/128 bits) > > $ posttls-finger -c -L summary -g high gmail.com > posttls-finger: Untrusted TLS connection established to > gmail-smtp-in.l.google.com[173.194.74.27]:25: TLSv1.1 with cipher AES128-SHA > (128/128 bits) > > So with "medium" you get RC4 with PFS, and with "high" you get > AES128 without PFS. Which is better, we don't know for sure. > > On a related note, in the Postfix SMTP client, I'd like at some > point to disable not only SSLv2, but also SSLv3, leaving only TLSv1 > and up enabled. This ensures that TLSv1 extensions are sent in > the SSL client HELO message. Extensions can signal the list of > supported EECDH curves, support for session tickets, ... > > The right time for this would probably be after OpenSSL 1.0.2 is > released, because then with an appropriate small change to Postfix, > the best EECDH curve can be negotiated, rather than fixed by the > server. > > 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? One could in theory disable only the MD5 based RC4 ciphers for now, as they are not used by the ECDHE based options? 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. Will see if that causes any trouble with the few big senders that seem to be stuck on SSLv3/RC4-MD5. May do the same for outgoing connections. Google seems to be only major user of 'ECDHE-RSA-RC4-SHA' at the moment, by the way, not seen that anywhere else. And the AES based ciphers make up the vast majority of connections seen. Mvg, Joni
