On 05 Jan 2015, at 19:33, Per Thorsheim <p...@thorsheim.net> wrote:

> Den 05.01.2015 18:59, skrev li...@rhsoft.net:
>> 
>> Am 05.01.2015 um 18:47 schrieb Viktor Dukhovni:
>>> On Mon, Jan 05, 2015 at 06:01:03PM +0100, DTNX Postmaster wrote:
>>> 
>>>>> With RC4-SHA early enough for the 11-year old Microsoft Exchange
>>>>> servers.
>>>> 
>>>> Sadly, older Exchange servers (2003 at least) will favour 3DES over RC4
>>>> for TLS connections, IIRC.
>>> 
>>> This is not correct.
>>> 
>>>> I don't have the fix we used on hand, as our oldest supported Exchange
>>>> version is 2010 these days, but we had an override of some sort that
>>>> required forcing 'DES-CBC3-SHA' for that specific box.
>>>> 
>>>> You can specify that as 'DES-CBC3-SHA', or select with something like
>>>> this;
>>>> 
>>>> ==
>>>> $ openssl ciphers -v 'RSA+3DES'
>>>> DES-CBC3-SHA            SSLv3 Kx=RSA      Au=RSA  Enc=3DES(168) Mac=SHA1
>>> 
>>> No, this is a bad idea, it is in fact 3DES that is broken with such
>>> servers
>> 
>> shouldn't we start to disable RC4 as well as DES-CBC3-SHA for that
>> horrible outdated crap servers and fallback to unencrypted at all
>> instead continue to work around them years again?
> 
> I wouldn't mind name & shame those who are running outdated crap
> servers, with automail to postmaster or something. Progress is made
> faster imho that way, instead of trying to be backwards compatible with
> *anything*. Do plaintext instead.

It depends. I see no reason to enforce for incoming mail, for example. 
Even 'crap' crypto is still better than none at all, and the cost of 
continuing to support older ciphers such as 3DES is basically zero.

For outgoing mail however, at least where it concerns backend delivery 
from our own relays to client servers, we will start strongly 
encouraging our clients to move to better options, because this 
concerns security they expect from *us*.

However, for everything else that we deliver, Postfix already does a 
very good job of being backwards compatible, at no cost to us. So I 
don't really see the need to name and shame there, as it is in our 
experience basically always the important client that one of our 
clients depends on for a large chunk of their business ... there is 
nothing to gain from interfering.

If you want to start setting an example to improve the state of crypto 
on the 'Net, start with your web servers. That's where you actually can 
safely disable RC4 by now, and could make a case for disabling 3DES 
this summer.

Mvg,
Joni

Reply via email to