TLS issues with old Exchange Servers

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

TLS issues with old Exchange Servers

Matthias Schneider
Hello,

I noticed that many Exchange Servers nowadays have problems with TLS. Is
there a way to make a fallback to plain if there is a timeout on MAIL
FROM? I currently use smtp_tls_security_level=may

I found some 100's domains on different IPs which have this problems
right now, here is a example server:

15F5450139E: to=<[hidden email]>,
relay=mail.kindersleytransport.com[207.195.36.62]:25, delay=244097,
delays=244096/0/1.1/0.16, dsn=4.4.2, status=deferred (lost connection
with mail.kindersleytransport.com[207.195.36.62] while sending MAIL FROM)

I can also verify this when i do a "openssl s_client -starttls smtp
-connect mail.kindersleytransport.com:25 -debug"
the TLS initiation works but when you enter MAIL FROM: [hidden email]
you will get an timeout.
When using just a simple telnet without TLS, sending mails will work fine!

all this servers are showing the same (old?) version: "Microsoft ESMTP
MAIL Service, Version: 6.0.3790.4675"
Maybe there is a way to disable STARTTLS when this prompt is shown?

Best regards

Matthias Schneider

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

Robert Schetterer-2
Am 05.01.2015 um 15:10 schrieb Matthias Schneider:

> Hello,
>
> I noticed that many Exchange Servers nowadays have problems with TLS. Is
> there a way to make a fallback to plain if there is a timeout on MAIL
> FROM? I currently use smtp_tls_security_level=may
>
> I found some 100's domains on different IPs which have this problems
> right now, here is a example server:
>
> 15F5450139E: to=<[hidden email]>,
> relay=mail.kindersleytransport.com[207.195.36.62]:25, delay=244097,
> delays=244096/0/1.1/0.16, dsn=4.4.2, status=deferred (lost connection
> with mail.kindersleytransport.com[207.195.36.62] while sending MAIL FROM)
>
> I can also verify this when i do a "openssl s_client -starttls smtp
> -connect mail.kindersleytransport.com:25 -debug"
> the TLS initiation works but when you enter MAIL FROM: [hidden email]
> you will get an timeout.
> When using just a simple telnet without TLS, sending mails will work fine!
>
> all this servers are showing the same (old?) version: "Microsoft ESMTP
> MAIL Service, Version: 6.0.3790.4675"
> Maybe there is a way to disable STARTTLS when this prompt is shown?
>
> Best regards
>
> Matthias Schneider
>

you may workaround with transport
and special target tls_policy

Best Regards
MfG Robert Schetterer

--
[*] sys4 AG

http://sys4.de, +49 (89) 30 90 46 64
Franziskanerstraße 15, 81669 München

Sitz der Gesellschaft: München, Amtsgericht München: HRB 199263
Vorstand: Patrick Ben Koetter, Marc Schiffbauer
Aufsichtsratsvorsitzender: Florian Kirstein
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

Viktor Dukhovni
In reply to this post by Matthias Schneider
On Mon, Jan 05, 2015 at 03:10:49PM +0100, Matthias Schneider wrote:

> I noticed that many Exchange Servers nowadays have problems with TLS. Is
> there a way to make a fallback to plain if there is a timeout on MAIL FROM?

Postfix 2.12 (almost released, but for now 2.12-20141228 is the
latest snapshot) will by default retry in cleartext when TLS data
transfer fails, in most cases after initially deferring the message.

http://permalink.gmane.org/gmane.mail.postfix.user/243401

http://archives.neohapsis.com/archives/postfix/2013-11/0121.html

https://www.ietf.org/mail-archive/web/tls/current/msg10471.html

You can configure your SMTP client with:

    -o tls_export_cipherlist=aNULL+AES128:aRSA+AES128:RC4-SHA:STRENGTH

This selects a cipherlist that is something like:

    AECDH-AES128-SHA        SSLv3 Kx=ECDH       Au=None Enc=AES(128)  Mac=SHA1
    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
    ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
    ADH-AES128-SHA          SSLv3 Kx=DH         Au=None Enc=AES(128)  Mac=SHA1
    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) Mac=AEAD
    ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
    ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH       Au=RSA  Enc=AES(128)  Mac=SHA1
    SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP        Au=RSA  Enc=AES(128)  Mac=SHA1
    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
    DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
    DHE-RSA-AES128-SHA      SSLv3 Kx=DH         Au=RSA  Enc=AES(128)  Mac=SHA1
    AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
    AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
    AES128-SHA              SSLv3 Kx=RSA        Au=RSA  Enc=AES(128)  Mac=SHA1
    RC4-SHA                 SSLv3 Kx=RSA        Au=RSA  Enc=RC4(128)  Mac=SHA1

