3

I posted this on askubuntu.com yesterday but haven't gotten any responses.

We run a production Ubuntu server that serves thousands of people per day. Sendmail is currently not working on this server. We've spent days trying to get it back up but we haven't found any solution yet.

There's currently a bug report that appears to be related to this problem, so it affects more people than just us.

Here's what we know.

On Sunday we ran updates on the server. The next day we found that sendmail was failing to send emails.

/var/log/sendmail.log reports "stat=Deferred" on every email entry.

It also occasionally repeats the following message:

STARTTLS=client, error:connect failed=-1, SSL_error=1, errno=0, retry=-1
STARTTLS=client: 7042:error:14082174:SSL routines:SSL3_CHECK_CERT_AND_ALGORITHM:dh key too small:s3_clnt.c:3338:ruleset=tls_server, arg1=SOFTWARE, relay=xxx.xxx.edu, reject=403 4.7.0 TLS handshake failed.

We checked the logs on the SMTP server and found the following:

06-25T10:57:20-06:00 gw26 sm-mta[17229]: STARTTLS=server, error: accept failed=0, SSL_error=1, errno=0, retry=-1
No explanation available 2015-06-25T10:57:20-06:00 gw26 sm-mta[17229]: STARTTLS=server: 17229:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1110:SSL alert number 40
Explain this log line 2015-06-25T10:57:20-06:00 gw26 sm-mta[17229]: t5PGvKk0017229: opus.byu.edu [128.187.102.135] did not issue MAIL/EXPN/VRFY/ETRN during connection to MTA

We have spent much time Googling around and have found several people with related problems on other operating systems (CentOS and OpenBSD). It appears that OpenSSL has been updated and now requires a longer SSL key to function properly.

This bug on launchpad page may be related.

We have attempted to fix the problem by following the CentOS instructions given here. NOTE: We changed the location of the new dhparams.pem file.

Generate DH parameters file on your server:

openssl dhparam -out /etc/pki/tls/certs/dhparams.pem 1024 Configure
sendmail to use this parameters file, and to use only strong ciphers.

Add to /etc/mail/sendmail.mc:

O LOCAL_CONFIG O CipherList=HIGH:!ADH
O DHParameters=/etc/pki/tls/certs/dhparams.pem 
O ServerSSLOptions=+SSL_OP_NO_SSLv2 +SSL_OP_NO_SSLv3
O SSL_OP_CIPHER_SERVER_PREFERENCE O ClientSSLOptions=+SSL_OP_NO_SSLv2 
O SSL_OP_NO_SSLv3

Then use make -C /etc/mail/ and service sendmail restart.

This did not appear to improve anything in any way.

Edit:

We turned off TLS by doing the following and sendmail instantly began functioning again. However, this isn't a solution, because we don't want to send plaintext emails.

Add Try_TLS:1.2.3.4 NO to /etc/mail/access.
Do a make in /etc/mail and restart sendmail.

Community
  • 1
Benjamin
  • 139
  • 3
  • 1
    Please DO NOT Crosspost to other SE groups! – mdpc Jun 26 '15 at 23:39
  • possible duplicate of [sendmail rejecting some connections with handshake failure: SSL alert number 40](http://serverfault.com/questions/700655/sendmail-rejecting-some-connections-with-handshake-failure-ssl-alert-number-40) – Mike B Jun 27 '15 at 21:55
  • @mdpc I wasn't aware of this rule. Where can I see it and other rules so I can familiarize myself? – Benjamin Jun 27 '15 at 22:22
  • @MikeB Not a duplicate. I actually link that exact post to say that the fix there didn't work for our server. It looks like a related issue though. – Benjamin Jun 27 '15 at 22:23

2 Answers2

2

As I understand this, the problem is that your OpenSSL upgrade has made you intolerant of other's short DH key lengths, in order to protect the conversation against the Logjam attack. That's why increasing your DH key length (openssl dhparam ..., etc.) did nothing to help, whilst turning off TLS did.

Obviously, what we'd all like is a flag to OpenSSL like --I'd-rather-my-mail-got-encrypted-even-if-the-NSA-are-reading-it-on-the-fly-so-just-shut-up-about-short-DH-keys-already. Sadly, this behaviour seems to be compiled into OpenSSL, the developers have not chosen to support a flag like the one I suggest, and sendmail seems not to have compiled into it the ability to deselect the ciphersuites that trigger this behaviour.

It also means that the long-term solution is for the other mail server's admins to upgrade their DH key length. You can turn off the use of TLS on a domain-by-domain basis, with access map entries like

Try_TLS:mail.example.com NO

(with thanks to novosial.org for that idea) if you can identify particular peers with whom you exchange a lot of email and whose admins are slow to respond. But as far as I know, if your server is (like mine) one of those that suddenly got picky about other people's crypto parameters, your ability to fix this is limited.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • This is an excellent response. We have already sent a request to the SMTP server administrator to increase his dh key size. I'll update the question and accept your answer if it solves the problem. It may take a few days (or weeks) depending on how quickly the server admin moves. – Benjamin Jul 01 '15 at 21:00
0

I faced the same problem and corrected sendmail.cf as follows.

O CipherList=HIGH:!ADH:+DH

This means that the priority of cipher which uses a DH key is lowered. When doing it this way, cipher unrelated to a DH key is used with priority, so a DH key error doesn't occur.