Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)
It seams that there is another difference between the two openssl versions then only the heartbleed bugfix. err, yes. The g release is a new minor release. I'd ALWAYS advise reading the changelog before deploying. .. You'd then have seen the new features (this is why vendors such as redhat are just back porting the fix rather than pushing 1.0.1g to RH6.5 usersfor example) alan
Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)
On Thu, Apr 10, 2014 at 06:39:21PM +0200, Dominik Mahrer (Teddy) wrote: [ The subject is a bit dramatic, Sendmail did not break, rather you're experiencing interop issues with one site. ] Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seamed to be fine. But after a while an error popped up in sendmail log: 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 The remote server sent a TLSv1 alert (50) decode error. My best guess is that the server in question has a problem with the TLS padding extension: commit 51624dbdaed5325ac763e63dc5eb0b3ef85d6489 Author: Dr. Stephen Henson st...@openssl.org Date: Sat Apr 5 20:43:54 2014 +0100 Set TLS padding extension value. Enable TLS padding extension using official value from: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v (cherry picked from commit cd6bd5ffda616822b52104fee0c4c7d623fd4f53) This extension deals works around interoperability issues with F5 load balancers. Perhaps it introduces an interoperability issue with Ironport appliances. Can you post the IP address of the target system? Have you tried connecting with SSLv3 (disable TLSv1, TLSv1.1 and TLSv1.2)? You can test with $ openssl s_client -starttls smtp -ssl3 -connect host:25 The mail has not been delivered. 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 The padding extension is not available in 1.0.1f. Then I tried on both versions: openssl s_client -starttls smtp -connect mail.example.com:25 Try ssl3. depth=0 C = US, ST = California, L = San Bruno, O = IronPort Systems, Inc., CN = IronPort Appliance Demo Certificate That's sad. The people should leave the Demo certificate in place, still we learn its an Ironport. I would contact Cisco and see whether they can help to isolate the issue. (I added a Cisco Ironport engineer to the Bcc, perhaps he'll respond). 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. The problem is unrelated to the demo certificate. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)
Thanks Viktor OK, I googled about IronPort-Systems (one can never learn enough). The output requested: openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 CONNECTED(0003) 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 -BEGIN CERTIFICATE- MIIDfTCCAuagAwIBAgIBATANBgkqhkiG9w0BAQQFADCBhTELMAkGA1UEBhMCVVMx EzARBgNVBAgTCkNhbGlmb3JuaWExEjAQBgNVBAcTCVNhbiBCcnVubzEfMB0GA1UE ChMWSXJvblBvcnQgU3lzdGVtcywgSW5jLjEsMCoGA1UEAxMjSXJvblBvcnQgQXBw bGlhbmNlIERlbW8gQ2VydGlmaWNhdGUwHhcNMDYwNTAxMjI1NzU4WhcNMTYwNTAx MjI1NzU4WjCBhTELMAkGA1UEBhMCVVMxEzARBgNVBAgTCkNhbGlmb3JuaWExEjAQ BgNVBAcTCVNhbiBCcnVubzEfMB0GA1UEChMWSXJvblBvcnQgU3lzdGVtcywgSW5j LjEsMCoGA1UEAxMjSXJvblBvcnQgQXBwbGlhbmNlIERlbW8gQ2VydGlmaWNhdGUw gZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALebxVos+JhWxNgAHKNZ7jtrtgsK dx94/76c/316FW5nS2Y1M6ZvhOE2rblbs9riDcPMkiDrt6Cdd/GU4WdGYoG/SWxr +0FqAiGLqyo45xUSmwg/hE/+LX3v1XM/bW0+SPUsyiXCFObafOFieHkaV+Rj9f3r 6f62Xsx6AlGyKQfjAgMBAAGjgfowgfcwCQYDVR0TBAIwADAsBglghkgBhvhCAQ0E HxYdT3BlblNTTCBHZW5lcmF0ZWQgQ2VydGlmaWNhdGUwHQYDVR0OBBYEFNeVBunw o9Zl9hGQvMJMuuY0qg7IMIGcBgNVHSMEgZQwgZGhgYukgYgwgYUxCzAJBgNVBAYT AlVTMRMwEQYDVQQIEwpDYWxpZm9ybmlhMRIwEAYDVQQHEwlTYW4gQnJ1bm8xHzAd BgNVBAoTFklyb25Qb3J0IFN5c3RlbXMsIEluYy4xLDAqBgNVBAMTI0lyb25Qb3J0 IEFwcGxpYW5jZSBEZW1vIENlcnRpZmljYXRlggEAMA0GCSqGSIb3DQEBBAUAA4GB AKtUIDqKx1BnIB0cqRNcU4sPsy1gUhp2ieynoep2LEILGEiYTb08hmyvDUFzBn+P Unv/RfHrD8XX4w/4ptV6e+jzwlqf63JBG3JZ4dGCp/jEX//SJtevmenctZRD4hyI ATAp5F6VvERCk7YfvFRmPUua15wLUyDMFFdr46IUMrxg -END CERTIFICATE- subject=/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate issuer=/C=US/ST=California/L=San Bruno/O=IronPort Systems, Inc./CN=IronPort Appliance Demo Certificate --- No client certificate CA names sent --- SSL handshake has read 1608 bytes and written 401 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 : SSLv3 Cipher: DHE-RSA-AES256-SHA Session-ID: 1CA7A0A5E2ED635DD10979AD459226068FF329E73F4E2F4C047AAFD938922187 Session-ID-ctx: Master-Key: 7B08A032113DD2E3F316E04B86B5F96F6D1081696F505784A8C3214B7C3EC58998F58978E6AB108B2AD25AD2530F577B Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1397153971 Timeout : 7200 (sec) Verify return code: 21 (unable to verify the first certificate) --- 250 STARTTLS Another Domain with the same problem: mx02.jhcn.net Enable TLS padding extension using official value from: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v (cherry picked from commit cd6bd5ffda616822b52104fee0c4c7d623fd4f53) I did not understand what you mean. I think 1.0.1g has enabled TLS padding extension by default? For the moment I have fixed my problems by adding the heartbleed-fix to version 1.0.1f and took this into production. But I would like to understand the problem with TLS padding anyway. Thanks Mit freundlichen Grüssen Dominik Mahrer Dipl. Ing. Informatik FH/STV Teddy Engineering GmbH http://www.teddy.ch/ Lettenmattstrasse 5mailto:te...@teddy.ch 8903 Birmensdorf ZH076 383 80 60 Am 10.04.2014 19:00, schrieb Viktor Dukhovni: On Thu, Apr 10, 2014 at 06:39:21PM +0200, Dominik Mahrer (Teddy) wrote: [ The subject is a bit dramatic, Sendmail did not break, rather you're experiencing interop issues with one site. ] Two days ago I updated openssl 1.0.1f to 1.0.1g. Everything seamed to be fine. But after a while an error popped up in sendmail log: 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 The remote server sent a TLSv1 alert (50) decode error. My best guess is that the server in question has a problem with the TLS padding extension: commit 51624dbdaed5325ac763e63dc5eb0b3ef85d6489 Author: Dr. Stephen Henson st...@openssl.org Date: Sat Apr 5 20:43:54 2014 +0100 Set TLS padding extension value. Enable TLS padding extension using official value from: http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v (cherry picked from commit cd6bd5ffda616822b52104fee0c4c7d623fd4f53) This extension deals works around interoperability issues
Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)
On Thu, Apr 10, 2014 at 09:58:47PM +0200, Dominik Mahrer (Teddy) wrote:
openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25
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 : SSLv3
Cipher: DHE-RSA-AES256-SHA
As expected, this works because SSLv3 sends no extensions.
Another Domain with the same problem: mx02.jhcn.net
Thanks, I'll also test these with Postfix.
Enable TLS padding extension using official value from:
http://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-v
(cherry picked from commit cd6bd5ffda616822b52104fee0c4c7d623fd4f53)
I did not understand what you mean. I think 1.0.1g has enabled TLS padding
extension by default?
Yes, 1.0.1g enables the padding extension by default, to work-around
common problems with F5 load-balancers that confuse SSLv3 Client
HELLO that are 256--511 bytes in length with SSLv2 HELLO. This
solves a problem, but appears to introduce a new problem with the
ironports in question.
For the moment I have fixed my problems by adding the heartbleed-fix to
version 1.0.1f and took this into production. But I would like to understand
the problem with TLS padding anyway.
The IETF TLS WG mailing list has a post from an F5 engineer from
some time in late 2013 IIRC that explained the F5 issue, and lead
to the padding extension being introduced. It is enabled unconditionally
in OpenSSL 1.0.1g:
--
Viktor.
commit 4a55631e4dc76fb8d668218bf461c45a9abc5b94
Author: Dr. Stephen Henson st...@openssl.org
Date: Fri Dec 13 14:41:32 2013 +
Backport TLS padding extension from master.
(cherry picked from commit 8c6d8c2a498146992123ef5407d7ba01a1e7224d)
Conflicts:
CHANGES
ssl/t1_lib.c
diff --git a/CHANGES b/CHANGES
index f6fabf9..58ac884 100644
--- a/CHANGES
+++ b/CHANGES
@@ -4,7 +4,24 @@
Changes between 1.0.1f and 1.0.1g [xx XXX ]
- *)
+ *) TLS pad extension: draft-agl-tls-padding-02
+
+ Workaround for the TLS hang bug (see FAQ and PR#2771): if the
+ TLS client Hello record length value would otherwise be 255 and
+ less that 512 pad with a dummy extension containing zeroes so it
+ is at least 512 bytes long.
+
+ To enable it use an unused extension number (for example chrome uses
+ 35655) using:
+
+ e.g. -DTLSEXT_TYPE_padding=35655
+
+ Since the extension is ignored the actual number doesn't matter as long
+ as it doesn't clash with any existing extension.
+
+ This will be updated when the extension gets an official number.
+
+ [Adam Langley, Steve Henson]
Changes between 1.0.1e and 1.0.1f [6 Jan 2014]
diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c
index e22ebbf..29ccd83 100644
--- a/ssl/t1_lib.c
+++ b/ssl/t1_lib.c
@@ -662,6 +662,36 @@ unsigned char *ssl_add_clienthello_tlsext(SSL *s, unsigned
char *p, unsigned cha
}
#endif
+#ifdef TLSEXT_TYPE_padding
+ /* Add padding to workaround bugs in F5 terminators.
+* See https://tools.ietf.org/html/draft-agl-tls-padding-02
+*
+* NB: because this code works out the length of all existing
+* extensions it MUST always appear last.
+*/
+ {
+ int hlen = ret - (unsigned char *)s-init_buf-data;
+ /* The code in s23_clnt.c to build ClientHello messages includes the
+* 5-byte record header in the buffer, while the code in s3_clnt.c does
+* not. */
+ if (s-state == SSL23_ST_CW_CLNT_HELLO_A)
+ hlen -= 5;
+ if (hlen 0xff hlen 0x200)
+ {
+ hlen = 0x200 - hlen;
+ if (hlen = 4)
+ hlen -= 4;
+ else
+ hlen = 0;
+
+ s2n(TLSEXT_TYPE_padding, ret);
+ s2n(hlen, ret);
+ memset(ret, 0, hlen);
+ ret += hlen;
+ }
+ }
+#endif
+
if ((extdatalen = ret-p-2)== 0)
return p;
__
OpenSSL Project http://www.openssl.org
User Support Mailing Listopenssl-users@openssl.org
Automated List Manager majord...@openssl.org
Re: openssl update 1.0.1f to 1.0.1g broke sendmail (SSL23_GET_SERVER_HELLO:tlsv1 alert decode error)
On Thu, Apr 10, 2014 at 08:24:33PM +, Viktor Dukhovni wrote: openssl s_client -starttls smtp -ssl3 -connect migze121.migros.ch:25 Protocol : SSLv3 Cipher: DHE-RSA-AES256-SHA As expected, this works because SSLv3 sends no extensions. When I test with Postfix and 1.0.1g and the full set of TLSv1.2 cipher-suites the client HELLO length exceeds 256 bytes and the padding extension kicks in, this triggers the decode alert from migros.ch: 220 migze121.migros.ch ESMTP EHLO amnesiac.local 250-migze121.migros.ch 250-8BITMIME 250-SIZE 47185920 250 STARTTLS STARTTLS 220 Go ahead with TLS SSL_connect:before/connect initialization write to 01F36460 [01F623E0] (517 bytes = 517 (0x205)) SSL_connect:SSLv2/v3 write client hello A read from 01F36460 [01F67940] (7 bytes = 7 (0x7)) 15 03 01 00 02 02 32 ..2 SSL3 alert read:fatal:decode error SSL_connect:error in SSLv2/v3 read server hello A SSL_connect error to migze121.migros.ch[146.67.146.31]:25: -1 warning: TLS library problem: error:1407741A:SSL routines: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error:s23_clnt.c:762: Another Domain with the same problem: mx02.jhcn.net Thanks, I'll also test these with Postfix. When I truncate the cipherlist to HIGH+AES:@STRENGTH, the client HELLO is short enough to not trigger padding and the connection succeeds: 220 migze121.migros.ch ESMTP EHLO amnesiac.local 250-migze121.migros.ch 250-8BITMIME 250-SIZE 47185920 250 STARTTLS STARTTLS 220 Go ahead with TLS SSL_connect:before/connect initialization write to 01D69130 [01D78170] (253 bytes = 253 (0xFD)) SSL_connect:SSLv2/v3 write client hello A read from 01D69130 [01D7D6D0] (7 bytes = 7 (0x7)) 16 03 01 00 35 025. read from 01D69130 [01D7D6DA] (51 bytes = 51 (0x33)) SSL_connect:SSLv3 read server hello A read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) 16 03 01 03 8b . read from 01D69130 [01D7D6D8] (907 bytes = 907 (0x38B)) SSL_connect:SSLv3 read server certificate A read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) read from 01D69130 [01D7D6D8] (397 bytes = 397 (0x18D)) SSL_connect:SSLv3 read server key exchange A read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) read from 01D69130 [01D7D6D8] (4 bytes = 4 (0x4)) SSL_connect:SSLv3 read server done A SSL_connect:SSLv3 write client key exchange A SSL_connect:SSLv3 write change cipher spec A SSL_connect:SSLv3 write finished A write to 01D69130 [01D8B090] (198 bytes = 198 (0xC6)) SSL_connect:SSLv3 flush data read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) read from 01D69130 [01D7D6D8] (202 bytes = 202 (0xCA)) SSL_connect:SSLv3 read server session ticket A read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) read from 01D69130 [01D7D6D8] (1 bytes = 1 (0x1)) read from 01D69130 [01D7D6D3] (5 bytes = 5 (0x5)) read from 01D69130 [01D7D6D8] (48 bytes = 48 (0x30)) SSL_connect:SSLv3 read finished A Untrusted TLS connection established to migze121.migros.ch[146.67.146.31]:25: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) So it seems that the F5 work-around breaks interoperability with some Ironport systems... Ironport and F5 need to fight it out to see who can fix their customer's appliances sooner to not require the extension. The extension may need an SSL_OP_... control bit that applications can use to disable it. -- Viktor. __ OpenSSL Project http://www.openssl.org User Support Mailing Listopenssl-users@openssl.org Automated List Manager majord...@openssl.org
RE: Openssl update
Read the file called README. Regards, jjf From: Harris, Steve D [mailto:steved.har...@fda.hhs.gov] Sent: Tuesday, July 09, 2013 3:26 PM To: openssl-users@openssl.org Subject: Openssl update How do you install openssl on AIX I have downloaded the latest I have unzip the file And tar command I have a directory with the data What do I do next Steve