With RC4-SHA early enough for the 11-year old Microsoft Exchange
servers.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
On 05 Jan 2015, at 15:52, Viktor Dukhovni <[hidden email]> wrote:

> On Mon, Jan 05, 2015 at 03:10:49PM +0100, Matthias Schneider wrote:
>
>> I noticed that many Exchange Servers nowadays have problems with TLS. Is
>> there a way to make a fallback to plain if there is a timeout on MAIL FROM?
>
> Postfix 2.12 (almost released, but for now 2.12-20141228 is the
> latest snapshot) will by default retry in cleartext when TLS data
> transfer fails, in most cases after initially deferring the message.
>
> http://permalink.gmane.org/gmane.mail.postfix.user/243401
>
> http://archives.neohapsis.com/archives/postfix/2013-11/0121.html
>
> https://www.ietf.org/mail-archive/web/tls/current/msg10471.html
>
> You can configure your SMTP client with:
>
>    -o tls_export_cipherlist=aNULL+AES128:aRSA+AES128:RC4-SHA:STRENGTH
>
> This selects a cipherlist that is something like:
>
>    AECDH-AES128-SHA        SSLv3 Kx=ECDH       Au=None Enc=AES(128)  Mac=SHA1
>    ADH-AES128-GCM-SHA256   TLSv1.2 Kx=DH       Au=None Enc=AESGCM(128) Mac=AEAD
>    ADH-AES128-SHA256       TLSv1.2 Kx=DH       Au=None Enc=AES(128)  Mac=SHA256
>    ADH-AES128-SHA          SSLv3 Kx=DH         Au=None Enc=AES(128)  Mac=SHA1
>    ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA  Enc=AESGCM(128) Mac=AEAD
>    ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH     Au=RSA  Enc=AES(128)  Mac=SHA256
>    ECDHE-RSA-AES128-SHA    SSLv3 Kx=ECDH       Au=RSA  Enc=AES(128)  Mac=SHA1
>    SRP-RSA-AES-128-CBC-SHA SSLv3 Kx=SRP        Au=RSA  Enc=AES(128)  Mac=SHA1
>    DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH     Au=RSA  Enc=AESGCM(128) Mac=AEAD
>    DHE-RSA-AES128-SHA256   TLSv1.2 Kx=DH       Au=RSA  Enc=AES(128)  Mac=SHA256
>    DHE-RSA-AES128-SHA      SSLv3 Kx=DH         Au=RSA  Enc=AES(128)  Mac=SHA1
>    AES128-GCM-SHA256       TLSv1.2 Kx=RSA      Au=RSA  Enc=AESGCM(128) Mac=AEAD
>    AES128-SHA256           TLSv1.2 Kx=RSA      Au=RSA  Enc=AES(128)  Mac=SHA256
>    AES128-SHA              SSLv3 Kx=RSA        Au=RSA  Enc=AES(128)  Mac=SHA1
>    RC4-SHA                 SSLv3 Kx=RSA        Au=RSA  Enc=RC4(128)  Mac=SHA1
>
> 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.

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
==

HTH,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

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.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

lists@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?
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
In reply to this post by Viktor Dukhovni
On 05 Jan 2015, at 18:47, Viktor Dukhovni <[hidden email]> wrote:

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

Ah, I remember now ... My bad. You are indeed correct, the override was
to disable 3DES altogether for that box.

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

Viktor Dukhovni
In reply to this post by lists@rhsoft.net
On Mon, Jan 05, 2015 at 06:59:06PM +0100, [hidden email] wrote:

> >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?

The goal of opportunistic TLS in Postfix is to deliver email with
as much and no more security than is available.  There is no agenda.

With Postfix 2.12 such servers will receive mail (slightly delayed)
without manual intervention.

The number of domains that don't support either AES or CAMELLIA,
but do have working RC4 or 3DES is probably quite low.  So if you
disable RC4, 3DES (and presumably all LOW and EXPORT ciphers) in
the SMTP client the impact should be small, but this should not be
necessary.

Gmail's outbound servers prefers RC4-SHA if offered by the SMTP
server, when Gmail drops RC4 support, these domains will finally
feel real pressure to either disable or fix their TLS stack.

--
        Viktor.
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
In reply to this post by lists@rhsoft.net
On 05 Jan 2015, at 18:59, [hidden email] wrote:

