"dh key too small" error

[Joe Brennan]

This week our mail servers began getting "TLS handshake failed" when sending to various mail systems. The problem is definitely the DH keys situation as logged--

Jul 8 09:37:35 oats sendmail[2749]: STARTTLS=client: 2749:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:2429:

The problem is I can't figure out how to fix it. Please note we are the client, sending.

I am sorry to see how old the RHEL5 stuff is but this is what we're dealing with:

OATS> /usr/sbin/sendmail -d0.1
Version 8.13.8
Compiled with: DNSMAP HESIOD HES_GETMAILHOST LDAPMAP LOG MAP_REGEX
MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6
NETUNIX NEWDB NIS PIPELINING SASLv2 SCANF SOCKETMAP STARTTLS
TCPWRAPPERS USERDB USE_LDAP_INIT

OATS> openssl version
OpenSSL 0.9.8e-fips-rhel5 01 Jul 2008



Following http://serverfault.com/questions/700655/sendmail-rejecting-some-connections-with-handshake-failure-ssl-alert-number-40 I did

openssl dhparam -out /etc/mail/ssl/dhparams.pem 1024

LOCAL_CONFIG
O CipherList=HIGH:!ADH
O DHParameters=/etc/mail/ssl/dhparams.pem
O ClientSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3

and generated sendmail.cf, but this does not improve the situation.


Would you think the problem is in the openssl library, or the old sendmail, or a sendmail configuration?


-- Joseph Brennan
Columbia University

[Claus Aßmann]

Joe Brennan wrote:

> Jul 8 09:37:35 oats sendmail[2749]: STARTTLS=client: 2749:error:14082174:SSL
> routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:2429:

> The problem is I can't figure out how to fix it. Please note we are the client, sending.

Contact the people who maintain those servers and tell them to fix
their setup.

> openssl dhparam -out /etc/mail/ssl/dhparams.pem 1024

That doesn't help anything on the client side.

8.15.2/8.15.2 2015/07/03
...
DHParameters now by default uses an included 2048 bit prime.
...
Also note that this option applies to the server side only.

> Would you think the problem is in the openssl library, or the old sendmail, or a sendmail
> configuration?

Newer openssl versions enforce a lower limit (768 bits?), so you could
say it's their fault...

You could try to disable the use of DH ciphers, but that's just another
ugly hack... (and breaks PFS with sites that are properly configured).
If you would use a recent sendmail version, you could set the ciphers per
host...


BTW: that LOCAL_CONFIG stuff is ugly, please see cf/README how
to use the proper mc features.
It's always great to see that kind of bad advice one some website...

--
Note: please read the netiquette before posting. I will almost never
reply to top-postings which include a full copy of the previous
article(s) at the end because it's annoying, shows that the poster
is too lazy to trim his article, and it's wasting the time of all readers.

[Joe Brennan]

On Wednesday, July 8, 2015 at 11:20:03 AM UTC-4, Claus Aßmann -no-copies-please wrote:

> Contact the people who maintain those servers and tell them to fix
> their setup.

I agree in principle, but there are too many. We have mail queued for about 30 domains that keep giving this error. I'm not eager to make special rules per domain. No end to it.

Credit to utoronto.ca who did do something to fix this at their end after a few days.

So we don't have a generic workaround? Sometimes we have to deal with ugly reality. The few remote servers I've checked are willing to accept mail with NO encryption.

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 08 Jul 2015 10:46:05 -0700, Joe Brennan wrote:

> So we don't have a generic workaround? Sometimes we have to deal with
> ugly
> reality. The few remote servers I've checked are willing to accept
> mail
> with NO encryption.

http://www.circleid.com/posts/20150620_logjam_openssl_and_email_delivera
bility

Exim apparently (by default) falls back to unencrypted delivery on tls
handshake failures.

- From a discussion on [mailop], Google stopped doing such fallback over 2
years ago. As far as key lengths, Google "expects to in the near future"
refuse to deliver to hosts with 512 bit DH keys. There was no indication
of what "near future" means to Google in this context.

For now, I periodically run a script using

grep 'Deferred: 403 4.7.0 TLS handshake failed' maillog

which adds appropriate "Try_TLS:target NO" entries in
/etc/mail/access.db

That allows our systems to deliver to those targets. Once Google starts
to refuse delivery to them, we can remove those entries.




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlWpeJMACgkQL6j7milTFsGWaQCfW8AL116S4RZqbkkCH1yDLJtJ
+PAAnjwa1LRC7Sz7fY96tNnmSsKJwzPs
=Hzgr
-----END PGP SIGNATURE-----

[Claus Aßmann]

Carl Byington wrote:

> Exim apparently (by default) falls back to unencrypted delivery on tls
> handshake failures.

postfix does that too.
sendmail can be "programmed" via rules to do that -- I haven't included
that patch because I didn't have the time to write tests for it and
haven't checked the interaction with TLS enforcements.

[marcus....@gmail.com]

Hi Carl,

Am Freitag, 17. Juli 2015 23:51:30 UTC+2 schrieb Carl Byington:
>
> For now, I periodically run a script using
>
> grep 'Deferred: 403 4.7.0 TLS handshake failed' maillog
>
> which adds appropriate "Try_TLS:target NO" entries in
> /etc/mail/access.db

Could you post your script please? :)

Thanks
Marcus

[Carl Byington]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tue, 21 Jul 2015 14:52:14 -0700, marcus.schopen wrote:

> Could you post your script please? :)

#!/bin/bash

cd /var/log
d=$(date)
grep 'delay=01.*Deferred: 403 4.7.0 TLS handshake failed' maillog | \
rev | cut -d' ' -f8 | rev | \
cut -c2- | cut -d']' -f1 | \
while read ip; do
echo "## weak DH key, $d" >>/etc/mail/access
echo "Try_TLS:$ip NO" >>/etc/mail/access
done

cd /etc/mail
make

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iEYEARECAAYFAlWwBt8ACgkQL6j7milTFsGPcwCfaiKzj50TIxiKeyFPoZCn4uHR
0w8An2LI9Vk31+GbTa9osAMrjAqMAhJX
=h9M7
-----END PGP SIGNATURE-----

[Claus Aßmann]

Untested, unofficial, not really supported, [add more disclaimers here]
patch is available at
http://www.sendmail.org/%7Eca/email/patches/tls_failures.p1
Problems should be reported here or at the usual support address.

[Kelsey Cummings]

On 07/17/15 14:50, Carl Byington wrote:
> For now, I periodically run a script using
>
> grep 'Deferred: 403 4.7.0 TLS handshake failed' maillog
>
> which adds appropriate "Try_TLS:target NO" entries in
> /etc/mail/access.db

FWIW, we've done the same things for years.

-K