openssl更新1.0.1f到1.0.1g打破sendmail(SSL23_GET_SERVER_HELLO:tlsv1警报解码错误)

两天前我更新了openssl 1.0.1f到1.0.1g。 一切似乎都很好。 但是过了一会儿,在sendmail日志中popup一个错误消息:

OpenSSL 1.0.1g失败

4月10日10:13:45邮件sendmail [17568]:STARTTLS =客户端,错误:连接失败= -1,reason = tlsv1警报解码错误,SSL_error = 1,errno = 0,重试= -1

4月10日10:13:45邮件sendmail [17568]:STARTTLS =客户端:17568:错误:1407741A:SSL例程:SSL23_GET_SERVER_HELLO:tlsv1警报解码错误:s23_clnt.c:762:

4月10日10:13:45 mail sendmail [17568]:ruleset = tls_server,arg1 = SOFTWARE,relay = mail.example.com,reject = 403 4.7.0 TLS握手失败。

邮件尚未发送。

OpenSSL 1.0.1f的作品

然后我降级到1.0.1f,邮件已经发送:

Apr 10 10:17:31 mail sendmail [31809]:STARTTLS = client,relay = mail.example.com,version = TLSv1 / SSLv3,verify = FAIL,cipher = DHE-RSA-AES256-SHA,bits = 256 / 256

看起来,这两个openssl版本之间还有另一个区别,那就是只有胆子很大的bug修复。

版本比较

然后我尝试了两个OpenSSL版本:

openssl s_client -starttls smtp -connect mail.example.com:25

OpenSSL版本1.0.1g的输出:

连(00000003)

140370040759952:错误:1407741A:SSL例程:SSL23_GET_SERVER_HELLO:tlsv1警报解码错误:s23_clnt.c:762:


没有对等证书可用


未发送客户端证书CA名称


SSL握手已经读取了131个字节并写入了552个字节


新(NONE),密码是(NONE)

不支持安全重新协商

压缩:无

扩展:无


OpenSSL版本1.0.1f的输出(部分):

连(00000003)

深度= 0 C =美国,ST =加州,L =圣布鲁诺,O =“IronPort系统公司”,CN = IronPort设备演示证书

validation错误:num = 20:无法获取本地颁发者证书

validation退货:1

深度= 0 C =美国,ST =加州,L =圣布鲁诺,O =“IronPort系统公司”,CN = IronPort设备演示证书

validation错误:num = 21:无法validation第一个证书

validation退货:1


证书链

0 s:/ C = US / ST = California / L = San Bruno / O = IronPort Systems,Inc./CN=IronPort设备演示证书

i:/ C = US / ST = California / L =圣布鲁诺/ O = IronPort Systems,Inc./CN=IronPort设备演示证书


服务器证书

— —剪断


未发送客户端证书CA名称


SSL握手已经读取了1771个字节并写入了552个字节


新的TLSv1 / SSLv3,密码是DHE-RSA-AES256-SHA

服务器公钥是1024位

支持安全重协商

压缩:无

扩展:无

SSL会话:

Protocol : TLSv1 Cipher : DHE-RSA-AES256-SHA ---Snipped--- 

现在怎么办?

我的解释是,从mail.example.com提交的证书是不意味着生产使用…

有没有办法如何处理与openssl 1.0.1g这样的证书? mail.example.com是我遇到的几个通信伙伴之一。

感谢泰迪

情况迫使我从源代码编译openssl 1.0.1g,我遇到了与上面报告相同的行为。 这是在64位英特尔Fedora 18下。 像原来的海报报告一样,大多数邮件都没有问题,但是一个邮件目的地遭遇了相同的TLS握手失败。

openssl更改日志( 这里简短的CL, 这里详细的CL)只显示了从1.0.1f到1.0.1g的三个变化:

  • 安全更新
  • 另一个安全更新
  • 为破损的服务器添加TLS填充扩展解决方法。

推测第三个变化是我对ssl/tls1.h中的一行进行注释的问题的原因,该行似乎控制了这种“TLS填充”修改的存在,如下所示:

/* #define TLSEXT_TYPE_padding 21 */

再次编译,把库.so文件放到位,重新启动sendmail ,出去排队邮件没有问题。 我希望我没有因此而提出新的问题。

是的,有两个解决scheme:

  • 使用SSLv3
  • 编译没有

     /* #define TLSEXT_TYPE_padding 21 */ 

在这里引用。