Fwd: SEMI-OT: Prohibiting RC4 Cipher Suites

Andreas Fink afink at list.fink.org
Fri Feb 20 20:25:43 CET 2015


Side question: why is there a reply to: ietf-dane at sys4.de <mailto:ietf-dane at sys4.de> in the post. Hitting simple reply makes it fail.

> 
> On 20 Feb 2015, at 20:15, Viktor Dukhovni <ietf-dane at dukhovni.org <mailto:ietf-dane at dukhovni.org>> wrote:
> 
> On Fri, Feb 20, 2015 at 08:01:09PM +0100, Andreas Fink wrote:
> 
> 
> Depends on what one  one means by "fallback".
>>> 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...
>> 

Fall back in the sense of we tell the end user it was transported in a secure way but actually insecure encryption was used by the server and the MITM was able to decode it. If its acceptable to transfer in the clear in case TLS fails is something the mail operator might choose or not and it depends also on the specific link. For example I could say I know google mail supports TLS so only TLS would be permitted in my config but then if TLS steps down to RC4, i'm no longer protected from that assumption.

>  When RC4 is enabled
> at a low preference MITM attackers cannot re-order the handshake
> without invalidating the TLS "finished" message.

Why this? a MITM attack implies the man in the middle terminates the TLS and thus he would in above example "mimic" the google mailserver's behaviour and simply would only offer RC4 inbound. Your sending mailserver would accept that as only option and use RC4 to deliver. So there's no "reordering" as its the only option provided. On the outbound connection, he simply would use a secure connection as usual to pass through the commands.


> 
> 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.
> 
> --
> 	Viktor.
> 
> 


--

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 at fink.org
www.datacell.com, www.backbone.is, www.finkconsulting.com www.fink.org
---------------------------------------------------------------
Jabber/XMPP: andreas at fink.org
ICQ: 8239353 Skype: andreasfink

Support the reboot of the internet into secure mode:  http://bootstrap.is <http://bootstrap.is/>


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.sys4.de/cgi-bin/mailman/private/dane-users/attachments/20150220/f7e25026/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 872 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://mail.sys4.de/cgi-bin/mailman/private/dane-users/attachments/20150220/f7e25026/attachment-0001.pgp>


More information about the dane-users mailing list