> 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?

Exchange 2003 has been EOL since May 2014, and Exchange 2007 and higher
should not have this problem if deployed on Windows Server 2008 or up,
as the core dependency is not Exchange but the Schannel component.

For Exchange 2007 on Windows Server 2003, if those exist; Windows
Server 2003 will be EOL on July 14th this year, so I would suggest
keeping the workaround (disabling 3DES for the SMTP client) active till
then, announce that support will be phased out at least three months in
advance, and then drop it like a rock at the end of July.

Because by that time, they really shouldn't be directly connected to
the Internet anymore, or at the very least paying a premium to keep the
workarounds in place :-/

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

Per Thorsheim
In reply to this post by lists@rhsoft.net
Den 05.01.2015 18:59, skrev [hidden email]:

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

.per

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
In reply to this post by Viktor Dukhovni
On 05 Jan 2015, at 19:18, Viktor Dukhovni <[hidden email]> wrote:

> On Mon, Jan 05, 2015 at 06:59:06PM +0100, [hidden email] wrote:
>
>>> 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?
>
> The goal of opportunistic TLS in Postfix is to deliver email with
> as much and no more security than is available.  There is no agenda.
>
> With Postfix 2.12 such servers will receive mail (slightly delayed)
> without manual intervention.
>
> The number of domains that don't support either AES or CAMELLIA,
> but do have working RC4 or 3DES is probably quite low.  So if you
> disable RC4, 3DES (and presumably all LOW and EXPORT ciphers) in
> the SMTP client the impact should be small, but this should not be
> necessary.
>
> Gmail's outbound servers prefers RC4-SHA if offered by the SMTP
> server, when Gmail drops RC4 support, these domains will finally
> feel real pressure to either disable or fix their TLS stack.

Gmail prefers ECDHE-RSA-AES256-SHA, and has for quite some time now, if
your inbound MTA supports and encourages it.

RC4-SHA and SSLv3 have practically disappeared, but 3DES is still quite
active for delivery. We have several customer backend servers that do
poorly with incoming connections, preferring older protocols and
ciphers, while their outgoing connections negotiate much better terms.

TLSv1.2 accounts for a higher percentage of connections than TLSv1 now,
too.

Of course, this is us. YMMV.

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

lists@rhsoft.net

Am 05.01.2015 um 19:43 schrieb DTNX Postmaster:

> On 05 Jan 2015, at 19:18, Viktor Dukhovni <[hidden email]> wrote:
>> On Mon, Jan 05, 2015 at 06:59:06PM +0100, [hidden email] wrote:
>>
>>>> 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?
>>
>> The goal of opportunistic TLS in Postfix is to deliver email with
>> as much and no more security than is available.  There is no agenda.
>>
>> With Postfix 2.12 such servers will receive mail (slightly delayed)
>> without manual intervention.
>>
>> The number of domains that don't support either AES or CAMELLIA,
>> but do have working RC4 or 3DES is probably quite low.  So if you
>> disable RC4, 3DES (and presumably all LOW and EXPORT ciphers) in
>> the SMTP client the impact should be small, but this should not be
>> necessary.
>>
>> Gmail's outbound servers prefers RC4-SHA if offered by the SMTP
>> server, when Gmail drops RC4 support, these domains will finally
>> feel real pressure to either disable or fix their TLS stack.
>
> Gmail prefers ECDHE-RSA-AES256-SHA, and has for quite some time now, if
> your inbound MTA supports and encourages it.

no true back in 2014/10

at least not without "tls_preempt_cipherlist = yes" and after that AES
was used, there are a few servers out there which are completly broken
and need DES or RC4 or fail completly to deliver

hence the settings below on the inbound MX turned out to receive 99% of
all mail encrypted and a few senders fall back to unencrypted which
previously failed to deliver until re-enable DES-SHA1

tls_preempt_cipherlist = yes
smtpd_tls_mandatory_ciphers = medium
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_ciphers = medium
smtpd_tls_protocols = !SSLv2, !SSLv3
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = EXP, IDEA, KRB5, MD5, RC2, RC4, SEED, SRP,
ECDH+ECDSA, ECDHE-RSA-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA,
EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA

> RC4-SHA and SSLv3 have practically disappeared, but 3DES is still quite
> active for delivery. We have several customer backend servers that do
> poorly with incoming connections, preferring older protocols and
> ciphers, while their outgoing connections negotiate much better terms.

i face the opposite, see above

> TLSv1.2 accounts for a higher percentage of connections than TLSv1 now,
> too.

