Re: [openssl.org #3310] Can't execute make command
On Mon, Apr 14, 2014 at 09:52:32PM +0200, Maria Moskaleva via RT wrote: Hello! Make fails, wihle I'm trying build the openssl library. http://screeny.ru/534bd10369000fff1f0225ce Why have I problem with md2test.c? (m2test.c:1: parse error before '.' token) What should I do? Thanks in advance! It also says that it's at the end of the file. I suspect that the file is corrupt or something like that. Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #3294] [PATCH] Documentation for PKCS5_PBKDF2_HMAC
On Sat, Apr 05, 2014 at 05:42:16PM +0200, noloa...@gmail.com via RT wrote: A question using PKCS5_PBKDF2_HMAC was recently asked on Stack Overflow. Currently, there is no documentation on the function. The PKCS5_PBKDF2_HMAC.pod is new. It is based on the documentation for EVP_BytesToKey. EVP_BytesToKey was updated to cross reference to PKCS5_PBKDF2_HMAC. Added in commit 6bcc4475fcdb2ea5daae80cbb2a5a5fcf677ac23 Kurt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
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
Re: [openssl.org #3326] [PATCH] expose -elapsed option of speed and include missing man pages references.
On Wed, Apr 23, 2014 at 06:29:26PM +0200, John-Mark Gurney via RT wrote: diff --git a/apps/speed.c b/apps/speed.c index 9232418..f70fd3e 100644 --- a/apps/speed.c +++ b/apps/speed.c @@ -1126,9 +1126,7 @@ int MAIN(int argc, char **argv) BIO_printf(bio_err,\n); BIO_printf(bio_err,Available options:\n); -#if defined(TIMES) || defined(USE_TOD) BIO_printf(bio_err,-elapsedmeasure time in real time instead of CPU user time.\n); -#endif #ifndef OPENSSL_NO_ENGINE BIO_printf(bio_err,-engine e use engine e, possibly a hardware device.\n); #endif This patch is wrong. Please take a look at all the alternative app_tminterval() functions. It would also be nice that the manpage got updated to reflect all the options. 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 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
[openssl.org #3336] 1.0.1g breaks IronPORT SMTP appliance (padding extension)
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. 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. 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 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
[openssl.org #3304] [PATCH] typo in SSL_get_peer_cert_chain docs
Fixed in commit: http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=e5676b8328a486565fc3c7f408a40beb4d47cd08 Matt __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
