Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On our mail system we have 18 different remote systems that TLS fails with in the last 24 hours. I assume they are using ironport since they are the kind of domains that would use cisco gear such as utah.edu or dell.com, but it's hard to tell since it is a security device and doesn't announce what it is. So to answer your question, no, not all Ironports are being updated. Last I spoke to another mail admin with an Ironport (probably 2 weeks ago) he said that the update wasn't in the main update channel and that you had to specifically create a cisco case to get them to send the patched release. So it looks like both 1.0.1g and 1.0.1h trigger a cisco bug that nobody is really dying to patch due in part to Cisco making it inconvenient and not obvious. In the end I did the same as Stephen and worked around it by patching openssl which is a hack, but all we could do, and thankful that we had something to get around Cisco's bug. schu -- View this message in context: http://openssl.6102.n7.nabble.com/openssl-org-3336-1-0-1g-breaks-IronPORT-SMTP-appliance-padding-extension-tp50483p51130.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Stephen Henson via RT rt at openssl.org writes: I've updated OpenSSL so the padding extension is no longer used by default Stephen, Does not work for me. Running sendmail 8.14.8, got the decode error problem with openssl 1.0.1g, fixed it by ssl/tls1.h changing to /* #define TLSEXT_TYPE_padding 21 */. Sine May, that worked. At Jun10, compiled openssl 1.0.1.h from source and the sendmail decode error came back by Jun 12. Did not realize that until Jun 22. Today, disabled the extension completly: ssl/ssl.h: #define SSL_OP_TLSEXT_PADDING 0xL Sendmail queue emptied after restart without further problems. greetings, Stefan __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Tue, Jun 24, 2014 at 02:29:10PM +, Stefan Runkel wrote: Stephen Henson via RT rt at openssl.org writes: I've updated OpenSSL so the padding extension is no longer used by default Stephen, Does not work for me. Running sendmail 8.14.8, got the decode error problem with openssl 1.0.1g, fixed it by ssl/tls1.h changing to /* #define TLSEXT_TYPE_padding 21 */. Sine May, that worked. At Jun10, compiled openssl 1.0.1.h from source and the sendmail decode error came back by Jun 12. Did not realize that until Jun 22. Today, disabled the extension completly: ssl/ssl.h: #define SSL_OP_TLSEXT_PADDING 0xL Sendmail queue emptied after restart without further problems. Ironport customers still have not applied the fix? Any evidence this applies to destinations that are not Ironport appliances? I other words, how many domains had the problem and were their MX hosts all Ironport devices? -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu 01 May 2014 13:26:48 Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP- appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. maybe a quick system would be useful. the default behavior is to do the right thing, but through a series of env vars, quirks can be injected at the right place ? then there is no wishy/washy behavior where we try to appease every broken system out there simultaneously. -mike signature.asc Description: This is a digitally signed message part.
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Sun, Jun 01, 2014 at 07:18:18PM +0200, Stephen Henson via RT wrote: I've updated OpenSSL so the padding extension is no longer used by default and the option SSL_OP_TLSEXT_PADDING enables it (it is part of the SSL_OP_ALL). This resolves this issue as applications can now decide whether to use the padding extension or not. Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension. Perhaps SSSL_OP_ALL should be ~0 cast appropriately. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Sun, Jun 01, 2014, Viktor Dukhovni wrote: On Sun, Jun 01, 2014 at 07:18:18PM +0200, Stephen Henson via RT wrote: I've updated OpenSSL so the padding extension is no longer used by default and the option SSL_OP_TLSEXT_PADDING enables it (it is part of the SSL_OP_ALL). This resolves this issue as applications can now decide whether to use the padding extension or not. Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension. Actually it currently reuses an obsolete bit of SSL_OP_ALL so any existing application setting SSL_OP_ALL will use it. That's not set in stone and we do have a spare bit. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Sun, Jun 01, 2014 at 07:47:30PM +0200, Dr. Stephen Henson wrote: Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension. Actually it currently reuses an obsolete bit of SSL_OP_ALL so any existing application setting SSL_OP_ALL will use it. That's not set in stone and we do have a spare bit. Repurposing bits in this way is problematic if that bit meant something else in any OpenSSL-1.x.y release (notional ABI). If the bit is from 0.9.x, and was never used in 1.x.y, then it is OK. I think it is actually a feature for older apps to not by default enable some feature that they have no way to disable. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Sun, Jun 01, 2014, Viktor Dukhovni wrote: On Sun, Jun 01, 2014 at 07:47:30PM +0200, Dr. Stephen Henson wrote: Thanks. In particular, since SSL_OP_ALL is a compile-time constant, applications compiled with older releases will not send the extension by default. Only applications compiled against 1.0.1g or later that use SSL_OP_ALL, or specifically enable this work-around, will send the extension. Actually it currently reuses an obsolete bit of SSL_OP_ALL so any existing application setting SSL_OP_ALL will use it. That's not set in stone and we do have a spare bit. Repurposing bits in this way is problematic if that bit meant something else in any OpenSSL-1.x.y release (notional ABI). If the bit is from 0.9.x, and was never used in 1.x.y, then it is OK. I think it is actually a feature for older apps to not by default enable some feature that they have no way to disable. Well the previous purpose of the bit was *ancient* referring to SSLRef and SSLv2 only and probably has been there since SSLeay. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Sun, Jun 01, 2014 at 08:32:55PM +0200, Dr. Stephen Henson wrote: Repurposing bits in this way is problematic if that bit meant something else in any OpenSSL-1.x.y release (notional ABI). If the bit is from 0.9.x, and was never used in 1.x.y, then it is OK. I think it is actually a feature for older apps to not by default enable some feature that they have no way to disable. Well the previous purpose of the bit was *ancient* referring to SSLRef and SSLv2 only and probably has been there since SSLeay. And yet, reporposing a bit is an ABI change. Applications that enable/disable SSL_OP_SSLREF2_REUSE_CERT_TYPE_BUG will now be inadvertently enabling/disabling SSL_OP_TLSEXT_PADDING. Option bits can only be repurposed across ABI changes. Please do not do this in a micro or patch version update. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Here's more information for those who are interested... https://supportforums.cisco.com/announcement/12198406/heartbleed-patched-email-servers-fail-tls-connections-esas-80 On 05/06/2014 07:08 PM, Viktor Dukhovni wrote: On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote: The defect information is available at https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is viewable to the public. You'll have to register for an account to view the data. After registering, the bug details are: Heartbleed patched email servers, fail TLS connections to ESAs 8.0 + CSCuo25329 Description Symptom: Machines installed with OpenSSL 1.0.1g patch fail to connect with Cisco Email Security Appliance Conditions: Cisco AsyncOS 8.0 for Email or later. Status: Fixed Known Affected Releases: 8.0.1 8.5.5 8.5.0 Severity: 1 Catastrophic So what we learn is that perhaps this problem is present in only the latest general availability release and two limited availability releases. If so, we can hope that customers running this release have support contracts, and the issue will not be with us for very long. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote: I'm trying to get that information from the IronPort team. In the mean time, this bug report appears to have some details: https://tools.cisco.com/bugsearch/bug/CSCuo25329 It would really be nice that we can get some more information about this, specially if there is a way to work around it. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
The defect information is available at https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is viewable to the public. You'll have to register for an account to view the data. Viktor already provided a link to the following details as well: http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-0/release_notes/ESA_8-0-1_HP2_Release_Notes.pdf On 05/06/2014 01:10 PM, Kurt Roeckx wrote: On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote: I'm trying to get that information from the IronPort team. In the mean time, this bug report appears to have some details: https://tools.cisco.com/bugsearch/bug/CSCuo25329 It would really be nice that we can get some more information about this, specially if there is a way to work around it. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Tue, May 06, 2014 at 02:32:05PM -0400, John Foley wrote: The defect information is available at https://tools.cisco.com/bugsearch/bug/CSCuo25329. This defect is viewable to the public. You'll have to register for an account to view the data. After registering, the bug details are: Heartbleed patched email servers, fail TLS connections to ESAs 8.0 + CSCuo25329 Description Symptom: Machines installed with OpenSSL 1.0.1g patch fail to connect with Cisco Email Security Appliance Conditions: Cisco AsyncOS 8.0 for Email or later. Status: Fixed Known Affected Releases: 8.0.1 8.5.5 8.5.0 Severity: 1 Catastrophic So what we learn is that perhaps this problem is present in only the latest general availability release and two limited availability releases. If so, we can hope that customers running this release have support contracts, and the issue will not be with us for very long. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
See also this thread: http://www.ietf.org/mail-archive/web/tls/current/msg12143.html On 01/05/14 11:29, Marcus Meissner via RT wrote: Hi, SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. For details, please refer to: postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Reproducible: Always Steps to Reproduce: 1. openssl s_client -connect some.ironport.com:25 -starttls smtp Note: Send me an email for a hostname of an Ironport SMTP appliance to test with. I don't want to disclose it here. Actual Results: CONNECTED(0003) 139718758192784: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 129 bytes and written 552 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Expected Results: CONNECTED(0003) --- Certificate chain [...cut...] New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 [...cut..-] 250 STARTTLS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online Office Tel: +44.(0)1274.730505 Office Fax: +44.(0)1274.730909 www.comodo.com COMODO CA Limited, Registered in England No. 04058690 Registered Office: 3rd Floor, 26 Office Village, Exchange Quay, Trafford Road, Salford, Manchester M5 3EQ This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the sender by replying to the e-mail containing this attachment. Replies to this email may be monitored by COMODO for operational or business reasons. Whilst every endeavour is taken to ensure that e-mails are free from viruses, no liability can be accepted and the recipient is requested to use their own virus checking software. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On 01/05/14 12:26, Stephen Henson via RT wrote: On Thu May 01 12:29:58 2014, meiss...@suse.de wrote: Hi, SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. snip Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( If you use a smaller cipherstring it should also work without having to force SSLv3. Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. -- Rob Stradling Senior Research Development Scientist COMODO - Creating Trust Online __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
+1 On 1. Mai 2014 13:35:19 MESZ, Hanno Böck ha...@hboeck.de wrote: On Thu, 1 May 2014 13:26:48 +0200 Stephen Henson via RT r...@openssl.org wrote: Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( Maybe this should teach us a lesson: Adding more and more Workarounds for broken stuff isn't the way to go forward. The way to go forward is to fix broken stuff. (we have another pretty simliar example - browsers implemented out-of-protocol downgrades to fix broken implementations just to notice that they introduced downgrade attacks and accidental downgrades - now there's a proposal for a downgrade protection extension that only tries to fix a problem we wouldn't have in the first place if people didn't introduce stupid workarounds for broken stuff) -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LISTALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by hash strength, followed by PFS presence, followed by SHA and AES bit length. I think that would give us: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA RC4-SHA DES-CBC3-SHA -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
How prevalent is RC4 today? While web browsers still advertise RC4 cipher suites, how often do you see RC4 cipher suites advertised by the client and no AES or 3DES suites advertised? Does Akamai have any data on this? Maybe RC4 should now be disabled by default. On 05/02/2014 09:49 AM, Salz, Rich wrote: Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by hash strength, followed by PFS presence, followed by SHA and AES bit length. I think that would give us: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA RC4-SHA DES-CBC3-SHA -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (���Z+�7�zZ)���1���x ��h���W^��^��%�� __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
The IETF TLS-WG is likely (my opinion) to soon put out an RFC that, basically deprecates RC4. We have customers with many embedded devices (old web TV's, almost every game console, etc), not just browsers. But for OpenSSL and in particular new code, dropping RC4 is the thing to do. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 09:49:47AM -0400, Salz, Rich wrote: Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), followed by hash strength, followed by PFS presence, followed by SHA and AES bit length. I think that would give us: As I understand things, RC4 needs to be before 3DES because some exchange servers have broken 3DES and don't support anything else. ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA256 I don't this one exists and you meant the next one. ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA RC4-SHA DES-CBC3-SHA I'm not really a fan of the ECDSA ciphers and would really put RSA in front of ECDSA, or remove them. You could optionally also remove all the AES256 versions. Since it's SMTP, you could also add anonymous ciphers. Anyway, a list of ciphers isn't that useful, the CIPHER_LIST to get the needed ones is probably more useful. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 09:58:37AM -0400, John Foley wrote: How prevalent is RC4 today? Here is a recent link for web servers: https://lists.fedoraproject.org/pipermail/security/2014-April/001810.html Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
- Original Message - From: John Foley fol...@cisco.com To: openssl-dev@openssl.org Sent: Friday, May 2, 2014 3:58:37 PM Subject: Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension) How prevalent is RC4 today? While web browsers still advertise RC4 cipher suites, how often do you see RC4 cipher suites advertised by the client and no AES or 3DES suites advertised? Does Akamai have any data on this? Maybe RC4 should now be disabled by default. After scanning Alexa top 1 million sites (as a semi-representative sample) the stats look like this: RC4 Supported 26829887.8859% RC4 Only 5418 1.7748% RC4 Preferred 59552 19.5073% RC4 preferred in TLS1.1+ 31737 10.396% On 05/02/2014 09:49 AM, Salz, Rich wrote: Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LISTALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: My weak opinion is that cipher brokenness is most important (so put 3DES and RC4 last, and the AEAD modes ahead of the MAC-then-encrypt modes), RC4 is broken, 3DES is just weak (as weak as 2048 bit RSA), you shouldn't put RC4 before 3DES followed by hash strength, followed by PFS presence, followed by SHA and It could be argued that even MD5 is secure when used as PRF or HMAC. SHA-1 when used as a PRF or HMAC has a higher security margin than AES-128. See http://openssl.6102.n7.nabble.com/Insecure-DEFAULT-cipher-set-td48995.html for in depth discussion. AES bit length. I think that would give us: ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES256-GCM-SHA384 ECDHE-RSA-AES128-GCM-SHA256 AES256-GCM-SHA384 AES128-GCM-SHA256 ECDHE-ECDSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES256-SHA384 ECDHE-RSA-AES128-SHA256 AES256-SHA256 AES128-SHA256 AES128-SHA RC4-SHA DES-CBC3-SHA -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m(���Z+�7�zZ)���1���x��h���W^��^��%�� __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Email: hka...@redhat.com Web: www.cz.redhat.com Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
After scanning Alexa top 1 million sites (as a semi-representative sample) the stats look like this: How many of those sites are served by CDN's, for example? -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
- Original Message - From: Rich Salz rs...@akamai.com To: openssl-dev@openssl.org Sent: Friday, May 2, 2014 4:28:44 PM Subject: RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension) After scanning Alexa top 1 million sites (as a semi-representative sample) the stats look like this: How many of those sites are served by CDN's, for example? I don't know, if you have a semi-robust way to detect that I'm willing to implement it. Though, the scan was more of a ballpark estimate than a truly representative result. -- Regards, Hubert Kario BaseOS QE Security team Red Hat Czech s.r.o., Purkyňova 99/71, 612 45, Brno, Czech Republic __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
How many of those sites are served by CDN's, for example? I don't know, if you have a semi-robust way to detect that I'm willing to implement it. Short of giving out customer lists :) I don't. I suppose you could do a DNS lookup and see if you got a CNAME to something else. Though, the scan was more of a ballpark estimate than a truly representative result. Oh it's definitely interesting. My point is that the stats might be weighted by the fact that 1/3 of them are being served by a single entity, for example. /r$ -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz :��IϮ��r�m (Z+�7�zZ)���1���x ��hW^��^��%�� ��jם.+-1�ځ��j:+v���h�
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 12:35:52PM +0100, Rob Stradling wrote: Steve, have you considered trimming the DEFAULT cipher list? This would be a *major* incompatibility. The master branch has security levels, which are a step in the right direction. It is perhaps safe to drop EXPORT, LOW and MD5, and not much else. It's currently... #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. There are a lot of real-world uses that we don't know about. The world is not just HTTPS. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 04:12:33PM +0200, Kurt Roeckx wrote: As I understand things, RC4 needs to be before 3DES because some exchange servers have broken 3DES and don't support anything else. No, that's a misreading of my posts. It suffices for RC4-SHA to be in the 64 ciphersuites in the client SSL HELLO. The servers in question will choose RC4-SHA if offered in the first 64 regardless of client preference. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Hey, How many of those sites are served by CDN's, for example? I don't know, if you have a semi-robust way to detect that I'm willing to implement it. Though, the scan was more of a ballpark estimate than a truly representative result. Whois the IP? That should work for majority of the CDN. For Amazon, you can distinguish S3 from CloudFront by looking for at the HTTP headers: - X-Amz-Cf-Id, - Via: ... .cloudfront.net (CloudFront), - X-Cache: ... from cloudfront. Best regards, Piotr Sikora __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Fri, May 02, 2014 at 10:50:28AM -0400, Salz, Rich wrote: How many of those sites are served by CDN's, for example? I don't know, if you have a semi-robust way to detect that I'm willing to implement it. Short of giving out customer lists :) I don't. I suppose you could do a DNS lookup and see if you got a CNAME to something else. I understand the script is available. Maybe you could run it yourself against your customer list? Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On 2/05/2014 11:49 PM, Salz, Rich wrote: Steve, have you considered trimming the DEFAULT cipher list? It's currently... #define SSL_DEFAULT_CIPHER_LIST ALL:!aNULL:!eNULL:!SSLv2 I wonder how many of these ciphers are actually ever negotiated in real-world use. I'm forwarding a bit of internal discussion; hope it's useful. This is from one of our chief info-sec people: A set of recommendations from the Mozilla team along with a write up of how to configure cipher suite selection in a range of servers is at: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Ciphersuite The short form of their recommendation is: 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256: DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256: ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384: ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256: DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA: DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA: AES128:AES256:RC4-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!3DES:!MD5:!PSK' Their rationale is described at https://wiki.mozilla.org/Security/Server_Side_TLS#Prioritization_logic and the cipher suite you select entirely depends on what your view point is on a range of issues. Discussions on what the One True Ciphersuite List should be tend to result in multiple correct answers. Placing a set of recommendations on the wiki (wiki.openssl.org) along with their rationale would be a good step to providing a selection of choices for OpenSSL users. Tim. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
RE: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
Discussions on what the One True Ciphersuite List should be tend to result in multiple correct answers. :) Placing a set of recommendations on the wiki (wiki.openssl.org) along with their rationale would be a good step to providing a selection of choices for OpenSSL users. Yes, and perhaps using the profile stuff to embed some of them in the distribution. -- Principal Security Engineer Akamai Technologies, Cambridge, MA IM: rs...@jabber.me; Twitter: RichSalz
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 12:29:58PM +0200, Marcus Meissner via RT wrote: Hi, SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html I've already reported this to the TLS workgroup too. See thread starting at: http://www.ietf.org/mail-archive/web/tls/current/msg12143.html Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, 1 May 2014 13:26:48 +0200 Stephen Henson via RT r...@openssl.org wrote: Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( Maybe this should teach us a lesson: Adding more and more Workarounds for broken stuff isn't the way to go forward. The way to go forward is to fix broken stuff. (we have another pretty simliar example - browsers implemented out-of-protocol downgrades to fix broken implementations just to notice that they introduced downgrade attacks and accidental downgrades - now there's a proposal for a downgrade protection extension that only tries to fix a problem we wouldn't have in the first place if people didn't introduce stupid workarounds for broken stuff) -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote: Maybe this should teach us a lesson: Adding more and more Workarounds for broken stuff isn't the way to go forward. The way to go forward is to fix broken stuff. The problem isn't always to fix the broken stuff but ussually to get people to upgrade to the fixed version. People are scared of changes. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, 1 May 2014 14:29:44 +0200 Kurt Roeckx k...@roeckx.be wrote: On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote: Maybe this should teach us a lesson: Adding more and more Workarounds for broken stuff isn't the way to go forward. The way to go forward is to fix broken stuff. The problem isn't always to fix the broken stuff but ussually to get people to upgrade to the fixed version. People are scared of changes. I'm well aware of that, but I think there is another option. If browsers (or other kind of tls using software) would display a warning your stuff is broken, it will no longer work with our next version if you don't install updates on your whatever hw, tell your admin NOW, I'm pretty sure those people would update their stuff. Certainly better than inventing yet another workaround for broken stuff-tls-extensions (because we all should know by now: too many tls extensions make the protocol too complex and can hurt). -- Hanno Böck http://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: BBB51E42 signature.asc Description: PGP signature
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 02:45:19PM +0200, Hanno Böck wrote: On Thu, 1 May 2014 14:29:44 +0200 Kurt Roeckx k...@roeckx.be wrote: On Thu, May 01, 2014 at 01:35:19PM +0200, Hanno Böck wrote: Maybe this should teach us a lesson: Adding more and more Workarounds for broken stuff isn't the way to go forward. The way to go forward is to fix broken stuff. The problem isn't always to fix the broken stuff but ussually to get people to upgrade to the fixed version. People are scared of changes. I'm well aware of that, but I think there is another option. If browsers (or other kind of tls using software) would display a warning your stuff is broken, it will no longer work with our next version if you don't install updates on your whatever hw, tell your admin NOW, I'm pretty sure those people would update their stuff. Certainly better than inventing yet another workaround for broken stuff-tls-extensions (because we all should know by now: too many tls extensions make the protocol too complex and can hurt). I'm just backporting the Safari detection to not to ECDSA since we plan to enable ECDHE in Debian stable and it seems their are still a significate enough amount of users using the broken version. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 01:26:48PM +0200, Stephen Henson via RT wrote: Workaround: Force protocol to SSLv3 or recompile without the define above. If there were an SSL_OP_ flag to allow applications to disable padding, that would be useful for SMTP applications. There is precious little presence of (buggy) F5 load-balancers in front of SMTP servers. Ironically it was added as a workaround for another bug. The padding extension was believed to have no side effects... obviously that isn't true :-( What I don't know is what fraction of Ironport devices have the problem. I know of 2 that do (from the original report), and 3 that don't (MX hosts for ironport.com, assumed to be actual ironport devices). If you use a smaller cipherstring it should also work without having to force SSLv3. Even with EXPORT and LOW ciphers disabled, the Postfix client HELLO is 287 bytes before padding. With DANE it will typically include SNI. I don't think consistently staying out of the danger zone is realistic (below padding starts at 0x124-5 = 0x11f and has a length of 4 + 0xdd = 0xe1, so the unpadded HELLO is 256 + 31 = 287 bytes). write to 7FC460C12F00 [7FC46100A400] (517 bytes = 517 (0x205)) 16 03 01 02 00 01 00 01|fc 03 03 00 5a e2 2b 4c Z.+L [...] 0120 0f 00 01 01 00 15 00 dd| 0128 - SPACES/NULLS SSL_connect:SSLv2/v3 write client hello A The padding extension is only used if the ClientHello would be between 256 and 511 bytes in length so if you reduce the number of ciphersuites it wont be used. This would have to be done across the board, don't have a client-side list of all the problem destinations. I don't like disabling ciphersuites, this reduces interoperability in an opportunistic TLS protocol causing potential fallback to cleartext. Sure on a per-site basis, one could attempt a much shorter cipherlist. With OpenSSL 1.0.1g, I can squeeze the HELLO down to 227 bytes with: ALL:+RC4:!LOW:!EXPORT:!MD5:!SRP:!PSK:!SEED:!IDEA:!DSS:!kECDHe:!kECDHr but that leaves little room for SNI, and new ciphers coming soon in 1.0.2 and master. The 1.0.1g cipherlist length is 48 in this case, which consumes 96 bytes in the handshake. The anonymous ciphers are 13 of these, accounting for 26 bytes. Much of the space is taken-up with various TLSv1.2 extensions (elliptic curves oids, supported digests, ...). Even more extensions are likely in the future. We should not have to hand-tune TLS for each destination. Right now Postfix users hand-tune for Exchange 2003 destinations (which need RC4-SHA in the first 64 cipher-suites in the HELLO) and now possibly for Ironport. The most radically short (29 cipher suites), and yet reasonably interoperable list I can come up with for SMTP is: aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:aNULL:-aNULL:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!kECDHe:!kECDHr I don't think I or Postfix users should have to go to such lengths to get interoperable behaviour. Expanded that list is: $ openssl ciphers -v 'aRSA:-aRSA:aECDSA:-aECDSA:kRSA:-kRSA:kEDH:-kEDH:kEECDH:-kEECDH:aNULL:-aNULL:AES128:CAMELLIA128:3DES:RC4:!EXPORT:!LOW:!MD5:!SRP:!PSK:!aDSS:!kECDHe:!kECDHr' | while read c; do set -- $c; printf %-29s %7s %-7s %s %s %s\n $@; done AECDH-AES128-SHASSLv3 Kx=ECDH Au=None Enc=AES(128) Mac=SHA1 ADH-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=None Enc=AESGCM(128) Mac=AEAD ADH-AES128-SHA256 TLSv1.2 Kx=DH Au=None Enc=AES(128) Mac=SHA256 ADH-AES128-SHA SSLv3 Kx=DH Au=None Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AESGCM(128) Mac=AEAD ECDHE-RSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA256 ECDHE-RSA-AES128-SHASSLv3 Kx=ECDH Au=RSA Enc=AES(128) Mac=SHA1 DHE-RSA-AES128-GCM-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AESGCM(128) Mac=AEAD DHE-RSA-AES128-SHA256 TLSv1.2 Kx=DH Au=RSA Enc=AES(128) Mac=SHA256 DHE-RSA-AES128-SHA SSLv3 Kx=DH Au=RSA Enc=AES(128) Mac=SHA1 AES128-GCM-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AESGCM(128) Mac=AEAD AES128-SHA256 TLSv1.2 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA256 AES128-SHA SSLv3 Kx=RSA Au=RSA Enc=AES(128) Mac=SHA1 ADH-CAMELLIA128-SHA SSLv3 Kx=DH Au=None Enc=Camellia(128) Mac=SHA1 DHE-RSA-CAMELLIA128-SHA SSLv3 Kx=DH Au=RSA Enc=Camellia(128) Mac=SHA1 CAMELLIA128-SHA SSLv3 Kx=RSA Au=RSA Enc=Camellia(128) Mac=SHA1 AECDH-DES-CBC3-SHA SSLv3 Kx=ECDH Au=None Enc=3DES(168) Mac=SHA1 ADH-DES-CBC3-SHASSLv3 Kx=DH Au=None Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
This is a known problem in the Ironport TLS stack. Ironport has released a hot patch to address this problem. On 05/01/2014 06:29 AM, Marcus Meissner via RT wrote: Hi, SUSE has received a bugreport from a user, that the padding extension change breaks IronPort SMTP appliances. There might a RT on this already, not sure. https://bugzilla.novell.com/show_bug.cgi?id=875639 http://postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Quoting from our openSUSE bugreport: Last upgrade to openssl-1.0.1g-11.36.1.x86_64 broke SSL connections to some services, e.g. Cisco Ironport SMTP appliances. 1.0.1g not only fixes the Heartbleed bug but also adds another change by adding: #define TLSEXT_TYPE_padding 21 This in turn breaks SSL connections to e.g. Ironports, probably others: SSL23_GET_SERVER_HELLO:tlsv1 alert decode error Workaround: Force protocol to SSLv3 or recompile without the define above. For details, please refer to: postfix.1071664.n5.nabble.com/OpenSSL-1-0-1g-and-Ironport-SMTP-appliances-interop-issue-td66873.html Reproducible: Always Steps to Reproduce: 1. openssl s_client -connect some.ironport.com:25 -starttls smtp Note: Send me an email for a hostname of an Ironport SMTP appliance to test with. I don't want to disclose it here. Actual Results: CONNECTED(0003) 139718758192784: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 129 bytes and written 552 bytes --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE --- Expected Results: CONNECTED(0003) --- Certificate chain [...cut...] New, TLSv1/SSLv3, Cipher is DHE-RSA-AES256-SHA Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1 [...cut..-] 250 STARTTLS __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org . __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote: This is a known problem in the Ironport TLS stack. Ironport has released a hot patch to address this problem. Any links to the fix? I'd like to post a link to the fix to the Postfix and Exim users lists, so that if anyone runs into the problem with a peer system, they can point the peer postmaster in the right direction. What versions of the product have the problem, and any idea what fraction of the install base is running those versions? Is there likely any significant portion of the install base that can't or won't upgrade (best guess)? -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
I'm trying to get that information from the IronPort team. In the mean time, this bug report appears to have some details: https://tools.cisco.com/bugsearch/bug/CSCuo25329 On 05/01/2014 12:26 PM, Viktor Dukhovni wrote: On Thu, May 01, 2014 at 12:08:50PM -0400, John Foley wrote: This is a known problem in the Ironport TLS stack. Ironport has released a hot patch to address this problem. Any links to the fix? I'd like to post a link to the fix to the Postfix and Exim users lists, so that if anyone runs into the problem with a peer system, they can point the peer postmaster in the right direction. What versions of the product have the problem, and any idea what fraction of the install base is running those versions? Is there likely any significant portion of the install base that can't or won't upgrade (best guess)? __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
On Thu, May 01, 2014 at 01:23:51PM -0400, John Foley wrote: I'm trying to get that information from the IronPort team. In the mean time, this bug report appears to have some details: https://tools.cisco.com/bugsearch/bug/CSCuo25329 Sadly, this requires a login. The bug is however referenced in a non-paywalled document: http://www.cisco.com/c/dam/en/us/td/docs/security/esa/esa8-0/release_notes/ESA_8-0-1_HP2_Release_Notes.pdf Table 1Resolved Issues in This Release -- Defect ID Description -- ... -- CSCuo25329 Machines installed with OpenSSL 1.0.1g patch fail to connect with Cisco Email Security Appliance. -- The PDF contains a link to: http://www.cisco.com/c/en/us/support/security/email-security-appliance/products-release-notes-list.html which seems like the right place to start looking for fixes, so far it seems that 8.0 is the only release with a fix, not clear whether any others need it. -- Viktor. __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
