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
p@rick
On 02/20/2015 07:26 PM, 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
How about support (as a fallback) for older clients? How "safe" (no pun intended) is it to disable as of today?
Kind regards, Stefan
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.
* Stefan Neufeind dane-users@stefan-neufeind.de:
On 02/20/2015 07:26 PM, 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
How about support (as a fallback) for older clients? How "safe" (no pun intended) is it to disable as of today?
There RFC states no fallback should be made:
If the TLS client only offers RC4 cipher suites, the TLS server MUST terminate the handshake. The TLS server MAY send the insufficient_security fatal alert in this case.
We've been running large (ISP) sites without RC4 and aNull for more than a year without any trouble. Personally I wouldn't hesitate to disable both. YMMV.
p@rick
Its simple: fallback = a MITM attacker can force fallback = youre pwned...
On 20 Feb 2015, at 19:42, Stefan Neufeind dane-users@stefan-neufeind.de wrote:
On 02/20/2015 07:26 PM, 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
How about support (as a fallback) for older clients? How "safe" (no pun intended) is it to disable as of today?
Kind regards, Stefan
Andreas Fink
CEO DataCell ehf CEO Backbone ehf
--------------------------------------------------------------- Tel: +41-61-6666330 Fax: +41-61-6666331 Mobile: +41-79-2457333 Address: Clarastrasse 3, 4058 Basel, Switzerland E-Mail: andreas@fink.org www.datacell.com, www.backbone.is, www.finkconsulting.com www.fink.org --------------------------------------------------------------- Jabber/XMPP: andreas@fink.org ICQ: 8239353 Skype: andreasfink
Support the reboot of the internet into secure mode: http://bootstrap.is http://bootstrap.is/
On Fri, Feb 20, 2015 at 07:54:01PM +0100, Patrick Ben Koetter wrote:
We've been running large (ISP) sites without RC4 and aNull for more than a year without any trouble. Personally I wouldn't hesitate to disable both. YMMV.
I also think that disabling anonymous Diffie-Hellman on SMTP servers is not a good idea or is at least pointless.
http://www.ietf.org/mail-archive/web/uta/current/msg01029.html
SMTP clients should IMHO only drop anonymous ciphersuites from their TLS cipherlist if they are planning to do *something* with the certificate.
On Fri, Feb 20, 2015 at 06:47:09PM +0000, Viktor Dukhovni wrote:
a broken 3DES implementation. They prefer RC4. If you drop RC4, you lose interoperability with these systems.
well, you might end up sending the message in the clear. Whether that's better or worse than RC4 depends on the perception of both the sender and the receiver. However, if they desparately care, they might encrypt end2end.
I would wait to disable RC4 for another 2-3 years. With
The RFC first and foremost gives _implementations_ (libs and apps) a hook to cease supporting RC4, so depending on sw vendors and maintainers (and your sw update cycle), you might not have these 2-3 years.
-Peter
On Fri, Feb 20, 2015 at 08:01:09PM +0100, Andreas Fink wrote:
How about support (as a fallback) for older clients? How "safe" (no pun intended) is it to disable as of today?
Its simple: fallback = a MITM attacker can force fallback = youre pwned...
Depends on what one one means by "fallback". When RC4 is enabled at a low preference MITM attackers cannot re-order the handshake without invalidating the TLS "finished" message.
I should be noted that, occasional bilateral security arrangements aside, MTA to MTA SMTP is generally vulnerable to MiTM attacks regardless of whether RC4 is enabled or not.
With DANE, SMTP client MTAs can also authenticate servers for which no prior security settings exist, and in *that* case we have a fairly MiTM resistant protocol.
In Postfix for peers that publish TLSA RRs, the "mandatory" TLS protocol, cipher and exclusion lists apply.
By all means, try:
smtp_tls_mandatory_protocols = !SSLv2, !SSLv3 smtp_tls_mandatory_exclude_ciphers = RC4
If there are any domains that publish TLSA records for an SMTP server that is capable only of legacy crypto, both they and I will be surprised.
On Fri, Feb 20, 2015 at 08:10:10PM +0100, Peter Koch wrote:
I would wait to disable RC4 for another 2-3 years. With
The RFC first and foremost gives _implementations_ (libs and apps) a hook to cease supporting RC4, so depending on sw vendors and maintainers (and your sw update cycle), you might not have these 2-3 years.
Yes, there is a proposal on the openssl-dev list to reclassify RC4 from "MEDIUM" to "LOW" in the upcoming (end of 2015) 1.1.0 release. I've vocally opposed making this change in the library.
As for applications, Postfix has not disabled RC4 in 3.0.x (2015 release) and will not likely do so in 3.1.x (2016 release).
So I'm working on giving Postfix users the necessary time to not force them into work-arounds.
Though admittedly sending *to* Exchange 2003 (as opposed to receiving from Exchange 2003) already requires some tweaks, because this implementation only looks at the top 64 ciphersuites in the client's proposal, and with OpenSSL 1.0.1 and later RC4-SHA is no longer in the top 64 by default.
One needs to "radically" trim the cipherlist to interoperate with Exchange 2003 receiving systems.
The following trims the list down to just around 50 elements (OpenSSL master branch, fewer with some older releases) above RC4-SHA.
# the "high" and "null" cipherlists don't have RC4, so can be # left alone. # tls_export_cipherlist = aNULL:-aNULL:ALL:-RC4:RC4-SHA:@STRENGTH tls_low_cipherlist = aNULL:-aNULL:ALL:!EXPORT:-RC4:RC4-SHA:@STRENGTH tls_medium_cipherlist = aNULL:-aNULL:ALL:!EXPORT:!LOW:-RC4:RC4-SHA:@STRENGTH
smtp_tls_exclude_ciphers = # # No longer used cipher grades # EXPORT, LOW, # # No longer used symmetric algorithms # 3DES, IDEA, # # No longer used digest # MD5, # # Nobody uses DSS # aDSS, aDH, # # SMTP servers don't generally do shared secret key agreement. # SRP, PSK, # # These are too exotic and perhaps slated for deprecation # kECDHr, kECDHe
Teilnehmer (5)
-
Andreas Fink -
Patrick Ben Koetter -
Peter Koch -
Stefan Neufeind -
Viktor Dukhovni