☰

更新后，Ubuntu 12.04 上的 Sendmail 关闭了，与 SSL 有关吗？

tag-icon • tag-icon email ssl ubuntu-12.04 sendmail tls
更新后，Ubuntu 12.04 上的 Sendmail 关闭了，与 SSL 有关吗？

我昨天在 askubuntu.com 上发布了此消息，但没有收到任何回复。

我们运行一个 Ubuntu 生产服务器，每天为数千人提供服务。Sendmail 目前无法在此服务器上运行。我们花了几天时间尝试恢复它，但尚未找到任何解决方案。

目前有一个错误报告这似乎与这个问题有关，所以它影响的人不仅仅只有我们。

以下是我们所知道的信息。

周日，我们对服务器进行了更新。第二天，我们发现 sendmail 无法发送电子邮件。

/var/log/sendmail.log 在每封电子邮件条目上报告“stat=Deferred”。

它还偶尔会重复以下消息：

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.

我们检查了 SMTP 服务器上的日志，发现以下内容：

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

我们花了很多时间在 Google 上搜索，发现有几个人在其他操作系统（CentOS 和 OpenBSD）上也遇到了类似的问题。看来 OpenSSL 已经更新，现在需要更长的 SSL 密钥才能正常运行。

这个错误启动板页面上可能有相关内容。

我们已尝试按照 CentOS 给出的说明修复该问题这里。注意：我们更改了新 dhparams.pem 文件的位置。

在你的服务器上生成 DH 参数文件：

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

添加到 /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

然后使用 make -C /etc/mail/ 和服务 sendmail 重新启动。

这似乎并没有带来任何改善。

编辑：

我们通过执行以下操作关闭了 TLS，sendmail 立即恢复运行。但是，这不是解决方案，因为我们不想发送纯文本电子邮件。

添加Try_TLS:1.2.3.4 NO到 /etc/mail/access。
在 /etc/mail 中执行 make 并重新启动 sendmail。

答案1

据我了解，问题在于你的OpenSSL 升级已完成你不宽容其他的较短的 DH 密钥长度，以保护对话免受僵局攻击这就是为什么增加你的DH 密钥长度（openssl dhparam ...等）没有任何帮助，而关闭 TLS 则有帮助。

显然，我们都希望 OpenSSL 有一个类似这样的标志--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。遗憾的是，这种行为似乎已被编译到 OpenSSL 中，开发人员并未选择支持我建议的标志，而 sendmail 似乎也没有在其中编译取消选择触发此行为的密码套件的功能。

这也意味着长期解决方案是其他邮件服务器的管理员升级其 DH 密钥长度。您可以逐个域地关闭 TLS 的使用，使用access如下映射条目

Try_TLS:mail.example.com NO

（感谢诺沃西亚如果你能识别出与你经常交换电子邮件且管理员响应缓慢的特定同伴，那么这个想法就很好了。但据我所知，如果你的服务器（像我的一样）突然变得挑剔其他人的加密参数，你修复这个问题的能力是有限的。

答案2

我遇到了同样的问题，并按如下方式更正了 sendmail.cf。

O CipherList=HIGH:!ADH:+DH

这意味着使用 DH 密钥的密码的优先级会降低。这样一来，与 DH 密钥无关的密码将优先使用，因此不会发生 DH 密钥错误。

相关内容