correct
Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
In reply to this post by Per Thorsheim
On 05 Jan 2015, at 19:33, Per Thorsheim <[hidden email]> wrote:

> Den 05.01.2015 18:59, skrev [hidden email]:
>>
>> 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 | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

DTNX Postmaster
In reply to this post by lists@rhsoft.net
On 05 Jan 2015, at 19:51, [hidden email] wrote:

>>> Gmail's outbound servers prefers RC4-SHA if offered by the SMTP
>>> server, when Gmail drops RC4 support, these domains will finally
>>> feel real pressure to either disable or fix their TLS stack.
>>
>> Gmail prefers ECDHE-RSA-AES256-SHA, and has for quite some time now, if
>> your inbound MTA supports and encourages it.
>
> no true back in 2014/10

I sampled a few days in October, and they all show the same cipher as I
listed above, no others. This is with "tls_preempt_cipherlist = yes"
active, which we've had since for almost a year now.

> at least not without "tls_preempt_cipherlist = yes" and after that AES was used, there are a few servers out there which are completly broken and need DES or RC4 or fail completly to deliver
>
> hence the settings below on the inbound MX turned out to receive 99% of all mail encrypted and a few senders fall back to unencrypted which previously failed to deliver until re-enable DES-SHA1
>
> tls_preempt_cipherlist = yes
> smtpd_tls_mandatory_ciphers = medium
> smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
> smtpd_tls_ciphers = medium
> smtpd_tls_protocols = !SSLv2, !SSLv3
> smtpd_tls_eecdh_grade = strong
> smtpd_tls_exclude_ciphers = EXP, IDEA, KRB5, MD5, RC2, RC4, SEED, SRP, ECDH+ECDSA, ECDHE-RSA-DES-CBC3-SHA, ECDH-RSA-DES-CBC3-SHA, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CBC3-SHA

Unless there's some unique configuration that breaks delivery, and
requires an override, I would recommend against using those settings.
Otherwise it's basically premature optimization, which quite often
leads to less reliable delivery.

These are the relevant TLS settings on our relay servers, from
'postconf -n';

==
smtp_tls_exclude_ciphers = EXPORT, LOW
smtp_tls_loglevel = 1
smtp_tls_protocols = !SSLv2
smtp_tls_security_level = may
smtpd_tls_dh1024_param_file = /etc/postfix/dh_2048.pem
smtpd_tls_dh512_param_file = /etc/postfix/dh_512.pem
smtpd_tls_eecdh_grade = strong
smtpd_tls_exclude_ciphers = EXPORT, LOW
smtpd_tls_loglevel = 1
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2
smtpd_tls_received_header = no
smtpd_tls_security_level = may
tls_preempt_cipherlist = yes
==

Minimal interference with the Postfix defaults, while still encouraging
the use of modern ciphers. Which works out very well so far; RC4 or
SSLv3 isn't used a whole lot, but still available if it's the only
non-plaintext option.

We are seeing 'EDH-RSA-DES-CBC3-SHA' for incoming mail as well, by the
way. It may not be the best option available, but certainly not the
worst. Why prevent its usage?

Oh, and as far as ECDSA is concerned; AFAIK, those won't be used unless
you have a ECDSA certificate, in which case you want those ciphers
available. No gain from excluding those, if I am not mistaken?

Mvg,
Joni

Reply | Threaded
Open this post in threaded view
|

Re: TLS issues with old Exchange Servers

lists@rhsoft.net

Am 05.01.2015 um 20:23 schrieb DTNX Postmaster:

> On 05 Jan 2015, at 19:51, [hidden email] wrote:
>
>>>> Gmail's outbound servers prefers RC4-SHA if offered by the SMTP
>>>> server, when Gmail drops RC4 support, these domains will finally
>>>> feel real pressure to either disable or fix their TLS stack.
>>>
>>> Gmail prefers ECDHE-RSA-AES256-SHA, and has for quite some time now, if
>>> your inbound MTA supports and encourages it.
>>
>> no true back in 2014/10
>
> I sampled a few days in October, and they all show the same cipher as I
> listed above, no others. This is with "tls_preempt_cipherlist = yes"
> active, which we've had since for almost a year now

where you confirm that Gmain *do not* prefer ECDHE-RSA-AES256-SHA beause
otherwise "tls_preempt_cipherlist = yes" would not be needed

to my (now stripped) smtpd TLS settings:

* there are no delivery errors over months
* only 0.5% of client fall back to plain
* no security auditor or scanner complains any longer