Skip to main content

openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error) [Resolved]

Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seemed fine. But after a while an error popped up in the sendmail log:

OpenSSL 1.0.1g fails

Apr 10 10:13:45 mail sendmail[17568]: STARTTLS=client, error: connect failed=-1, reason=tlsv1 alert decode error, SSL_error=1, errno=0, retry=-1

Apr 10 10:13:45 mail sendmail[17568]: STARTTLS=client: 17568:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:

Apr 10 10:13:45 mail sendmail[17568]: ruleset=tls_server, arg1=SOFTWARE, relay=mail.example.com, reject=403 4.7.0 TLS handshake failed.

The mail has not been delivered.

OpenSSL 1.0.1f works

Then I downgraded to 1.0.1f and the mail has been sent with:

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

It seems that there is another difference between the two openssl versions than only the heartbleed bugfix.

Version comparison

Then I tried on both OpenSSL versions:

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

Output of OpenSSL version 1.0.1g:

CONNECTED(00000003)

140370040759952:error:1407741A:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762:


no peer certificate available


No client certificate CA names sent


SSL handshake has read 131 bytes and written 552 bytes


New, (NONE), Cipher is (NONE)

Secure Renegotiation IS NOT supported

Compression: NONE

Expansion: NONE


Output of OpenSSL version 1.0.1f (parts):

CONNECTED(00000003)

depth=0 C = US, ST = California, L = San Bruno, O = "IronPort Systems, Inc.", CN = IronPort Appliance Demo Certificate

verify error:num=20:unable to get local issuer certificate

verify return:1

depth=0 C = US, ST = California, L = San Bruno, O = "IronPort Systems, Inc.", CN = IronPort Appliance Demo Certificate

verify error:num=21:unable to verify the first certificate

verify return:1


Certificate chain

0 s:/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate

i:/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate


Server certificate

---snipped---


No client certificate CA names sent


SSL handshake has read 1771 bytes and written 552 bytes


New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA

Server public key is 1024 bit

Secure Renegotiation IS supported

Compression: NONE

Expansion: NONE

SSL-Session:

Protocol  : TLSv1

Cipher    : DHE-RSA-AES256-SHA

---Snipped---

What now?

I interpret, that the presented certificate from mail.example.com is one not meant for productive usage...

Is there a way how I can handle such certificates with openssl 1.0.1g? mail.example.com is one of several communication-partners which I have problems with.

Thanks Teddy


Asked April 21, 2017
Posted Under: Network
38 views
2 Answers

Circumstances forced me to compile openssl 1.0.1g from sources and I encountered behavior identical to that reported above. This is under Fedora 18 on a 64-bit Intel. Like the original poster reports, most mail went out OK but one mail destination suffered the same TLS handshake failures.

The openssl change log (brief CL here, detailed CL here) showed only three changes from 1.0.1f to 1.0.1g:

  • a security update
  • another security update
  • Add TLS padding extension workaround for broken servers.

Speculating that third change was responsible for the problem I commented out one line in ssl/tls1.h that appears to control presence of this "TLS padding" modification, like so:

/* #define TLSEXT_TYPE_padding 21 */

Compiled again, put the library .so files in place, restarted sendmail, and out went the queued mail with no problems. I hope I haven't opened up new issues as a result.


Answered April 21, 2017

Yes, there are two solutions:

  • Use SSLv3
  • compile without

    /* #define TLSEXT_TYPE_padding 21 */
    

Reference here.


Answered April 21, 2017
 
So in order to work around one broken middlebox (F5) they found out that another middlebox was broken (IronPort). Hate those broken middleboxes :( – Steffen Ullrich Apr 16 '14 at 6:53
 CanDoerz  3 months ago
Your Answer
D:\Adnan\Candoerz\CandoProject\vQA