On Fri, Feb 20, 2015 at 07:26:00PM +0100, Patrick Ben Koetter wrote:
A little off topic for DANE users, but somehow in scope. You might consider disabling RC4 in your servers cipher suite. IETF released an RFC requiring
(...) that Transport Layer Security (TLS) clients and servers never negotiate the use of RC4 cipher suites when they establish connections. This applies to all TLS versions. This document updates RFCs 5246, 4346, and 2246. -- Prohibiting RC4 Cipher Suites, https://tools.ietf.org/rfc/rfc7465.txt
However, this is not a good fit for opportunistic TLS in SMTP.
Leave RC4 enabled for now, there are still MTAs (mostly Microsoft Exchange 2003) in the field that can only do RC4-SHA, RC4-MD5 or a broken 3DES implementation. They prefer RC4. If you drop RC4, you lose interoperability with these systems.
I would wait to disable RC4 for another 2-3 years. With Postfix one might do this instead:
# Assumption, anyone with working 3DES can also do either AES # or RC4 with RC4 as the only remaining option rather rare. # smtpd_tls_exclude_ciphers = EXPORT, LOW, MD5, 3DES tls_preempt_cipherlist = yes
with these settings, the server chooses the best ciphersuite proposed by the client based on its own preference order, not the client's. By disabling no longer used EXPORT and <=64 bit (LOW) ciphers *and* 3DES, you still interoperate with any machines that only do RC4, but it is only used as a *last* resort.
Fully disabling RC4 loses connectivity with some sites or best case downgrades some email to cleartext instead, which is not more secure than RC4.
Admittedly, if the server honours the clients cipherlist preferences (default OpenSSL behaviour and also Postfix default tls_preempt_cipherlist = no), then you might sometimes negotiate RC4 with clients that can do AES, but chose to propose RC4 at a higher preference.
If you see evidence of this in your logs, you can apply the above work-around, otherwise just leave things as they are.