From philipp_subx at redfish-solutions.com Thu Dec 4 19:22:02 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 04 Dec 2014 17:22:02 -0700 Subject: [openssl-dev] Under-utilization of "const" in prototyping? Message-ID: <5480FAAA.8000908@redfish-solutions.com> Hi all, I was looking at some functions like ASN1_digest() or macros like TYPEDEF_I2D_OF() and wondering why more of the parameters that are unmodified aren't marked as "const", for instance "data" in ASN1_digest() and "type" in TYPEDEF_I2D_OF(). I started to think about doing a scrub of this, but it likely couldn't be done incrementally: there's too much interdependence in some of the code. It would best be done as "throwing a switch". How likely is this? In most cases, changing a parameter to "const" in the API shouldn't affect user code, so this wouldn't break existing source using OpenSSL. Looks like all of the code could be changed in a couple of man-days. Is it worthwhile doing? -Philip From kurt at roeckx.be Thu Dec 4 19:30:30 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 5 Dec 2014 01:30:30 +0100 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <5480FAAA.8000908@redfish-solutions.com> References: <5480FAAA.8000908@redfish-solutions.com> Message-ID: <20141205003030.GA29970@roeckx.be> On Thu, Dec 04, 2014 at 05:22:02PM -0700, Philip Prindeville wrote: > Hi all, > > I was looking at some functions like ASN1_digest() or macros like > TYPEDEF_I2D_OF() and wondering why more of the parameters that are > unmodified aren't marked as "const", for instance "data" in ASN1_digest() > and "type" in TYPEDEF_I2D_OF(). > > I started to think about doing a scrub of this, but it likely couldn't be > done incrementally: there's too much interdependence in some of the code. > > It would best be done as "throwing a switch". > > How likely is this? > > In most cases, changing a parameter to "const" in the API shouldn't affect > user code, so this wouldn't break existing source using OpenSSL. > > Looks like all of the code could be changed in a couple of man-days. > > Is it worthwhile doing? I would like to see such changes. We've been slowly adding more const, but it could always use more of them. So feel free to send a patch. Kurt From philipp_subx at redfish-solutions.com Thu Dec 4 19:34:11 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Thu, 04 Dec 2014 17:34:11 -0700 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <20141205003030.GA29970@roeckx.be> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> Message-ID: <5480FD83.1080404@redfish-solutions.com> On 12/04/2014 05:30 PM, Kurt Roeckx wrote: > On Thu, Dec 04, 2014 at 05:22:02PM -0700, Philip Prindeville wrote: >> Hi all, >> >> I was looking at some functions like ASN1_digest() or macros like >> TYPEDEF_I2D_OF() and wondering why more of the parameters that are >> unmodified aren't marked as "const", for instance "data" in ASN1_digest() >> and "type" in TYPEDEF_I2D_OF(). >> >> I started to think about doing a scrub of this, but it likely couldn't be >> done incrementally: there's too much interdependence in some of the code. >> >> It would best be done as "throwing a switch". >> >> How likely is this? >> >> In most cases, changing a parameter to "const" in the API shouldn't affect >> user code, so this wouldn't break existing source using OpenSSL. >> >> Looks like all of the code could be changed in a couple of man-days. >> >> Is it worthwhile doing? > I would like to see such changes. We've been slowly adding more > const, but it could always use more of them. So feel free to send > a patch. > > > Kurt > I'll make a deal: if you can suggest a way to carve up the task so that it *can* be done incrementally, I'll see what I can do. For kicks and giggles, I tried to change crypto/asn1/asn1.h and the functions it contains, and it quickly rippled out into other modules (like RSA, etc). -Philip From milhous.30 at gmail.com Thu Dec 4 22:06:54 2014 From: milhous.30 at gmail.com (Matt Miller) Date: Thu, 4 Dec 2014 21:06:54 -0600 Subject: [openssl-dev] please remove me from you list milhous.30@gmail.com Message-ID: From dkg at fifthhorseman.net Fri Dec 5 10:40:07 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 05 Dec 2014 10:40:07 -0500 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <5480FD83.1080404@redfish-solutions.com> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> Message-ID: <5481D1D7.9020501@fifthhorseman.net> On 12/04/2014 07:34 PM, Philip Prindeville wrote: > I'll make a deal: if you can suggest a way to carve up the task so that > it *can* be done incrementally, I'll see what I can do. My experience with trying to constify larger, more-complex codebases is that it is often *very* difficult to do incrementally. If you have a way to do static analysis to find leaf functions, that might be a way to get some smaller pieces that you can constify, but i don't know the common static analysis tools well enough to be able to point you to such a thing. > For kicks and giggles, I tried to change crypto/asn1/asn1.h and the > functions it contains, and it quickly rippled out into other modules > (like RSA, etc). I think sometimes just diving in like this is worth doing. A successful constifying rampage across the OpenSSL codebase would be real boon to the project (of course it would probably end up modifying some public interfaces, so it would need to take effect publicly during an API change). --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From karakucukoh at gmail.com Fri Dec 5 11:04:18 2014 From: karakucukoh at gmail.com (=?UTF-8?B?w5ZtZXIgSGFrYW4gS0FSQUvDnMOHw5xL?=) Date: Fri, 5 Dec 2014 18:04:18 +0200 Subject: [openssl-dev] (no subject) Message-ID: -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Fri Dec 5 11:07:04 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 5 Dec 2014 17:07:04 +0100 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <5481D1D7.9020501@fifthhorseman.net> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> <5481D1D7.9020501@fifthhorseman.net> Message-ID: <20141205160704.GA1760@roeckx.be> On Fri, Dec 05, 2014 at 10:40:07AM -0500, Daniel Kahn Gillmor wrote: > (of course it would probably end up modifying some public > interfaces, so it would need to take effect publicly during an API change). Adding const to a function shouldn't be a problem for C. It would be for C++. Kurt From openssl-users at dukhovni.org Fri Dec 5 12:15:24 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 5 Dec 2014 17:15:24 +0000 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <20141205160704.GA1760@roeckx.be> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> <5481D1D7.9020501@fifthhorseman.net> <20141205160704.GA1760@roeckx.be> Message-ID: <20141205171524.GN285@mournblade.imrryr.org> On Fri, Dec 05, 2014 at 05:07:04PM +0100, Kurt Roeckx wrote: > On Fri, Dec 05, 2014 at 10:40:07AM -0500, Daniel Kahn Gillmor wrote: > > (of course it would probably end up modifying some public > > interfaces, so it would need to take effect publicly during an API change). > > Adding const to a function shouldn't be a problem for C. It would > be for C++. Actually, it can be a problem with C also. Replacing "char **" in a function prototype with "const char **" changes the API. Postfix has #ifdefs for a previous "constification" effort in OpenSSL: SSL_SESSION *tls_session_activate(const char *session_data, int session_data_len) { #if (OPENSSL_VERSION_NUMBER < 0x0090707fL) #define BOGUS_CONST #else #define BOGUS_CONST const #endif SSL_SESSION *session; BOGUS_CONST unsigned char *ptr; /* * Activate the SSL_SESSION object. */ ptr = (BOGUS_CONST unsigned char *) session_data; session = d2i_SSL_SESSION((SSL_SESSION **) 0, &ptr, session_data_len); if (!session) tls_print_errors(); return (session); } -- Viktor. From kurt at roeckx.be Fri Dec 5 12:24:02 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 5 Dec 2014 18:24:02 +0100 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <20141205171524.GN285@mournblade.imrryr.org> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> <5481D1D7.9020501@fifthhorseman.net> <20141205160704.GA1760@roeckx.be> <20141205171524.GN285@mournblade.imrryr.org> Message-ID: <20141205172402.GA16114@roeckx.be> On Fri, Dec 05, 2014 at 05:15:24PM +0000, Viktor Dukhovni wrote: > On Fri, Dec 05, 2014 at 05:07:04PM +0100, Kurt Roeckx wrote: > > > On Fri, Dec 05, 2014 at 10:40:07AM -0500, Daniel Kahn Gillmor wrote: > > > (of course it would probably end up modifying some public > > > interfaces, so it would need to take effect publicly during an API change). > > > > Adding const to a function shouldn't be a problem for C. It would > > be for C++. > > Actually, it can be a problem with C also. Replacing "char **" in > a function prototype with "const char **" changes the API. This is actually in the C FAQ: http://c-faq.com/ansi/constmismatch.html Kurt From rsalz at akamai.com Fri Dec 5 12:28:29 2014 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 5 Dec 2014 12:28:29 -0500 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <20141205171524.GN285@mournblade.imrryr.org> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> <5481D1D7.9020501@fifthhorseman.net> <20141205160704.GA1760@roeckx.be> <20141205171524.GN285@mournblade.imrryr.org> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA542@USMBX1.msg.corp.akamai.com> Gee, BOGUS_CONST is a little harsh. MAYBE_CONST or SHOULDBE_CONST would have been nicer. From openssl-users at dukhovni.org Fri Dec 5 12:33:19 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 5 Dec 2014 17:33:19 +0000 Subject: [openssl-dev] Under-utilization of "const" in prototyping? In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA542@USMBX1.msg.corp.akamai.com> References: <5480FAAA.8000908@redfish-solutions.com> <20141205003030.GA29970@roeckx.be> <5480FD83.1080404@redfish-solutions.com> <5481D1D7.9020501@fifthhorseman.net> <20141205160704.GA1760@roeckx.be> <20141205171524.GN285@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA542@USMBX1.msg.corp.akamai.com> Message-ID: <20141205173318.GP285@mournblade.imrryr.org> On Fri, Dec 05, 2014 at 12:28:29PM -0500, Salz, Rich wrote: > Gee, BOGUS_CONST is a little harsh. MAYBE_CONST or SHOULDBE_CONST would have been nicer. Wietse does not mince words, and sarcasm is often lost in translation. -- Viktor. From krzysiek at leeds.pl Fri Dec 5 14:22:37 2014 From: krzysiek at leeds.pl (Krzysztof Kwiatkowski) Date: Fri, 05 Dec 2014 20:22:37 +0100 Subject: [openssl-dev] Ticket 2578 Message-ID: Hi, Do you plan to integrate this one somewhere soon? https://github.com/openssl/openssl/pull/113 I can help with merge if needed. Kris From rt at openssl.org Fri Dec 5 12:06:07 2014 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 5 Dec 2014 18:06:07 +0100 Subject: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64 In-Reply-To: <5481E5F3.5040105@openssl.org> References: <546CBF16.9080109@orange.fr> <5481E5F3.5040105@openssl.org> Message-ID: > OpenSSL is currently not supported under Cygwin64. Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a little bit more about what kind of problem does it cause. The Cygwin64 support was submitted by Cygwin maintainer, and no additional issues were reported. From rt at openssl.org Fri Dec 5 12:11:11 2014 From: rt at openssl.org (Michal Bozon via RT) Date: Fri, 5 Dec 2014 18:11:11 +0100 Subject: [openssl-dev] [openssl.org #3535] Resolved: TS high-precision time malformation In-Reply-To: <5481E54D.2080300@cesnet.cz> References: <5481E54D.2080300@cesnet.cz> Message-ID: .. credits should really go (if) to V. Smotlacha in the first place (and I wonder, why the original Cc header was not preserved) MB From rt at openssl.org Sat Dec 6 07:53:58 2014 From: rt at openssl.org (Corinna Vinschen via RT) Date: Sat, 6 Dec 2014 13:53:58 +0100 Subject: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64 In-Reply-To: <20141206123117.GS3810@calimero.vinschen.de> References: <546CBF16.9080109@orange.fr> <5481E5F3.5040105@openssl.org> <20141206123117.GS3810@calimero.vinschen.de> Message-ID: On Dec 5 18:06, Andy Polyakov via RT wrote: > > OpenSSL is currently not supported under Cygwin64. > > Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a > little bit more about what kind of problem does it cause. The Cygwin64 > support was submitted by Cygwin maintainer, and no additional issues > were reported. So far we didn't encounter any issues, but the OP is right. The __CYGWIN32__ definition is very old and was already deprecated in the late 1990's in favor of __CYGWIN__. As long as there was only a 32 bit Cygwin anyway, that was no problem, but it's now. I inspected the remaining two places where __CYGWIN32__ is used, and both shouldn't result in problems: e_os2.h: # if defined(__CYGWIN32__) || defined(OPENSSL_SYSNAME_CYGWIN32) OPENSSL_SYSNAME_CYGWIN32 is set anyway, so the additional check for __CYGWIN32__ is redundant. crypto/des/read_pwd.c: #if defined(OPENSSL_SYS_MSDOS) && !defined(__CYGWIN32__) && !defined(OPENSSL_SYS_WINCE) OPENSSL_SYS_MSDOS is never set for Cygwin, so the test for !__CYGWIN32__ is redundant as well. I suggest to remove both. Along the same lines, I'd like to suggest to replace OPENSSL_SYSNAME_CYGWIN32 with OPENSSL_SYSNAME_CYGWIN, and to get rid of old, unused Cygwin targets in Configure. Patch attached. I'm just not sure about "debug-ulf". If that's not required anymore, it should be removed, but that's not part of my patch. As a sidenote, the Cygwin 64 bit patch has also been backported to 1.0.1, and it's currently used in the official Cygwin OpenSSH package available as part of the Cygwin distro, see https://cygwin.com/ml/cygwin-announce/2014-10/msg00027.html https://cygwin.com/packages/x86_64/openssl/ Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- Subject: [PATCH] Drop redundant and outdated __CYGWIN32__ tests. Change OPENSSL_SYSNAME_CYGWIN32 to OPENSSL_SYSNAME_CYGWIN. Drop outdated Cygwin targets. Signed-off-by: Corinna Vinschen --- Configure | 8 +++--- TABLE | 74 +++------------------------------------------------ crypto/des/read_pwd.c | 2 +- e_os2.h | 2 +- 4 files changed, 8 insertions(+), 78 deletions(-) diff --git a/Configure b/Configure index 5e9337c..80aa223 100755 --- a/Configure +++ b/Configure @@ -184,7 +184,7 @@ my %table=( "debug-rse","cc:-DTERMIOS -DL_ENDIAN -pipe -O -g -ggdb3 -Wall::(unknown):::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}", "debug-bodo", "gcc:$gcc_devteam_warn -Wno-error=overlength-strings -DBN_DEBUG -DBN_DEBUG_RAND -DCONF_DEBUG -DBIO_PAIR_DEBUG -m64 -DL_ENDIAN -DTERMIO -g -DMD32_REG_T=int::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64", "debug-erbridge", "gcc:$gcc_devteam_warn -DBN_DEBUG -DCONF_DEBUG -DCRYPTO_MDEBUG -m64 -DL_ENDIAN -DTERMIO -g::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR):::64", -"debug-ulf", "gcc:-DTERMIOS -DL_ENDIAN -march=i486 -Wall -DBN_DEBUG -DBN_DEBUG_RAND -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DOPENSSL_NO_ASM -g -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations:::CYGWIN32:::${no_asm}:win32:cygwin-shared:::.dll", +"debug-ulf", "gcc:-DTERMIOS -DL_ENDIAN -march=i486 -Wall -DBN_DEBUG -DBN_DEBUG_RAND -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DOPENSSL_NO_ASM -g -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations:::CYGWIN:::${no_asm}:win32:cygwin-shared:::.dll", "debug-steve64", "gcc:$gcc_devteam_warn -m64 -DL_ENDIAN -DTERMIO -DCONF_DEBUG -DDEBUG_SAFESTACK -Wno-overlength-strings -g::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", "debug-steve32", "gcc:$gcc_devteam_warn -m32 -DL_ENDIAN -DCONF_DEBUG -DDEBUG_SAFESTACK -Wno-overlength-strings -g -pipe::-D_REENTRANT::-rdynamic -ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:linux-shared:-fPIC:-m32:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", "debug-steve-opt", "gcc:$gcc_devteam_warn -m64 -O3 -DL_ENDIAN -DTERMIO -DCONF_DEBUG -DDEBUG_SAFESTACK -Wno-overlength-strings -g::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:elf:dlfcn:linux-shared:-fPIC:-m64:.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", @@ -568,10 +568,8 @@ my %table=( "UWIN", "cc:-DTERMIOS -DL_ENDIAN -O -Wall:::UWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", # Cygwin -"Cygwin-pre1.3", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall::(unknown):CYGWIN32::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${no_asm}:win32", -"Cygwin", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::CYGWIN32::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", -"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN32::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", -"debug-Cygwin", "gcc:-DTERMIOS -DL_ENDIAN -march=i486 -Wall -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DOPENSSL_NO_ASM -g -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations -Werror:::CYGWIN32:::${no_asm}:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", +"Cygwin", "gcc:-DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall:::CYGWIN::BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_asm}:coff:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", +"Cygwin-x86_64", "gcc:-DTERMIOS -DL_ENDIAN -O3 -Wall:::CYGWIN::SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL:${x86_64_asm}:mingw64:dlfcn:cygwin-shared:-D_WINDLL:-shared:.dll.a", # NetWare from David Ward (dsward at novell.com) # requires either MetroWerks NLM development tools, or gcc / nlmconv diff --git a/TABLE b/TABLE index d778dac..bd4d43e 100644 --- a/TABLE +++ b/TABLE @@ -345,7 +345,7 @@ $cc = gcc $cflags = -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall $unistd = $thread_cflag = -$sys_id = CYGWIN32 +$sys_id = CYGWIN $lflags = $bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT $cpuid_obj = x86cpuid.o @@ -374,46 +374,12 @@ $ranlib = $arflags = $multilib = -*** Cygwin-pre1.3 -$cc = gcc -$cflags = -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -m486 -Wall -$unistd = -$thread_cflag = (unknown) -$sys_id = CYGWIN32 -$lflags = -$bn_ops = BN_LLONG DES_PTR DES_RISC1 DES_UNROLL RC4_INDEX MD2_INT -$cpuid_obj = -$bn_obj = -$ec_obj = -$des_obj = -$aes_obj = -$bf_obj = -$md5_obj = -$sha1_obj = -$cast_obj = -$rc4_obj = -$rmd160_obj = -$rc5_obj = -$wp_obj = -$cmll_obj = -$modes_obj = -$engines_obj = -$perlasm_scheme = void -$dso_scheme = win32 -$shared_target= -$shared_cflag = -$shared_ldflag = -$shared_extension = -$ranlib = -$arflags = -$multilib = - *** Cygwin-x86_64 $cc = gcc $cflags = -DTERMIOS -DL_ENDIAN -O3 -Wall $unistd = $thread_cflag = -$sys_id = CYGWIN32 +$sys_id = CYGWIN $lflags = $bn_ops = SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL $cpuid_obj = x86_64cpuid.o @@ -1666,40 +1632,6 @@ $ranlib = $arflags = $multilib = -*** debug-Cygwin -$cc = gcc -$cflags = -DTERMIOS -DL_ENDIAN -march=i486 -Wall -DBN_DEBUG -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DOPENSSL_NO_ASM -g -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations -Werror -$unistd = -$thread_cflag = -$sys_id = CYGWIN32 -$lflags = -$bn_ops = -$cpuid_obj = -$bn_obj = -$ec_obj = -$des_obj = -$aes_obj = -$bf_obj = -$md5_obj = -$sha1_obj = -$cast_obj = -$rc4_obj = -$rmd160_obj = -$rc5_obj = -$wp_obj = -$cmll_obj = -$modes_obj = -$engines_obj = -$perlasm_scheme = void -$dso_scheme = dlfcn -$shared_target= cygwin-shared -$shared_cflag = -D_WINDLL -$shared_ldflag = -shared -$shared_extension = .dll.a -$ranlib = -$arflags = -$multilib = - *** debug-VC-WIN32 $cc = cl $cflags = -W3 -Gs0 -GF -Gy -Zi -nologo -DOPENSSL_SYSNAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE @@ -3099,7 +3031,7 @@ $cc = gcc $cflags = -DTERMIOS -DL_ENDIAN -march=i486 -Wall -DBN_DEBUG -DBN_DEBUG_RAND -DREF_CHECK -DCONF_DEBUG -DBN_CTX_DEBUG -DCRYPTO_MDEBUG -DOPENSSL_NO_ASM -g -Wformat -Wshadow -Wmissing-prototypes -Wmissing-declarations $unistd = $thread_cflag = -$sys_id = CYGWIN32 +$sys_id = CYGWIN $lflags = $bn_ops = $cpuid_obj = diff --git a/crypto/des/read_pwd.c b/crypto/des/read_pwd.c index 7e3f902..be74e47 100644 --- a/crypto/des/read_pwd.c +++ b/crypto/des/read_pwd.c @@ -169,7 +169,7 @@ #include #endif -#if defined(OPENSSL_SYS_MSDOS) && !defined(__CYGWIN32__) && !defined(OPENSSL_SYS_WINCE) +#if defined(OPENSSL_SYS_MSDOS) && !defined(OPENSSL_SYS_WINCE) #include #define fgets(a,b,c) noecho_fgets(a,b,c) #endif diff --git a/e_os2.h b/e_os2.h index bbb2ab6..e4f6f2d 100644 --- a/e_os2.h +++ b/e_os2.h @@ -91,7 +91,7 @@ extern "C" { # undef OPENSSL_SYS_UNIX # define OPENSSL_SYS_WIN32_UWIN #else -# if defined(__CYGWIN32__) || defined(OPENSSL_SYSNAME_CYGWIN32) +# if defined(OPENSSL_SYSNAME_CYGWIN) # undef OPENSSL_SYS_UNIX # define OPENSSL_SYS_WIN32_CYGWIN # else -- 1.9.3 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Sat Dec 6 12:24:16 2014 From: rt at openssl.org (Francis ANDRE via RT) Date: Sat, 6 Dec 2014 18:24:16 +0100 Subject: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64 In-Reply-To: <54833BB0.3020200@orange.fr> References: <546CBF16.9080109@orange.fr> <5481E5F3.5040105@openssl.org> <20141206123117.GS3810@calimero.vinschen.de> <54833BB0.3020200@orange.fr> Message-ID: Hi Corinna See my comments thru the mail. Le 06/12/2014 13:53, Corinna Vinschen via RT a ?crit : > On Dec 5 18:06, Andy Polyakov via RT wrote: >>> OpenSSL is currently not supported under Cygwin64. >> Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a >> little bit more about what kind of problem does it cause. The Cygwin64 >> support was submitted by Cygwin maintainer, and no additional issues >> were reported. > So far we didn't encounter any issues, but the OP is right. The > __CYGWIN32__ definition is very old and was already deprecated in the > late 1990's in favor of __CYGWIN__. As long as there was only a 32 bit > Cygwin anyway, that was no problem, but it's now. > > I inspected the remaining two places where __CYGWIN32__ is used, and > both shouldn't result in problems: > > e_os2.h: > > # if defined(__CYGWIN32__) || defined(OPENSSL_SYSNAME_CYGWIN32) > > OPENSSL_SYSNAME_CYGWIN32 is set anyway, so the additional check for > __CYGWIN32__ is redundant. Not exactly true. In the package OpenSSL_Win32 delivered by http://slproweb.com/products/Win32OpenSSL.html, the OPENSSL_SYSNAME_CYGWIN32 is never defined, thus the conditional expression of the #if statement is alxays false which leads to the compile error. > > crypto/des/read_pwd.c: > > #if defined(OPENSSL_SYS_MSDOS) && !defined(__CYGWIN32__) && !defined(OPENSSL_SYS_WINCE) > > OPENSSL_SYS_MSDOS is never set for Cygwin, so the test for !__CYGWIN32__ > is redundant as well. > > I suggest to remove both. Along the same lines, I'd like to suggest to > replace OPENSSL_SYSNAME_CYGWIN32 with OPENSSL_SYSNAME_CYGWIN, and to get > rid of old, unused Cygwin targets in Configure. > > Patch attached. > > I'm just not sure about "debug-ulf". If that's not required anymore, it > should be removed, but that's not part of my patch. > > As a sidenote, the Cygwin 64 bit patch has also been backported to > 1.0.1, and it's currently used in the official Cygwin OpenSSH package > available as part of the Cygwin distro, see > > https://cygwin.com/ml/cygwin-announce/2014-10/msg00027.html > https://cygwin.com/packages/x86_64/openssl/ > > > Corinna > From vinschen at redhat.com Sat Dec 6 13:03:04 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 6 Dec 2014 19:03:04 +0100 Subject: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64 In-Reply-To: References: <546CBF16.9080109@orange.fr> <5481E5F3.5040105@openssl.org> <20141206123117.GS3810@calimero.vinschen.de> <54833BB0.3020200@orange.fr> Message-ID: <20141206180304.GZ3810@calimero.vinschen.de> On Dec 6 18:24, Francis ANDRE via RT wrote: > Hi Corinna > > See my comments thru the mail. > > > Le 06/12/2014 13:53, Corinna Vinschen via RT a ?crit : > > On Dec 5 18:06, Andy Polyakov via RT wrote: > >>> OpenSSL is currently not supported under Cygwin64. > >> Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a > >> little bit more about what kind of problem does it cause. The Cygwin64 > >> support was submitted by Cygwin maintainer, and no additional issues > >> were reported. > > So far we didn't encounter any issues, but the OP is right. The > > __CYGWIN32__ definition is very old and was already deprecated in the > > late 1990's in favor of __CYGWIN__. As long as there was only a 32 bit > > Cygwin anyway, that was no problem, but it's now. > > > > I inspected the remaining two places where __CYGWIN32__ is used, and > > both shouldn't result in problems: > > > > e_os2.h: > > > > # if defined(__CYGWIN32__) || defined(OPENSSL_SYSNAME_CYGWIN32) > > > > OPENSSL_SYSNAME_CYGWIN32 is set anyway, so the additional check for > > __CYGWIN32__ is redundant. > Not exactly true. In the package OpenSSL_Win32 delivered by > http://slproweb.com/products/Win32OpenSSL.html, the > OPENSSL_SYSNAME_CYGWIN32 is never defined, thus the conditional > expression of the #if statement is alxays false which leads to the > compile error. Hang on. What exactly has this to do with Cygwin? This website is dedicated to build OpenSSL for native Windows. Cygwin is an entirely different beast, and the packages (which are provided by the official Cygwin repo at http://cygwin.com anyway) should be build from the upstream sources. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Sat Dec 6 12:59:40 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 6 Dec 2014 18:59:40 +0100 Subject: [openssl-dev] [openssl.org #3605] bug report: compilation error and fix for OpenSSL on Cygwin64 In-Reply-To: References: <546CBF16.9080109@orange.fr> <5481E5F3.5040105@openssl.org> <20141206123117.GS3810@calimero.vinschen.de> <54833BB0.3020200@orange.fr> Message-ID: <20141206175940.GY3810@calimero.vinschen.de> On Dec 6 18:24, Francis ANDRE via RT wrote: > Hi Corinna > > See my comments thru the mail. > > > Le 06/12/2014 13:53, Corinna Vinschen via RT a ?crit : > > On Dec 5 18:06, Andy Polyakov via RT wrote: > >>> OpenSSL is currently not supported under Cygwin64. > >> Support for Cygwin64 will appear in 1.0.2, so that I'd like to hear a > >> little bit more about what kind of problem does it cause. The Cygwin64 > >> support was submitted by Cygwin maintainer, and no additional issues > >> were reported. > > So far we didn't encounter any issues, but the OP is right. The > > __CYGWIN32__ definition is very old and was already deprecated in the > > late 1990's in favor of __CYGWIN__. As long as there was only a 32 bit > > Cygwin anyway, that was no problem, but it's now. > > > > I inspected the remaining two places where __CYGWIN32__ is used, and > > both shouldn't result in problems: > > > > e_os2.h: > > > > # if defined(__CYGWIN32__) || defined(OPENSSL_SYSNAME_CYGWIN32) > > > > OPENSSL_SYSNAME_CYGWIN32 is set anyway, so the additional check for > > __CYGWIN32__ is redundant. > Not exactly true. In the package OpenSSL_Win32 delivered by > http://slproweb.com/products/Win32OpenSSL.html, the > OPENSSL_SYSNAME_CYGWIN32 is never defined, thus the conditional > expression of the #if statement is alxays false which leads to the > compile error. Then that package needs fixing. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon Dec 8 06:09:55 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 8 Dec 2014 12:09:55 +0100 Subject: [openssl-dev] [openssl.org #3181] [PATCH] OCB In-Reply-To: References: Message-ID: OCB support has been merged in. Closing my own ticket. Matt From rt at openssl.org Mon Dec 8 08:46:25 2014 From: rt at openssl.org (Vijendra Boopathy via RT) Date: Mon, 8 Dec 2014 14:46:25 +0100 Subject: [openssl-dev] [openssl.org #3623] faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b. In-Reply-To: References: Message-ID: Hi, The exact error which i faced in Event log are given below. Faulting application name: aeagent.exe, version:0.0.0.0, time stamp:0x53e1f20f Faulting module name: SSLEAY32.dll, version:0.0.0.0, time stamp: 0x405a2628 Exception code: 0xc0000005 Fault offset: 0x00010c8b Faulting process id : 0x1bc0 What is that mean?? I googled with this error, firefox faced the same error and they gave workaround was replace the latest version of dll. I did the same but no use.. Please tell what i want to do?? On 5 December 2014 at 22:01, Andy Polyakov via RT wrote: > > Am using openssl for my monitoring tools and i have facing *faulting > module > > ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b *in application > > log and its all type of windows OS > > May i know that it is known issue or new issue,if it is known issue > please > > provide issue id. > > > > Kindly help ASP... > > > > Note : am using latest openssl (openssl-1.0.1j.tar.gz > > ) > > Specific fault address does not provide sufficient information by itself > and it's impossible to tell anything from it. You refer to source code, > and if you compile it yourself, you'll have symbol information as .pdb > files that you can use to identify failing function. You should be able > to use it together with crash dump information in debugger to identify > failing function and collect so called stack back-trace. Only then it > would be possible to make some assessment about nature of the problem. > [As for "crash dump", I don't think meaningful crash dump generation is > enabled by default nowadays, i.e. you would have to configure it, google > should be your friend]. > > > > -- Thanks & Regards vijendra boopathy.k From rt at openssl.org Mon Dec 8 13:35:36 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Mon, 8 Dec 2014 19:35:36 +0100 Subject: [openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8] In-Reply-To: <20141205215246.3AaohGjC%sdaoden@yandex.com> References: <20141205215246.3AaohGjC%sdaoden@yandex.com> Message-ID: Does: - Fixes a typo in s_client.pod (2x "in the"). - Changes .pod to reflect reality: it is SSL_CONF_CTX_finish(), not SSL_CONF_finish(). - While here it seems best to change the remaining SSL_CONF_cmd(), SSL_CONF_cmd_argv() and SSL_CONF_cmd_value_type() to have a SSL_CONF_CTX_ prefix, too. PODs renamed accordingly. - Adjusts all places where git grep -i matches against the former. It compiles etc. It's ugly to have SSL_CONF_CTX_ as a prefix, but isn't it better to have a unique interface instead of special-treating the _cmd* stuff? Would be really nice like that. - --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_conf-unify.diff Type: text/x-diff Size: 49834 bytes Desc: not available URL: From rt at openssl.org Mon Dec 8 13:57:45 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Mon, 8 Dec 2014 19:57:45 +0100 Subject: [openssl-dev] [openssl.org #3624] Unify SSL_CONF_* interface to be SSL_CONF_CTX_*, with patch against [master/33d5ba8] In-Reply-To: <20141206134738.V6rejqv-%sdaoden@yandex.com> References: <20141205215246.3AaohGjC%sdaoden@yandex.com> <20141206134738.V6rejqv-%sdaoden@yandex.com> Message-ID: Oh yes: and on top of that former patch there really where also dangling SSL_CTX_cmd() use cases in .pod files, which are thus and finally changed to SSL_CONF_CTX_cmd via the attached patch, too. Thank you. --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_conf-unify-fixup.diff Type: text/x-diff Size: 3082 bytes Desc: not available URL: From rt at openssl.org Mon Dec 8 13:58:31 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Mon, 8 Dec 2014 19:58:31 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141205220511.FmMVpf0B%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> Message-ID: Commit [45f55f6] (Remove SSLv2 support, 2014-11-30) completely removed SSLv2 support and the commit message states "The only support for SSLv2 left is receiving a SSLv2 compatible client hello". If people start using SSL_CONF_CTX as they are supposed to with v1.0.2, then it can be expected that users start using strings like, e.g. (from my thing), set ssl-protocol="ALL,-SSLv2" This results in the obvious problem that when they (get) upgrade(d) their OpenSSL library they will see a completely intransparent error message that no normal user will understand: SSL_CONF_CTX_cmd() failed:\ error:1414E180:SSL routines:SSL_CONF_CTX_cmd:bad value (Ah ja, my _CTX_ diff also works in practice.) I think it would be much better if at least a user request to explicitly disable SSLv2 is silently ignored. Another option would be to enhance the error message, of course... --steffen From rt at openssl.org Mon Dec 8 14:20:09 2014 From: rt at openssl.org (Glen Miner via RT) Date: Mon, 8 Dec 2014 20:20:09 +0100 Subject: [openssl-dev] [openssl.org #3626] Entropy on Win discounts CryptGenRandom length In-Reply-To: References: Message-ID: rand_win.c(361) RAND_add(buf, sizeof(buf), 0);This is inconsistent with line 375 which passes sizeof(buf) for the bytes of entropy. This means that the entropy from the OS pool is discounted; in normal circumstances this is insignificant because the rest of this function collects plenty of entropy from the rest of the system. In rare cases this leads to problems in md_rand.c -- line 403 ok = (entropy >= ENTROPY_NEEDED); if (!ok) In the case that rand_win.c doesn't seed with enough entropy it goes on to stir the pool it but never sets 'ok' afterward and so ssleay_rand_bytes returns failure which seems a bit harsh. Locally we've changed rand_win.c to pass sizeof(buf) when adding the entropy from PROV_RSA_FULL which avoids the problems in md_rand.c -- I'm not sure what the intention is there, though. The rare case involved actually came about after we discovered that RAND_poll was locking heaps in our process and generally causing massive hitches in certain parts of our game; once we'd traced it back to this heap-crawling stuff we made two changes to RAND_poll: 1) We increased the size of buf to 10242) We changed line 45 to if (kernel && !good) The idea is that if the OS entropy pool will feed us a good chunk of good random numbers we can avoid beating the hell out of the heap which required serialization. Initially we found this worked great until certain users started complaining about OpenSSL errors because of the bugs described above -- it turns out some of them had turned off the OS Workstation service which was contributing entropy in rand_win.c(269) which brought us below the required amount of entropy in md_rand.c and here we are. -g From rt at openssl.org Mon Dec 8 14:20:44 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Mon, 8 Dec 2014 20:20:44 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141206212107.xQjigGTt%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: Hello, and finally i propose three new values for the "Protocol" slot of SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I included OLDEST for completeness sake, NEWEST is in effect what i've always forced for my thing whenever possible, and encouraged users to use themselve, but of course it was pretty inflexible before the advent of NEWEST. :) I think VULNERABLE is a good thing to have despite it's humiliating name, because it could be used to automatically secure users by simply updating the OpenSSL library, effectively giving the option to obsolete insecure protocols faster than what was possible in the past, and of course: only possibly so. But anyway: in my opinion it would be a real security improvement if users could either use "-ALL,NEWEST", or, shall that not be possible, "ALL,-VULNERABLE", rather in the spirit "configure once and forget, but stay secure". Or something along these lines. Find attached a patch that does this and can be applied on top of the other two patches i've send regarding SSL_CONF_CTX. Notes: - Readds a dummy SSLv2 value (thus includes a patch for the other issue i've opened). - Fixes some whitespace-at-eol issues of the .pod. Thanks and ciao. P.S.: i plan to release a new minor of my thing before the christian christmas feast, it would be _really_ great to know what the OpenSSL thinks regarding the function renaming and these new values, since i'm switching over to the new SSL_CONF_CTX interface and am implementing a wrapper unless HAVE_OPENSSL_CONF_CTX becomes omnipresent. Thank you. --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ssl_conf-more-opts.diff Type: text/x-diff Size: 5752 bytes Desc: not available URL: From rsalz at akamai.com Mon Dec 8 14:37:49 2014 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 8 Dec 2014 14:37:49 -0500 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. From rt at openssl.org Mon Dec 8 14:37:57 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 8 Dec 2014 20:37:57 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> Message-ID: I think magic names -- shorthands -- are a very bad idea. They are point-in-time statements whose meaning evolves, if not erodes, over time. From rt at openssl.org Mon Dec 8 15:29:30 2014 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 8 Dec 2014 21:29:30 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141208202923.GA11298@roeckx.be> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141208202923.GA11298@roeckx.be> Message-ID: On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote: > set ssl-protocol="ALL,-SSLv2" > > This results in the obvious problem that when they (get) > upgrade(d) their OpenSSL library they will see a completely > intransparent error message that no normal user will understand: It was actually my intention to keep supporting that, but I seem to have removed that line. I think the following patch should fix that: --- a/ssl/ssl_conf.c +++ b/ssl/ssl_conf.c @@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx, const char *value) static const ssl_flag_tbl ssl_protocol_list[] = { SSL_FLAG_TBL_INV("ALL", SSL_OP_NO_SSL_MASK), + SSL_FLAG_TBL_INV("SSLv2", SSL_OP_NO_SSLv2), SSL_FLAG_TBL_INV("SSLv3", SSL_OP_NO_SSLv3), SSL_FLAG_TBL_INV("TLSv1", SSL_OP_NO_TLSv1), SSL_FLAG_TBL_INV("TLSv1.1", SSL_OP_NO_TLSv1_1), Kurt From rt at openssl.org Mon Dec 8 15:37:03 2014 From: rt at openssl.org (Kurt Roeckx via RT) Date: Mon, 8 Dec 2014 21:37:03 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141208203655.GB11298@roeckx.be> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141208203655.GB11298@roeckx.be> Message-ID: On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: > Hello, > > and finally i propose three new values for the "Protocol" slot of > SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. I actually find the option unfortunate and I think it should have been one that sets the minimum and maximum version. But I think we're too late 1.0.2 process to still change this. Kurt From appro at openssl.org Mon Dec 8 15:51:08 2014 From: appro at openssl.org (Andy Polyakov) Date: Mon, 08 Dec 2014 21:51:08 +0100 Subject: [openssl-dev] [openssl.org #3181] [PATCH] OCB In-Reply-To: References: Message-ID: <54860F3C.3040601@openssl.org> > OCB support has been merged in. Closing my own ticket. Following is not directly related to the case per se [which is why rt doesn't get this message]. It's just that it makes nice example on why one sometimes wants to implement encryption mode in assembly. If you compare performance on AES-NI-capable processor, you'll see significant differences depending on compiler used. Here is result for clang: type ... 8192 bytes aes-128-ocb ... 909434.88k And here is for gcc aes-128-ocb ... 399447.38k Thing is that hardware-assisted crypto is so fast that surrounding code can start dominating execution time. I mean above is indication of such case. And it also likely to mean that even former above result is actually far from optimal, it's surely possible to improve it by several *times*. Indeed, OCB is parallelizeable mode, and it should be close to other parallelizeable ones. Here is CTR result from same processor: aes-128-ctr ... 4407367.00k Well, it's AEAD, so there would be some overhead, but it's minimal in OCB. But let's compare to GCM anyway: aes-128-gcm ... 2719591.59k Once again, this is *not* some kind of objection, only a note that *if* we decide to consider the mode in question important, it should be possible to improve it by factor of several times on contemporary CPUs. From richmoore44 at gmail.com Mon Dec 8 16:31:58 2014 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 8 Dec 2014 21:31:58 +0000 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: On 8 December 2014 at 19:20, Steffen Nurpmeso via RT wrote: > and finally i propose three new values for the "Protocol" slot of > SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > In Qt we've added an enum value for TLS versions that is SecureProtocols so that we could remove versions as required without requiring apps to be updated. It's an open question which is more likely to get updated - Qt or the apps of course. For Qt 5.4 which is due out this week we've removed SSL3 from this enum so apps will silently get updated to drop support for it. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon Dec 8 16:38:42 2014 From: rt at openssl.org (Richard Moore via RT) Date: Mon, 8 Dec 2014 22:38:42 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: On 8 December 2014 at 19:20, Steffen Nurpmeso via RT wrote: > and finally i propose three new values for the "Protocol" slot of > SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > In Qt we've added an enum value for TLS versions that is SecureProtocols so that we could remove versions as required without requiring apps to be updated. It's an open question which is more likely to get updated - Qt or the apps of course. For Qt 5.4 which is due out this week we've removed SSL3 from this enum so apps will silently get updated to drop support for it. Cheers Rich. From rt at openssl.org Mon Dec 8 23:38:56 2014 From: rt at openssl.org (The Tester via RT) Date: Tue, 9 Dec 2014 05:38:56 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <1576649245.7050421.1418099724211.JavaMail.yahoo@jws10685.mail.bf1.yahoo.com> References: <1576649245.7050421.1418099724211.JavaMail.yahoo@jws10685.mail.bf1.yahoo.com> Message-ID: Thanks for the response, Andy, it's good to know that the demo program does actually work for someone. Sorry for the delay, I'm kinda busy with other things right now. Also, I realised the link was truncated, but it looks as though you found the demo anyway. https://github.com/saju/misc/blob/master/misc/openssl_aes.c The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Switching to calloc instead of malloc does not hide the issue, which suggests that it's actually a problem somewhere in the bowels of OpenSSL, copying unassigned values into the output. Likewise, the demo program uses null-terminated strings because they're easy to see in operation. My real program uses manually padded, known-size binary packets but adding extra code to show that did not seem worth while. It would likely lead to a bunch of other questions about design decisions and other irrelevancies when the problem is that valgrind is unhappy about the way OpenSSL (appears to) work. I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using? "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" if that might make a difference. Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013" ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ... ==2793== Conditional jump or move depends on uninitialised value(s) ==2793==??? at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2793==??? by 0x400FA1: main (in /home/digidev/test/a.out) ==2793==? Uninitialised value was created by a stack allocation ==2793==??? at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... I hoped that the padding functions would mean that manually padding the inputs was not necessary. Admittedly in my real code I am doing manual padding to get control over the padding - the hardware I'm communicating with does not pad or accept padding on a plaintext that is an exact multiple of the block size where OpenSSL/PKCS does. But the demo uses auto padding, and I'd hoped that it would work. aes_encrypt function has this: ??? /* update ciphertext with the final remaining bytes */ ??? EVP_EncryptFinal_ex(e, ciphertext + encryptedLength, &paddingLength); ??? *len = encryptedLength + paddingLength; Surely this means that the output is padded and therefore the input does not need to be a multiple of the block size. The program claims to work without manual padding, anyway. As far as querying the block size, that has ramifications beyond my program so changing it would break compatibility with hardware we've already shipped (for example). All I could do if I queried was check against the hard-coded value and exit abruptly since my program will not work. ?ThanksChris From: Andy Polyakov via RT To: prwh1x4 at yahoo.com.au Cc: openssl-dev at openssl.org Sent: Saturday, 6 December 2014, 3:27 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext > I started with an AES256 demo I found at https://github.com/saju/misc and modified the initialisations to use AES128. The test strings that program uses are quite short - less than 100 characters. If I add a significantly longer string to those test values Valgrind reports a string of what I suspect are buffer overruns. Note that I discovered this in my real code and this is a simple test case that seems to demonstrate the same problem. I also print the library version that the program is using. I don't get any valgrind errors, not a single one. But then I had to add -DAES_BLOCK_SIZE=16 at compiler command line, as program in question failed to include . Well, I don't really want to say "failed to include", because it implies that I'd suggest to do so, when I don't actually mean to. Correct solution in real life would be to query cipher block size with EVP_CIPHER_block_size, as opposite to relying on cipher-specific header. It's just that I see no point in fixing that program. As for alleged buffer overruns in your program. You have to recognize and remember that AES is a block cipher, which means that CBC encrypt output and decrypt input lengths has to be divisible by block size. [Ideally even encrypt input and decrypt output lengths should be divisible, but EVP gives you some help by padding encrypt input.] In other words, is it possible that you allocate buffer based in input string length, which would actually be prone to overrun. Though I again say things I don't want to say, namely implicitly suggest that it's OK to encrypt null-terminated strings with CBC without application controlled padding. Though, for completeness sake one can mention that there are CBC variants suitable for this purpose, namely Cipher Text Stealing modes, but these are not supported by OpenSSL (yet?). From rt at openssl.org Mon Dec 8 23:50:06 2014 From: rt at openssl.org (The Tester via RT) Date: Tue, 9 Dec 2014 05:50:06 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <47977426.5764049.1418100595337.JavaMail.yahoo@jws10679.mail.bf1.yahoo.com> References: <1576649245.7050421.1418099724211.JavaMail.yahoo@jws10685.mail.bf1.yahoo.com> <47977426.5764049.1418100595337.JavaMail.yahoo@jws10679.mail.bf1.yahoo.com> Message-ID: Is there a better demo program I can use as the basis for my code? I'd be happy to redo my stuff based on anything that I can download and run without having to dig through the OpenSSL/test sets to try to find hints (which I've done, but there didn't seem to be a simple AES128/cbc test that I could find. The only matches from the string were in test binaries for ssl and evp). And one apparently irrelevant error: the first version on Fedora below I forgot to change the demo code from ASE256 ot AES128... but the Valgrind complaints are the same when I make the change. ... ==2810== Conditional jump or move depends on uninitialised value(s)==2810==??? at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2810==??? by 0x400FF1: main (in /home/digidev/test/a.out) ==2810==? Uninitialised value was created by a stack allocation ==2810==??? at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... The advantage of the Fedora VM is that it's literally brand new out of the box - I downloaded the latest Fedora Desktop ISO, installed using the defaults, then ran through the "yum install..." iterations I needs to be able to reproduce the problem. I suspect that you could do that in one line: ?? yum install gpp gcc-c++ valgrind openssl openssl-devel (I appreciate that this is ~500MB of download and an hour or so to install, but it does mean that you should be able to reproduce the problem if you're really desperate). Chris From: The Tester To: "rt at openssl.org" Cc: "openssl-dev at openssl.org" Sent: Tuesday, 9 December 2014, 15:35 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext Thanks for the response, Andy, it's good to know that the demo program does actually work for someone. Sorry for the delay, I'm kinda busy with other things right now. Also, I realised the link was truncated, but it looks as though you found the demo anyway. https://github.com/saju/misc/blob/master/misc/openssl_aes.c The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Switching to calloc instead of malloc does not hide the issue, which suggests that it's actually a problem somewhere in the bowels of OpenSSL, copying unassigned values into the output. Likewise, the demo program uses null-terminated strings because they're easy to see in operation. My real program uses manually padded, known-size binary packets but adding extra code to show that did not seem worth while. It would likely lead to a bunch of other questions about design decisions and other irrelevancies when the problem is that valgrind is unhappy about the way OpenSSL (appears to) work. I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using? "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" if that might make a difference. Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013" ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info ... ==2793== Conditional jump or move depends on uninitialised value(s) ==2793==??? at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==2793==??? by 0x400FA1: main (in /home/digidev/test/a.out) ==2793==? Uninitialised value was created by a stack allocation ==2793==??? at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) ... I hoped that the padding functions would mean that manually padding the inputs was not necessary. Admittedly in my real code I am doing manual padding to get control over the padding - the hardware I'm communicating with does not pad or accept padding on a plaintext that is an exact multiple of the block size where OpenSSL/PKCS does. But the demo uses auto padding, and I'd hoped that it would work. aes_encrypt function has this: ??? /* update ciphertext with the final remaining bytes */ ??? EVP_EncryptFinal_ex(e, ciphertext + encryptedLength, &paddingLength); ??? *len = encryptedLength + paddingLength; Surely this means that the output is padded and therefore the input does not need to be a multiple of the block size. The program claims to work without manual padding, anyway. As far as querying the block size, that has ramifications beyond my program so changing it would break compatibility with hardware we've already shipped (for example). All I could do if I queried was check against the hard-coded value and exit abruptly since my program will not work. ?ThanksChris From: Andy Polyakov via RT To: prwh1x4 at yahoo.com.au Cc: openssl-dev at openssl.org Sent: Saturday, 6 December 2014, 3:27 Subject: Re: [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext > I started with an AES256 demo I found at https://github.com/saju/misc and modified the initialisations to use AES128. The test strings that program uses are quite short - less than 100 characters. If I add a significantly longer string to those test values Valgrind reports a string of what I suspect are buffer overruns. Note that I discovered this in my real code and this is a simple test case that seems to demonstrate the same problem. I also print the library version that the program is using. I don't get any valgrind errors, not a single one. But then I had to add -DAES_BLOCK_SIZE=16 at compiler command line, as program in question failed to include . Well, I don't really want to say "failed to include", because it implies that I'd suggest to do so, when I don't actually mean to. Correct solution in real life would be to query cipher block size with EVP_CIPHER_block_size, as opposite to relying on cipher-specific header. It's just that I see no point in fixing that program. As for alleged buffer overruns in your program. You have to recognize and remember that AES is a block cipher, which means that CBC encrypt output and decrypt input lengths has to be divisible by block size. [Ideally even encrypt input and decrypt output lengths should be divisible, but EVP gives you some help by padding encrypt input.] In other words, is it possible that you allocate buffer based in input string length, which would actually be prone to overrun. Though I again say things I don't want to say, namely implicitly suggest that it's OK to encrypt null-terminated strings with CBC without application controlled padding. Though, for completeness sake one can mention that there are CBC variants suitable for this purpose, namely Cipher Text Stealing modes, but these are not supported by OpenSSL (yet?). From rt at openssl.org Tue Dec 9 05:02:41 2014 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 9 Dec 2014 11:02:41 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <5486C8B8.20302@openssl.org> References: <1576649245.7050421.1418099724211.JavaMail.yahoo@jws10685.mail.bf1.yahoo.com> <5486C8B8.20302@openssl.org> Message-ID: > The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Yes, which is why I said "as for alleged buffer overruns in *your* program". I mean you said "I discovered this [suspected buffer overrun] in my real code" and as you didn't present it, I found it appropriate to remind that strlen-based allocations are prone to overruns, and if it would be case, it would be something for you to address. > My real program uses manually padded, known-size binary packets Excellent! If you would have clarified this from beginning, we wouldn't have this digression :-) > I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" if that might make a difference. > Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) > > > Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013" > ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info > ... > ==2793== Conditional jump or move depends on uninitialised value(s) > ==2793== at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2793== by 0x400FA1: main (in /home/digidev/test/a.out) > ==2793== Uninitialised value was created by a stack allocation > ==2793== at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) > ... OK. Keyword here is that it's 1.0.1 (I was testing against development branch, master and 1.0.2). 1.0.1 is actually known to upset valgrind (see RT#2862), but it looks more like valgrind bug. Well, it's somewhat in between: one can argue that valgrind has formal right to complain, but at the same time aesni_cbc_encrypt doesn't actually violate ABI constrains. Latter means that result is always correct and code in question doesn't actually overrun any buffers nor uses uninitialized values. The reason for why I failed to initially reproduce it in master and 1.0.2 is that module in question was updated after 1.0.1 release to not rely on red zone (the thing valgrind is complaining about). But this was done for reason other than appeasing valgrind. In case you wonder why problem pops up with longer lengths. This is because with shorter lengths it's possible to keep everything in processor registers. And with longer length it has to spill one value to stack. From sdaoden at yandex.com Tue Dec 9 06:11:34 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 12:11:34 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141208202923.GA11298@roeckx.be> Message-ID: <20141209111134.8zKkrs4f%sdaoden@yandex.com> "Kurt Roeckx via RT" wrote: |On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote: |> set ssl-protocol="ALL,-SSLv2" |> |> This results in the obvious problem that when they (get) |> upgrade(d) their OpenSSL library they will see a completely |> intransparent error message that no normal user will understand: | |It was actually my intention to keep supporting that, but I seem |to have removed that line. I think the following patch should fix |that: |--- a/ssl/ssl_conf.c |+++ b/ssl/ssl_conf.c |@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx, |const char *value) | static const ssl_flag_tbl ssl_protocol_list[] = | { | SSL_FLAG_TBL_INV("ALL", SSL_OP_NO_SSL_MASK), |+ SSL_FLAG_TBL_INV("SSLv2", SSL_OP_NO_SSLv2), | SSL_FLAG_TBL_INV("SSLv3", SSL_OP_NO_SSLv3), | SSL_FLAG_TBL_INV("TLSv1", SSL_OP_NO_TLSv1), | SSL_FLAG_TBL_INV("TLSv1.1", SSL_OP_NO_TLSv1_1), Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know. --steffen From sdaoden at yandex.com Tue Dec 9 06:21:18 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 12:21:18 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> Message-ID: <20141209112118.8QH3mNrZ%sdaoden@yandex.com> "Salz, Rich" wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. How many people have read all the RFCs that are involved? And how many people have sufficient knowledge to _really_ understand the mathematical concepts and actual algorithms? Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' and leave the task of deciding what is VULNERABLE up to you. Imagine that. I have already implemented the necessary _CONF_ wrapper for OpenSSL v1.0.1 and it'll gave you a hand (shall the list receive this message). --steffen From sdaoden at yandex.com Tue Dec 9 06:27:38 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 12:27:38 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141208203655.GB11298@roeckx.be> Message-ID: <20141209112738.qOw6yRaC%sdaoden@yandex.com> "Kurt Roeckx via RT" wrote: |On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |I actually find the option unfortunate and I think it should have |been one that sets the minimum and maximum version. But I think |we're too late 1.0.2 process to still change this. A good benefit for a three line patch. Being able to say "-ALL,>=TLSv1.1" etc. is surely on the list of many, and much more complicated to implement than that. --steffen From sdaoden at yandex.com Tue Dec 9 06:35:30 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 12:35:30 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: <20141209113530.Va82J7PF%sdaoden@yandex.com> Richard Moore wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen From richmoore44 at gmail.com Tue Dec 9 07:09:03 2014 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 9 Dec 2014 12:09:03 +0000 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209113530.Va82J7PF%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141209113530.Va82J7PF%sdaoden@yandex.com> Message-ID: On 9 December 2014 at 11:35, Steffen Nurpmeso wrote: > Richard Moore wrote: > |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT > wrote: > |> and finally i propose three new values for the "Protocol" slot of > |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > | > |In Qt we've added an enum value for TLS versions that is SecureProtocols > so > |that we could remove versions as required without requiring apps to be > |updated. It's an open question which is more likely to get updated - Qt > or > |the apps of course. For Qt 5.4 which is due out this week we've removed > |SSL3 from this enum so apps will silently get updated to drop support for > |it. > > I see. And i think this is the most impressive or, lesser > enthusiastic, important feature of the slow _CONF_ interface: that > users can use strings and that those are directly swallowed by the > OpenSSL library, so that neither recompilation nor understanding > is necessary on the program side in order to upgrade to a new > level of security. > The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. > (As a side note: SecureProtocols is such a Volvo wording... > Doesn't vulnerable energises a deeper feeling of insecurity? > I think Hitchcock would have used the naked and bare vulnerable.) > That's partly due to the API naming conventions for enums. :-) Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sdaoden at yandex.com Tue Dec 9 08:46:30 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 14:46:30 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141209113530.Va82J7PF%sdaoden@yandex.com> Message-ID: <20141209134630.z8eQl8Xc%sdaoden@yandex.com> Richard Moore wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso wrote: |> Richard Moore wrote: |>|On 8 December 2014 at 19:20, Steffen Nurpmeso via RT |> wrote: |>|> and finally i propose three new values for the "Protocol" slot of |>|> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. |>| |>|In Qt we've added an enum value for TLS versions that is SecureProtocols |> so |>|that we could remove versions as required without requiring apps to be |>|updated. It's an open question which is more likely to get updated - Qt |> or |>|the apps of course. For Qt 5.4 which is due out this week we've removed |>|SSL3 from this enum so apps will silently get updated to drop support for |>|it. |> |> I see. And i think this is the most impressive or, lesser |> enthusiastic, important feature of the slow _CONF_ interface: that |> users can use strings and that those are directly swallowed by the |> OpenSSL library, so that neither recompilation nor understanding |> is necessary on the program side in order to upgrade to a new |> level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. |> (As a side note: SecureProtocols is such a Volvo wording... |> Doesn't vulnerable energises a deeper feeling of insecurity? |> I think Hitchcock would have used the naked and bare vulnerable.) |> | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen From sdaoden at yandex.com Tue Dec 9 08:58:19 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 09 Dec 2014 14:58:19 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209112738.qOw6yRaC%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141208203655.GB11298@roeckx.be> <20141209112738.qOw6yRaC%sdaoden@yandex.com> Message-ID: <20141209135819.P5OJp-Ag%sdaoden@yandex.com> |"Kurt Roeckx via RT" wrote: ||been one that sets the minimum and maximum version. But I think ||we're too late 1.0.2 process to still change this. Attached a git format-patch MBOX for 1.0.2 (on top of [6806b69]). It boils anything down into two changesets (SSL_CONF_CTX and pseudo protocols). Remarks: - I've adjusted anything for SSLv2 (in the PODs, as OLDEST, in VULNERABLE). - s_client.pod and s_server.pod did not yet state that they support the SSL_CONF_CTX arguments, so i've added that (which s_cb.c seems to support already). - make && make test work, rest yet just installed. Let me know if you want the same for [master] again. I really hope you do that, and Ciao from Germany --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ossl-1_0_2.mbox Type: application/mbox Size: 29466 bytes Desc: not available URL: From amdeich at gmail.com Tue Dec 9 21:16:07 2014 From: amdeich at gmail.com (Andrey Kulikov) Date: Wed, 10 Dec 2014 05:16:07 +0300 Subject: [openssl-dev] License compatibility: OpenSSL and Apache v2 Message-ID: Hello, Let's imagine someone develop extension module to OpenSSL, and release it under Apache v2 license. Do you see any possible issues with using this extension module as a part of OpenSSL? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Dec 9 21:54:29 2014 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 Dec 2014 21:54:29 -0500 Subject: [openssl-dev] License compatibility: OpenSSL and Apache v2 In-Reply-To: References: Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BFFE@USMBX1.msg.corp.akamai.com> > Let's imagine someone develop extension module to OpenSSL, and release it under Apache v2 license. > Do you see any possible issues with using this extension module as a part of OpenSSL? Are you writing an extension that you are going to distribute, or is it something you want to contribute to OpenSSL? You cannot change the license on openssl files, and any work derived from them such as modifications to those source files, must have the same license. And if you want to to contribute it to the project, it is easiest for us if the license is the same. But if it is your own code, and you are distributing it, then you can do anything you want :) From amdeich at gmail.com Wed Dec 10 11:42:29 2014 From: amdeich at gmail.com (Andrey Kulikov) Date: Wed, 10 Dec 2014 19:42:29 +0300 Subject: [openssl-dev] License compatibility: OpenSSL and Apache v2 In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BFFE@USMBX1.msg.corp.akamai.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BFFE@USMBX1.msg.corp.akamai.com> Message-ID: This is something I would like to be contributed to OpenSSL. Sure, I'm talking about new engine and new files. And I agree that using the same license as OpenSSL itself would be the best solution. But, if for some reasons licensing of it will be possible under Apache v2 only - what issues could it cause? On 10 December 2014 at 05:54, Salz, Rich wrote: > > Let's imagine someone develop extension module to OpenSSL, and release > it under Apache v2 license. > > Do you see any possible issues with using this extension module as a > part of OpenSSL? > > Are you writing an extension that you are going to distribute, or is it > something you want to contribute to OpenSSL? > > You cannot change the license on openssl files, and any work derived from > them such as modifications to those source files, must have the same > license. And if you want to to contribute it to the project, it is easiest > for us if the license is the same. > > But if it is your own code, and you are distributing it, then you can do > anything you want :) > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Wed Dec 10 11:51:15 2014 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 10 Dec 2014 09:51:15 -0700 Subject: [openssl-dev] More POODLE issues Message-ID: <20141210164918.GA24166@doctor.nl2k.ab.ca> Now POODLE is hitting TLS http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html Any fixes in the works? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2014 and Happy New Year 2015 From rt at openssl.org Tue Dec 9 09:33:33 2014 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 9 Dec 2014 15:33:33 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141205220511.FmMVpf0B%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> Message-ID: On Mon Dec 08 19:58:31 2014, sdaoden at yandex.com wrote: > Commit [45f55f6] (Remove SSLv2 support, 2014-11-30) completely > removed SSLv2 support and the commit message states "The only > support for SSLv2 left is receiving a SSLv2 compatible client > hello". > > If people start using SSL_CONF_CTX as they are supposed to with > v1.0.2, then it can be expected that users start using strings > like, e.g. (from my thing), > > set ssl-protocol="ALL,-SSLv2" > > This results in the obvious problem that when they (get) > upgrade(d) their OpenSSL library they will see a completely > intransparent error message that no normal user will understand: > > SSL_CONF_CTX_cmd() failed:\ > error:1414E180:SSL routines:SSL_CONF_CTX_cmd:bad value > > (Ah ja, my _CTX_ diff also works in practice.) > I think it would be much better if at least a user request to > explicitly disable SSLv2 is silently ignored. > Another option would be to enhance the error message, of course... > If you print out the additional error data it should also indicate which command and value it is objecting to, though it will only say it doesn't like the whole string and not the specific part of it it is rejecting. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Wed Dec 10 03:06:20 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 09:06:20 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Sorry. Line 1244 is OPENSSL_assert(s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH == (unsigned int)s->init_num); 2014-12-10 11:05 GMT+03:00 ???????? ??????? : > (gdb) p s->d1->w_msg_hdr.msg_len > $2 = 0 > (gdb) p s->init_num > $3 = 0 > > > 2014-12-10 10:59 GMT+03:00 ???????? ??????? : > >> Get again ASSERT in d1_both.c:1244 >> >> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >> >> ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned >> int)s->init_num); >> } >> >> >> >> >> >> 2014-12-10 6:32 GMT+03:00 ???????? ??????? : >> >>> Hello. I begin test you patch. I attach to mail patched version of you >>> patch wthat may clear added current SRPM of Centos 6 >>> >>> 2014-12-03 5:16 GMT+03:00 ???????? ??????? : >>> >>>> Thanks! I need time to test it... i will try answer at this week >>>> >>>> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >>>> >>>>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>>>> > if you send patch i can add it to SRPM build and try results >>>>> > >>>>> The patch is attached. However you may have problems with this >>>>> approach. I have >>>>> built the patch for 1.0.1e (which is the version you originally said >>>>> you were >>>>> running). However any additional patches that have been applied to the >>>>> SRPM >>>>> could cause the patch to fail to apply (and it is quite a large >>>>> patch). I can >>>>> also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable >>>>> from git >>>>> if you prefer. >>>>> >>>>> Matt >>>>> >>>>> >>>> >>>> >>>> -- >>>> ? ?????????, >>>> ??????? ???????? ????????? >>>> >>>> ??? "???????? ??????-???????" >>>> ??????????? ???????? >>>> +7 (495) 666-0-111 >>>> http://www.open-bs.ru >>>> >>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Tue Dec 9 17:26:36 2014 From: rt at openssl.org (The Tester via RT) Date: Tue, 9 Dec 2014 23:26:36 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <873619206.7485426.1418163965656.JavaMail.yahoo@jws10653.mail.bf1.yahoo.com> References: <873619206.7485426.1418163965656.JavaMail.yahoo@jws10653.mail.bf1.yahoo.com> Message-ID: Excellent. My summary is: -? valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say "will not affect") - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. That's good, because I'm seeing a significant speed increase over CryptoPP in my test code and my program is currently CPU bound in the crypto code. Hopefully this will push the performance bottleneck somewhere else for a while :) Thanks for your helpChris From: Andy Polyakov via RT To: prwh1x4 at yahoo.com.au Cc: openssl-dev at openssl.org Sent: Tuesday, 9 December 2014, 21:02 Subject: Re: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext > The demo program actually allocates a whole extra block for the output, so there should always be extra space available. Yes, which is why I said "as for alleged buffer overruns in *your* program". I mean you said "I discovered this [suspected buffer overrun] in my real code" and as you didn't present it, I found it appropriate to remind that strlen-based allocations are prone to overruns, and if it would be case, it would be something for you to address. > My real program uses manually padded, known-size binary packets Excellent! If you would have clarified this from beginning, we wouldn't have this digression :-) > I've just re-tested, pasting the code in to both C and C++ netbeans projects (since that's what my main project uses) and fixing the C++ convert-from-const errors as well as adding aes.h. Both give the same valgrind issues for me. I'm using? "gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)" and "valgrind-3.10.0.SVN" if that might make a difference. > Experimentation shows that the magic length is 96 bytes - strlen()=94 works fine on my machine, strlen()=95 produces the valgrind complaints. That means input length of 96, since the code uses strlen()+1. What's magic about a 96 byte input size? (other than being 6 AES128 blocks) > > > Since I have a new Fedora 20 virtual machine handy I have also run on that with the same result:Using OpenSSL version "OpenSSL 1.0.1e-fips 11 Feb 2013" > ==2793== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info > ... > ==2793== Conditional jump or move depends on uninitialised value(s) > ==2793==? ? at 0x4C2A79E: strncmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==2793==? ? by 0x400FA1: main (in /home/digidev/test/a.out) > ==2793==? Uninitialised value was created by a stack allocation > ==2793==? ? at 0x4EC0DB7: aesni_cbc_encrypt (in /usr/lib64/libcrypto.so.1.0.1e) > ... OK. Keyword here is that it's 1.0.1 (I was testing against development branch, master and 1.0.2). 1.0.1 is actually known to upset valgrind (see RT#2862), but it looks more like valgrind bug. Well, it's somewhat in between: one can argue that valgrind has formal right to complain, but at the same time aesni_cbc_encrypt doesn't actually violate ABI constrains. Latter means that result is always correct and code in question doesn't actually overrun any buffers nor uses uninitialized values. The reason for why I failed to initially reproduce it in master and 1.0.2 is that module in question was updated after 1.0.1 release to not rely on red zone (the thing valgrind is complaining about). But this was done for reason other than appeasing valgrind. In case you wonder why problem pops up with longer lengths. This is because with shorter lengths it's possible to keep everything in processor registers. And with longer length it has to spill one value to stack. From rt at openssl.org Tue Dec 9 07:15:58 2014 From: rt at openssl.org (Richard Moore via RT) Date: Tue, 9 Dec 2014 13:15:58 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141209113530.Va82J7PF%sdaoden@yandex.com> Message-ID: On 9 December 2014 at 11:35, Steffen Nurpmeso wrote: > Richard Moore wrote: > |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT > wrote: > |> and finally i propose three new values for the "Protocol" slot of > |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > | > |In Qt we've added an enum value for TLS versions that is SecureProtocols > so > |that we could remove versions as required without requiring apps to be > |updated. It's an open question which is more likely to get updated - Qt > or > |the apps of course. For Qt 5.4 which is due out this week we've removed > |SSL3 from this enum so apps will silently get updated to drop support for > |it. > > I see. And i think this is the most impressive or, lesser > enthusiastic, important feature of the slow _CONF_ interface: that > users can use strings and that those are directly swallowed by the > OpenSSL library, so that neither recompilation nor understanding > is necessary on the program side in order to upgrade to a new > level of security. > The API we offer in Qt isn't tied to openssl so we can't do that. We also support a Windows RT backend and a SecureTransport backend is under development too. > (As a side note: SecureProtocols is such a Volvo wording... > Doesn't vulnerable energises a deeper feeling of insecurity? > I think Hitchcock would have used the naked and bare vulnerable.) > That's partly due to the API naming conventions for enums. :-) Rich. From rt at openssl.org Tue Dec 9 06:35:46 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 12:35:46 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209113530.Va82J7PF%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141209113530.Va82J7PF%sdaoden@yandex.com> Message-ID: Richard Moore wrote: |On 8 December 2014 at 19:20, Steffen Nurpmeso via RT wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |In Qt we've added an enum value for TLS versions that is SecureProtocols so |that we could remove versions as required without requiring apps to be |updated. It's an open question which is more likely to get updated - Qt or |the apps of course. For Qt 5.4 which is due out this week we've removed |SSL3 from this enum so apps will silently get updated to drop support for |it. I see. And i think this is the most impressive or, lesser enthusiastic, important feature of the slow _CONF_ interface: that users can use strings and that those are directly swallowed by the OpenSSL library, so that neither recompilation nor understanding is necessary on the program side in order to upgrade to a new level of security. (As a side note: SecureProtocols is such a Volvo wording... Doesn't vulnerable energises a deeper feeling of insecurity? I think Hitchcock would have used the naked and bare vulnerable.) Ciao, --steffen From rt at openssl.org Wed Dec 10 03:18:57 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 09:18:57 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Looks like need add some check to return code len.... 2014-12-10 11:06 GMT+03:00 ???????? ??????? : > Sorry. Line 1244 is > OPENSSL_assert(s->d1->w_msg_hdr.msg_len + > DTLS1_HM_HEADER_LENGTH == (unsigned > int)s->init_num); > > > 2014-12-10 11:05 GMT+03:00 ???????? ??????? : > >> (gdb) p s->d1->w_msg_hdr.msg_len >> $2 = 0 >> (gdb) p s->init_num >> $3 = 0 >> >> >> 2014-12-10 10:59 GMT+03:00 ???????? ??????? : >> >>> Get again ASSERT in d1_both.c:1244 >>> >>> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >>> >>> ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned >>> int)s->init_num); >>> } >>> >>> >>> >>> >>> >>> 2014-12-10 6:32 GMT+03:00 ???????? ??????? : >>> >>>> Hello. I begin test you patch. I attach to mail patched version of you >>>> patch wthat may clear added current SRPM of Centos 6 >>>> >>>> 2014-12-03 5:16 GMT+03:00 ???????? ??????? : >>>> >>>>> Thanks! I need time to test it... i will try answer at this week >>>>> >>>>> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >>>>> >>>>>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>>>>> > if you send patch i can add it to SRPM build and try results >>>>>> > >>>>>> The patch is attached. However you may have problems with this >>>>>> approach. I have >>>>>> built the patch for 1.0.1e (which is the version you originally said >>>>>> you were >>>>>> running). However any additional patches that have been applied to >>>>>> the SRPM >>>>>> could cause the patch to fail to apply (and it is quite a large >>>>>> patch). I can >>>>>> also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable >>>>>> from git >>>>>> if you prefer. >>>>>> >>>>>> Matt >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> ? ?????????, >>>>> ??????? ???????? ????????? >>>>> >>>>> ??? "???????? ??????-???????" >>>>> ??????????? ???????? >>>>> +7 (495) 666-0-111 >>>>> http://www.open-bs.ru >>>>> >>>> >>>> >>>> >>>> -- >>>> ? ?????????, >>>> ??????? ???????? ????????? >>>> >>>> ??? "???????? ??????-???????" >>>> ??????????? ???????? >>>> +7 (495) 666-0-111 >>>> http://www.open-bs.ru >>>> >>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- --- a/ssl/d1_srvr.c` 2014-12-10 11:12:43.570309059 +0300 +++ b/ssl/d1_srvr.c 2014-12-10 11:13:53.418025227 +0300 @@ -1593,7 +1593,9 @@ } } - l=dtls1_output_cert_chain(s,x); + if ((l=dtls1_output_cert_chain(s,x)) <= 0){ + return -1; + } s->state=SSL3_ST_SW_CERT_B; s->init_num=(int)l; s->init_off=0; From rt at openssl.org Tue Dec 9 22:32:56 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 04:32:56 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Hello. I begin test you patch. I attach to mail patched version of you patch wthat may clear added current SRPM of Centos 6 2014-12-03 5:16 GMT+03:00 ???????? ??????? : > Thanks! I need time to test it... i will try answer at this week > > 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : > >> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >> > if you send patch i can add it to SRPM build and try results >> > >> The patch is attached. However you may have problems with this approach. >> I have >> built the patch for 1.0.1e (which is the version you originally said you >> were >> running). However any additional patches that have been applied to the >> SRPM >> could cause the patch to fail to apply (and it is quite a large patch). I >> can >> also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable >> from git >> if you prefer. >> >> Matt >> >> > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- >From a0473d82c6ad0d4f5f1e2f778a20ae374317720a Mon Sep 17 00:00:00 2001 From: Matt Caswell Date: Mon, 1 Dec 2014 11:10:38 +0000 Subject: [PATCH] MTU fixes patch --- apps/s_client.c | 16 +++++++- apps/s_server.c | 18 ++++++++- crypto/bio/bio.h | 4 ++ crypto/bio/bss_dgram.c | 46 ++++++++++++++++++++-- ssl/d1_both.c | 103 +++++++++++++++++++++++++++++++------------------ ssl/d1_lib.c | 32 +++++++++++++-- ssl/dtls1.h | 4 ++ ssl/ssl.h | 8 ++++ ssl/ssl_lib.c | 13 ------- ssl/ssl_locl.h | 3 +- 10 files changed, 184 insertions(+), 63 deletions(-) diff --git a/apps/s_client.c b/apps/s_client.c index 3ba6605..9f4be61 100644 --- a/apps/s_client.c +++ b/apps/s_client.c @@ -1307,10 +1307,22 @@ re_start: BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0, &timeout); } - if (socket_mtu > 28) + if (socket_mtu) { + if(socket_mtu < DTLS_get_link_min_mtu(con)) + { + BIO_printf(bio_err,"MTU too small. Must be at least %d\n", + DTLS_get_link_min_mtu(con)); + BIO_free(sbio); + goto shut; + } SSL_set_options(con, SSL_OP_NO_QUERY_MTU); - SSL_set_mtu(con, socket_mtu - 28); + if(!DTLS_set_link_mtu(con, socket_mtu)) + { + BIO_printf(bio_err, "Failed to set MTU\n"); + BIO_free(sbio); + goto shut; + } } else /* want to do MTU discovery */ diff --git a/apps/s_server.c b/apps/s_server.c index 8198d7f..a6f090b 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -2035,10 +2035,24 @@ static int sv_body(char *hostname, int s, unsigned char *context) BIO_ctrl(sbio, BIO_CTRL_DGRAM_SET_SEND_TIMEOUT, 0, &timeout); } - if (socket_mtu > 28) + if (socket_mtu) { + if(socket_mtu < DTLS_get_link_min_mtu(con)) + { + BIO_printf(bio_err,"MTU too small. Must be at least %d\n", + DTLS_get_link_min_mtu(con)); + ret = -1; + BIO_free(sbio); + goto err; + } SSL_set_options(con, SSL_OP_NO_QUERY_MTU); - SSL_set_mtu(con, socket_mtu - 28); + if(!DTLS_set_link_mtu(con, socket_mtu)) + { + BIO_printf(bio_err, "Failed to set MTU\n"); + ret = -1; + BIO_free(sbio); + goto err; + } } else /* want to do MTU discovery */ diff --git a/crypto/bio/bio.h b/crypto/bio/bio.h index 05699ab..32eba71 100644 --- a/crypto/bio/bio.h +++ b/crypto/bio/bio.h @@ -175,6 +175,8 @@ extern "C" { #define BIO_CTRL_DGRAM_SET_NEXT_TIMEOUT 45 /* Next DTLS handshake timeout to * adjust socket timeouts */ +#define BIO_CTRL_DGRAM_GET_MTU_OVERHEAD 49 + #ifndef OPENSSL_NO_SCTP /* SCTP stuff */ #define BIO_CTRL_DGRAM_SCTP_SET_IN_HANDSHAKE 50 @@ -607,6 +609,8 @@ int BIO_ctrl_reset_read_request(BIO *b); (int)BIO_ctrl(b, BIO_CTRL_DGRAM_GET_PEER, 0, (char *)peer) #define BIO_dgram_set_peer(b,peer) \ (int)BIO_ctrl(b, BIO_CTRL_DGRAM_SET_PEER, 0, (char *)peer) +#define BIO_dgram_get_mtu_overhead(b) \ + (unsigned int)BIO_ctrl((b), BIO_CTRL_DGRAM_GET_MTU_OVERHEAD, 0, NULL) /* These two aren't currently implemented */ /* int BIO_get_ex_num(BIO *bio); */ diff --git a/crypto/bio/bss_dgram.c b/crypto/bio/bss_dgram.c index 8990909..0e5a52f 100644 --- a/crypto/bio/bss_dgram.c +++ b/crypto/bio/bss_dgram.c @@ -454,6 +454,36 @@ static int dgram_write(BIO *b, const char *in, int inl) return(ret); } +static long dgram_get_mtu_overhead(bio_dgram_data *data) + { + long ret; + + switch (data->peer.sa.sa_family) + { + case AF_INET: + /* Assume this is UDP - 20 bytes for IP, 8 bytes for UDP */ + ret = 28; + break; +#if OPENSSL_USE_IPV6 + case AF_INET6: +#ifdef IN6_IS_ADDR_V4MAPPED + if (IN6_IS_ADDR_V4MAPPED(&data->peer.sa_in6.sin6_addr)) + /* Assume this is UDP - 20 bytes for IP, 8 bytes for UDP */ + ret = 28; + else +#endif + /* Assume this is UDP - 40 bytes for IP, 8 bytes for UDP */ + ret = 48; + break; +#endif + default: + /* We don't know. Go with the historical default */ + ret = 28; + break; + } + return ret; + } + static long dgram_ctrl(BIO *b, int cmd, long num, void *ptr) { long ret=1; @@ -630,23 +660,24 @@ static long dgram_ctrl(BIO *b, int cmd, long num, void *ptr) #endif break; case BIO_CTRL_DGRAM_GET_FALLBACK_MTU: + ret = -dgram_get_mtu_overhead(data); switch (data->peer.sa.sa_family) { case AF_INET: - ret = 576 - 20 - 8; + ret += 576; break; #if OPENSSL_USE_IPV6 case AF_INET6: #ifdef IN6_IS_ADDR_V4MAPPED if (IN6_IS_ADDR_V4MAPPED(&data->peer.sa_in6.sin6_addr)) - ret = 576 - 20 - 8; + ret += 576; else #endif - ret = 1280 - 40 - 8; + ret += 1280; break; #endif default: - ret = 576 - 20 - 8; + ret += 576; break; } break; @@ -847,6 +878,9 @@ static long dgram_ctrl(BIO *b, int cmd, long num, void *ptr) ret = 0; break; #endif + case BIO_CTRL_DGRAM_GET_MTU_OVERHEAD: + ret = dgram_get_mtu_overhead(data); + break; default: ret=0; break; @@ -1367,6 +1401,10 @@ static long dgram_sctp_ctrl(BIO *b, int cmd, long num, void *ptr) * Returns always 1. */ break; + case BIO_CTRL_DGRAM_GET_MTU_OVERHEAD: + /* We allow transport protocol fragmentation so this is irrelevant */ + ret = 0; + break; case BIO_CTRL_DGRAM_SCTP_SET_IN_HANDSHAKE: if (num > 0) data->in_handshake = 1; diff --git a/ssl/d1_both.c b/ssl/d1_both.c index de8bab8..0781ca5 100644 --- a/ssl/d1_both.c +++ b/ssl/d1_both.c @@ -156,9 +156,8 @@ static unsigned char bitmask_start_values[] = {0xff, 0xfe, 0xfc, 0xf8, 0xf0, 0xe static unsigned char bitmask_end_values[] = {0xff, 0x01, 0x03, 0x07, 0x0f, 0x1f, 0x3f, 0x7f}; /* XDTLS: figure out the right values */ -static unsigned int g_probable_mtu[] = {1500 - 28, 512 - 28, 256 - 28}; +static const unsigned int g_probable_mtu[] = {1500, 512, 256}; -static unsigned int dtls1_guess_mtu(unsigned int curr_mtu); static void dtls1_fix_message_header(SSL *s, unsigned long frag_off, unsigned long frag_len); static unsigned char *dtls1_write_message_header(SSL *s, @@ -219,29 +218,48 @@ dtls1_hm_fragment_free(hm_fragment *frag) OPENSSL_free(frag); } +static int dtls1_query_mtu(SSL *s) +{ + if(s->d1->link_mtu) + { + s->d1->mtu = s->d1->link_mtu-BIO_dgram_get_mtu_overhead(SSL_get_wbio(s)); + s->d1->link_mtu = 0; + } + + /* AHA! Figure out the MTU, and stick to the right size */ + if (s->d1->mtu < dtls1_min_mtu(s)) + { + if(!(SSL_get_options(s) & SSL_OP_NO_QUERY_MTU)) + { + s->d1->mtu = + BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_QUERY_MTU, 0, NULL); + + /* I've seen the kernel return bogus numbers when it doesn't know + * (initial write), so just make sure we have a reasonable number */ + if (s->d1->mtu < dtls1_min_mtu(s)) + { + /* Set to min mtu */ + s->d1->mtu = dtls1_min_mtu(s); + BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_SET_MTU, + s->d1->mtu, NULL); + } + } + else + return 0; + } + return 1; +} + /* send s->init_buf in records of type 'type' (SSL3_RT_HANDSHAKE or SSL3_RT_CHANGE_CIPHER_SPEC) */ int dtls1_do_write(SSL *s, int type) { int ret; int curr_mtu; + int retry = 1; unsigned int len, frag_off, mac_size, blocksize; - /* AHA! Figure out the MTU, and stick to the right size */ - if (s->d1->mtu < dtls1_min_mtu() && !(SSL_get_options(s) & SSL_OP_NO_QUERY_MTU)) - { - s->d1->mtu = - BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_QUERY_MTU, 0, NULL); - - /* I've seen the kernel return bogus numbers when it doesn't know - * (initial write), so just make sure we have a reasonable number */ - if (s->d1->mtu < dtls1_min_mtu()) - { - s->d1->mtu = 0; - s->d1->mtu = dtls1_guess_mtu(s->d1->mtu); - BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_SET_MTU, - s->d1->mtu, NULL); - } - } + if(!dtls1_query_mtu(s)) + return -1; #if 0 mtu = s->d1->mtu; @@ -265,7 +283,7 @@ int dtls1_do_write(SSL *s, int type) } #endif - OPENSSL_assert(s->d1->mtu >= dtls1_min_mtu()); /* should have something reasonable now */ + OPENSSL_assert(s->d1->mtu >= dtls1_min_mtu(s)); /* should have something reasonable now */ if ( s->init_off == 0 && type == SSL3_RT_HANDSHAKE) OPENSSL_assert(s->init_num == @@ -318,12 +336,18 @@ int dtls1_do_write(SSL *s, int type) len += DTLS1_HM_HEADER_LENGTH; } + if ( len < DTLS1_HM_HEADER_LENGTH ) + { + /* + * len is so small that we really can't do anything sensible + * so fail + */ + return -1; + } dtls1_fix_message_header(s, frag_off, len - DTLS1_HM_HEADER_LENGTH); dtls1_write_message_header(s, (unsigned char *)&s->init_buf->data[s->init_off]); - - OPENSSL_assert(len >= DTLS1_HM_HEADER_LENGTH); } ret=dtls1_write_bytes(s,type,&s->init_buf->data[s->init_off], @@ -336,12 +360,23 @@ int dtls1_do_write(SSL *s, int type) * is fine and wait for an alert to handle the * retransmit */ - if ( BIO_ctrl(SSL_get_wbio(s), + if ( retry && BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_MTU_EXCEEDED, 0, NULL) > 0 ) - s->d1->mtu = BIO_ctrl(SSL_get_wbio(s), - BIO_CTRL_DGRAM_QUERY_MTU, 0, NULL); + { + if(!(SSL_get_options(s) & SSL_OP_NO_QUERY_MTU)) + { + if(!dtls1_query_mtu(s)) + return -1; + /* Have one more go */ + retry = 0; + } + else + return -1; + } else + { return(-1); + } } else { @@ -1380,28 +1415,20 @@ dtls1_write_message_header(SSL *s, unsigned char *p) return p; } -unsigned int -dtls1_min_mtu(void) +unsigned int +dtls1_link_min_mtu(void) { return (g_probable_mtu[(sizeof(g_probable_mtu) / sizeof(g_probable_mtu[0])) - 1]); } -static unsigned int -dtls1_guess_mtu(unsigned int curr_mtu) +unsigned int +dtls1_min_mtu(SSL *s) { - unsigned int i; - - if ( curr_mtu == 0 ) - return g_probable_mtu[0] ; - - for ( i = 0; i < sizeof(g_probable_mtu)/sizeof(g_probable_mtu[0]); i++) - if ( curr_mtu > g_probable_mtu[i]) - return g_probable_mtu[i]; - - return curr_mtu; + return dtls1_link_min_mtu()-BIO_dgram_get_mtu_overhead(SSL_get_wbio(s)); } + void dtls1_get_message_header(unsigned char *data, struct hm_header_st *msg_hdr) { diff --git a/ssl/d1_lib.c b/ssl/d1_lib.c index f61f718..87c36ad 100644 --- a/ssl/d1_lib.c +++ b/ssl/d1_lib.c @@ -113,6 +113,9 @@ int dtls1_new(SSL *s) d1->cookie_len = sizeof(s->d1->cookie); } + d1->link_mtu = 0; + d1->mtu = 0; + if( ! d1->unprocessed_rcds.q || ! d1->processed_rcds.q || ! d1->buffered_messages || ! d1->sent_messages || ! d1->buffered_app_data.q) { @@ -206,6 +209,7 @@ void dtls1_clear(SSL *s) pqueue sent_messages; pqueue buffered_app_data; unsigned int mtu; + unsigned int link_mtu; if (s->d1) { @@ -215,6 +219,7 @@ void dtls1_clear(SSL *s) sent_messages = s->d1->sent_messages; buffered_app_data = s->d1->buffered_app_data.q; mtu = s->d1->mtu; + link_mtu = s->d1->link_mtu; dtls1_clear_queues(s); @@ -228,6 +233,7 @@ void dtls1_clear(SSL *s) if (SSL_get_options(s) & SSL_OP_NO_QUERY_MTU) { s->d1->mtu = mtu; + s->d1->link_mtu = link_mtu; } s->d1->unprocessed_rcds.q = unprocessed_rcds; @@ -401,12 +422,17 @@ void dtls1_stop_timer(SSL *s) int dtls1_check_timeout_num(SSL *s) { + unsigned int mtu; + s->d1->timeout.num_alerts++; /* Reduce MTU after 2 unsuccessful retransmissions */ - if (s->d1->timeout.num_alerts > 2) + if (s->d1->timeout.num_alerts > 2 + && !(SSL_get_options(s) & SSL_OP_NO_QUERY_MTU)) { - s->d1->mtu = BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL); + mtu = BIO_ctrl(SSL_get_wbio(s), BIO_CTRL_DGRAM_GET_FALLBACK_MTU, 0, NULL); + if(mtu < s->d1->mtu) + s->d1->mtu = mtu; } if (s->d1->timeout.num_alerts > DTLS1_TMO_ALERT_COUNT) diff --git a/ssl/dtls1.h b/ssl/dtls1.h index e65d501..fd168e7 100644 --- a/ssl/dtls1.h +++ b/ssl/dtls1.h @@ -115,6 +115,9 @@ extern "C" { #define DTLS1_SCTP_AUTH_LABEL "EXPORTER_DTLS_OVER_SCTP" #endif +/* Max MTU overhead we know about so far is 40 for IPv6 + 8 for UDP */ +#define DTLS1_MAX_MTU_OVERHEAD 48 + typedef struct dtls1_bitmap_st { unsigned long map; /* track 32 packets on 32-bit systems @@ -229,6 +232,7 @@ typedef struct dtls1_state_st */ record_pqueue buffered_app_data; + unsigned int link_mtu; /* max on-the-wire DTLS packet size */ unsigned int mtu; /* max DTLS packet size */ struct hm_header_st w_msg_hdr; diff --git a/ssl/ssl.h b/ssl/ssl.h index 593579e..377ceff 100644 --- a/ssl/ssl.h +++ b/ssl/ssl.h @@ -672,6 +672,12 @@ struct ssl_session_st SSL_ctrl((ssl),SSL_CTRL_MODE,0,NULL) #define SSL_set_mtu(ssl, mtu) \ SSL_ctrl((ssl),SSL_CTRL_SET_MTU,(mtu),NULL) +#define DTLS_set_link_mtu(ssl, mtu) \ + SSL_ctrl((ssl),DTLS_CTRL_SET_LINK_MTU,(mtu),NULL) +#define DTLS_get_link_min_mtu(ssl) \ + SSL_ctrl((ssl),DTLS_CTRL_GET_LINK_MIN_MTU,0,NULL) +#define DTLS_CTRL_SET_LINK_MTU 120 +#define DTLS_CTRL_GET_LINK_MIN_MTU 121 #define SSL_get_secure_renegotiation_support(ssl) \ SSL_ctrl((ssl), SSL_CTRL_GET_RI_SUPPORT, 0, NULL) diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c index 14d143d..cd94f30 100644 --- a/ssl/ssl_lib.c +++ b/ssl/ssl_lib.c @@ -1080,19 +1080,6 @@ long SSL_ctrl(SSL *s,int cmd,long larg,void *parg) l=s->max_cert_list; s->max_cert_list=larg; return(l); - case SSL_CTRL_SET_MTU: -#ifndef OPENSSL_NO_DTLS1 - if (larg < (long)dtls1_min_mtu()) - return 0; -#endif - - if (SSL_version(s) == DTLS1_VERSION || - SSL_version(s) == DTLS1_BAD_VER) - { - s->d1->mtu = larg; - return larg; - } - return 0; case SSL_CTRL_SET_MAX_SEND_FRAGMENT: if (larg < 512 || larg > SSL3_RT_MAX_PLAIN_LENGTH) return 0; diff --git a/ssl/ssl_locl.h b/ssl/ssl_locl.h index 1b98947..7f4c375 100644 --- a/ssl/ssl_locl.h +++ b/ssl/ssl_locl.h @@ -983,7 +983,8 @@ void dtls1_stop_timer(SSL *s); int dtls1_is_timer_expired(SSL *s); void dtls1_double_timeout(SSL *s); int dtls1_send_newsession_ticket(SSL *s); -unsigned int dtls1_min_mtu(void); +unsigned int dtls1_min_mtu(SSL *s); +unsigned int dtls1_link_min_mtu(void); /* some client-only functions */ int ssl3_client_hello(SSL *s); -- 2.1.0 -------------- next part -------------- --- a/ssl/d1_lib.c 2014-12-10 05:27:02.313246685 +0300 +++ b/ssl/d1_lib.c 2014-12-10 05:28:01.364020724 +0300 @@ -279,7 +279,22 @@ /* Just one protocol version is supported so far; * fail closed if the version is not as expected. */ return s->version == DTLS_MAX_VERSION; - + case DTLS_CTRL_SET_LINK_MTU: + if (larg < (long)dtls1_link_min_mtu()) + return 0; + s->d1->link_mtu = larg; + return 1; + case DTLS_CTRL_GET_LINK_MIN_MTU: + return (long)dtls1_link_min_mtu(); + case SSL_CTRL_SET_MTU: + /* + * We may not have a BIO set yet so can't call dtls1_min_mtu() + * We'll have to make do with dtls1_link_min_mtu() and max overhead + */ + if (larg < (long)dtls1_link_min_mtu() - DTLS1_MAX_MTU_OVERHEAD) + return 0; + s->d1->mtu = larg; + return larg; default: ret = ssl3_ctrl(s, cmd, larg, parg); break; From rt at openssl.org Wed Dec 10 03:38:58 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 09:38:58 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: After add check get crash 2014-12-10 11:18 GMT+03:00 ???????? ??????? : > Looks like need add some check to return code len.... > > > 2014-12-10 11:06 GMT+03:00 ???????? ??????? : > >> Sorry. Line 1244 is >> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >> DTLS1_HM_HEADER_LENGTH == (unsigned >> int)s->init_num); >> >> >> 2014-12-10 11:05 GMT+03:00 ???????? ??????? : >> >>> (gdb) p s->d1->w_msg_hdr.msg_len >>> $2 = 0 >>> (gdb) p s->init_num >>> $3 = 0 >>> >>> >>> 2014-12-10 10:59 GMT+03:00 ???????? ??????? : >>> >>>> Get again ASSERT in d1_both.c:1244 >>>> >>>> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >>>> >>>> ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned >>>> int)s->init_num); >>>> } >>>> >>>> >>>> >>>> >>>> >>>> 2014-12-10 6:32 GMT+03:00 ???????? ??????? : >>>> >>>>> Hello. I begin test you patch. I attach to mail patched version of you >>>>> patch wthat may clear added current SRPM of Centos 6 >>>>> >>>>> 2014-12-03 5:16 GMT+03:00 ???????? ??????? : >>>>> >>>>>> Thanks! I need time to test it... i will try answer at this week >>>>>> >>>>>> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >>>>>> >>>>>>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>>>>>> > if you send patch i can add it to SRPM build and try results >>>>>>> > >>>>>>> The patch is attached. However you may have problems with this >>>>>>> approach. I have >>>>>>> built the patch for 1.0.1e (which is the version you originally said >>>>>>> you were >>>>>>> running). However any additional patches that have been applied to >>>>>>> the SRPM >>>>>>> could cause the patch to fail to apply (and it is quite a large >>>>>>> patch). I can >>>>>>> also supply a patch against the latest 1.0.1j or >>>>>>> OpenSSL_1_0_1-stable from git >>>>>>> if you prefer. >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ? ?????????, >>>>>> ??????? ???????? ????????? >>>>>> >>>>>> ??? "???????? ??????-???????" >>>>>> ??????????? ???????? >>>>>> +7 (495) 666-0-111 >>>>>> http://www.open-bs.ru >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ? ?????????, >>>>> ??????? ???????? ????????? >>>>> >>>>> ??? "???????? ??????-???????" >>>>> ??????????? ???????? >>>>> +7 (495) 666-0-111 >>>>> http://www.open-bs.ru >>>>> >>>> >>>> >>>> >>>> -- >>>> ? ?????????, >>>> ??????? ???????? ????????? >>>> >>>> ??? "???????? ??????-???????" >>>> ??????????? ???????? >>>> +7 (495) 666-0-111 >>>> http://www.open-bs.ru >>>> >>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- #0 _int_malloc (av=0x7fff4c000020, bytes=) at malloc.c:4476 iters = nb = 6496 idx = 103 bin = victim = 0x7fff4c007d70 size = 8016 victim_index = remainder = remainder_size = block = bit = map = fwd = bck = 0x0 errstr = 0x0 #1 0x00000037c9e7a6b1 in __libc_malloc (bytes=6488) at malloc.c:3664 ar_ptr = 0x7fff4c000020 victim = hook = #2 0x00007ffff780bd36 in CRYPTO_realloc_clean (str=0x7fff4c026ca0, old_len=4780, num=6488, file=0x7ffff7912c9b "buffer.c", line=166) at mem.c:372 ret = 0x0 #3 0x00007ffff787bae6 in BUF_MEM_grow_clean (str=0x7fff3c034870, len=4864) at buffer.c:166 ret = n = 6488 #4 0x00007ffff787d513 in mem_write (b=, in=0x7fff4c0231b0 "\026\376\377", inl=256) at bss_mem.c:189 ret = -1 blen = 4608 bm = 0x7fff3c034870 #5 0x00007ffff787c747 in BIO_write (b=0x7fff3c033a60, in=0x7fff4c0231b0, inl=256) at bio_lib.c:247 i = cb = 0 #6 0x00007ffff787f871 in buffer_ctrl (b=0x7fff4c012fd0, cmd=, num=0, ptr=0x0) at bf_buff.c:404 dbio = ctx = 0x7fff4c018a70 ret = 1 p1 = p2 = r = i = ip = ibs = obs = #7 0x00007ffff7bc2b0d in dtls1_do_write (s=0x7fff3c0335f0, type=22) at d1_both.c:318 ret = curr_mtu = -13 retry = 1 len = frag_off = 3816 mac_size = 0 blocksize = 0 #8 0x00007ffff7bbbdf7 in dtls1_accept (s=0x7fff3c0335f0) at d1_srvr.c:426 buf = Time = 1418200173 cb = 0 alg_k = ret = new_state = state = 8512 skip = 0 listen = 0 #9 0x00007ffff7bc085d in dtls1_read_bytes (s=0x7fff3c0335f0, type=23, buf=0x7fff3c0060f8 "\026\376\377", len=121, peek=0) at d1_pkt.c:787 al = i = j = ret = n = rr = cb = 0 #10 0x00007ffff7baaed0 in ssl3_read_internal (s=0x7fff3c0335f0, buf=0x7fff3c0060f8, len=121, peek=0) at s3_lib.c:4273 ret = #11 0x00007fffa25fbef5 in __rtp_recvfrom (instance=0x7fff3c015348, buf=0x7fff3c0060f8, size=8192, flags=0, sa=0x7fff9ada69d0, rtcp=0) at res_rtp_asterisk.c:2019 dtls = 0x7fff3c008ce0 res = 0 len = 121 rtp = 0x7fff3c005f40 srtp = 0x0 in = 0x7fff3c0060f8 "\026\376\377" loop = 0x7fff3c0085e8 __PRETTY_FUNCTION__ = "__rtp_recvfrom" #12 0x00007fffa25fc31f in rtp_recvfrom (instance=0x7fff3c015348, buf=0x7fff3c0060f8, size=8192, flags=0, sa=0x7fff9ada69d0) at res_rtp_asterisk.c:2094 No locals. #13 0x00007fffa2605621 in ast_rtp_read (instance=0x7fff3c015348, rtcp=0) at res_rtp_asterisk.c:4127 rtp = 0x7fff3c005f40 addr = {ss = {ss_family = 2, __ss_align = 0, __ss_padding = "\b\243\001L\377\177\000\000R\367\346\311\067\000\000\000\001\200\255\373\377\177\000\000\b\243\001L\377\177\000\000\b\243\001L\377\177\000\000\b\243\001L\377\177\000\000\b\243\001L\377\177\000\000\020\243\001L\377\177\000\000\a\244\001L\377\177\000\000\b\243\001L\377\177\000\000\a\244\001L\377\177", '\000' }, len = 16} res = 0 hdrlen = 12 version = 32767 payloadtype = 0 padding = 0 mark = 1275080150 ext = 32767 cc = 1275080150 prev_seqno = 32767 rtpheader = 0x7fff3c0060f8 seqno = 0 ssrc = 33 timestamp = 29 payload = {asterisk_format = 6, format = {id = 0, fattr = {format_attr = {1275100224, 32767, 1275100229, 32767, 6567044, 0, 2598004992, 4294967295, 5775753, 19, 1006650992, 78, 78, 77, 9665472, 0, 5262095, 0, 1275083272, 32767, 9381552, 0, 6717365, 0, 6718801, 0, 6717397, 1589, 6714548, 0, 16, 1587, 6714548, 0, 2598005744, 32767, 5281951, 0, 1548, 32767, 6718801, 0, 1418200173, 0, 92029, 0, 24, 48, 2598006224, 32767, 6715567, 0, 1006651024, 32767, 4094289024, 32767, 4094283063, 474, 4094284180, 32767, 2598005232, 5, 875638834, 758264109}, rtp_marker_bit = 49 '1'}}, rtp_code = 959593009, payload = 3355450} remote_address = {ss = {ss_family = 0, __ss_align = 0, __ss_padding = '\000' }, len = 0} frames = {first = 0x1039500, last = 0x5983a5} __PRETTY_FUNCTION__ = "ast_rtp_read" #14 0x00000000005529d3 in ast_rtp_instance_read (instance=0x7fff3c015348, rtcp=0) at rtp_engine.c:314 No locals. #15 0x00007fffb26d6839 in sip_rtp_read (ast=0x7fff3c0373b8, p=0x7fff3c00bef8, faxdetect=0x7fff9ada6c64) at chan_sip.c:8198 f = 0x7fff3c00bea0 __PRETTY_FUNCTION__ = "sip_rtp_read" #16 0x00007fffb26d6fe8 in sip_read (ast=0x7fff3c0373b8) at chan_sip.c:8295 fr = 0x498779 p = 0x7fff3c00bef8 faxdetected = 0 __PRETTY_FUNCTION__ = "sip_read" #17 0x000000000047d255 in __ast_read (chan=0x7fff3c0373b8, dropaudio=0) at channel.c:4054 f = 0x0 prestate = 6 cause = 0 __PRETTY_FUNCTION__ = "__ast_read" #18 0x000000000047effe in ast_read (chan=0x7fff3c0373b8) at channel.c:4408 No locals. #19 0x0000000000476b90 in ast_safe_sleep_conditional (chan=0x7fff3c0373b8, timeout_ms=5000, cond=0, data=0x0) at channel.c:1702 dup_f = 0x0 f = 0x8f0fe0 silgen = 0x0 res = 0 start = {tv_sec = 1418200173, tv_usec = 92058} ms = 5000 deferred_frames = {first = 0x0, last = 0x0} __PRETTY_FUNCTION__ = "ast_safe_sleep_conditional" #20 0x0000000000476dc0 in ast_safe_sleep (chan=0x7fff3c0373b8, ms=5000) at channel.c:1746 No locals. #21 0x00007ffff40986c2 in play_moh_exec (chan=0x7fff3c0373b8, data=0x7fff9ada9490 ",5") at res_musiconhold.c:801 parse = 0x7fff9ada7220 "" class = 0x0 timeout = 5000 res = 0 args = {argc = 2, argv = 0x7fff9ada7250, class = 0x7fff9ada7220 "", duration = 0x7fff9ada7221 "5"} __PRETTY_FUNCTION__ = "play_moh_exec" #22 0x000000000052c661 in pbx_exec (c=0x7fff3c0373b8, app=0x10394a0, data=0x7fff9ada9490 ",5") at pbx.c:1622 res = 36 u = 0x7fff4c01a1b0 saved_c_appl = 0x0 saved_c_data = 0x0 __PRETTY_FUNCTION__ = "pbx_exec" #23 0x0000000000537108 in pbx_extension_helper (c=0x7fff3c0373b8, con=0x0, context=0x7fff3c038208 "from-internal", exten=0x7fff3c038258 "766", priority=2, label=0x0, callerid=0x7fff3c034090 "74996051913", action=E_SPAWN, found=0x7fff9adabb70, combined_find_spawn=1) at pbx.c:4915 e = 0xf66c60 app = 0x10394a0 substitute = 0x0 res = 1006858600 q = {incstack = {0xfb6f80 "from-internal", 0xfb7fa0 "from-internal-noxfer", 0xfa58e0 "from-internal-noxfer-additional", 0xfe5880 "from-internal-xfer", 0xfd7780 "from-internal-additional", 0x0 }, stacklen = 5, status = 5, swo = 0x0, data = 0x0, foundcontext = 0xfd78d0 "from-internal-additional-custom"} passdata = ",5\000\232\377\177\000\000\360\226?\377\177\000\000\000\000\000\000\377\177\000\000\376\226?\377\177\000\000\377\377\377\377\000\000\000\000\220\225?\377\177\000\000\377\377\377\377\377\377\377\377\000\232?\377\177\000\000\000\000\000\000\000\000\000\000`\226?\377\177\000\000\037\000\000\000\000\000\000\000x\231?\377\177\000\000\060\236?\000\000\000\000 \367\346\311\067\000\000\000\001\200\255\373\377\177\000\000\060\236?\377\177\000\000\060\236?\000\000\000\000\257\t\000\000\000\000\000\000\000\000\000\000\377\177\000\000\061\236?\377\177\000\000\000\000\000\000\377\177\000\000\000\000\000\000\001\000\000\000O\236?\377\177\000\000\377\377\377\377", '\000' , "x\231?\377\177\000\000s", '\000' "\302, \352f\000\000\000\000\000\360\226?", '\000' , "\v\000\000\000\001\004\000\000\000\000\000\000\270\362\344\311\067\000\000\000\060\000\000\000\060", '\000' "\300, \225?\377"... matching_action = 0 __PRETTY_FUNCTION__ = "pbx_extension_helper" #24 0x000000000053a5a3 in ast_spawn_extension (c=0x7fff3c0373b8, context=0x7fff3c038208 "from-internal", exten=0x7fff3c038258 "766", priority=2, callerid=0x7fff3c034090 "74996051913", found=0x7fff9adabb70, combined_find_spawn=1) at pbx.c:6037 No locals. #25 0x000000000053bd40 in __ast_pbx_run (c=0x7fff3c0373b8, args=0x0) at pbx.c:6512 digit = 0 invalid = 0 timeout = 0 dst_exten = "\000\377\377\377\377\377\377\377\001", '\000' , "@\001\000\000\000\000\000\000\a", '\000' , "\001\000\000\000\000\000\000\000x{ \312\067", '\000' "\370, \377\377\377\377\377\377\377\001\000\000\000\000\000\000\000\020\000\000\000\000\000\000\000\033\377\001", '\000' , " \275?\377\177\000\000??\377\177\000\000\020\275?\377\177\000\000p\315?\377\177\000\000\340\272?\377\177\000\000\320\336 \312\067\000\000\000\003\000\000\000\000\000\000\000\264\062\243\232\377\177\000\000??\377\177\000\000\340\274?\377\177\000\000\000\000\000\000\000\000\000\000\350\274?\377\177", '\000' "\360, \275?\377\177\000\000\000\000\000\000\000\000\000" pos = 0 found = 1 res = 0 autoloopflag = 0 error = 0 pbx = 0x7fff4c01c3a0 callid = 0x0 __PRETTY_FUNCTION__ = "__ast_pbx_run" #26 0x000000000053d81d in pbx_thread (data=0x7fff3c0373b8) at pbx.c:6842 c = 0x7fff3c0373b8 #27 0x0000000000599ddc in dummy_start (data=0x7fff3c01b080) at utils.c:1192 __cancel_buf = {__cancel_jmp_buf = {{__cancel_jmp_buf = {140735791417088, -9220635199591366855, 140735787189888, 140735791417792, 0, 3, -9220635199582978247, 9220711381188919097}, __mask_was_saved = 0}}, __pad = { 0x7fff9adabe90, 0x0, 0x7fff9adaca10, 0x0}} __cancel_routine = 0x441124 __cancel_arg = 0x7fff9adac700 not_first_call = 0 ret = 0x37ca18a850 a = {start_routine = 0x53d7f8 , data = 0x7fff3c0373b8, name = 0x7fff3c03a740 "pbx_thread", ' ' , "started at [ 6868] pbx.c ast_pbx_start()"} #28 0x00000037ca2079d1 in start_thread (arg=0x7fff9adac700) at pthread_create.c:301 __res = pd = 0x7fff9adac700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735791417088, 9220711866970718009, 140735787189888, 140735791417792, 0, 3, -9220635199622824135, 9194407422128865081}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #29 0x00000037c9ee89dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 No locals. From rt at openssl.org Wed Dec 10 03:05:14 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 09:05:14 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: (gdb) p s->d1->w_msg_hdr.msg_len $2 = 0 (gdb) p s->init_num $3 = 0 2014-12-10 10:59 GMT+03:00 ???????? ??????? : > Get again ASSERT in d1_both.c:1244 > > OPENSSL_assert(s->d1->w_msg_hdr.msg_len + > > ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned > int)s->init_num); > } > > > > > > 2014-12-10 6:32 GMT+03:00 ???????? ??????? : > >> Hello. I begin test you patch. I attach to mail patched version of you >> patch wthat may clear added current SRPM of Centos 6 >> >> 2014-12-03 5:16 GMT+03:00 ???????? ??????? : >> >>> Thanks! I need time to test it... i will try answer at this week >>> >>> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >>> >>>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>>> > if you send patch i can add it to SRPM build and try results >>>> > >>>> The patch is attached. However you may have problems with this >>>> approach. I have >>>> built the patch for 1.0.1e (which is the version you originally said >>>> you were >>>> running). However any additional patches that have been applied to the >>>> SRPM >>>> could cause the patch to fail to apply (and it is quite a large patch). >>>> I can >>>> also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable >>>> from git >>>> if you prefer. >>>> >>>> Matt >>>> >>>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Tue Dec 9 08:46:46 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 14:46:46 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209134630.z8eQl8Xc%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141209113530.Va82J7PF%sdaoden@yandex.com> <20141209134630.z8eQl8Xc%sdaoden@yandex.com> Message-ID: Richard Moore wrote: |On 9 December 2014 at 11:35, Steffen Nurpmeso wrote: |> Richard Moore wrote: |>|On 8 December 2014 at 19:20, Steffen Nurpmeso via RT |> wrote: |>|> and finally i propose three new values for the "Protocol" slot of |>|> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. |>| |>|In Qt we've added an enum value for TLS versions that is SecureProtocols |> so |>|that we could remove versions as required without requiring apps to be |>|updated. It's an open question which is more likely to get updated - Qt |> or |>|the apps of course. For Qt 5.4 which is due out this week we've removed |>|SSL3 from this enum so apps will silently get updated to drop support for |>|it. |> |> I see. And i think this is the most impressive or, lesser |> enthusiastic, important feature of the slow _CONF_ interface: that |> users can use strings and that those are directly swallowed by the |> OpenSSL library, so that neither recompilation nor understanding |> is necessary on the program side in order to upgrade to a new |> level of security. | |The API we offer in Qt isn't tied to openssl so we can't do that. We also |support a Windows RT backend and a SecureTransport backend is under |development too. Well, of course. Implementing a simple fixed-string wrapper isn't hard to do shall there be desire, however, i've done the mine in about two hours in 43 lines plus the mapping array and some testing (a n_strsep() already existed). And it can be hoped that other libraries follow with their interfaces, functions like SSLSetProtocolVersionMin() or Ssl3AllowWeakEncryption SocketProtectionLevel constants are really inflexible and hard to use. And result in ugly mail paragraph formatting. And do i think most of the time not really describe what is desired (a secure transport, or SecureProtocols in your QT world). But not that i wouldn't prefer compile-checks in favour of intransparent strings. That makes me think that some prodding by you could possibly get the ball rolling. It needn't be _that_ flexible.. |> (As a side note: SecureProtocols is such a Volvo wording... |> Doesn't vulnerable energises a deeper feeling of insecurity? |> I think Hitchcock would have used the naked and bare vulnerable.) |> | |That's partly due to the API naming conventions for enums. :-) Yet that only describes the lesser part :) --steffen From rt at openssl.org Tue Dec 9 06:27:43 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 12:27:43 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209112738.qOw6yRaC%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141208203655.GB11298@roeckx.be> <20141209112738.qOw6yRaC%sdaoden@yandex.com> Message-ID: "Kurt Roeckx via RT" wrote: |On Mon, Dec 08, 2014 at 08:20:44PM +0100, Steffen Nurpmeso via RT wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |I actually find the option unfortunate and I think it should have |been one that sets the minimum and maximum version. But I think |we're too late 1.0.2 process to still change this. A good benefit for a three line patch. Being able to say "-ALL,>=TLSv1.1" etc. is surely on the list of many, and much more complicated to implement than that. --steffen From rt at openssl.org Wed Dec 10 11:21:24 2014 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 10 Dec 2014 17:21:24 +0100 Subject: [openssl-dev] [openssl.org #2595] Capitalize X509 subject key STREET according to rfc1779 In-Reply-To: <93E86AD0-E01F-46C6-8332-DEF0F2A35CBB@lyndir.com> References: <93E86AD0-E01F-46C6-8332-DEF0F2A35CBB@lyndir.com> Message-ID: Test, please ignore From rt at openssl.org Tue Dec 9 06:11:53 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 12:11:53 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141209111134.8zKkrs4f%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141208202923.GA11298@roeckx.be> <20141209111134.8zKkrs4f%sdaoden@yandex.com> Message-ID: "Kurt Roeckx via RT" wrote: |On Mon, Dec 08, 2014 at 07:58:31PM +0100, Steffen Nurpmeso via RT wrote: |> set ssl-protocol="ALL,-SSLv2" |> |> This results in the obvious problem that when they (get) |> upgrade(d) their OpenSSL library they will see a completely |> intransparent error message that no normal user will understand: | |It was actually my intention to keep supporting that, but I seem |to have removed that line. I think the following patch should fix |that: |--- a/ssl/ssl_conf.c |+++ b/ssl/ssl_conf.c |@@ -333,6 +333,7 @@ static int cmd_Protocol(SSL_CONF_CTX *cctx, |const char *value) | static const ssl_flag_tbl ssl_protocol_list[] = | { | SSL_FLAG_TBL_INV("ALL", SSL_OP_NO_SSL_MASK), |+ SSL_FLAG_TBL_INV("SSLv2", SSL_OP_NO_SSLv2), | SSL_FLAG_TBL_INV("SSLv3", SSL_OP_NO_SSLv3), | SSL_FLAG_TBL_INV("TLSv1", SSL_OP_NO_TLSv1), | SSL_FLAG_TBL_INV("TLSv1.1", SSL_OP_NO_TLSv1_1), Sure, since SSL_OP_NO_SSLv2 still exists as 0x0L as i see know. --steffen From rt at openssl.org Wed Dec 10 02:59:35 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 08:59:35 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Get again ASSERT in d1_both.c:1244 OPENSSL_assert(s->d1->w_msg_hdr.msg_len + ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned int)s->init_num); } 2014-12-10 6:32 GMT+03:00 ???????? ??????? : > Hello. I begin test you patch. I attach to mail patched version of you > patch wthat may clear added current SRPM of Centos 6 > > 2014-12-03 5:16 GMT+03:00 ???????? ??????? : > >> Thanks! I need time to test it... i will try answer at this week >> >> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >> >>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>> > if you send patch i can add it to SRPM build and try results >>> > >>> The patch is attached. However you may have problems with this approach. >>> I have >>> built the patch for 1.0.1e (which is the version you originally said you >>> were >>> running). However any additional patches that have been applied to the >>> SRPM >>> could cause the patch to fail to apply (and it is quite a large patch). >>> I can >>> also supply a patch against the latest 1.0.1j or OpenSSL_1_0_1-stable >>> from git >>> if you prefer. >>> >>> Matt >>> >>> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- #0 0x00000037c9e32625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 resultvar = 0 pid = selftid = 19173 #1 0x00000037c9e33e05 in abort () at abort.c:92 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x8f91b0 , sa_sigaction = 0x8f91b0 }, sa_mask = {__val = {140737349776136, 140735810636400, 140735676423408, 0, 0, 239610129240, 140737351974912, 140734669926416, 4294967295, 206158430240, 5, 4001896, 0, 8512, 3, 140737345359872}}, sa_flags = -912203712, sa_restorer = 0x7fff00000005} sigs = {__val = {32, 0 }} #2 0x00007ffff780ae3f in OpenSSLDie (file=, line=, assertion=) at cryptlib.c:923 No locals. #3 0x00007ffff7bc165e in dtls1_buffer_message (s=0x7fff58023010, is_ccs=0) at d1_both.c:1244 item = frag = 0x7fff94001cf0 seq64be = "\020\060\002X\377\177\000" #4 0x00007ffff7bb9fd0 in dtls1_send_server_certificate (s=0x7fff58023010) at d1_srvr.c:1602 l = x = #5 0x00007ffff7bbbdf7 in dtls1_accept (s=0x7fff58023010) at d1_srvr.c:426 buf = Time = 1418197945 cb = 0 alg_k = ret = new_state = state = 8512 skip = 0 listen = 0 #6 0x00007fff9e282999 in dtls_perform_handshake (instance=0x7fff58014dd8, dtls=0x7fff5800fbb0, rtcp=0) at res_rtp_asterisk.c:1584 rtp = 0x7fff5800ce10 #7 0x00007fff9e282a8a in ast_rtp_on_ice_complete (ice=0x7fff5801db58, status=0) at res_rtp_asterisk.c:1610 instance = 0x7fff58014dd8 rtp = 0x7fff5800ce10 #8 0x00007fff9e294dad in on_timer () from /usr/lib/asterisk/modules/res_rtp_asterisk.so No symbol table info available. #9 0x00007fff9e2c3b6e in pj_timer_heap_poll () from /usr/lib/asterisk/modules/res_rtp_asterisk.so No symbol table info available. #10 0x00007fff9e282d59 in timer_worker_thread (data=0x0) at res_rtp_asterisk.c:1696 delay = {sec = 0, msec = 10} ioqueue = 0x7fff940008e8 #11 0x00007fff9e2b509b in thread_main () from /usr/lib/asterisk/modules/res_rtp_asterisk.so No symbol table info available. #12 0x00000037ca2079d1 in start_thread (arg=0x7fff9c001700) at pthread_create.c:301 __res = pd = 0x7fff9c001700 now = unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140735810639616, 179920719414352890, 140737488340608, 140735810640320, 0, 3, -180129756062360582, 148795465936985082}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = pagesize_m1 = sp = freesize = #13 0x00000037c9ee89dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 From rt at openssl.org Tue Dec 9 09:02:30 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 15:02:30 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209135819.P5OJp-Ag%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141208203655.GB11298@roeckx.be> <20141209112738.qOw6yRaC%sdaoden@yandex.com> <20141209135819.P5OJp-Ag%sdaoden@yandex.com> Message-ID: |"Kurt Roeckx via RT" wrote: ||been one that sets the minimum and maximum version. But I think ||we're too late 1.0.2 process to still change this. Attached a git format-patch MBOX for 1.0.2 (on top of [6806b69]). It boils anything down into two changesets (SSL_CONF_CTX and pseudo protocols). Remarks: - I've adjusted anything for SSLv2 (in the PODs, as OLDEST, in VULNERABLE). - s_client.pod and s_server.pod did not yet state that they support the SSL_CONF_CTX arguments, so i've added that (which s_cb.c seems to support already). - make && make test work, rest yet just installed. Let me know if you want the same for [master] again. I really hope you do that, and Ciao from Germany --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ossl-1_0_2.mbox Type: application/mbox Size: 29466 bytes Desc: not available URL: From rt at openssl.org Tue Dec 9 18:09:48 2014 From: rt at openssl.org (Adam Langley via RT) Date: Wed, 10 Dec 2014 00:09:48 +0100 Subject: [openssl-dev] [openssl.org #3607] nistz256 is broken. In-Reply-To: References: <547CBF3D.6010309@openssl.org> <54816C29.9010204@openssl.org> <5481C240.3050704@openssl.org> Message-ID: On Fri, Dec 5, 2014 at 6:33 AM, Andy Polyakov via RT wrote: > Attached. A little bit worse performance on some CPUs. I also took > opportunity to harmonize ecp_nistz256_from_mont by applying same pattern > for reduction. The patch is cumulative, i.e. is not incremental to > previously posted one[s], and addresses both problems, originally > reported one and discovered in the course. Patch to ecp_nistz256.c > referred above doesn't matter. When applying just that patch, the original test case fails. Specially this test code (C++): BIGNUM *n = nullptr, *X = nullptr, *Y = nullptr, *Z = nullptr; BIGNUM *x = BN_new(); BIGNUM *y = BN_new(); ASSERT_NE(BN_hex2bn(&n, "2269520AFB46450398DE95AE59DDBDC1D42B8B7030F81BCFEF12D819C1D678DD"), 0); ASSERT_NE(BN_hex2bn(&X, "C4EB2994C09557B400FF6A543CFB257F945E86FE3DF1D32A8128F32927666A8F"), 0); ASSERT_NE(BN_hex2bn(&Y, "3D5283F8F10F559AE5310005005F321B28D2D699F3E01F179F91AC6660013328"), 0); ASSERT_NE(BN_hex2bn(&Z, "F97FD7E6757991A2C7E0C2488FF3C54E58030BCACF3FB95954FD3EF211C24631"), 0); EC_GROUP *group = EC_GROUP_new_by_curve_name(NID_X9_62_prime256v1); EC_POINT *p = EC_POINT_new(group); BN_CTX *ctx = BN_CTX_new(); ASSERT_EQ(1, EC_POINT_set_Jprojective_coordinates_GFp(group, p, X, Y, Z, ctx)); EC_POINT *r = EC_POINT_new(group); // Set r = ??n. ASSERT_EQ(1, EC_POINT_mul(group, r, NULL, p, n, ctx)); ASSERT_EQ(1, EC_POINT_get_affine_coordinates_GFp(group, r, x, y, ctx)); char *x_out = BN_bn2hex(x); char *y_out = BN_bn2hex(y); EXPECT_STREQ("C2910AA0216D12DE30C5573CCFC4116546E3091DC1E9EC8604F634185CE40863", x_out); EXPECT_STREQ("C9071E13D688C305CE179C6168DD9066657BC6CDC1639A44B68DF7F1E0A40EDF", y_out); free(x_out); free(y_out); BN_free(x); BN_free(y); BN_free(X); BN_free(Y); BN_free(Z); BN_free(n); EC_POINT_free(r); EC_POINT_free(p); BN_CTX_free(ctx); EC_GROUP_free(group); Just to check that I'm not doing anything stupid (which is always a distinct possibility), here are the .pl[1] and resulting .s[2] file that I ended up with. [1] https://drive.google.com/file/d/0B_OzbbAp1CG5OVdVc196QmV3bG8/view?usp=sharing [2] https://drive.google.com/file/d/0B_OzbbAp1CG5Z3NoZzBqU09scFE/view?usp=sharing Cheers AGL From rt at openssl.org Tue Dec 9 06:24:31 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 9 Dec 2014 12:24:31 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141209112118.8QH3mNrZ%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> Message-ID: "Salz, Rich" wrote: |I think magic names -- shorthands -- are a very bad idea. \ I _completely_ disagree. | They are point-in-time statements whose meaning evolves, \ |if not erodes, over time. Because i don't think that a normal user, or even normal administrators and programmers is and are willing or even capable to understand what they are doing. How many people have read all the RFCs that are involved? And how many people have sufficient knowledge to _really_ understand the mathematical concepts and actual algorithms? Personally i am willing to put enough trust in the OpenSSL team *even insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' and leave the task of deciding what is VULNERABLE up to you. Imagine that. I have already implemented the necessary _CONF_ wrapper for OpenSSL v1.0.1 and it'll gave you a hand (shall the list receive this message). --steffen From rt at openssl.org Wed Dec 10 04:08:48 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Wed, 10 Dec 2014 10:08:48 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Also valgrind output ==17767== Thread 37: ==17767== Source and destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, 4294967209) ==17767== at 0x4A09A48: memcpy (vg_replace_strmem.c:916) ==17767== by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767== by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767== by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767== by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767== by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767== by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767== by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767== by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767== by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767== by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767== by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767== by 0x47D254: __ast_read (channel.c:4054) ==17767== by 0x47EFFD: ast_read (channel.c:4408) ==17767== by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) ==17767== ==17767== Invalid read of size 2 ==17767== at 0x4A09C4C: memcpy (vg_replace_strmem.c:916) ==17767== by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767== by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767== by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767== by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767== by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767== by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767== by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767== by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767== by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767== by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767== by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767== by 0x47D254: __ast_read (channel.c:4054) ==17767== by 0x47EFFD: ast_read (channel.c:4408) ==17767== by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) ==17767== Address 0x107e9c4c2 is not stack'd, malloc'd or (recently) free'd ==17767== ==17767== ==17767== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==17767== Access not within mapped region at address 0x107E9C4C2 ==17767== at 0x4A09C4C: memcpy (vg_replace_strmem.c:916) ==17767== by 0x4E5A2B6: do_dtls1_write (d1_pkt.c:1592) ==17767== by 0x4E5DA69: dtls1_do_write (d1_both.c:359) ==17767== by 0x4E56DF6: dtls1_accept (d1_srvr.c:426) ==17767== by 0x4E5B85C: dtls1_read_bytes (d1_pkt.c:787) ==17767== by 0x4E45ECF: ssl3_read_internal (s3_lib.c:4273) ==17767== by 0x215E3EF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==17767== by 0x215E431E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==17767== by 0x215ED620: ast_rtp_read (res_rtp_asterisk.c:4127) ==17767== by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==17767== by 0x114A7838: sip_rtp_read (chan_sip.c:8198) ==17767== by 0x114A7FE7: sip_read (chan_sip.c:8295) ==17767== by 0x47D254: __ast_read (channel.c:4054) ==17767== by 0x47EFFD: ast_read (channel.c:4408) ==17767== by 0x476B8F: ast_safe_sleep_conditional (channel.c:1702) 2014-12-10 11:38 GMT+03:00 ???????? ??????? : > After add check get crash > > 2014-12-10 11:18 GMT+03:00 ???????? ??????? : > >> Looks like need add some check to return code len.... >> >> >> 2014-12-10 11:06 GMT+03:00 ???????? ??????? : >> >>> Sorry. Line 1244 is >>> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >>> DTLS1_HM_HEADER_LENGTH == (unsigned >>> int)s->init_num); >>> >>> >>> 2014-12-10 11:05 GMT+03:00 ???????? ??????? : >>> >>>> (gdb) p s->d1->w_msg_hdr.msg_len >>>> $2 = 0 >>>> (gdb) p s->init_num >>>> $3 = 0 >>>> >>>> >>>> 2014-12-10 10:59 GMT+03:00 ???????? ??????? : >>>> >>>>> Get again ASSERT in d1_both.c:1244 >>>>> >>>>> OPENSSL_assert(s->d1->w_msg_hdr.msg_len + >>>>> >>>>> ((s->version==DTLS1_VERSION)?DTLS1_CCS_HEADER_LENGTH:3) == (unsigned >>>>> int)s->init_num); >>>>> } >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> 2014-12-10 6:32 GMT+03:00 ???????? ??????? : >>>>> >>>>>> Hello. I begin test you patch. I attach to mail patched version of >>>>>> you patch wthat may clear added current SRPM of Centos 6 >>>>>> >>>>>> 2014-12-03 5:16 GMT+03:00 ???????? ??????? : >>>>>> >>>>>>> Thanks! I need time to test it... i will try answer at this week >>>>>>> >>>>>>> 2014-12-02 19:37 GMT+03:00 Matt Caswell via RT : >>>>>>> >>>>>>>> On Tue Dec 02 17:31:05 2014, v.badalyan at open-bs.ru wrote: >>>>>>>> > if you send patch i can add it to SRPM build and try results >>>>>>>> > >>>>>>>> The patch is attached. However you may have problems with this >>>>>>>> approach. I have >>>>>>>> built the patch for 1.0.1e (which is the version you originally >>>>>>>> said you were >>>>>>>> running). However any additional patches that have been applied to >>>>>>>> the SRPM >>>>>>>> could cause the patch to fail to apply (and it is quite a large >>>>>>>> patch). I can >>>>>>>> also supply a patch against the latest 1.0.1j or >>>>>>>> OpenSSL_1_0_1-stable from git >>>>>>>> if you prefer. >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> ? ?????????, >>>>>>> ??????? ???????? ????????? >>>>>>> >>>>>>> ??? "???????? ??????-???????" >>>>>>> ??????????? ???????? >>>>>>> +7 (495) 666-0-111 >>>>>>> http://www.open-bs.ru >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> ? ?????????, >>>>>> ??????? ???????? ????????? >>>>>> >>>>>> ??? "???????? ??????-???????" >>>>>> ??????????? ???????? >>>>>> +7 (495) 666-0-111 >>>>>> http://www.open-bs.ru >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> ? ?????????, >>>>> ??????? ???????? ????????? >>>>> >>>>> ??? "???????? ??????-???????" >>>>> ??????????? ???????? >>>>> +7 (495) 666-0-111 >>>>> http://www.open-bs.ru >>>>> >>>> >>>> >>>> >>>> -- >>>> ? ?????????, >>>> ??????? ???????? ????????? >>>> >>>> ??? "???????? ??????-???????" >>>> ??????????? ???????? >>>> +7 (495) 666-0-111 >>>> http://www.open-bs.ru >>>> >>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rsalz at akamai.com Wed Dec 10 11:56:23 2014 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Dec 2014 11:56:23 -0500 Subject: [openssl-dev] License compatibility: OpenSSL and Apache v2 In-Reply-To: References: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7BFFE@USMBX1.msg.corp.akamai.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C1CD@USMBX1.msg.corp.akamai.com> > This is something I would like to be contributed to OpenSSL. > Sure, I'm talking about new engine and new files. Great, thanks. > But, if for some reasons licensing of it will be possible under Apache v2 only - what issues could it cause? Impossible to say for sure. Maybe no issues. Maybe a hassle. The devil is in the details, as the old saying goes. From rsalz at akamai.com Wed Dec 10 11:58:01 2014 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Dec 2014 11:58:01 -0500 Subject: [openssl-dev] More POODLE issues In-Reply-To: <20141210164918.GA24166@doctor.nl2k.ab.ca> References: <20141210164918.GA24166@doctor.nl2k.ab.ca> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C1D0@USMBX1.msg.corp.akamai.com> > Now POODLE is hitting TLS > > http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls- > itbwcw.html > > Any fixes in the works? As has already been covered in the openssl-dev list. OpenSSL does not have this defect. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From kurt at roeckx.be Wed Dec 10 11:59:09 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 10 Dec 2014 17:59:09 +0100 Subject: [openssl-dev] More POODLE issues In-Reply-To: <20141210164918.GA24166@doctor.nl2k.ab.ca> References: <20141210164918.GA24166@doctor.nl2k.ab.ca> Message-ID: <20141210165909.GA2038@roeckx.be> On Wed, Dec 10, 2014 at 09:51:15AM -0700, The Doctor wrote: > Now POODLE is hitting TLS > > http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html > > Any fixes in the works? As already said previously, openssl is not affected by this. kurt From matt at openssl.org Wed Dec 10 12:04:04 2014 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 Dec 2014 17:04:04 +0000 Subject: [openssl-dev] More POODLE issues In-Reply-To: <20141210164918.GA24166@doctor.nl2k.ab.ca> References: <20141210164918.GA24166@doctor.nl2k.ab.ca> Message-ID: <54887D04.2030004@openssl.org> On 10/12/14 16:51, The Doctor wrote: > Now POODLE is hitting TLS > > http://www.computerworld.com/article/2857274/security0/poodle-flaw-tls-itbwcw.html > > Any fixes in the works? > See my response to this yesterday on openssl-users: https://mta.opensslfoundation.net/pipermail/openssl-users/2014-December/000033.html In summary OpenSSL is not vulnerable to this. Matt From rt at openssl.org Wed Dec 10 12:35:48 2014 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 10 Dec 2014 18:35:48 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <54888469.5010207@openssl.org> References: <873619206.7485426.1418163965656.JavaMail.yahoo@jws10653.mail.bf1.yahoo.com> <54888469.5010207@openssl.org> Message-ID: > Excellent. My summary is: > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say "will not affect") Well, as there is suggestion of what I would say, I would only say that it's false positive. > - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. Another alternative is that they recognize it as bug worthy fixing, valgrind or OpenSSL. Even though I argue that it's valgrind bug, I'm ready to assist in addressing the issue on OpenSSL side. In other words try to report it to your favorite distro vendor. Refer to this ticket. But for now, I'm dismissing the case. From rt at openssl.org Wed Dec 10 12:59:35 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 10 Dec 2014 18:59:35 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> Message-ID: > Personally i am willing to put enough trust in the OpenSSL team *even > insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' > and leave the task of deciding what is VULNERABLE up to you. That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' From ynir.ietf at gmail.com Wed Dec 10 14:07:14 2014 From: ynir.ietf at gmail.com (Yoav Nir) Date: Wed, 10 Dec 2014 21:07:14 +0200 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> Message-ID: <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> > On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT wrote: > > "Salz, Rich" wrote: > |I think magic names -- shorthands -- are a very bad idea. \ > > I _completely_ disagree. > > | They are point-in-time statements whose meaning evolves, \ > |if not erodes, over time. > > Because i don't think that a normal user, or even normal > administrators and programmers is and are willing or even capable > to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can?t make on their behalf. So there?s bettercrypto.org and there?s Qualys and there?s this BCP document that the UTA working group at the IETF is writing, but ultimately we can?t shove security down people?s throat - just make good tools for them and provide (hopefully) good advice. Yoav From rt at openssl.org Wed Dec 10 14:07:25 2014 From: rt at openssl.org (Yoav Nir via RT) Date: Wed, 10 Dec 2014 20:07:25 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> Message-ID: > On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT wrote: > > "Salz, Rich" wrote: > |I think magic names -- shorthands -- are a very bad idea. \ > > I _completely_ disagree. > > | They are point-in-time statements whose meaning evolves, \ > |if not erodes, over time. > > Because i don't think that a normal user, or even normal > administrators and programmers is and are willing or even capable > to understand what they are doing. You are almost certainly far better qualified to make this decision than most administrators. Nevertheless, if upgrading OpenSSL from version X to version Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, there are going to be angry phone calls from users whose browser or application has stopped working. It is the administrator who is going to get those phone calls, not you, and the decision of whether to enable an obsolete ciphersuite or to force the user/programmer to update is a political decision that you can?t make on their behalf. So there?s bettercrypto.org and there?s Qualys and there?s this BCP document that the UTA working group at the IETF is writing, but ultimately we can?t shove security down people?s throat - just make good tools for them and provide (hopefully) good advice. Yoav From rt at openssl.org Wed Dec 10 13:05:53 2014 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 10 Dec 2014 19:05:53 +0100 Subject: [openssl-dev] [openssl.org #3607] nistz256 is broken. In-Reply-To: <54888B7B.4040002@openssl.org> References: <547CBF3D.6010309@openssl.org> <5481C240.3050704@openssl.org> <54888B7B.4040002@openssl.org> Message-ID: >> Attached. A little bit worse performance on some CPUs. I also took >> opportunity to harmonize ecp_nistz256_from_mont by applying same pattern >> for reduction. The patch is cumulative, i.e. is not incremental to >> previously posted one[s], and addresses both problems, originally >> reported one and discovered in the course. Patch to ecp_nistz256.c >> referred above doesn't matter. > > When applying just that patch, the original test case fails. Specially > this test code (C++): > > > ... > > > Just to check that I'm not doing anything stupid (which is always a > distinct possibility), here are the .pl[1] and resulting .s[2] file > that I ended up with. > > [1] https://drive.google.com/file/d/0B_OzbbAp1CG5OVdVc196QmV3bG8/view?usp=sharing > [2] https://drive.google.com/file/d/0B_OzbbAp1CG5Z3NoZzBqU09scFE/view?usp=sharing Patching went wrong for you. As you seem to operate in 1.0.2 context attached is corresponding ecp_nistz256.pl. -------------- next part -------------- A non-text attachment was scrubbed... Name: ecp_nistz256-x86_64.pl Type: text/x-perl Size: 67673 bytes Desc: not available URL: From dkg at fifthhorseman.net Wed Dec 10 14:26:00 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 10 Dec 2014 14:26:00 -0500 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> Message-ID: <54889E48.9080307@fifthhorseman.net> On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: >> Personally i am willing to put enough trust in the OpenSSL team *even >> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' >> and leave the task of deciding what is VULNERABLE up to you. > > That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've "turned on security", instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. > There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say "to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Wed Dec 10 14:31:28 2014 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Wed, 10 Dec 2014 20:31:28 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <54889E48.9080307@fifthhorseman.net> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> Message-ID: On 12/10/2014 12:59 PM, Salz, Rich via RT wrote: >> Personally i am willing to put enough trust in the OpenSSL team *even >> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' >> and leave the task of deciding what is VULNERABLE up to you. > > That is not a responsibility we want. No how, no way. It is enough to be responsible for the code. this is disappointing. The OpenSSL team is in the best position to provide sane and simple defaults/profiles, and to have those mechanisms be upgraded smoothly without applications or admins needing to know about them. Requiring administrators to tweak every application that uses TLS is a losing battle, and pretty much guarantees that we'll be keeping users with less-secure or outdated configurations. Programs which use the OpenSSL library generally just want to flip a switch and know that they've "turned on security", instead of trying to expose dozens of complex controls to the user or administrator. The closer OpenSSL can come to that ideal, the more likely its users will have reasonably strong crypto without having to learn the dirty dirty details and history of TLS and its predecessors. > There are better alternatives, including bettercrypto.org and another proposal from RedHat to have site/distro-specific 'profiles' I am happy that both of these things exist, but they don't preclude OpenSSL providing something and they shouldn't need to be as complex as they are. The configuration recommendations in bettercrypto.org are *at best* an ugly workaround to the lack of sane and simple mechanisms in the projects it supports. I'd love to see a version of bettercrypto.org that only has to say "to configure OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: not available URL: From rt at openssl.org Wed Dec 10 14:40:01 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 10 Dec 2014 20:40:01 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> Message-ID: -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz > You are almost certainly far better qualified to make this decision than most > administrators. Not sure who the "you" is. Me, openssl, or the original poster :) > Nevertheless, if upgrading OpenSSL from version X to version > Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, > there are going to be angry phone calls from users whose browser or > application has stopped working. It is the administrator who is going to get > those phone calls, not you I am more concerned about the case where a common crypto type is broken, and zillions (a technical term :) of websites are now at-risk because there wasn't an immediate OpenSSL update that added the broken crypto to the VULNERABLE list, and everyone didn't update immediately. Policy and configuration should be on a separate, arguably faster, distribution pattern than code. Which is why I favor a "profile" mechanism in openssl.conf and not hardwired magic keywords embedded in code. > So there?s bettercrypto.org and there?s Qualys and there?s this BCP > document that the UTA working group at the IETF is writing Perhaps modesty prevented you from posting the link, but it won't stop me (we're both in the acknowledgements section :) https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 From rt at openssl.org Wed Dec 10 14:47:49 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 10 Dec 2014 20:47:49 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2CA@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2CA@USMBX1.msg.corp.akamai.com> Message-ID: > I'd love to see a version of bettercrypto.org that only has to say "to configure > OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" That can happen but not by embedding magic strings into code. See http://rt.openssl.org/Ticket/Display.html?id=3266 http://rt.openssl.org/Ticket/Display.html?id=3299 From ynir.ietf at gmail.com Wed Dec 10 14:53:28 2014 From: ynir.ietf at gmail.com (Yoav Nir) Date: Wed, 10 Dec 2014 21:53:28 +0200 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> Message-ID: <7AF91CD0-385B-424C-BC88-6326861FCB1A@gmail.com> > On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT wrote: > > > I'd love to see a version of bettercrypto.org that only has to say "to > configure OpenSSL version 1.0.3 and higher, you should use the string > BEST_PRACTICE? I?d be much happier if that string was called ?best_practice_2015?, and when a future version of OpenSSL added ?best_practice_2017?, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (?you?ll lose support for all versions of Chrome below 52?) From rt at openssl.org Wed Dec 10 14:53:39 2014 From: rt at openssl.org (Yoav Nir via RT) Date: Wed, 10 Dec 2014 20:53:39 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <7AF91CD0-385B-424C-BC88-6326861FCB1A@gmail.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> <7AF91CD0-385B-424C-BC88-6326861FCB1A@gmail.com> Message-ID: > On Dec 10, 2014, at 9:31 PM, Daniel Kahn Gillmor via RT wrote: > > > I'd love to see a version of bettercrypto.org that only has to say "to > configure OpenSSL version 1.0.3 and higher, you should use the string > BEST_PRACTICE? I?d be much happier if that string was called ?best_practice_2015?, and when a future version of OpenSSL added ?best_practice_2017?, there would also be a wiki (or a site like bettercrypto) telling administrators what might happen if they switch (?you?ll lose support for all versions of Chrome below 52?) From quanah at zimbra.com Wed Dec 10 15:12:26 2014 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Wed, 10 Dec 2014 12:12:26 -0800 Subject: [openssl-dev] invalid certificate setup for mta.opensslfoundation.net Message-ID: <8A48F001912B49103E3ED5AB@[192.168.1.61]> Kind of humorous that I get cert errors when connecting to https://mta.opensslfoundation.net/ URLs. The cert itself looks to be very poorly formed (like someone who doesn't understand how to create certs set it up). Cert information: CN: mta O: NONE OU: NONE Issued by: CN: mta O: mta OU: NONE --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Wed Dec 10 15:35:44 2014 From: rt at openssl.org (=?UTF-8?B?0JDQu9C10LrRgdC10Lkg0JrQvtC80L3QuNC9?= via RT) Date: Wed, 10 Dec 2014 21:35:44 +0100 Subject: [openssl-dev] [openssl.org #3628] [PATCH] NDEBUG macro and redundant strings In-Reply-To: References: Message-ID: During the development process we found that libcrypto contains a lot of redundant strings in the final binary even when it was built with Debugging turned off. These strings undesirably reveal absolute paths to the source files of libcrypto. The paths usually contain private information, e.g. "/Users/john.johnson/Projects/libssl/crypto/evp/encode.c". That happens because several macros, like OPENSSL_malloc(), OPENSSL_assert() etc., pass __FILE__ as an operand to the underlying routines. I'd like to propose a new macro, NDEBUG, which turns on/off passing __FILE__ as an argument. Thanks, Alex Komnin. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-ndebug.patch Type: application/octet-stream Size: 10628 bytes Desc: not available URL: From rsalz at akamai.com Wed Dec 10 15:39:57 2014 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Dec 2014 15:39:57 -0500 Subject: [openssl-dev] invalid certificate setup for mta.opensslfoundation.net In-Reply-To: <8A48F001912B49103E3ED5AB@[192.168.1.61]> References: <8A48F001912B49103E3ED5AB@[192.168.1.61]> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C30E@USMBX1.msg.corp.akamai.com> > Kind of humorous that I get cert errors when connecting to > https://mta.opensslfoundation.net/ Glad you appreciate the humor :) We didn't want to wait for the CA to reply before making the switch. From npentako at Brocade.com Wed Dec 10 16:10:59 2014 From: npentako at Brocade.com (Vyas Pentakota) Date: Wed, 10 Dec 2014 21:10:59 +0000 Subject: [openssl-dev] Any way to create a large encrypted finish message? Message-ID: Hi I am working on issue involving openssl TLS 1.2 finish message decryption. I was wondering if anyone can tell me how I can generate "encrypted handshake message" (client finish message) larger than 64 bytes (using RSA AES256-SHA/ AES128-SHA/DES-CBC3-SHA). You suggestion is greatly appreciated. Thank you Vyas -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Wed Dec 10 16:28:07 2014 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 10 Dec 2014 21:28:07 +0000 Subject: [openssl-dev] More POODLE issues In-Reply-To: <54887D04.2030004@openssl.org> References: <20141210164918.GA24166@doctor.nl2k.ab.ca> <54887D04.2030004@openssl.org> Message-ID: Purely to give an independent answer - I'm not one of the openssl developers and I've tested this. As expected the ssl3 implementation allows any padding but the invalid padding is rejected with an alert when using TLS. So as Matt has said, it's not a problem for openssl. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Wed Dec 10 16:34:21 2014 From: richmoore44 at gmail.com (Richard Moore) Date: Wed, 10 Dec 2014 21:34:21 +0000 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <54889E48.9080307@fifthhorseman.net> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> Message-ID: On 10 December 2014 at 19:26, Daniel Kahn Gillmor wrote: > Programs which use the OpenSSL library generally just want to flip a > switch and know that they've "turned on security", instead of trying to > expose dozens of complex controls to the user or administrator. The > closer OpenSSL can come to that ideal, the more likely its users will > have reasonably strong crypto without having to learn the dirty dirty > details and history of TLS and its predecessors. > My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Dec 10 16:39:38 2014 From: rt at openssl.org (Richard Moore via RT) Date: Wed, 10 Dec 2014 22:39:38 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> Message-ID: On 10 December 2014 at 19:26, Daniel Kahn Gillmor wrote: > Programs which use the OpenSSL library generally just want to flip a > switch and know that they've "turned on security", instead of trying to > expose dozens of complex controls to the user or administrator. The > closer OpenSSL can come to that ideal, the more likely its users will > have reasonably strong crypto without having to learn the dirty dirty > details and history of TLS and its predecessors. > My experience suggests that while that might be what some developers want, that's not what users want. They expect that if it works in the browser it should work everywhere - even when the browser is jumping through hoops like fetching missing intermediate certificates, downgrading security etc. If the world were perfect and the browsers didn't do this then life would be a lot easier. Cheers Rich. From rt at openssl.org Wed Dec 10 18:03:54 2014 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Dec 2014 00:03:54 +0100 Subject: [openssl-dev] [openssl.org #3543] Remove #ifdef LINT fluff In-Reply-To: References: Message-ID: master 5cf3795 RT3543: Remove #ifdef LINT Author: Rich Salz Date: Tue Sep 23 13:23:09 2014 -0400 RT3543: Remove #ifdef LINT I also replaced some exit/return wrappers in various programs (from main) to standardize on return. Reviewed-by: Richard Levitte -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From sdaoden at yandex.com Thu Dec 11 07:03:30 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 13:03:30 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> Message-ID: <20141211120330.FVGktAAQ%sdaoden@yandex.com> Hello, "Stephen Henson via RT" wrote: |On Mon Dec 08 19:58:31 2014, sdaoden at yandex.com wrote: |> If people start using SSL_CONF_CTX as they are supposed to with |> v1.0.2, then it can be expected that users start using strings |> like, e.g. (from my thing), |> |> set ssl-protocol="ALL,-SSLv2" |If you print out the additional error data it should also indicate which |command and value it is objecting to, though it will only \ |say it doesn't like |the whole string and not the specific part of it it is rejecting. Oh i'm not complaining on that, error handling is always weird, and i think strings like error:140D00CF:SSL routines:SSL_write:protocol is shutdown are hard (not only to parse) for users but there is a lot of information for good in very few bytes; sad is Received SIGPIPE during IMAP operation IMAP write error: error:00000000:lib(0):func(0):reason(0) but as i think for most (Open)SSL related problems this is all my / our fault, users should not be bothered with that. Strings are intransparent for application programmers, but myriads of error enumerations can be too. Whatever. Regarding #3625: i think no user (that made it so far at first glance, which maybe even required buying a book and reading a lot!) would expect an error for saying "-SSLv2". But since it was an accidental oversight and the _OP_NO_SSLv2 is still defined (what i didn't even look for after reading the commit message) i think it'll be ok anyway once committed and this can be closed? Ciao, --steffen From rt at openssl.org Thu Dec 11 07:03:46 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 13:03:46 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141211120330.FVGktAAQ%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141211120330.FVGktAAQ%sdaoden@yandex.com> Message-ID: Hello, "Stephen Henson via RT" wrote: |On Mon Dec 08 19:58:31 2014, sdaoden at yandex.com wrote: |> If people start using SSL_CONF_CTX as they are supposed to with |> v1.0.2, then it can be expected that users start using strings |> like, e.g. (from my thing), |> |> set ssl-protocol="ALL,-SSLv2" |If you print out the additional error data it should also indicate which |command and value it is objecting to, though it will only \ |say it doesn't like |the whole string and not the specific part of it it is rejecting. Oh i'm not complaining on that, error handling is always weird, and i think strings like error:140D00CF:SSL routines:SSL_write:protocol is shutdown are hard (not only to parse) for users but there is a lot of information for good in very few bytes; sad is Received SIGPIPE during IMAP operation IMAP write error: error:00000000:lib(0):func(0):reason(0) but as i think for most (Open)SSL related problems this is all my / our fault, users should not be bothered with that. Strings are intransparent for application programmers, but myriads of error enumerations can be too. Whatever. Regarding #3625: i think no user (that made it so far at first glance, which maybe even required buying a book and reading a lot!) would expect an error for saying "-SSLv2". But since it was an accidental oversight and the _OP_NO_SSLv2 is still defined (what i didn't even look for after reading the commit message) i think it'll be ok anyway once committed and this can be closed? Ciao, --steffen From sdaoden at yandex.com Thu Dec 11 07:42:46 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 13:42:46 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> Message-ID: <20141211124246.Tp37AxWc%sdaoden@yandex.com> "Salz, Rich via RT" wrote: |> Personally i am willing to put enough trust in the OpenSSL team *even |> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' |> and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is enough to be responsible for the code. | |There are better alternatives, including bettercrypto.org \ |and another proposal from RedHat to have site/distro-specific 'profiles' Sorry but i simply fail to understand your point of view. I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as MIN/MAX/SECURE (booooring, but.. understandable). But i really missed (and still miss) the possibility on the _OP_NO_ level, and being able to completely bypass my own thing and give the user a direct hook into OpenSSL via _CONF_ is a great thing to have. That is what is actual fact in normal user space applications, if you want to replace that by some installation-wide policy then this is a nice idea, but it'll take decades until it reaches the last (maintained) application. Many programs support multiple TLS/SSL implementations and need to be able to configure the one which the user actually chooses to use / is available on the box. So your proposal needs to be adhered to by other TLS/SSL providers too in order to release applications from their compatibility problem. Of course i need an application internal compatibility layer for those implementations which don't support a direct _CONF_ hook as OpenSSL will start to support with v1.0.2 (though reducing my own thing to only support OpenSSL was one of the first steps i did, yet support for others will be readded later again). And for those i need to know relationships, "what is secure" etc. But i also need to know actual protocol names anyway, so whatever i do, without active maintainership things will rot. This is why i would be very happy if there would be "NEWEST", because even a rotted codebase would be automatically secure -- should the NEWEST protocol be secure. And if NEWEST is not supported by some counterpart server, then the user can still fine-tune and lower as far as necessary. I think this is the much better way 'round. Giving a user an option to actively deselect what is known not to be secure for a library release that still needs to support old protocols due to compatibility reasons can't be wrong. Of course users are capable to understand that a library update is necessary to overcome a newly detected insecurity. The maintenance burden of the OpenSSL library seems to be pretty drastic; regarding these strings those could be placed into ssl.h, maybe encapsulated in some library-built-time preprocessor toggle. Surely my own thing can be enhanced a lot, with more configuration options for users, with adhering to system wide defaults, but i am only one and that needs more time. I neither have the time nor the will (i am an elder man in the end) to spend time on rat racing some stylish internet pages. If i want communication i listen to good interprets of classical music. Thanks for your consideration. Ciao, --steffen From rt at openssl.org Thu Dec 11 07:42:57 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 13:42:57 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211124246.Tp37AxWc%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <20141211124246.Tp37AxWc%sdaoden@yandex.com> Message-ID: "Salz, Rich via RT" wrote: |> Personally i am willing to put enough trust in the OpenSSL team *even |> insofar* as i now do 'set ssl-protocol="ALL,-VULNERABLE"' |> and leave the task of deciding what is VULNERABLE up to you. | |That is not a responsibility we want. No how, no way. It \ |is enough to be responsible for the code. | |There are better alternatives, including bettercrypto.org \ |and another proposal from RedHat to have site/distro-specific 'profiles' Sorry but i simply fail to understand your point of view. I'm fine would OLDEST/NEWEST/VULNERABLE instead end up as MIN/MAX/SECURE (booooring, but.. understandable). But i really missed (and still miss) the possibility on the _OP_NO_ level, and being able to completely bypass my own thing and give the user a direct hook into OpenSSL via _CONF_ is a great thing to have. That is what is actual fact in normal user space applications, if you want to replace that by some installation-wide policy then this is a nice idea, but it'll take decades until it reaches the last (maintained) application. Many programs support multiple TLS/SSL implementations and need to be able to configure the one which the user actually chooses to use / is available on the box. So your proposal needs to be adhered to by other TLS/SSL providers too in order to release applications from their compatibility problem. Of course i need an application internal compatibility layer for those implementations which don't support a direct _CONF_ hook as OpenSSL will start to support with v1.0.2 (though reducing my own thing to only support OpenSSL was one of the first steps i did, yet support for others will be readded later again). And for those i need to know relationships, "what is secure" etc. But i also need to know actual protocol names anyway, so whatever i do, without active maintainership things will rot. This is why i would be very happy if there would be "NEWEST", because even a rotted codebase would be automatically secure -- should the NEWEST protocol be secure. And if NEWEST is not supported by some counterpart server, then the user can still fine-tune and lower as far as necessary. I think this is the much better way 'round. Giving a user an option to actively deselect what is known not to be secure for a library release that still needs to support old protocols due to compatibility reasons can't be wrong. Of course users are capable to understand that a library update is necessary to overcome a newly detected insecurity. The maintenance burden of the OpenSSL library seems to be pretty drastic; regarding these strings those could be placed into ssl.h, maybe encapsulated in some library-built-time preprocessor toggle. Surely my own thing can be enhanced a lot, with more configuration options for users, with adhering to system wide defaults, but i am only one and that needs more time. I neither have the time nor the will (i am an elder man in the end) to spend time on rat racing some stylish internet pages. If i want communication i listen to good interprets of classical music. Thanks for your consideration. Ciao, --steffen From sdaoden at yandex.com Thu Dec 11 07:51:12 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 13:51:12 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> Message-ID: <20141211125112.zmzGNd2m%sdaoden@yandex.com> Yoav Nir wrote: |> On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT \ |> wrote: |> "Salz, Rich" wrote: |>|I think magic names -- shorthands -- are a very bad idea. \ |> |> I _completely_ disagree. |> |>| They are point-in-time statements whose meaning evolves, \ |>|if not erodes, over time. |> |> Because i don't think that a normal user, or even normal |> administrators and programmers is and are willing or even capable |> to understand what they are doing. |decision than most administrators. Nevertheless, if upgrading \ |OpenSSL from version X to version Y causes a ciphersuite (or \ |TLS version) to be dropped into VULNERABLE, there are going \ |to be angry phone calls from users whose browser or application \ |has stopped working. It is the administrator who is going \ Applications don't need to use -VULNERABLE/+SECURE. Heck, the monster ones have become so intransparent that i have to place such an enormous trust into them that i only use one, Firefox, but that does terrible things and there is no knob that i can toggle wheresoever. (I've used Opera for over a decade and am very new to Firefox: i'm pretty sure there is some kind of registry that experienced users can tweak. But still: certainly neither in the Advanced nor the Security Tab.) _How_ i would appreciate being able to enter -VULNERABLE in some text field. And have a nicer and easier exception handling, too. Can be imagined. --steffen From rt at openssl.org Thu Dec 11 07:51:22 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 13:51:22 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211125112.zmzGNd2m%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <20141211125112.zmzGNd2m%sdaoden@yandex.com> Message-ID: Yoav Nir wrote: |> On Dec 9, 2014, at 1:24 PM, Steffen Nurpmeso via RT \ |> wrote: |> "Salz, Rich" wrote: |>|I think magic names -- shorthands -- are a very bad idea. \ |> |> I _completely_ disagree. |> |>| They are point-in-time statements whose meaning evolves, \ |>|if not erodes, over time. |> |> Because i don't think that a normal user, or even normal |> administrators and programmers is and are willing or even capable |> to understand what they are doing. |decision than most administrators. Nevertheless, if upgrading \ |OpenSSL from version X to version Y causes a ciphersuite (or \ |TLS version) to be dropped into VULNERABLE, there are going \ |to be angry phone calls from users whose browser or application \ |has stopped working. It is the administrator who is going \ Applications don't need to use -VULNERABLE/+SECURE. Heck, the monster ones have become so intransparent that i have to place such an enormous trust into them that i only use one, Firefox, but that does terrible things and there is no knob that i can toggle wheresoever. (I've used Opera for over a decade and am very new to Firefox: i'm pretty sure there is some kind of registry that experienced users can tweak. But still: certainly neither in the Advanced nor the Security Tab.) _How_ i would appreciate being able to enter -VULNERABLE in some text field. And have a nicer and easier exception handling, too. Can be imagined. --steffen From sdaoden at yandex.com Thu Dec 11 08:04:10 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 14:04:10 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> Message-ID: <20141211130410.epHIhesv%sdaoden@yandex.com> "Salz, Rich via RT" wrote: |> Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update \ |that added the broken crypto to the VULNERABLE list, and \ |everyone didn't update immediately. | |Policy and configuration should be on a separate, arguably \ |faster, distribution pattern than code. Which is why I favor \ |a "profile" mechanism in openssl.conf and not hardwired magic \ |keywords embedded in code. So you want a separate "openssl-conf" package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. | |Perhaps modesty prevented you from posting the link, but it \ |won't stop me (we're both in the acknowledgements section :) | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I have to look into OCSP. (But it has nothing to do with #3627.) --steffen From rt at openssl.org Thu Dec 11 08:04:19 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 14:04:19 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211130410.epHIhesv%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> Message-ID: "Salz, Rich via RT" wrote: |> Y causes a ciphersuite (or TLS version) to be dropped into VULNERABLE, |I am more concerned about the case where a common crypto type \ |is broken, and zillions (a technical term :) of websites are \ |now at-risk because there wasn't an immediate OpenSSL update \ |that added the broken crypto to the VULNERABLE list, and \ |everyone didn't update immediately. | |Policy and configuration should be on a separate, arguably \ |faster, distribution pattern than code. Which is why I favor \ |a "profile" mechanism in openssl.conf and not hardwired magic \ |keywords embedded in code. So you want a separate "openssl-conf" package. Fine, then provide it and give an easy mechanism for applications to hook into it. And for users to be able to overwrite system defaults. But this has not that much to do with #3627. | |Perhaps modesty prevented you from posting the link, but it \ |won't stop me (we're both in the acknowledgements section :) | https://tools.ietf.org/html/draft-ietf-uta-tls-bcp-07 I have to look into OCSP. (But it has nothing to do with #3627.) --steffen From sdaoden at yandex.com Thu Dec 11 08:09:15 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 14:09:15 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2CA@USMBX1.msg.corp.akamai.com> Message-ID: <20141211130915.1QjtcjPN%sdaoden@yandex.com> "Salz, Rich via RT" wrote: |> I'd love to see a version of bettercrypto.org that only \ |> has to say "to configure |> OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a magic string? I mean i hope we come to an end with this soon... But doesn't a OpenSSL library installation _as such_ represent such an immense combination of magic, regarding the internal configuration settings..? I wouldn't have a problem if you would add even more VULNERABLE, also to other _CONF_ settings. But i'm simple minded and as of today "Protocol" is just about anything that my thing is concerned of. :-) --steffen From rt at openssl.org Thu Dec 11 08:09:28 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 14:09:28 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211130915.1QjtcjPN%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2CA@USMBX1.msg.corp.akamai.com> <20141211130915.1QjtcjPN%sdaoden@yandex.com> Message-ID: "Salz, Rich via RT" wrote: |> I'd love to see a version of bettercrypto.org that only \ |> has to say "to configure |> OpenSSL version 1.0.3 and higher, you should use the string BEST_PRACTICE" | |That can happen but not by embedding magic strings into code. See But isn't TLSv1.2 also a magic string? I mean i hope we come to an end with this soon... But doesn't a OpenSSL library installation _as such_ represent such an immense combination of magic, regarding the internal configuration settings..? I wouldn't have a problem if you would add even more VULNERABLE, also to other _CONF_ settings. But i'm simple minded and as of today "Protocol" is just about anything that my thing is concerned of. :-) --steffen From sdaoden at yandex.com Thu Dec 11 08:15:01 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 14:15:01 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141209112118.8QH3mNrZ%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> Message-ID: <20141211131501.n8msRL4f%sdaoden@yandex.com> Hi. Richard Moore wrote: |> Programs which use the OpenSSL library generally just want to flip a |> switch and know that they've "turned on security", instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect that if it works in the browser it |should work everywhere - even when the browser is jumping through hoops |like fetching missing intermediate certificates, downgrading security etc. But now that it is christmas they can at least donate some dollars to some charitable aid organisation. |If the world were perfect and the browsers didn't do this then life would |be a lot easier. Ah, come on. No. --steffen From rt at openssl.org Thu Dec 11 08:15:10 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 14:15:10 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211131501.n8msRL4f%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C22E@USMBX1.msg.corp.akamai.com> <54889E48.9080307@fifthhorseman.net> <20141211131501.n8msRL4f%sdaoden@yandex.com> Message-ID: Hi. Richard Moore wrote: |> Programs which use the OpenSSL library generally just want to flip a |> switch and know that they've "turned on security", instead of trying to |My experience suggests that while that might be what some developers want, |that's not what users want. They expect that if it works in the browser it |should work everywhere - even when the browser is jumping through hoops |like fetching missing intermediate certificates, downgrading security etc. But now that it is christmas they can at least donate some dollars to some charitable aid organisation. |If the world were perfect and the browsers didn't do this then life would |be a lot easier. Ah, come on. No. --steffen From tmraz at redhat.com Thu Dec 11 08:52:19 2014 From: tmraz at redhat.com (Tomas Mraz) Date: Thu, 11 Dec 2014 14:52:19 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: References: <873619206.7485426.1418163965656.JavaMail.yahoo@jws10653.mail.bf1.yahoo.com> <54888469.5010207@openssl.org> Message-ID: <1418305939.13967.5.camel@vespa.frost.loc> On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote: > > Excellent. My summary is: > > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say "will not affect") > > Well, as there is suggestion of what I would say, I would only say that > it's false positive. > > > - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. > > Another alternative is that they recognize it as bug worthy fixing, > valgrind or OpenSSL. Even though I argue that it's valgrind bug, I'm > ready to assist in addressing the issue on OpenSSL side. In other words > try to report it to your favorite distro vendor. Refer to this ticket. > But for now, I'm dismissing the case. As the Fedora OpenSSL maintainer I would say it is not worth fixing in OpenSSL. We will rebase to 1.0.2 final in Fedora Rawhide once it is released. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From rt at openssl.org Thu Dec 11 08:52:32 2014 From: rt at openssl.org (Tomas Mraz via RT) Date: Thu, 11 Dec 2014 14:52:32 +0100 Subject: [openssl-dev] [openssl.org #3622] bug: crypto, valgrind reports improper memory access with AES128 cbc and longer plaintext In-Reply-To: <1418305939.13967.5.camel@vespa.frost.loc> References: <873619206.7485426.1418163965656.JavaMail.yahoo@jws10653.mail.bf1.yahoo.com> <54888469.5010207@openssl.org> <1418305939.13967.5.camel@vespa.frost.loc> Message-ID: On St, 2014-12-10 at 18:35 +0100, Andy Polyakov via RT wrote: > > Excellent. My summary is: > > - valgrind complaints about 1.0.1 OpenSLL are extremely unlikely to affect my program in operation (you will probably say "will not affect") > > Well, as there is suggestion of what I would say, I would only say that > it's false positive. > > > - when OpenSLL 1.0.2 eventually percolates through to Ubuntu and Fedora valgrind will stop complaining. > > Another alternative is that they recognize it as bug worthy fixing, > valgrind or OpenSSL. Even though I argue that it's valgrind bug, I'm > ready to assist in addressing the issue on OpenSSL side. In other words > try to report it to your favorite distro vendor. Refer to this ticket. > But for now, I'm dismissing the case. As the Fedora OpenSSL maintainer I would say it is not worth fixing in OpenSSL. We will rebase to 1.0.2 final in Fedora Rawhide once it is released. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From rt at openssl.org Thu Dec 11 10:23:50 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 11 Dec 2014 16:23:50 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> Message-ID: > So you want a separate "openssl-conf" package. Fine, then provide it and > give an easy mechanism for applications to hook into it. > And for users to be able to overwrite system defaults. > But this has not that much to do with #3627. Yes it does. :) A newer simpler API that does what you want seems exactly the way forward. Go for it. I've said that adding new magic keywords is not something we're going to do, and I've tried to explain the reasoning. I am sorry that you don't like it. From steve at openssl.org Thu Dec 11 10:48:39 2014 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Dec 2014 15:48:39 +0000 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141211120330.FVGktAAQ%sdaoden@yandex.com> Message-ID: <20141211154839.GA29964@openssl.org> On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: > > are hard (not only to parse) for users but there is a lot of > information for good in very few bytes; sad is > > Received SIGPIPE during IMAP operation > IMAP write error: error:00000000:lib(0):func(0):reason(0) > OpenSSL itself should never generate that error through (for example) ERR_print_errors(): if anyone can do that I'd like details and it will be fixed. If ERR_get_error() returns zero it indicates there is no error in the error queue if an application doesn't check for that value and attempts to interpret it as an error code you get the result above... Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Dec 11 11:52:10 2014 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 11 Dec 2014 17:52:10 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141206212107.xQjigGTt%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: On Mon Dec 08 20:20:44 2014, sdaoden at yandex.com wrote: > Hello, > > and finally i propose three new values for the "Protocol" slot of > SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. > Just to add my 2p to this thread which seems to have veered into rather different territory... I don't think it's appropriate to have a "VULNERABLE" option as a protocol selection value partly because vulnerability rarely affects a whole protocol version, just aspects of it. You can (for example) restrict yourself to TLS v1.2 and still do insecure things such as talk to servers with 512 bit RSA keys or using 256 bit DH parameters. Your request seems closer to the "security levels" code which is currently only in the OpenSSL master branch. It will by default reject many things: including the RSA, DH examples above. An application can increase the security level to make things stricter (but this will fail for many existing servers so it isn't the default), disable it completely and handle everything themselves (which is what previous versions of OpenSSL do) or have finer control using an application specific callback. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From sdaoden at yandex.com Thu Dec 11 13:37:39 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 19:37:39 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> Message-ID: <20141211183739.zlxLUIld%sdaoden@yandex.com> "Salz, Rich via RT" wrote: |> So you want a separate "openssl-conf" package. Fine, then provide it and |> give an easy mechanism for applications to hook into it. |> And for users to be able to overwrite system defaults. |> But this has not that much to do with #3627. | |Yes it does. :) A newer simpler API that does what you want \ |seems exactly the way forward. Go for it. You sound pretty good and done here.. Gratulations. [Laughter] Regarding the interface: back in 2011 i have started (only) writing a Python (grr) script, which had a really simple way of doing _any_ socket connection via class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator The basic concept was that all you can do is def create_connection(serv, cafile=None, all_fingerprints=False): where serv is a class Service, class Service(Config.Section): that directly maps to a configuration type (shortened by doc) [service] uid = UID url = NAME proto = proto port = NUMBER upgrade-secure = BOOLEAN fetch-folders = mailbox, another-mailbox, ... options = protocol-dependend (comma separated list of options) So wether TLS or not you simply (err, conn) = SaSo.create_connection(serv) if err: return (intro + 'connect failure: ' + err, ESTAT_CONNECTION) print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT) _maximally_ extended by (for non-initially secured transport) # Shall we try to upgrade to TLS (RFC 2595)? if self.service.upgrade_secure: resp = self._single('STLS') if not resp: self.error_append('\nServer does not seem to support secure ' + 'transport.\nYou need to disable the *upgrade-secure* ' + 'configuration setting.') return resp = SaSo.wrap_connection(self.conn) if resp is not None: self.error = 'failed to perform *upgrade-secure*: ' + resp return Cool, eh? S-postman.py was that thing. _That_ is in essence what i mean -- just think about the current Python urllib is it CVE-2014-9365: not even programmers that know do it the right way, how can you expect administrators and normal users to do so, even _if_ the software allows the necessary configuration. Nono. |I've said that adding new magic keywords is not something \ |we're going to do, and I've tried to explain the reasoning. \ | I am sorry that you don't like it. Despite that i continue to disagree _completely_. The other way around would be the right way to go for configuration, and if that doesn't work then the _library_ had to be adjusted. E.g. by splitting off a small config update package that updates cipher lists and whatever (i am really not an expert. Nor do i plan to become one) without the need to recompile OpenSSL. Cool. But you are not there yet, are you? :-) So please please, give us "MIN" and "MAX". Ciao, From rt at openssl.org Thu Dec 11 13:37:58 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 19:37:58 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211183739.zlxLUIld%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> <20141211183739.zlxLUIld%sdaoden@yandex.com> Message-ID: "Salz, Rich via RT" wrote: |> So you want a separate "openssl-conf" package. Fine, then provide it and |> give an easy mechanism for applications to hook into it. |> And for users to be able to overwrite system defaults. |> But this has not that much to do with #3627. | |Yes it does. :) A newer simpler API that does what you want \ |seems exactly the way forward. Go for it. You sound pretty good and done here.. Gratulations. [Laughter] Regarding the interface: back in 2011 i have started (only) writing a Python (grr) script, which had a really simple way of doing _any_ socket connection via class SaSo: # {{{ Sa[fe]So[cket] SSL and socket creation encapsulator The basic concept was that all you can do is def create_connection(serv, cafile=None, all_fingerprints=False): where serv is a class Service, class Service(Config.Section): that directly maps to a configuration type (shortened by doc) [service] uid = UID url = NAME proto = proto port = NUMBER upgrade-secure = BOOLEAN fetch-folders = mailbox, another-mailbox, ... options = protocol-dependend (comma separated list of options) So wether TLS or not you simply (err, conn) = SaSo.create_connection(serv) if err: return (intro + 'connect failure: ' + err, ESTAT_CONNECTION) print('@ ', intro, conn.pretty_addr, sep='', file=STDOUT) _maximally_ extended by (for non-initially secured transport) # Shall we try to upgrade to TLS (RFC 2595)? if self.service.upgrade_secure: resp = self._single('STLS') if not resp: self.error_append('\nServer does not seem to support secure ' + 'transport.\nYou need to disable the *upgrade-secure* ' + 'configuration setting.') return resp = SaSo.wrap_connection(self.conn) if resp is not None: self.error = 'failed to perform *upgrade-secure*: ' + resp return Cool, eh? S-postman.py was that thing. _That_ is in essence what i mean -- just think about the current Python urllib is it CVE-2014-9365: not even programmers that know do it the right way, how can you expect administrators and normal users to do so, even _if_ the software allows the necessary configuration. Nono. |I've said that adding new magic keywords is not something \ |we're going to do, and I've tried to explain the reasoning. \ | I am sorry that you don't like it. Despite that i continue to disagree _completely_. The other way around would be the right way to go for configuration, and if that doesn't work then the _library_ had to be adjusted. E.g. by splitting off a small config update package that updates cipher lists and whatever (i am really not an expert. Nor do i plan to become one) without the need to recompile OpenSSL. Cool. But you are not there yet, are you? :-) So please please, give us "MIN" and "MAX". Ciao, From sdaoden at yandex.com Thu Dec 11 13:45:44 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 19:45:44 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141211154839.GA29964@openssl.org> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141211120330.FVGktAAQ%sdaoden@yandex.com> <20141211154839.GA29964@openssl.org> Message-ID: <20141211184544.moYaU70Q%sdaoden@yandex.com> "Dr. Stephen Henson" wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: |> are hard (not only to parse) for users but there is a lot of |> information for good in very few bytes; sad is |> |> Received SIGPIPE during IMAP operation |> IMAP write error: error:00000000:lib(0):func(0):reason(0) | |OpenSSL itself should never generate that error through (for example) |ERR_print_errors(): if anyone can do that I'd like details and it will be |fixed. If ERR_get_error() returns zero it indicates there is no error in Ok. I really have a lot of work to do with my thing... |the error queue if an application doesn't check for that value |and attempts to interpret it as an error code you get the result above... Sigh. And then these old codebases that jump around like grazy from the middle of nowhere. Amazing how stable all that is with all the, also thread-safe, third party libaries linked into it, just like OpenSSL. But that is not your problem, of course. Thank you. --steffen From rt at openssl.org Thu Dec 11 13:47:06 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 19:47:06 +0100 Subject: [openssl-dev] [openssl.org #3625] Enhancement request: user convenience for SSL_CONF_CTX with SSLv2 In-Reply-To: <20141211184544.moYaU70Q%sdaoden@yandex.com> References: <20141205220511.FmMVpf0B%sdaoden@yandex.com> <20141211120330.FVGktAAQ%sdaoden@yandex.com> <20141211154839.GA29964@openssl.org> <20141211184544.moYaU70Q%sdaoden@yandex.com> Message-ID: "Dr. Stephen Henson" wrote: |On Thu, Dec 11, 2014, Steffen Nurpmeso via RT wrote: |> are hard (not only to parse) for users but there is a lot of |> information for good in very few bytes; sad is |> |> Received SIGPIPE during IMAP operation |> IMAP write error: error:00000000:lib(0):func(0):reason(0) | |OpenSSL itself should never generate that error through (for example) |ERR_print_errors(): if anyone can do that I'd like details and it will be |fixed. If ERR_get_error() returns zero it indicates there is no error in Ok. I really have a lot of work to do with my thing... |the error queue if an application doesn't check for that value |and attempts to interpret it as an error code you get the result above... Sigh. And then these old codebases that jump around like grazy from the middle of nowhere. Amazing how stable all that is with all the, also thread-safe, third party libaries linked into it, just like OpenSSL. But that is not your problem, of course. Thank you. --steffen From sdaoden at yandex.com Thu Dec 11 14:09:04 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Thu, 11 Dec 2014 20:09:04 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: References: <20141206212107.xQjigGTt%sdaoden@yandex.com> Message-ID: <20141211190904.xXOWTR7O%sdaoden@yandex.com> "Stephen Henson via RT" wrote: |On Mon Dec 08 20:20:44 2014, sdaoden at yandex.com wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |Just to add my 2p to this thread which seems to have veered into rather |different territory... Please. Oh yes, i think i have digressed a lot by now. |I don't think it's appropriate to have a "VULNERABLE" option as a protocol |selection value partly because vulnerability rarely affects a whole protocol |version, just aspects of it. You can (for example) restrict yourself to TLS |v1.2 and still do insecure things such as talk to servers \ |with 512 bit RSA keys |or using 256 bit DH parameters. | |Your request seems closer to the "security levels" code which \ |is currently only |in the OpenSSL master branch. It will by default reject many \ |things: including |the RSA, DH examples above. An application can increase the \ |security level to |make things stricter (but this will fail for many existing \ |servers so it isn't |the default), disable it completely and handle everything \ |themselves (which is |what previous versions of OpenSSL do) or have finer control using an |application specific callback. Ok, i've never ment to go that much into the details, what i've also said in the other responses. Yours is the view of someone who deeply penetrates the problem for i think way over a decade, mine is rather restricted to a well-known book, what you hear here and there plus some manual reading, no more and no less. On this level "SSLv2" is "very insecure" and so for a very long time, "SSLv3" was "insecure" and now has made it to the same level as is predecessor. After reading the draft linked in a message of this thread and following some references it seems that i drive very well with restricting myself (and recommend users that ask) to TLSv1.2, which i do for well over a year, when i can. I just _never_ played with any other setting regarding TLS/SSL, though i have to admit that i once adjusted a "MACs" SSH configuration setting (to be able to connect). That is all i know -- and _my_ opinion is that if that is not sufficient, something is wrong. Because _i_ will _never_ accomplish an intellectual penetration of -- short -- anything involved to get at a permanently secured encrypted transport. Just never. And, when that far, i'm a buddhist, actually i'm even disgusted of secure transport as such. Here is all about reflection, canalisation and transformation, but now i think i'm really off-topic. So if that doesn't clash a desire to intellectually penetrate secure transport then i don't know. :-) I'm still hoping for at least (OLDEST/MIN and) NEWEST/MAX. Ciao, --steffen From rt at openssl.org Thu Dec 11 14:09:17 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 11 Dec 2014 20:09:17 +0100 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211190904.xXOWTR7O%sdaoden@yandex.com> References: <20141206212107.xQjigGTt%sdaoden@yandex.com> <20141211190904.xXOWTR7O%sdaoden@yandex.com> Message-ID: "Stephen Henson via RT" wrote: |On Mon Dec 08 20:20:44 2014, sdaoden at yandex.com wrote: |> and finally i propose three new values for the "Protocol" slot of |> SSL_CONF_CTX_cmd(): OLDEST, NEWEST and VULNERABLE. | |Just to add my 2p to this thread which seems to have veered into rather |different territory... Please. Oh yes, i think i have digressed a lot by now. |I don't think it's appropriate to have a "VULNERABLE" option as a protocol |selection value partly because vulnerability rarely affects a whole protocol |version, just aspects of it. You can (for example) restrict yourself to TLS |v1.2 and still do insecure things such as talk to servers \ |with 512 bit RSA keys |or using 256 bit DH parameters. | |Your request seems closer to the "security levels" code which \ |is currently only |in the OpenSSL master branch. It will by default reject many \ |things: including |the RSA, DH examples above. An application can increase the \ |security level to |make things stricter (but this will fail for many existing \ |servers so it isn't |the default), disable it completely and handle everything \ |themselves (which is |what previous versions of OpenSSL do) or have finer control using an |application specific callback. Ok, i've never ment to go that much into the details, what i've also said in the other responses. Yours is the view of someone who deeply penetrates the problem for i think way over a decade, mine is rather restricted to a well-known book, what you hear here and there plus some manual reading, no more and no less. On this level "SSLv2" is "very insecure" and so for a very long time, "SSLv3" was "insecure" and now has made it to the same level as is predecessor. After reading the draft linked in a message of this thread and following some references it seems that i drive very well with restricting myself (and recommend users that ask) to TLSv1.2, which i do for well over a year, when i can. I just _never_ played with any other setting regarding TLS/SSL, though i have to admit that i once adjusted a "MACs" SSH configuration setting (to be able to connect). That is all i know -- and _my_ opinion is that if that is not sufficient, something is wrong. Because _i_ will _never_ accomplish an intellectual penetration of -- short -- anything involved to get at a permanently secured encrypted transport. Just never. And, when that far, i'm a buddhist, actually i'm even disgusted of secure transport as such. Here is all about reflection, canalisation and transformation, but now i think i'm really off-topic. So if that doesn't clash a desire to intellectually penetrate secure transport then i don't know. :-) I'm still hoping for at least (OLDEST/MIN and) NEWEST/MAX. Ciao, --steffen From kannanar at cisco.com Thu Dec 11 15:00:36 2014 From: kannanar at cisco.com (Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco)) Date: Thu, 11 Dec 2014 20:00:36 +0000 Subject: [openssl-dev] Openssl Shared library mode compilation Message-ID: Hi Team, For Vulnerability issue, we are indeed to upgrade the openssl version to 0.9.8zc version. We have downloaded the source from www.openssl.org site. While compiling we have followed the below steps including environment variables setting ready for compilation. But we are unable to compile with "shared" basis. Previously we have used this option but with this openssl version we are unable to compiled in shared basis. Steps followed: ============= VCVARS32.BAT perl Configure VC-WIN32 no-idea shared --prefix=c:/openssl --> "Shared" option is giving the problem. Without "shared" option compilation get successful. ms\do_masm nmake -f ms\ntdll.mak Can anyone help us to compile with "Shared" option for this openssl version(0.9.8zc) ? Thanks, Kannan Narayanasamy. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Dec 11 16:06:09 2014 From: rt at openssl.org (Lawrence via RT) Date: Thu, 11 Dec 2014 22:06:09 +0100 Subject: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile In-Reply-To: <005f01d014ea$ad5c3b30$0814b190$@codeaurora.org> References: <005f01d014ea$ad5c3b30$0814b190$@codeaurora.org> Message-ID: Hello. I am one of the llvm developer, I run into a situation that I think it is bug in souce code: "run" in speed.c should be declared as volatile because "run"'s value can be predicted. The problem is the following code: signal(SIGALRM,sig_done); . for (j=0; j References: Message-ID: Info: Windows 8.1 64-bit Visual Studio Premium 2012 Zlib 1.2.8 OpenSSL fips object module 2.0.8 OpenSSL 1.0.1j Note: zlib and fips object module build fine (FYI: zlib dll built from zlib distro directory contrib\vstudio\vc11 that makes zlibwapi.dll instead of making ZLIB1.DLL). The following build commands work (with zlib, without fips): perl Configure no-asm zlib --with-zlib-include=..\..\zlib\include --with-zlib-lib=..\..\zlib\Release\zlibwapi.lib -DZLIB_WINAPI -MP VC-WIN64A call ms\do_win64a.bat nmake -f ms\ntdll.mak The following build commands fail: perl Configure no-asm zlib --with-zlib-include=..\..\zlib\include --with-zlib-lib=..\..\zlib\Release\zlibwapi.lib -DZLIB_WINAPI -MP fips --with-fipsdir=c:\usr\local\ssl\fips-2.0 VC-WIN64A call ms\do_win64a.bat nmake -f ms\ntdll.mak I have tracked it down to mk1mf.pl line 416 not running: $ex_libs .= " $zlib_lib" if $zlib_opt == 1; My possible fix is to move that line above line 394 so it looks like (maybe fix indentation): $ex_libs .= " $zlib_lib" if $zlib_opt == 1; if ($shlib) If you need more info please let me know. Thanks, SLDR (Stephen L. De Rudder) e-mail: rdls22 at tditx.com PS: The following build works too: The following build commands work (without zlib, with fips): perl Configure no-asm -MP fips --with-fipsdir=c:\usr\local\ssl\fips-2.0 VC-WIN64A call ms\do_win64a.bat nmake -f ms\ntdll.mak From rt at openssl.org Thu Dec 11 16:24:08 2014 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 11 Dec 2014 22:24:08 +0100 Subject: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile In-Reply-To: <20141211212401.GA32213@roeckx.be> References: <005f01d014ea$ad5c3b30$0814b190$@codeaurora.org> <20141211212401.GA32213@roeckx.be> Message-ID: Yes, global variables used in signal handlers should be volatile. Kurt From rt at openssl.org Thu Dec 11 17:04:13 2014 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 11 Dec 2014 23:04:13 +0100 Subject: [openssl-dev] [openssl.org #3497] Move dclean actions to clean In-Reply-To: References: Message-ID: Fixed in master. commit 5ab65c50ef8287b128d6642209525283e1ea07be Author: Rich Salz Date: Thu Dec 11 17:01:16 2014 -0500 RT3497: Clean up "dclean" targets Some Makefiles had actions for "dclean" that really belonged to the "clean" target. This is wrong because clean ends up, well, not really cleaning everything. Reviewed-by: Richard Levitte -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From steve at openssl.org Thu Dec 11 18:03:14 2014 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Dec 2014 23:03:14 +0000 Subject: [openssl-dev] Openssl Shared library mode compilation In-Reply-To: References: Message-ID: <20141211230314.GA4474@openssl.org> On Thu, Dec 11, 2014, Kannan Narayanasamy -X (kannanar - HCL TECHNOLOGIES LIMITED at Cisco) wrote: > > Hi Team, > > For Vulnerability issue, we are indeed to upgrade the openssl version to 0.9.8zc version. We have downloaded the source from www.openssl.org site. While compiling we have followed the below steps including environment variables setting ready for compilation. But we are unable to compile with "shared" basis. Previously we have used this option but with this openssl version we are unable to compiled in shared basis. > > Steps followed: > ============= > VCVARS32.BAT > perl Configure VC-WIN32 no-idea shared --prefix=c:/openssl --> "Shared" option is giving the problem. Without "shared" option compilation get successful. > ms\do_masm > nmake -f ms\ntdll.mak > > Can anyone help us to compile with "Shared" option for this openssl version(0.9.8zc) ? > You don't use the "shared" option for VC builds. Two makefiles are generated: ms\ntdll.mak creates shared libraries while ms\nt.mak creates static ones. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Thu Dec 11 18:31:22 2014 From: rt at openssl.org (Adam Langley via RT) Date: Fri, 12 Dec 2014 00:31:22 +0100 Subject: [openssl-dev] [openssl.org #3607] nistz256 is broken. In-Reply-To: References: <547CBF3D.6010309@openssl.org> <54888B7B.4040002@openssl.org> Message-ID: On Wed, Dec 10, 2014 at 10:05 AM, Andy Polyakov via RT wrote: > Patching went wrong for you. As you seem to operate in 1.0.2 context > attached is corresponding ecp_nistz256.pl. Thanks. So far that version is good to ~1B random tests. I'll leave it going until Monday. Cheers AGL From mancha1 at zoho.com Fri Dec 12 06:05:31 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 12 Dec 2014 06:05:31 +0000 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211183739.zlxLUIld%sdaoden@yandex.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> <20141211183739.zlxLUIld%sdaoden@yandex.com> Message-ID: <20141212060531.GA27128@zoho.com> On Thu, Dec 11, 2014 at 07:37:39PM +0100, Steffen Nurpmeso wrote: > "Salz, Rich via RT" wrote: > > So you want a separate "openssl-conf" package. Fine, then provide > > it and give an easy mechanism for applications to hook into it. > > And for users to be able to overwrite system defaults. But this > > has not that much to do with #3627. > > Yes it does. :) A newer simpler API that does what you want \ seems > exactly the way forward. Go for it. > > You sound pretty good and done here.. Gratulations. [Laughter] Emails sent to an RT issue are automatically forwarded by the system to the openssl-dev ML. There's no need to explicitly cc: openssl-dev as you're doing - all that does is clutter the ML with duplicates. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Fri Dec 12 15:35:35 2014 From: mancha1 at zoho.com (mancha) Date: Fri, 12 Dec 2014 15:35:35 +0000 Subject: [openssl-dev] [openssl.org #3627] Enhancement request: add more "Protocol" options for SSL_CONF_CTX In-Reply-To: <20141211183739.zlxLUIld%sdaoden@yandex.com> References: <2A0EFB9C05D0164E98F19BB0AF3708C71D547AA9C6@USMBX1.msg.corp.akamai.com> <37B0CF87-459A-4300-9E4F-683A7079C908@gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C2C1@USMBX1.msg.corp.akamai.com> <20141211130410.epHIhesv%sdaoden@yandex.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7C4FC@USMBX1.msg.corp.akamai.com> <20141211183739.zlxLUIld%sdaoden@yandex.com> Message-ID: <20141212153535.GB28578@zoho.com> On Thu, Dec 11, 2014 at 07:37:39PM +0100, Steffen Nurpmeso wrote: > "Salz, Rich via RT" wrote: > > So you want a separate "openssl-conf" package. Fine, then provide > > it and give an easy mechanism for applications to hook into it. > > And for users to be able to overwrite system defaults. But this > > has not that much to do with #3627. > > Yes it does. :) A newer simpler API that does what you want \ seems > exactly the way forward. Go for it. > > You sound pretty good and done here.. Gratulations. [Laughter] Emails sent to an RT issue are automatically forwarded by the system to the openssl-dev ML. There's no need to explicitly cc: openssl-dev as you're doing - all that does is clutter the ML with duplicates. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Fri Dec 12 16:05:46 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 12 Dec 2014 17:05:46 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: On Wed Dec 10 09:18:57 2014, v.badalyan at open-bs.ru wrote: > Looks like need add some check to return code len.... I agree. Co-incidentally I already have a very similar fix for the same defect going through the review process. Matt From rt at openssl.org Fri Dec 12 16:13:31 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 12 Dec 2014 17:13:31 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: On Wed Dec 10 10:08:48 2014, v.badalyan at open-bs.ru wrote: > Also valgrind output > > ==17767== Thread 37: > ==17767== Source and > destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, > 4294967209) ^^^^^^^^^^^^ This is interesting. That equates to -87. I think there is a signed/unsigned conversion issue going on here. I have another patch. It is cummulative on the last one (i.e. apply the first one, and then apply this one on top). Keep your other change too (although I think that is an unrelated problem). Let me know how you get on. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: rt3592-curr-mtu-1.0.1e.patch Type: text/x-diff Size: 2771 bytes Desc: not available URL: From rt at openssl.org Fri Dec 12 16:52:07 2014 From: rt at openssl.org (Matthias Mucha via RT) Date: Fri, 12 Dec 2014 17:52:07 +0100 Subject: [openssl-dev] [openssl.org #3631] Bug in the binary search in OBJ_bsearch_ex_ in obj_dat.c (1.0.1j) In-Reply-To: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> References: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> Message-ID: Hello, I strapped down OpenSSL 1.0.1j to only the PEM to RSA, BIO and RSA public decrypt functions. So a bug in the binary search in appeared: Current code: const void *OBJ_bsearch_ex_(const void *key, const void *base_, int num, int size, int (*cmp)(const void *, const void *), int flags) { const char *base=base_; int l,h,i=0,c=0; const char *p = NULL; if (num == 0) return(NULL); l=0; h=num; while (l < h) { i=(l+h)/2; p= &(base[i*size]); c=(*cmp)(key,p); if (c < 0) h=i; else if (c > 0) l=i+1; else break; } [...] My case: size = 4 num = 4 In the first round i evaluates to 2 which can not be divided by size and lets p escape the frame for the pointers, which results in a segfault. General case: This will fail for every case where num < (size * 2) My fix: const void *OBJ_bsearch_ex_(const void *key, const void *base_, int num, int size, int (*cmp)(const void *, const void *), int flags) { const char *base=base_; int l,h,i=0,c=0; const char *p = NULL; if (num == 0) return(NULL); if (num < size*2) { while(i 0) l=i+1; else break; } } [...] Regards Matthias Mucha From rt at openssl.org Fri Dec 12 16:52:15 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 12 Dec 2014 17:52:15 +0100 Subject: [openssl-dev] [openssl.org #3632] Enhancement request: CONF_modules_load_file(): please include filename in error message In-Reply-To: <20141212134419.FaVijj4C%sdaoden@yandex.com> References: <20141212134419.FaVijj4C%sdaoden@yandex.com> Message-ID: So i follow Rich Salz and am adding support for SSL_CONF_modules_load_file() (but i'm still wondering a bit why i do that) and while testing (with v1.0.2 beta4) i see messages like error:02001002:system library:fopen:No such file or directory error:0200100D:system library:fopen:Permission denied Which file are we talking about? (Hint: it is /usr/local/ssl/openssl.cnf.) --steffen From rt at openssl.org Fri Dec 12 16:52:22 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 12 Dec 2014 17:52:22 +0100 Subject: [openssl-dev] [openssl.org #3633] Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE In-Reply-To: <20141212135242.beVW_JqY%sdaoden@yandex.com> References: <20141212135242.beVW_JqY%sdaoden@yandex.com> Message-ID: Hello, while following Rich Salz's suggestion to make use of CONF_modules_load_file() i stumbled personally over the restriction that only a global openssl.cnf seems to be supported. There is no support for automatic loading of a $HOME/.openssl.cnf on top of the global version. And whereas setting of $OPENSSL_CONF could be used and communicated to users to achieve the desire, doing so actually replaces inclusion of the global openssl.cnf, which likely not results in the wanted effect!?! While here, it doesn't seem possible to _forbid_ use of $OPENSSL_CONF (from reading the manual)? If that is true then i would ask for an additional CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too. --steffen From rt at openssl.org Fri Dec 12 16:53:33 2014 From: rt at openssl.org (Lawrence via RT) Date: Fri, 12 Dec 2014 17:53:33 +0100 Subject: [openssl-dev] FW: [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile In-Reply-To: <013401d01587$df20ee70$9d62cb50$@codeaurora.org> References: <013401d01587$df20ee70$9d62cb50$@codeaurora.org> Message-ID: One correction, the value of "run" can be changed asynchronously because of the interaction of signal and alarm, alarm raise the signal, signal register the handler, the handler is sig_done, From: Lawrence [mailto:lawrence at codeaurora.org] Sent: Wednesday, December 10, 2014 6:32 PM To: 'rt at openssl.org' Subject: Bug report: "run" in speed.c should be declared as volatile Hello. I am one of the llvm developer, I run into a situation that I think it is bug in souce code: "run" in speed.c should be declared as volatile because "run"'s value can be predicted. The problem is the following code: signal(SIGALRM,sig_done); . for (j=0; j References: <200805311113.32854.hanno@hboeck.de> <200806010008.39258.daniel.subs@internode.on.net> Message-ID: master c3f2225 RT1688: Add dependencies for parallel make Author: Rich Salz Date: Fri Dec 12 13:17:51 2014 -0500 RT1688: Add dependencies for parallel make Reviewed-by: Dr. Stephen Henson ; -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri Dec 12 18:57:02 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 12 Dec 2014 19:57:02 +0100 Subject: [openssl-dev] [openssl.org #3634] Docfix: doc/apps/enc.pod says "aes-[128|192|256]" but means "aes[..]" In-Reply-To: <20141212181907.fQIM_ujl%sdaoden@yandex.com> References: <20141212181907.fQIM_ujl%sdaoden@yandex.com> Message-ID: ..so that even after OpenSSL_add_all_algorithms(3) EVP_get_cipherbyname(3) fails to load "aes-128" as an alias for "aes-128-cbc". --steffen diff --git a/doc/apps/enc.pod b/doc/apps/enc.pod index 41791ad..88e8b79 100644 --- a/doc/apps/enc.pod +++ b/doc/apps/enc.pod @@ -282,7 +282,7 @@ authentication tag. rc5-ofb RC5 cipher in OFB mode aes-[128|192|256]-cbc 128/192/256 bit AES in CBC mode - aes-[128|192|256] Alias for aes-[128|192|256]-cbc + aes[128|192|256] Alias for aes-[128|192|256]-cbc aes-[128|192|256]-cfb 128/192/256 bit AES in 128 bit CFB mode aes-[128|192|256]-cfb1 128/192/256 bit AES in 1 bit CFB mode aes-[128|192|256]-cfb8 128/192/256 bit AES in 8 bit CFB mode From rt at openssl.org Fri Dec 12 19:06:48 2014 From: rt at openssl.org (Paul A. Steckler via RT) Date: Fri, 12 Dec 2014 20:06:48 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: Hi, I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured with some xxx_DEBUG flags, which results in a compile failure in ssl/t1_enc.c. See the attached testlog for the exact flags used. Application details: N/A Problem Description: These compile-time (warnings and) errors: -- t1_enc.c: In function ?tls1_enc?: t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, but argument 4 has type ?long unsigned int? [-Wformat=] ds->cipher->iv_len); ^ t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, but argument 5 has type ?long unsigned int? [-Wformat=] t1_enc.c: In function ?tls1_mac?: t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) {unsigned int z; for (z=0; z From rt at openssl.org Sat Dec 13 07:14:31 2014 From: rt at openssl.org (Istvan Noszticzius via RT) Date: Sat, 13 Dec 2014 08:14:31 +0100 Subject: [openssl-dev] [openssl.org #3636] BIO_read() (enc_read()) with 0 length In-Reply-To: <3b68783e-fd2f-4f16-8905-88d03d3a649a@default> References: <3b68783e-fd2f-4f16-8905-88d03d3a649a@default> Message-ID: Dear Openssl-bugs, According to the BIO_read() documentation [1]: "All these functions return either the amount of data successfully read or written (if the return value is positive) or that no data was successfully read or written if the result is 0 or -1.". However if there is a decryption BIO in the chain, requesting the reading of 0 bytes (by setting the "len" parameter to 0) results in a return value of 1, indicating that 1 byte was actually read, but - upon checking the passed in buffer's contents - turns not to be the case (as it should be). Now it is not documented whether passing 0 to as the value for "len" is legal and what the defined behavior (if any) should be in that case, but (looking at the code) if a NULL "buf" value is passed to enc_read() (thus BIO_read()) it will always return 0 (including when "len" is 0), see [2]. It seems to me that enc_read() (thus BIO_read()) should always return 0 if the value of "len" is 0 (regardless of whether "buf" is NULL or not), and in fact that seems to be the behavior for enc_write() [3]. Attached is a small test program demonstrating the issue (tested against the latest 1.x OpenSSL). Sincerely, Istvan Noszticzius RightNow/Oracle development [1] "int BIO_read(BIO *b, void *buf, int len)": https://www.openssl.org/docs/crypto/BIO_read.html [2] line 148 of https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/bio_enc.c [3] line 258 of https://git.openssl.org/gitweb/?p=openssl.git;a=blob;f=crypto/evp/bio_enc.c -------------- next part -------------- #include #include #include int main(int argc, char** argv) { unsigned char encrypted_buffer[16+1] = "\xea\xde\x4d\xb3\xaf\xa2\x03\x20\x0b\x45\xdd\x82\x0e\xa9\x38\x26"; unsigned char read_buffer[16+1] = { 0 }; unsigned char key[] ="\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00\x00"; unsigned char iv[] = "\x00\x00\x00\x00\x00\x00\x00\x00"; int read_bytes; ERR_load_crypto_strings(); OpenSSL_add_all_algorithms(); BIO* bio_mem = BIO_new_mem_buf(encrypted_buffer, sizeof(encrypted_buffer)-1); BIO* bio_dec = BIO_new(BIO_f_cipher()); BIO_set_cipher(bio_dec, EVP_get_cipherbyname("des-ede3-cbc"), key, iv, 0); bio_dec = BIO_push(bio_dec, bio_mem); read_bytes = BIO_read(bio_dec, read_buffer, 0); // Reading 0 bytes printf("read bytes: %d (data: \"%s\")\n", read_bytes, read_buffer); // read_bytes is 1 (but no bytes were actually read) return(0); } From rt at openssl.org Sat Dec 13 07:15:32 2014 From: rt at openssl.org (Paul A. Steckler via RT) Date: Sat, 13 Dec 2014 08:15:32 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: Please note that in the testlog I had attached to my earlier message, there was a "bad decrypt" error message for des-ede-cbc. That's not an issue for me, particularly, but it may be for others! -- Paul On Fri, Dec 12, 2014 at 11:03 AM, Paul A. Steckler wrote: > Hi, > > I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured > with some xxx_DEBUG > flags, which results in a compile failure in ssl/t1_enc.c. See the > attached testlog for > the exact flags used. > > Application details: N/A > > Problem Description: > > These compile-time (warnings and) errors: > -- > t1_enc.c: In function ?tls1_enc?: > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?long unsigned int? [-Wformat=] > ds->cipher->iv_len); > ^ > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 5 has type ?long unsigned int? [-Wformat=] > t1_enc.c: In function ?tls1_mac?: > t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) > {unsigned int z; for (z=0; z ",mac_sec[z]); printf("\n"); } > ^ > t1_enc.c:1075:59: note: each undeclared identifier is reported only > once for each function it appears in > t1_enc.c:1079:44: error: ?buf? undeclared (first use in this function) > {int z; for (z=0; z<5; z++) printf("%02X ",buf[z]); printf("\n"); } > ^ > t1_enc.c: In function ?tls1_export_keying_material?: > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?size_t? [-Wformat=] > printf ("tls1_export_keying_material(%p,%p,%d,%s,%d,%p,%d)\n", s, > out, olen, label, llen, context, contextlen); > ^ > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 6 has type ?size_t? [-Wformat=] > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 8 has type ?size_t? [-Wformat=] > -- > > Stack traceback: N/A > > -- Paul From rt at openssl.org Sat Dec 13 14:49:16 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Sat, 13 Dec 2014 15:49:16 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Thanks! I apply patch and run test robot. On monday will send to you results. 2014-12-12 19:13 GMT+03:00 Matt Caswell via RT : > > On Wed Dec 10 10:08:48 2014, v.badalyan at open-bs.ru wrote: > > Also valgrind output > > > > ==17767== Thread 37: > > ==17767== Source and > > destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, > > 4294967209) > ^^^^^^^^^^^^ This is interesting. That equates to -87. I think there is a > signed/unsigned conversion issue going on here. > > I have another patch. It is cummulative on the last one (i.e. apply the > first > one, and then apply this one on top). Keep your other change too (although > I > think that is an unrelated problem). > > Let me know how you get on. > > Matt > > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Mon Dec 15 11:35:06 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Mon, 15 Dec 2014 12:35:06 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Hello. We got openssl assert on header len... sorry i can't send it to you becouse i delete screen log :( 2014-12-14 4:07 GMT+03:00 ???????? ??????? : > > We got openssl assert. > 13 ???. 2014 ?. 17:49 ???????????? "???????? ???????" < > v.badalyan at open-bs.ru> ???????: > > Thanks! >> I apply patch and run test robot. On monday will send to you results. >> >> 2014-12-12 19:13 GMT+03:00 Matt Caswell via RT : >>> >>> On Wed Dec 10 10:08:48 2014, v.badalyan at open-bs.ru wrote: >>> > Also valgrind output >>> > >>> > ==17767== Thread 37: >>> > ==17767== Source and >>> > destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, >>> > 4294967209) >>> ^^^^^^^^^^^^ This is interesting. That equates to -87. I think there is a >>> signed/unsigned conversion issue going on here. >>> >>> I have another patch. It is cummulative on the last one (i.e. apply the >>> first >>> one, and then apply this one on top). Keep your other change too >>> (although I >>> think that is an unrelated problem). >>> >>> Let me know how you get on. >>> >>> Matt >>> >>> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Mon Dec 15 12:19:39 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Mon, 15 Dec 2014 13:19:39 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: On vagrind we got this ==48882== Thread 40: ==48882== Invalid write of size 8 ==48882== at 0x4A0B4BC: memset (vg_replace_strmem.c:1094) ==48882== by 0x34354DAB63: BUF_MEM_grow_clean (buffer.c:152) ==48882== by 0x34354DC512: mem_write (bss_mem.c:189) ==48882== by 0x34354DB746: BIO_write (bio_lib.c:247) ==48882== by 0x34354DE870: buffer_ctrl (bf_buff.c:404) ==48882== by 0x343583FA48: dtls1_do_write (d1_both.c:323) ==48882== by 0x3435838DF6: dtls1_accept (d1_srvr.c:426) ==48882== by 0x343583D85C: dtls1_read_bytes (d1_pkt.c:787) ==48882== by 0x3435827ECF: ssl3_read_internal (s3_lib.c:4273) ==48882== by 0x20CCFEF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) ==48882== by 0x20CD031E: rtp_recvfrom (res_rtp_asterisk.c:2094) ==48882== by 0x20CD9620: ast_rtp_read (res_rtp_asterisk.c:4127) ==48882== by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) ==48882== by 0x10B93838: sip_rtp_read (chan_sip.c:8198) ==48882== by 0x10B93FE7: sip_read (chan_sip.c:8295) ==48882== Address 0x570f138 is 2,120 bytes inside a block of size 2,392 free'd ==48882== at 0x4A06BE4: free (vg_replace_malloc.c:473) ==48882== by 0x343546AD62: CRYPTO_realloc_clean (mem.c:377) ==48882== by 0x34354DAAE5: BUF_MEM_grow_clean (buffer.c:166) ==48882== by 0x34354DC512: mem_write (bss_mem.c:189) ==48882== by 0x34354DB746: BIO_write (bio_lib.c:247) ==48882== by 0x34354DE870: buffer_ctrl (bf_buff.c:404) ==48882== by 0x343583FA48: dtls1_do_write (d1_both.c:323) ==48882== by 0x3435838DF6: dtls1_accept (d1_srvr.c:426) ==48882== by 0x20CCE998: dtls_perform_handshake (res_rtp_asterisk.c:1584) ==48882== by 0x20CCEA89: ast_rtp_on_ice_complete (res_rtp_asterisk.c:1610) ==48882== by 0x20CE0DAC: on_timer (in /usr/lib/asterisk/modules/res_rtp_asterisk.so) ==48882== by 0x20D0FB6D: pj_timer_heap_poll (in /usr/lib/asterisk/modules/res_rtp_asterisk.so) ==48882== by 0x20CCED58: timer_worker_thread (res_rtp_asterisk.c:1696) ==48882== by 0x20D0109A: thread_main (in /usr/lib/asterisk/modules/res_rtp_asterisk.so) ==48882== by 0x37CA2079D0: start_thread (pthread_create.c:301) 2014-12-15 14:34 GMT+03:00 ???????? ??????? : > > Hello. We got openssl assert on header len... sorry i can't send it to you > becouse i delete screen log :( > > 2014-12-14 4:07 GMT+03:00 ???????? ??????? : >> >> We got openssl assert. >> 13 ???. 2014 ?. 17:49 ???????????? "???????? ???????" < >> v.badalyan at open-bs.ru> ???????: >> >> Thanks! >>> I apply patch and run test robot. On monday will send to you results. >>> >>> 2014-12-12 19:13 GMT+03:00 Matt Caswell via RT : >>>> >>>> On Wed Dec 10 10:08:48 2014, v.badalyan at open-bs.ru wrote: >>>> > Also valgrind output >>>> > >>>> > ==17767== Thread 37: >>>> > ==17767== Source and >>>> > destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, >>>> > 4294967209) >>>> ^^^^^^^^^^^^ This is interesting. That equates to -87. I think there is >>>> a >>>> signed/unsigned conversion issue going on here. >>>> >>>> I have another patch. It is cummulative on the last one (i.e. apply the >>>> first >>>> one, and then apply this one on top). Keep your other change too >>>> (although I >>>> think that is an unrelated problem). >>>> >>>> Let me know how you get on. >>>> >>>> Matt >>>> >>>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Mon Dec 15 12:39:43 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Mon, 15 Dec 2014 13:39:43 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Got assert d1_both.c(296): OpenSSL internal error, assertion failed: s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH 2014-12-15 15:19 GMT+03:00 ???????? ??????? : > > On vagrind we got this > > ==48882== Thread 40: > ==48882== Invalid write of size 8 > ==48882== at 0x4A0B4BC: memset (vg_replace_strmem.c:1094) > ==48882== by 0x34354DAB63: BUF_MEM_grow_clean (buffer.c:152) > ==48882== by 0x34354DC512: mem_write (bss_mem.c:189) > ==48882== by 0x34354DB746: BIO_write (bio_lib.c:247) > ==48882== by 0x34354DE870: buffer_ctrl (bf_buff.c:404) > ==48882== by 0x343583FA48: dtls1_do_write (d1_both.c:323) > ==48882== by 0x3435838DF6: dtls1_accept (d1_srvr.c:426) > ==48882== by 0x343583D85C: dtls1_read_bytes (d1_pkt.c:787) > ==48882== by 0x3435827ECF: ssl3_read_internal (s3_lib.c:4273) > ==48882== by 0x20CCFEF4: __rtp_recvfrom (res_rtp_asterisk.c:2019) > ==48882== by 0x20CD031E: rtp_recvfrom (res_rtp_asterisk.c:2094) > ==48882== by 0x20CD9620: ast_rtp_read (res_rtp_asterisk.c:4127) > ==48882== by 0x5529D2: ast_rtp_instance_read (rtp_engine.c:314) > ==48882== by 0x10B93838: sip_rtp_read (chan_sip.c:8198) > ==48882== by 0x10B93FE7: sip_read (chan_sip.c:8295) > ==48882== Address 0x570f138 is 2,120 bytes inside a block of size 2,392 > free'd > ==48882== at 0x4A06BE4: free (vg_replace_malloc.c:473) > ==48882== by 0x343546AD62: CRYPTO_realloc_clean (mem.c:377) > ==48882== by 0x34354DAAE5: BUF_MEM_grow_clean (buffer.c:166) > ==48882== by 0x34354DC512: mem_write (bss_mem.c:189) > ==48882== by 0x34354DB746: BIO_write (bio_lib.c:247) > ==48882== by 0x34354DE870: buffer_ctrl (bf_buff.c:404) > ==48882== by 0x343583FA48: dtls1_do_write (d1_both.c:323) > ==48882== by 0x3435838DF6: dtls1_accept (d1_srvr.c:426) > ==48882== by 0x20CCE998: dtls_perform_handshake > (res_rtp_asterisk.c:1584) > ==48882== by 0x20CCEA89: ast_rtp_on_ice_complete > (res_rtp_asterisk.c:1610) > ==48882== by 0x20CE0DAC: on_timer (in > /usr/lib/asterisk/modules/res_rtp_asterisk.so) > ==48882== by 0x20D0FB6D: pj_timer_heap_poll (in > /usr/lib/asterisk/modules/res_rtp_asterisk.so) > ==48882== by 0x20CCED58: timer_worker_thread (res_rtp_asterisk.c:1696) > ==48882== by 0x20D0109A: thread_main (in > /usr/lib/asterisk/modules/res_rtp_asterisk.so) > ==48882== by 0x37CA2079D0: start_thread (pthread_create.c:301) > > > 2014-12-15 14:34 GMT+03:00 ???????? ??????? : >> >> Hello. We got openssl assert on header len... sorry i can't send it to >> you becouse i delete screen log :( >> >> 2014-12-14 4:07 GMT+03:00 ???????? ??????? : >>> >>> We got openssl assert. >>> 13 ???. 2014 ?. 17:49 ???????????? "???????? ???????" < >>> v.badalyan at open-bs.ru> ???????: >>> >>> Thanks! >>>> I apply patch and run test robot. On monday will send to you results. >>>> >>>> 2014-12-12 19:13 GMT+03:00 Matt Caswell via RT : >>>>> >>>>> On Wed Dec 10 10:08:48 2014, v.badalyan at open-bs.ru wrote: >>>>> > Also valgrind output >>>>> > >>>>> > ==17767== Thread 37: >>>>> > ==17767== Source and >>>>> > destination overlap in memcpy(0x253bfcbd, 0x7e9c51b, >>>>> > 4294967209) >>>>> ^^^^^^^^^^^^ This is interesting. That equates to -87. I think there >>>>> is a >>>>> signed/unsigned conversion issue going on here. >>>>> >>>>> I have another patch. It is cummulative on the last one (i.e. apply >>>>> the first >>>>> one, and then apply this one on top). Keep your other change too >>>>> (although I >>>>> think that is an unrelated problem). >>>>> >>>>> Let me know how you get on. >>>>> >>>>> Matt >>>>> >>>>> >>>> >>>> -- >>>> ? ?????????, >>>> ??????? ???????? ????????? >>>> >>>> ??? "???????? ??????-???????" >>>> ??????????? ???????? >>>> +7 (495) 666-0-111 >>>> http://www.open-bs.ru >>>> >>> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Mon Dec 15 13:54:46 2014 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 15 Dec 2014 14:54:46 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> Message-ID: On Friday 05 December 2014 15:18:30 you wrote: > When discussing this issue, my colleague Hubert Kario made me aware of a > flag offered by e.g. the openssl s_client utility: "-trusted_first". > When using -trusted_first, the server verification works successfully in > the above scenario. > > Given that the suggestion is to change openssl's default behaviour, > changing openssl to use the -trusted_first mode by default might > potentially be a solution. However, it's not obvious if this mode could > have other side effects that are undesirable. > > Therefore I suggest to discuss which approach is best to support the > removal of legacy CAs, either by changing the default of the > -trusted_first setting, or by implementing another solution. I think it > would be good to find a solution that could be backported to the openssl > 1.0.1 branch. For what it's worth, I have tested the Alexa top 1 million servers with the -trusted_first option and haven't found a single server that looses its trusted status, on the other hand, good few percent of servers do gain it. That doesn't mean there aren't any (or that I haven't made a mistake in the tests), but I can't think of a CA structure that would validate correctly with old mode while not with the new mode (so at least the experiment matches theory). More specifically the test was done by setting X509_STORE_set_flags(store, X509_V_FLAG_TRUSTED_FIRST); during verification. Full code that I used for testing is available here: https://github.com/jvehent/cipherscan/blob/master/top1m/parse_CAs.c https://github.com/jvehent/cipherscan/blob/master/top1m/process-certificate-statistics.sh (the baseline was achieved by just commenting out the above mentioned line) -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From rsalz at akamai.com Mon Dec 15 14:23:26 2014 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 15 Dec 2014 09:23:26 -0500 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> > For what it's worth, I have tested the Alexa top 1 million servers with the - > trusted_first option and haven't found a single server that looses its trusted > status, on the other hand, good few percent of servers do gain it. It's worth a great deal. Thanks! I love fact-based analysis. :) From rt at openssl.org Mon Dec 15 14:23:35 2014 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 15 Dec 2014 15:23:35 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> Message-ID: > For what it's worth, I have tested the Alexa top 1 million servers with the - > trusted_first option and haven't found a single server that looses its trusted > status, on the other hand, good few percent of servers do gain it. It's worth a great deal. Thanks! I love fact-based analysis. :) From openssl-users at dukhovni.org Mon Dec 15 14:48:00 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 15 Dec 2014 14:48:00 +0000 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> Message-ID: <20141215144800.GS25666@mournblade.imrryr.org> On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote: > > For what it's worth, I have tested the Alexa top 1 million servers with the - > > trusted_first option and haven't found a single server that looses its trusted > > status, on the other hand, good few percent of servers do gain it. > > It's worth a great deal. Thanks! I love fact-based analysis. :) This can break DANE TLSA verification, because the site's designated trust anchor might no longer be in the shorter constructed chain. It won't break Postfix because it does not support PKIX-TA(0) or PKIX-EE(1), and with DANE-TA(2), Postfix disables all default CAs using only the wire chain and any full TA keys from DNS. However, it could break other applications. This might include applications that have specifically configured a short list of CAs to trust (perhaps just one for a particular peer, rather than the usual browser bundle). So this is an incompatible change, and cannot be made in a stable release (1.0.x). If this changes in master, this must be prominently listed in the release notes as an incompatible change. -- Viktor. From tmraz at redhat.com Mon Dec 15 16:24:03 2014 From: tmraz at redhat.com (Tomas Mraz) Date: Mon, 15 Dec 2014 17:24:03 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <20141215144800.GS25666@mournblade.imrryr.org> References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> <20141215144800.GS25666@mournblade.imrryr.org> Message-ID: <1418660643.31261.25.camel@vespa.frost.loc> On Po, 2014-12-15 at 14:48 +0000, Viktor Dukhovni wrote: > On Mon, Dec 15, 2014 at 09:23:26AM -0500, Salz, Rich wrote: > > > > For what it's worth, I have tested the Alexa top 1 million servers with the - > > > trusted_first option and haven't found a single server that looses its trusted > > > status, on the other hand, good few percent of servers do gain it. > > > > It's worth a great deal. Thanks! I love fact-based analysis. :) > > This can break DANE TLSA verification, because the site's designated > trust anchor might no longer be in the shorter constructed chain. > > It won't break Postfix because it does not support PKIX-TA(0) or > PKIX-EE(1), and with DANE-TA(2), Postfix disables all default CAs > using only the wire chain and any full TA keys from DNS. Yes, this can be possibly broken by this change although I don't believe there are many (or any at all?) real world cases of such configuration. > However, it could break other applications. This might include > applications that have specifically configured a short list of CAs > to trust (perhaps just one for a particular peer, rather than the > usual browser bundle). Please enlighten me how this case could be broken by this change of default? If the trust anchor is not found in the trust list, the intermediate that is sent by the peer is followed anyway. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From openssl-users at dukhovni.org Mon Dec 15 16:32:42 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 15 Dec 2014 16:32:42 +0000 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <1418660643.31261.25.camel@vespa.frost.loc> References: <1417696415.31613.83.camel@kuix.de> <94582507.FVCc2Qj4GV@pintsize.usersys.redhat.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54B7CB72@USMBX1.msg.corp.akamai.com> <20141215144800.GS25666@mournblade.imrryr.org> <1418660643.31261.25.camel@vespa.frost.loc> Message-ID: <20141215163242.GW25666@mournblade.imrryr.org> On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote: > > This can break DANE TLSA verification, because the site's designated > > trust anchor might no longer be in the shorter constructed chain. > > > > [Postfix not affected] > > Please enlighten me how this case could be broken by this change of > default? If the trust anchor is not found in the trust list, the > intermediate that is sent by the peer is followed anyway. Yes, when a smaller list of trust anchors is employed the "trusted-first" change does no harm, sorry about any confusion. The DANE TLSA issue stands. DANE TLSA PKIX-TA(0) records can designate the digest of a trust anchor selected by the server operator. When TLS server transmits a corresponding certificate chain it may not be safe to replace that chain with a shorter chain, because the shorter chain may not employ the designated trust anchor, causing DANE TLSA checks to fail. -- Viktor. From rt at openssl.org Mon Dec 15 17:50:33 2014 From: rt at openssl.org (Lawrence via RT) Date: Mon, 15 Dec 2014 18:50:33 +0100 Subject: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile In-Reply-To: <000201d0188f$9a6fc2f0$cf4f48d0$@codeaurora.org> References: <005f01d014ea$ad5c3b30$0814b190$@codeaurora.org> <20141211212401.GA32213@roeckx.be> <000201d0188f$9a6fc2f0$cf4f48d0$@codeaurora.org> Message-ID: Great, thanks. -----Original Message----- From: Kurt Roeckx via RT [mailto:rt at openssl.org] Sent: Thursday, December 11, 2014 1:24 PM To: lawrence at codeaurora.org Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile Yes, global variables used in signal handlers should be volatile. Kurt From rt at openssl.org Mon Dec 15 22:09:04 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 15 Dec 2014 23:09:04 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: I'm having a look at this (going through all xxx_DEBUG, might as well while I'm at it) On Fri Dec 12 20:06:48 2014, steck at stecksoft.com wrote: > Hi, > > I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured > with some xxx_DEBUG > flags, which results in a compile failure in ssl/t1_enc.c. See the > attached testlog for > the exact flags used. > > Application details: N/A > > Problem Description: > > These compile-time (warnings and) errors: > -- > t1_enc.c: In function ?tls1_enc?: > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?long unsigned int? [-Wformat=] > ds->cipher->iv_len); > ^ > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 5 has type ?long unsigned int? [-Wformat=] > t1_enc.c: In function ?tls1_mac?: > t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) > {unsigned int z; for (z=0; z ",mac_sec[z]); printf("\n"); } > ^ > t1_enc.c:1075:59: note: each undeclared identifier is reported only > once for each function it appears in > t1_enc.c:1079:44: error: ?buf? undeclared (first use in this function) > {int z; for (z=0; z<5; z++) printf("%02X ",buf[z]); printf("\n"); } > ^ > t1_enc.c: In function ?tls1_export_keying_material?: > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?size_t? [-Wformat=] > printf ("tls1_export_keying_material(%p,%p,%d,%s,%d,%p,%d)\n", s, > out, olen, label, llen, context, contextlen); > ^ > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 6 has type ?size_t? [-Wformat=] > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 8 has type ?size_t? [-Wformat=] > -- > > Stack traceback: N/A > > -- Paul -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 15 23:37:39 2014 From: rt at openssl.org (Paul A. Steckler via RT) Date: Tue, 16 Dec 2014 00:37:39 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: Thanks! -- Paul On Mon, Dec 15, 2014 at 2:09 PM, Richard Levitte via RT wrote: > I'm having a look at this (going through all xxx_DEBUG, might as well while I'm > at it) > > On Fri Dec 12 20:06:48 2014, steck at stecksoft.com wrote: >> Hi, >> >> I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured >> with some xxx_DEBUG >> flags, which results in a compile failure in ssl/t1_enc.c. See the >> attached testlog for >> the exact flags used. >> >> Application details: N/A >> >> Problem Description: >> >> These compile-time (warnings and) errors: >> -- >> t1_enc.c: In function ?tls1_enc?: >> t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, >> but argument 4 has type ?long unsigned int? [-Wformat=] >> ds->cipher->iv_len); >> ^ >> t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, >> but argument 5 has type ?long unsigned int? [-Wformat=] >> t1_enc.c: In function ?tls1_mac?: >> t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) >> {unsigned int z; for (z=0; z> ",mac_sec[z]); printf("\n"); } >> ^ >> t1_enc.c:1075:59: note: each undeclared identifier is reported only >> once for each function it appears in >> t1_enc.c:1079:44: error: ?buf? undeclared (first use in this function) >> {int z; for (z=0; z<5; z++) printf("%02X ",buf[z]); printf("\n"); } >> ^ >> t1_enc.c: In function ?tls1_export_keying_material?: >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 4 has type ?size_t? [-Wformat=] >> printf ("tls1_export_keying_material(%p,%p,%d,%s,%d,%p,%d)\n", s, >> out, olen, label, llen, context, contextlen); >> ^ >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 6 has type ?size_t? [-Wformat=] >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 8 has type ?size_t? [-Wformat=] >> -- >> >> Stack traceback: N/A >> >> -- Paul > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Mon Dec 15 23:39:23 2014 From: rt at openssl.org (Adam Langley via RT) Date: Tue, 16 Dec 2014 00:39:23 +0100 Subject: [openssl-dev] [openssl.org #3607] nistz256 is broken. In-Reply-To: References: <547CBF3D.6010309@openssl.org> <54888B7B.4040002@openssl.org> Message-ID: On Thu, Dec 11, 2014 at 3:30 PM, Adam Langley wrote: > Thanks. So far that version is good to ~1B random tests. I'll leave it > going until Monday. It's good for ~6B random tests. Of course, that's not as compelling for 64-bit code as it would be for 32-bit, but I think we can safely say that there aren't any low-hanging bugs left. Thanks Andy. Cheers AGL From hanno at hboeck.de Tue Dec 16 01:18:40 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 02:18:40 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes Message-ID: <20141216021840.5904747b@pc> Hi, Sorry for crossposting this to three lists but I feel this is a multi-software-issue and I feel all software involved need to find a way to resolve this. I feel the current software setting of tls server configs and browsers leads to the unoptimal result that often CBC modes are preferred over authenticated encryption GCM-modes. There seems to be widespread agreement that TLS-CBC-Modes are not optimal and should be avoided (Padding oracles, Lucky Thirteen etc.) Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM these days. However they have for some reason decided not to support AES-256 but only AES-128. This is in itself no problem because there is no reason to believe AES-128 is not safe. But it leads to the probably unintended consequence that often AES-256-CBC is preferred over AES-128-GCM. Take this scenario: * Server operator uses apache+openssl wiht cipher string "HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH". This seems reasonable. Only HIGH security ciphers and sort them by strength. * Browser (Chrome or Firefox) will take the first preferred cipher suite it supports. As it doesn't support AES-GCM-256 it will choose AES-CBC_256. What can be done to avoid this? a) First of all server operators can do more manual work and sort ciphers on their own. However it's probably not desired that every server operator needs to know the inner details of TLS. b) OpenSSL changes so that it considers GCM-modes always more secure than CBC modes and sorts them to the front. c) Browsers could start supporting AES-256-GCM d) Browsers could stop supporting AES-256-CBC Each of these would solve the issue, they don't exclude each other (in theory you could do all of them). I feel b) should happen anyway and probably one of c) or d). If browsers feel AES-128 is "good enough" they could just remove AES-256 support completely. If they feel they want AES-256 in the unlikely case that attacks against AES improve by a great margin then there is no reason not to support AES-256-GCM. It feels illogical to support AES-256, but only in its less secure mode. Thoughts? cu, -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rsalz at akamai.com Tue Dec 16 01:31:53 2014 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 15 Dec 2014 20:31:53 -0500 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216021840.5904747b@pc> References: <20141216021840.5904747b@pc> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F113@USMBX1.msg.corp.akamai.com> Is this a theoretical issue, or have you seen it in widespread use? I thought most servers these days picked what they wanted, and used the client ordering as a suggestion, at best. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From hanno at hboeck.de Tue Dec 16 01:43:03 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 02:43:03 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F113@USMBX1.msg.corp.akamai.com> References: <20141216021840.5904747b@pc> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F113@USMBX1.msg.corp.akamai.com> Message-ID: <20141216024303.385324d0@pc> On Mon, 15 Dec 2014 20:31:53 -0500 "Salz, Rich" wrote: > Is this a theoretical issue, or have you seen it in widespread use? www.openssl.org would be an example where you can see it live and real :-) -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From hanno at hboeck.de Tue Dec 16 02:02:29 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 03:02:29 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: References: <20141216021840.5904747b@pc> Message-ID: <20141216030229.2a919518@pc> On Mon, 15 Dec 2014 17:36:40 -0800 Ryan Sleevi wrote: > > > * Server operator uses apache+openssl wiht cipher string > > > "HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH". This seems reasonable. > > > Only HIGH security ciphers and sort them by strength. > > > * Browser (Chrome or Firefox) will take the first preferred cipher > > > suite it supports. As it doesn't support AES-GCM-256 it will > > > choose AES-CBC_256. > > > > This isn't an accurate description of the flow. > > The client advertises its set of ciphersuites in the client hello. The > server is responsible for choosing the ciphersuite used, and may take > either client priority into consideration (e.g. if the client is a > constrained device, it might intentionally prefer a > weaker-but-efficient algorithm; this was classically true for 3DES > and RC4) or it may ignore this and choose at the server level. For > example, with Apache, > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslhonorcipherorder Ah, sorry, of course you're right. My analysis of the situation was wrong, however it doesn't really change the outcome: There are a number of sites probably configured in good faith with secure settings that result in CBC being preferred over GCM. (But good to note that a quick fix is to disable SSLHonorCipherOrder on affected apache servers) -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From hanno at hboeck.de Tue Dec 16 02:15:41 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 03:15:41 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: References: <20141216021840.5904747b@pc> <20141216030229.2a919518@pc> Message-ID: <20141216031541.413d565a@pc> On Mon, 15 Dec 2014 18:07:15 -0800 Ryan Sleevi wrote: > I fear you may have misread again. > > SSLHonorCipherOrder is on by default, and respects the client > preferences. The mainstream clients generally prefer GCM over CBC, > ergo, honoring the cipher order is the right thing. > > By setting SSLHonorCipherOrder to false (disabling it), you set the > servers preference. It now becomes the server operator's > responsibility to configure the ciphersuites correctly, which gets > into the issues you were wanting to avoid. Reading apache doc tells me the opposite: "When choosing a cipher during an SSLv3 or TLSv1 handshake, normally the client's preference is used. If this directive is enabled, the server's preference will be used instead." > As Rich said, have you observed this in practice and looked into why? I have on my own servers and as I already wrote you can on see it on www.openssl.org. Having tested with not setting SSLHonorCipherOrder however causes other issues - some other browsers won't use FS ciphers then (notably some older IE versions and all mobile IEs - at least that's what the ssl labs test says). To reiterate the above said, I have two apache configs: SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH Result: GCM in chrome/ff, but no FS in many IE versions (and A- on ssl labs). SSLProtocol -SSLv2 -SSLv3 +TLSv1 +TLSv1.1 +TLSv1.2 SSLHonorCipherOrder on SSLCipherSuite HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH Result: no GCM in chrome/ff, but FS in all ssl labs reference browsers (and A+ rating). -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Dec 16 03:09:53 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 03:09:53 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216021840.5904747b@pc> References: <20141216021840.5904747b@pc> Message-ID: <20141216030952.GF25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote: > Firefox and Chrome support authenticated encryption via TLS 1.2 and GCM > these days. However they have for some reason decided not to support > AES-256 but only AES-128. In which case, they will never use AES-256, and yet: > This is in itself no problem because there is > no reason to believe AES-128 is not safe. But it leads to the probably > unintended consequence that often AES-256-CBC is preferred over > AES-128-GCM. you claim that somehow AES-256 is used anyway. This is simply wrong. > Take this scenario: > * Server operator uses apache+openssl wiht cipher string > "HIGH:!MEDIUM:!LOW:!aNULL at STRENGTH". This seems reasonable. Only HIGH This is a cipherstring with great redundancy and a typo. What you meant was: DEFAULT:!EXPORT:!LOW:!MEDIUM which is simpler and harder to screw up (subtracting from DEFAULT is the safest approach for most users, building up from nothing is error-prone). > * Browser (Chrome or Firefox) will take the first preferred cipher > suite it supports. As it doesn't support AES-GCM-256 it will choose > AES-CBC_256. The server chooses the client's best cipher (from client's preference order or its own). Not the other way around. > What can be done to avoid this? Since you've got the wrong end of the stick, there's not much to discuss. -- Viktor. From hanno at hboeck.de Tue Dec 16 03:23:24 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 04:23:24 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216030952.GF25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <20141216030952.GF25666@mournblade.imrryr.org> Message-ID: <20141216042324.019b667e@pc> On Tue, 16 Dec 2014 03:09:53 +0000 Viktor Dukhovni wrote: > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote: > > > Firefox and Chrome support authenticated encryption via TLS 1.2 and > > GCM these days. However they have for some reason decided not to > > support AES-256 but only AES-128. > > In which case, they will never use AES-256, and yet: No, you understood that wrong: They decided to not support AES-256 for CGM. For CBC they support both 128/256. > This is a cipherstring with great redundancy and a typo. What you > meant was: The cipher string doesn't really matter, it happens with every setting where you enable AES CBC/GCM ciphers in both 128/256 bit setting. And yes, my initial mail was a bit confused (server chooses, not client), still the result is the same: For very common settings it happens that browsers choose cbc if gcm would be available (just point chrome to https://www.openssl.org to see it). -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Dec 16 04:53:11 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 04:53:11 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216042324.019b667e@pc> References: <20141216021840.5904747b@pc> <20141216030952.GF25666@mournblade.imrryr.org> <20141216042324.019b667e@pc> Message-ID: <20141216045310.GG25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote: > > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote: > > > > > Firefox and Chrome support authenticated encryption via TLS 1.2 and > > > GCM these days. However they have for some reason decided not to > > > support AES-256 but only AES-128. > > > > In which case, they will never use AES-256, and yet: > > No, you understood that wrong: They decided to not support AES-256 for > CGM. For CBC they support both 128/256. In that case indeed many servers will choose CBC at 256 bits over GCM at 128. This is a browser configuration issue, and should be addressed there. > And yes, my initial mail was a bit confused (server chooses, not > client), still the result is the same: For very common settings it > happens that browsers choose cbc if gcm would be available (just > point chrome to https://www.openssl.org to see it). The browsers need to fix their settings, but there are many competing factors here, and perhaps they have good reasons for the choices they made. -- Viktor. From philipp_subx at redfish-solutions.com Tue Dec 16 06:18:31 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Mon, 15 Dec 2014 23:18:31 -0700 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format Message-ID: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> Is there an easy way to get at the parameter ?y? (DSA->pub_key, which is a BIGNUM *) in ASN.1 format? (See (2) below?) Better yet, how to take that and pass it to ASN_item_digest()? Also, there?s some confusion (at least for me) about what constitutes DSAPublicKey. According to RFC-5912 you have: pk-dsa PUBLIC-KEY ::= { IDENTIFIER id-dsa KEY DSAPublicKey PARAMS TYPE DSA-Params ARE inheritable -- Private key format not in this module -- CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, cRLSign } } id-dsa OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } DSA-Params ::= SEQUENCE { p INTEGER, q INTEGER, g INTEGER } DSAPublicKey ::= INTEGER -- public key, y so I?d assume that i2d_DSAPublicKey() would generate a DER string containing the serialization of a single ASN.1 object, i.e. the INTEGER containing ?y? or dsa->pub_key as the serialized ASN representation of that BIGNUM. Alas, it doesn?t. If I run test/dsatest for instance and I write out the generated DSA key, then parse it, I get: .++++++++++++++++++++++++++++++++++++++++++++++++++* ...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++* seed D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3 counter=105 h=2 P: 00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68: 69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d: 78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac: 32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36: ee:31:c8:02:91 Q: 00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30: f4:8e:da:ce:91:5f G: 62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5: 00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce: 2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21: 92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53: e6:d7:88:02 as the output of the program, and: $ openssl asn1parse -in dsa.der -inform DER -i 0:d=0 hl=3 l= 222 cons: SEQUENCE 3:d=1 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA 69:d=1 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291 136:d=1 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F 159:d=1 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802 $ is the result of calling i2d_DSAPublicKey() and writing that to a file. Calling i2d_DSA_PUBKEY_fp() results in something else: $ openssl asn1parse -in dsa5.der -inform DER -i 0:d=0 hl=3 l= 240 cons: SEQUENCE 3:d=1 hl=3 l= 168 cons: SEQUENCE 6:d=2 hl=2 l= 7 prim: OBJECT :dsaEncryption 15:d=2 hl=3 l= 156 cons: SEQUENCE 18:d=3 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291 85:d=3 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F 108:d=3 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802 174:d=1 hl=2 l= 67 prim: BIT STRING $ Using dumpasn1 I find out that the BIT STRING at the end is actually: $ dumpasn1 -a -d -z -h -l dsa5.der <30 81 F0> 0 240: SEQUENCE { <30 81 A8> 3 168: . SEQUENCE { <06 07> 6 7: . . OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) : . . . (ANSI X9.57 algorithm) <30 81 9C> 15 156: . . SEQUENCE { <02 41> 18 65: . . . INTEGER : . . . . 00 8D F2 A4 94 49 22 76 AA 3D 25 75 9B B0 68 69 : . . . . CB EA C0 D8 3A FB 8D 0C F7 CB B8 32 4F 0D 78 82 : . . . . E5 D0 76 2F C5 B7 21 0E AF C2 E9 AD AC 32 AB 7A : . . . . AC 49 69 3D FB F8 37 24 C2 EC 07 36 EE 31 C8 02 : . . . . 91 <02 15> 85 21: . . . INTEGER : . . . . 00 C7 73 21 8C 73 7E C8 EE 99 3B 4F 2D ED 30 F4 : . . . . 8E DA CE 91 5F <02 40> 108 64: . . . INTEGER : . . . . 62 6D 02 78 39 EA 0A 13 41 31 63 A5 5B 4C B5 00 : . . . . 29 9D 55 22 95 6C EF CB 3B FF 10 F3 99 CE 2C 2E : . . . . 71 CB 9D E5 FA 24 BA BF 58 E5 B7 95 21 92 5C 9C : . . . . C4 2E 9F 6F 46 4B 08 8C C5 72 AF 53 E6 D7 88 02 : . . . } : . . } <03 43> 174 67: . BIT STRING, encapsulates { <02 40> 177 64: . . INTEGER : . . . 18 CF 7F 66 E2 32 21 AE A1 4D B9 00 DA 06 BE 46 : . . . A9 1D F1 13 D4 90 C3 C6 A0 C5 7E EA EE 56 DF 1E : . . . 90 59 A5 41 44 5C FC BE 1B 63 E8 19 71 99 C0 C9 : . . . FD 25 A7 CC E3 35 4C C1 07 7D 57 7C 31 12 A6 CA : . . } : . } 0 warnings, 0 errors. $ which is DSA-Params (p, q, g) per RFC-5480. But I couldn?t find this construction anywhere. Oddly, though, if I define: int i2d_DSAPublicKey_fp(FILE *fp, DSA *dsa) { return ASN1_i2d_fp_of_const(DSA,i2d_DSAPublicKey,fp,dsa); } and call that, it correctly writes out ?y? (dsa->pub_key) as: $ openssl asn1parse -in dsa4.der -inform DER -i 0:d=0 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA $ which I?m happy about, but don?t quite understand. So, a few questions: (1) what?s the quick way to, given a DSA *, compute a hash (given an EVP_MD *) over dsa->pub_key as an ASN.1 primitive? I tried: ASN1_item_digest(ASN1_ITEM_ref(BIGNUM), mdtype, dsa->pub_key, md, mdlen); but it?s giving me highly dubious results. (2) where is the ASN.1 module definition which corresponds to the format used by i2d_DSA_PUBKEY_fp()? (3) is there a way to generate a pk-dsa serialization in the library or do I have to muster this by hand? (4) why does i2d_DSAPublicKey() give you its current results and not the DER representation of ?y? (dsa->pub_key)? Thanks, -Philip From Satish.KumarYarru at cognizant.com Tue Dec 16 10:53:38 2014 From: Satish.KumarYarru at cognizant.com (Satish.KumarYarru at cognizant.com) Date: Tue, 16 Dec 2014 10:53:38 +0000 Subject: [openssl-dev] Cipher Suites Message-ID: Hi, I am setting SSL client method as SSLv23_Client_method(). And i set the cipher suite using SSL_CTX_set_cipher_list() with cipher name as "RC4-MD5". But when I check the "Client Hello" packet, 2 cipher suites are going 1. TLS_RSA_WITH_RC4_128_MD5 (0x0004) 2. Unknown (0x00FF) Can any one tell me why this 0x00FF cipher suite is going in ClientHello? I want to block this Unknown cipher (0x00FF) going to server during handshake. Can anyone help me on how to block this 0xFF cipher suite? Regards, Satish This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Tue Dec 16 11:04:12 2014 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 16 Dec 2014 11:04:12 +0000 Subject: [openssl-dev] Cipher Suites In-Reply-To: References: Message-ID: On 16 December 2014 at 10:53, wrote: > > But when I check the "Client Hello" packet, 2 cipher suites are going > > Can any one tell me why this 0x00FF cipher suite is going in ClientHello? > > I want to block this Unknown cipher (0x00FF) going to server during > handshake. > > Can anyone help me on how to block this 0xFF cipher suite? > > > It's not a cipher suite. It's the TLS_EMPTY_RENEGOTIATION_INFO_SCSV from RFC 5746. It will never be negotiated. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Dec 16 11:46:44 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 16 Dec 2014 12:46:44 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: On Mon Dec 15 13:39:43 2014, v.badalyan at open-bs.ru wrote: > Got assert > d1_both.c(296): OpenSSL internal error, assertion failed: s->init_num == > (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > To confirm: you did retain your change to check the return value from dtls1_output_cert_chain? The official patch for that issue is here: https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9beb948c0dae6056caddf46a9aa099e18905d184 Matt From hkario at redhat.com Tue Dec 16 14:02:22 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 15:02:22 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <20141215163242.GW25666@mournblade.imrryr.org> References: <1418660643.31261.25.camel@vespa.frost.loc> <20141215163242.GW25666@mournblade.imrryr.org> Message-ID: <3595461.LrVInOj3RS@pintsize.usersys.redhat.com> On Monday 15 December 2014 16:32:42 Viktor Dukhovni wrote: > On Mon, Dec 15, 2014 at 05:24:03PM +0100, Tomas Mraz wrote: > > > This can break DANE TLSA verification, because the site's designated > > > trust anchor might no longer be in the shorter constructed chain. > > > > > > [Postfix not affected] > > > > Please enlighten me how this case could be broken by this change of > > default? If the trust anchor is not found in the trust list, the > > intermediate that is sent by the peer is followed anyway. > > The DANE TLSA issue stands. > > DANE TLSA PKIX-TA(0) records can designate the digest of a trust > anchor selected by the server operator. When TLS server transmits > a corresponding certificate chain it may not be safe to replace > that chain with a shorter chain, because the shorter chain may not > employ the designated trust anchor, causing DANE TLSA checks to > fail. But then why would you use the PKIX chain builder with system root store? If you use DANE with CA digest, then the server needs to send all certificates, so you just need to validate the chain you have - you don't have to build it, you already have it built and in correct order, you just need to verify signatures and root digest. If you really want to use the PKIX builder and verifier (to workaround misconfigured servers), then you search for the cert with matching digest, load it as trusted, load other certs as untrusted and then try to verify peer certificate with such trust store. So it does affect only buggy DANE clients with a root that is signed by other root (and probably you could even argue about misconfigured DANE records - missing all valid trust anchors). -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From hkario at redhat.com Tue Dec 16 14:14:13 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 15:14:13 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216045310.GG25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <20141216042324.019b667e@pc> <20141216045310.GG25666@mournblade.imrryr.org> Message-ID: <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> On Tuesday 16 December 2014 04:53:11 Viktor Dukhovni wrote: > On Tue, Dec 16, 2014 at 04:23:24AM +0100, Hanno B?ck wrote: > > > On Tue, Dec 16, 2014 at 02:18:40AM +0100, Hanno B?ck wrote: > > > > Firefox and Chrome support authenticated encryption via TLS 1.2 and > > > > GCM these days. However they have for some reason decided not to > > > > support AES-256 but only AES-128. > > > > > > In which case, they will never use AES-256, and yet: > > No, you understood that wrong: They decided to not support AES-256 for > > CGM. For CBC they support both 128/256. > > In that case indeed many servers will choose CBC at 256 bits over > GCM at 128. This is a browser configuration issue, and should be > addressed there. > (...) > > The browsers need to fix their settings, but there are many competing > factors here, and perhaps they have good reasons for the choices > they made. No, this is problem with OpenSSL cipher order - it prefers key size over other factors - it should prefer AEAD and PFS ciphers before ordering on key size, doubly so that in practice you can't get anywhere near 256 bit level of security using TLS. we've talked about this before preferring AES-256 over AES-128 in Internet setting with Internet CAs just burns cycles for nought also, the reason why neither Firefox nor Chrome support AES-256-GCM is because NSS doesn't support SHA-384 PFS for TLSv1.2 - it's not a case of "just flipping a switch" -- Regards, Hubert Kario From hanno at hboeck.de Tue Dec 16 14:38:01 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 15:38:01 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> References: <20141216021840.5904747b@pc> <20141216042324.019b667e@pc> <20141216045310.GG25666@mournblade.imrryr.org> <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> Message-ID: <20141216153801.35f4ccca@pc> On Tue, 16 Dec 2014 15:14:13 +0100 Hubert Kario wrote: > No, this is problem with OpenSSL cipher order - it prefers key size > over other factors - it should prefer AEAD and PFS ciphers before > ordering on key size, doubly so that in practice you can't get > anywhere near 256 bit level of security using TLS. Agreed, this is one of the things I think that should happen. I got a reply on the chromium list that this is already so in boringssl. Code is in ssl/ssl_ciph.c If there is consensus that this should be ported I would try to isolate the neccessary patches from boringssl and submit them. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From hkario at redhat.com Tue Dec 16 14:42:43 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 15:42:43 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216153801.35f4ccca@pc> References: <20141216021840.5904747b@pc> <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> <20141216153801.35f4ccca@pc> Message-ID: <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> On Tuesday 16 December 2014 15:38:01 Hanno B?ck wrote: > On Tue, 16 Dec 2014 15:14:13 +0100 > > Hubert Kario wrote: > > No, this is problem with OpenSSL cipher order - it prefers key size > > over other factors - it should prefer AEAD and PFS ciphers before > > ordering on key size, doubly so that in practice you can't get > > anywhere near 256 bit level of security using TLS. > > Agreed, this is one of the things I think that should happen. > > I got a reply on the chromium list that this is already so in > boringssl. Code is in ssl/ssl_ciph.c > > If there is consensus that this should be ported I would try to isolate > the neccessary patches from boringssl and submit them. Last time we have discussed it[1], the only voices against were about removal of RC4 ciphers from default What is the exact ordering of ALL:COMPLEMENTOFALL in boringssl? 1 - http://openssl.6102.n7.nabble.com/Insecure-DEFAULT-cipher-set-td48995.html -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From sdaoden at yandex.com Tue Dec 16 14:45:02 2014 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 16 Dec 2014 15:45:02 +0100 Subject: [openssl-dev] There is no SSL_CTX_get_ciphers() (and .._get_cipher_list()) Message-ID: <20141216144502.YYnG46wj%sdaoden@yandex.com> I wonder about this interface oddity. There is int SSL_CTX_set_cipher_list(SSL_CTX *ctx, const char *str); int SSL_set_cipher_list(SSL *ssl, const char *str); but only STACK_OF(SSL_CIPHER) *SSL_get_ciphers(const SSL *ssl); const char *SSL_get_cipher_list(const SSL *ssl, int priority); Since practically all other functions exist in two version (for SSL_CTX*, for SSL*) this looks odd. Shall i post an enhancement request? --steffen From hanno at hboeck.de Tue Dec 16 15:18:09 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 16:18:09 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> References: <20141216021840.5904747b@pc> <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> <20141216153801.35f4ccca@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> Message-ID: <20141216161809.27985b23@pc> On Tue, 16 Dec 2014 15:42:43 +0100 Hubert Kario wrote: > Last time we have discussed it[1], the only voices against were about > removal of RC4 ciphers from default The boringssl patch was quite invasive, so I gave up to try to port their changes. But in essence it's quite trivial, just re-order stuff a bit. See attached patch. Output after my patch of ALL:COMPLEMENTOFALL: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC3-SHA:EDH-DSS-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:AECDH-AES256-SHA:AECDH-AES128-SHA:ADH-AES256-GCM-SHA384:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES128-SHA256:ADH-AES256-SHA:ADH-AES128-SHA:AECDH-DES-CBC3-SHA:ADH-SEED-SHA:ADH-CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES256-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:SEED-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-DES-CBC-SHA:IDEA-CBC-SHA:EXP-RC2-CBC-MD5:DES-CBC3-MD5:DES-CBC-MD5:IDEA-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:EXP-ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-NULL-SHA:ECDHE-ECDSA-NULL-SHA:AECDH-NULL-SHA:ECDH-RSA-NULL-SHA:ECDH-ECDSA-NULL-SHA:NULL-SHA256:NULL-SHA:NULL-MD5 To compare, output of plain openssl: ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA:SRP-AES-128-CBC-SHA:DHE-DSS-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3DES-EDE-CBC-SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:EDH-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC-SHA:EXP-EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC3-SHA:EDH-DSS-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:AECDH-AES256-SHA:AECDH-AES128-SHA:ADH-AES256-GCM-SHA384:ADH-AES128-GCM-SHA256:ADH-AES256-SHA256:ADH-AES128-SHA256:ADH-AES256-SHA:ADH-AES128-SHA:AECDH-DES-CBC3-SHA:ADH-SEED-SHA:ADH-CAMELLIA256-SHA:ADH-CAMELLIA128-SHA:ADH-DES-CBC3-SHA:ADH-DES-CBC-SHA:EXP-ADH-DES-CBC-SHA:ECDH-RSA-AES256-GCM-SHA384:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES256-GCM-SHA384:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RSA-AES256-SHA384:ECDH-RSA-AES128-SHA256:ECDH-ECDSA-AES256-SHA384:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES256-SHA:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES256-SHA:ECDH-ECDSA-AES128-SHA:ECDH-RSA-DES-CBC3-SHA:ECDH-ECDSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:SEED-SHA:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA:DES-CBC-SHA:EXP-DES-CBC-SHA:IDEA-CBC-SHA:EXP-RC2-CBC-MD5:DES-CBC3-MD5:DES-CBC-MD5:IDEA-CBC-MD5:EXP-RC2-CBC-MD5:RC2-CBC-MD5:PSK-AES256-CBC-SHA:PSK-AES128-CBC-SHA:PSK-3DES-EDE-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:AECDH-RC4-SHA:ADH-RC4-MD5:EXP-ADH-RC4-MD5:ECDH-RSA-RC4-SHA:ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:EXP-RC4-MD5:EXP-RC4-MD5:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-NULL-SHA:ECDHE-ECDSA-NULL-SHA:AECDH-NULL-SHA:ECDH-RSA-NULL-SHA:ECDH-ECDSA-NULL-SHA:NULL-SHA256:NULL-SHA:NULL-MD5 -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-intelligent-ordering.patch Type: text/x-patch Size: 1126 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Tue Dec 16 15:27:47 2014 From: rt at openssl.org (Stephen Henson via RT) Date: Tue, 16 Dec 2014 16:27:47 +0100 Subject: [openssl-dev] [openssl.org #3633] Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE In-Reply-To: <20141212135242.beVW_JqY%sdaoden@yandex.com> References: <20141212135242.beVW_JqY%sdaoden@yandex.com> Message-ID: On Fri Dec 12 17:52:22 2014, sdaoden at yandex.com wrote: > Hello, > > while following Rich Salz's suggestion to make use of > CONF_modules_load_file() i stumbled personally over the > restriction that only a global openssl.cnf seems to be supported. > There is no support for automatic loading of a $HOME/.openssl.cnf > on top of the global version. > > And whereas setting of $OPENSSL_CONF could be used and > communicated to users to achieve the desire, doing so actually > replaces inclusion of the global openssl.cnf, which likely not > results in the wanted effect!?! > While here, it doesn't seem possible to _forbid_ use of > $OPENSSL_CONF (from reading the manual)? > If that is true then i would ask for an additional > CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too. > While that could be done it would be a while before the new feature appeared in released versions of OpenSSL. You can get finger control over the configuration using existing APIs with current versions of OpenSSL. With CONF_modules_load_file() if the passed filename is not NULL then that value is used only. You only get the use of a local or system openssl.cnf if the filename passed is NULL. So if you pass the path to a "system" openssl.cnf it cannot be overridden by the OPENSSL_CONF environment variable. The function CONF_modules_load can be passed the CONF structure to use directly which doesn't need to come from a file at all. It could be from multiple files, hard coded data or something strange like the Window registry (if the appropriate code was written to add the data to the CONF structure). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Tue Dec 16 15:45:22 2014 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Dec 2014 10:45:22 -0500 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216161809.27985b23@pc> References: <20141216021840.5904747b@pc> <2569250.6RvL1jDLES@pintsize.usersys.redhat.com> <20141216153801.35f4ccca@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F27C@USMBX1.msg.corp.akamai.com> > The boringssl patch was quite invasive, so I gave up to try to port their > changes. We're working with the Boring folks to keep closer in sync so maybe something will happen in this area. From hkario at redhat.com Tue Dec 16 16:11:34 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 17:11:34 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216161809.27985b23@pc> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> Message-ID: <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> On Tuesday 16 December 2014 16:18:09 Hanno B?ck wrote: > On Tue, 16 Dec 2014 15:42:43 +0100 > > Hubert Kario wrote: > > Last time we have discussed it[1], the only voices against were about > > removal of RC4 ciphers from default > > The boringssl patch was quite invasive, so I gave up to try to port > their changes. > > But in essence it's quite trivial, just re-order stuff a bit. See > attached patch. > > > Output after my patch of ALL:COMPLEMENTOFALL: > To compare, output of plain openssl: they don't differ... but comparing that to what Fedora version of openssl outputs, then new order certainly makes things a bit better. there are few issues still - aRSA preferred before aECDSA - AES256 before AES128 in general - few export grade ciphers placed before secure ciphers - 3DES is placed arbitrarily I'd prefer not only change the order, but also say what was the intent and what is the preferred ordering (which keys are used for ordering), so that when new ciphers come, it will be more or less obvious where they should be placed -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From rt at openssl.org Tue Dec 16 16:27:13 2014 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Tue, 16 Dec 2014 17:27:13 +0100 Subject: [openssl-dev] [openssl.org #3633] Enhancement request: CONF_modules_load_file(): please add a CONF_MFLAGS_LOAD_USER_FILE In-Reply-To: <20141216162657.A3JkHHjQ%sdaoden@yandex.com> References: <20141212135242.beVW_JqY%sdaoden@yandex.com> <20141216162657.A3JkHHjQ%sdaoden@yandex.com> Message-ID: "Stephen Henson via RT" wrote: All i can parse from your answer is that the statement that is long in OpenSSL documentation and was referred to by Rich Salz (unless i'm mistaken) in a different #issue, namely the following paragraph from OPENSSL_config(3): It is strongly recommended that all new applications call OPENSSL_config() or the more sophisticated functions such as CONF_modules_load() during initialization (that is before starting any threads). By doing this an application does not need to keep track of all configuration options and some new functionality can be supported automatically. |On Fri Dec 12 17:52:22 2014, sdaoden at yandex.com wrote: |> Hello, |> |> while following Rich Salz's suggestion to make use of |> CONF_modules_load_file() i stumbled personally over the |> restriction that only a global openssl.cnf seems to be supported. |> There is no support for automatic loading of a $HOME/.openssl.cnf |> on top of the global version. |> |> And whereas setting of $OPENSSL_CONF could be used and |> communicated to users to achieve the desire, doing so actually |> replaces inclusion of the global openssl.cnf, which likely not |> results in the wanted effect!?! |> While here, it doesn't seem possible to _forbid_ use of |> $OPENSSL_CONF (from reading the manual)? |> If that is true then i would ask for an additional |> CONF_MFLAGS_NO_OPENSSL_CNF_ENV bit, too. |> | |While that could be done it would be a while before the new \ |feature appeared in |released versions of OpenSSL. You can get finger control over \ |the configuration |using existing APIs with current versions of OpenSSL. |With CONF_modules_load_file() if the passed filename is not NULL then that |value is used only. You only get the use of a local or system openssl.cnf if |the filename passed is NULL. So if you pass the path to a \ |"system" openssl.cnf |it cannot be overridden by the OPENSSL_CONF environment variable. How do i get a notion of the actual path in order to prevent that? I'd like the openssl-conf package provided openssl.cnf with the newest global protocol and cipher specifications, and i don't want noone to mess that up. Except that i want that a user may add something on top. Btw. i also once had a failed attempt with resource files, along the lines * [!/immutable/group] * [#10#/group/with/limit] * !immutable_entry=some value * (int)refresh_time=60 i.e., with things that were fixateable on a global level, even if a user provided his own ~/.xyrc. (With compiled-in default configs etc., it became much too bloated and never sprung into existence. But only a `!' prefix may be worthwile for something security related as OpenSSL is.) |The function CONF_modules_load can be passed the CONF structure \ |to use directly |which doesn't need to come from a file at all. It could be \ |from multiple files, |hard coded data or something strange like the Window registry (if the |appropriate code was written to add the data to the CONF structure). Wise words spoken. ("Could".) --steffen From deengert at gmail.com Tue Dec 16 16:40:29 2014 From: deengert at gmail.com (Douglas E Engert) Date: Tue, 16 Dec 2014 10:40:29 -0600 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format In-Reply-To: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> References: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> Message-ID: <5490607D.10509@gmail.com> On 12/16/2014 12:18 AM, Philip Prindeville wrote: > Is there an easy way to get at the parameter ?y? (DSA->pub_key, which is a BIGNUM *) in ASN.1 format? (See (2) below?) > > Better yet, how to take that and pass it to ASN_item_digest()? > > Also, there?s some confusion (at least for me) about what constitutes DSAPublicKey. According to RFC-5912 you have: > > pk-dsa PUBLIC-KEY ::= { > IDENTIFIER id-dsa > KEY DSAPublicKey > PARAMS TYPE DSA-Params ARE inheritable > -- Private key format not in this module -- > CERT-KEY-USAGE { digitalSignature, nonRepudiation, keyCertSign, > cRLSign } > } > > id-dsa OBJECT IDENTIFIER ::= { > iso(1) member-body(2) us(840) x9-57(10040) x9algorithm(4) 1 } > > DSA-Params ::= SEQUENCE { > p INTEGER, > q INTEGER, > g INTEGER > } > > DSAPublicKey ::= INTEGER -- public key, y > > > so I?d assume that i2d_DSAPublicKey() would generate a DER string containing the serialization of a single ASN.1 object, i.e. the INTEGER containing ?y? or dsa->pub_key as the serialized ASN representation of that BIGNUM. > > Alas, it doesn?t. I would assume it would do what you say. People confuse what is in a SubjectPublicKeyInfo which includes an algorithm oid, parameters and the public key. The same type of confusion can occur with ECC. PKCS#15 has ASN.1 definitions that might help, and it referes to ANSI X9 documents. > > If I run test/dsatest for instance and I write out the generated DSA key, then parse it, I get: > > .++++++++++++++++++++++++++++++++++++++++++++++++++* > ...+........+..+...+............+.+..+..........................................................................+++++++++++++++++++++++++++++++++++++++++++++++++++* > seed > D5014E4B 60EF2BA8 B6211B40 62BA3224 E0427DD3 > counter=105 h=2 > P: > 00:8d:f2:a4:94:49:22:76:aa:3d:25:75:9b:b0:68: > 69:cb:ea:c0:d8:3a:fb:8d:0c:f7:cb:b8:32:4f:0d: > 78:82:e5:d0:76:2f:c5:b7:21:0e:af:c2:e9:ad:ac: > 32:ab:7a:ac:49:69:3d:fb:f8:37:24:c2:ec:07:36: > ee:31:c8:02:91 > Q: > 00:c7:73:21:8c:73:7e:c8:ee:99:3b:4f:2d:ed:30: > f4:8e:da:ce:91:5f > G: > 62:6d:02:78:39:ea:0a:13:41:31:63:a5:5b:4c:b5: > 00:29:9d:55:22:95:6c:ef:cb:3b:ff:10:f3:99:ce: > 2c:2e:71:cb:9d:e5:fa:24:ba:bf:58:e5:b7:95:21: > 92:5c:9c:c4:2e:9f:6f:46:4b:08:8c:c5:72:af:53: > e6:d7:88:02 > > > as the output of the program, and: > > $ openssl asn1parse -in dsa.der -inform DER -i > 0:d=0 hl=3 l= 222 cons: SEQUENCE > 3:d=1 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA > 69:d=1 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291 > 136:d=1 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F > 159:d=1 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802 > $ It is not clear to me where the above is defined. > > is the result of calling i2d_DSAPublicKey() and writing that to a file. > > Calling i2d_DSA_PUBKEY_fp() results in something else: > > $ openssl asn1parse -in dsa5.der -inform DER -i > 0:d=0 hl=3 l= 240 cons: SEQUENCE > 3:d=1 hl=3 l= 168 cons: SEQUENCE > 6:d=2 hl=2 l= 7 prim: OBJECT :dsaEncryption > 15:d=2 hl=3 l= 156 cons: SEQUENCE > 18:d=3 hl=2 l= 65 prim: INTEGER :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736EE31C80291 > 85:d=3 hl=2 l= 21 prim: INTEGER :C773218C737EC8EE993B4F2DED30F48EDACE915F > 108:d=3 hl=2 l= 64 prim: INTEGER :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E6D78802 > 174:d=1 hl=2 l= 67 prim: BIT STRING > $ That appears to be a SubjectPublicKeyInfo (SPKI) , with algorithm ID, parameters, and the public key in the bit string. But as you say below, the bit string looks like a SPKI! In PKCS#15 there is: DSAPublicKeyChoice ::= CHOICE { raw INTEGER, spki SubjectPublicKeyInfo, -- See X.509. Must contain a public DSA key. ... } In PKCS#15 there is a choice like this for every type of public key. But DSAPublicKeyChoice is not part SPKI. An SPKI should not include a SPKI of itself. > > Using dumpasn1 I find out that the BIT STRING at the end is actually: > > $ dumpasn1 -a -d -z -h -l dsa5.der > <30 81 F0> > 0 240: SEQUENCE { > <30 81 A8> > 3 168: . SEQUENCE { > <06 07> > 6 7: . . OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) > : . . . (ANSI X9.57 algorithm) > <30 81 9C> > 15 156: . . SEQUENCE { > <02 41> > 18 65: . . . INTEGER > : . . . . 00 8D F2 A4 94 49 22 76 AA 3D 25 75 9B B0 68 69 > : . . . . CB EA C0 D8 3A FB 8D 0C F7 CB B8 32 4F 0D 78 82 > : . . . . E5 D0 76 2F C5 B7 21 0E AF C2 E9 AD AC 32 AB 7A > : . . . . AC 49 69 3D FB F8 37 24 C2 EC 07 36 EE 31 C8 02 > : . . . . 91 > <02 15> > 85 21: . . . INTEGER > : . . . . 00 C7 73 21 8C 73 7E C8 EE 99 3B 4F 2D ED 30 F4 > : . . . . 8E DA CE 91 5F > <02 40> > 108 64: . . . INTEGER > : . . . . 62 6D 02 78 39 EA 0A 13 41 31 63 A5 5B 4C B5 00 > : . . . . 29 9D 55 22 95 6C EF CB 3B FF 10 F3 99 CE 2C 2E > : . . . . 71 CB 9D E5 FA 24 BA BF 58 E5 B7 95 21 92 5C 9C > : . . . . C4 2E 9F 6F 46 4B 08 8C C5 72 AF 53 E6 D7 88 02 > : . . . } > : . . } > <03 43> > 174 67: . BIT STRING, encapsulates { > <02 40> > 177 64: . . INTEGER > : . . . 18 CF 7F 66 E2 32 21 AE A1 4D B9 00 DA 06 BE 46 > : . . . A9 1D F1 13 D4 90 C3 C6 A0 C5 7E EA EE 56 DF 1E > : . . . 90 59 A5 41 44 5C FC BE 1B 63 E8 19 71 99 C0 C9 > : . . . FD 25 A7 CC E3 35 4C C1 07 7D 57 7C 31 12 A6 CA > : . . } > : . } > > 0 warnings, 0 errors. > > $ > > which is DSA-Params (p, q, g) per RFC-5480. But I couldn?t find this construction anywhere. > > Oddly, though, if I define: > > int i2d_DSAPublicKey_fp(FILE *fp, DSA *dsa) > { > return ASN1_i2d_fp_of_const(DSA,i2d_DSAPublicKey,fp,dsa); > } > > and call that, it correctly writes out ?y? (dsa->pub_key) as: > > $ openssl asn1parse -in dsa4.der -inform DER -i > 0:d=0 hl=2 l= 64 prim: INTEGER :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3112A6CA > $ > > which I?m happy about, but don?t quite understand. > > So, a few questions: > > (1) what?s the quick way to, given a DSA *, compute a hash (given an EVP_MD *) over dsa->pub_key as an ASN.1 primitive? I tried: > > ASN1_item_digest(ASN1_ITEM_ref(BIGNUM), mdtype, dsa->pub_key, md, mdlen); > > but it?s giving me highly dubious results. > > > (2) where is the ASN.1 module definition which corresponds to the format used by i2d_DSA_PUBKEY_fp()? > > > (3) is there a way to generate a pk-dsa serialization in the library or do I have to muster this by hand? > > > (4) why does i2d_DSAPublicKey() give you its current results and not the DER representation of ?y? (dsa->pub_key)? > > > Thanks, > > -Philip > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -- Douglas E. Engert From hanno at hboeck.de Tue Dec 16 17:15:19 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 18:15:19 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> Message-ID: <20141216181519.0d0601f4@pc> On Tue, 16 Dec 2014 17:11:34 +0100 Hubert Kario wrote: > they don't differ... oh sorry, must've pasted the wrong string. But please ignore my first patch, I don't think this is optimal. I'll do another one later. What I think is a sane approach is to leave the current code mostly as it is, just add one further sorting step that will bring GCM ciphers in front of non-gcm ones. I think that should give the desired result. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Dec 16 17:17:01 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 17:17:01 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> Message-ID: <20141216171701.GH25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 05:11:34PM +0100, Hubert Kario wrote: > there are few issues still > - aRSA preferred before aECDSA > - AES256 before AES128 in general > - few export grade ciphers placed before secure ciphers > - 3DES is placed arbitrarily > > I'd prefer not only change the order, but also say what was the intent and > what is the preferred ordering (which keys are used for ordering), so that > when new ciphers come, it will be more or less obvious where they should be > placed In particular there MUST NOT be any fragile hand-tuning. All ordering needs to be based on general principles. One might for example say that any CBC cipher at 128+ bits gets a baseline sorting strength of 128 bits. One might then apply either "@STRENGTH" or "@SPEED" (new), the first of which adds "1" to any CBC cipher whose key is longer than 128-bits, the second to those that are equal to "128" bits. With AES AEAD the baseline could be "129", with similar "STRENGTH" vs. "SPEED" boosts. Which would ensure that AEAD at 128 beats CBC at 256. However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement, but some extensible algorithm. -- Viktor. From hkario at redhat.com Tue Dec 16 17:18:05 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 18:18:05 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216181519.0d0601f4@pc> References: <20141216021840.5904747b@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216181519.0d0601f4@pc> Message-ID: <2785581.KY7Imkjufy@pintsize.usersys.redhat.com> On Tuesday 16 December 2014 18:15:19 Hanno B?ck wrote: > On Tue, 16 Dec 2014 17:11:34 +0100 > > Hubert Kario wrote: > > they don't differ... > > oh sorry, must've pasted the wrong string. > > But please ignore my first patch, I don't think this is optimal. I'll > do another one later. > > What I think is a sane approach is to leave the current code mostly as > it is, just add one further sorting step that will bring GCM ciphers in > front of non-gcm ones. > I think that should give the desired result. to this specific issue, yes, but in general fixing ordering also with relation to PFS is a good idea -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic From rsalz at akamai.com Tue Dec 16 17:26:32 2014 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Dec 2014 12:26:32 -0500 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216171701.GH25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> > In particular there MUST NOT be any fragile hand-tuning. All ordering needs > to be based on general principles. This is not a universally-held view. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From hanno at hboeck.de Tue Dec 16 17:28:03 2014 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Tue, 16 Dec 2014 18:28:03 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216171701.GH25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> Message-ID: <20141216182803.0044e4a4@pc> On Tue, 16 Dec 2014 17:17:01 +0000 Viktor Dukhovni wrote: > However, where do we fit ChaCha20/Poly-1305? Again, not > hand-placement, but some extensible algorithm. How about this simpler criterion: AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with it. (this doesn't answer whether chacha20-poly1305 or aes-gcm should be considered "better", but I don't know if there is a clear consensus on that) -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From openssl-users at dukhovni.org Tue Dec 16 17:39:43 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 17:39:43 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216182803.0044e4a4@pc> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216182803.0044e4a4@pc> Message-ID: <20141216173942.GJ25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno B?ck wrote: > > However, where do we fit ChaCha20/Poly-1305? Again, not > > hand-placement, but some extensible algorithm. > > How about this simpler criterion: > AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with > it. That does not solve the problem of some folks wanting speed (preferring AES128 over AES256), and others safety (converse). > (this doesn't answer whether chacha20-poly1305 or aes-gcm should be > considered "better", but I don't know if there is a clear consensus on > that) Well, the "DEFAULT" and "ALL" cipherlists need to be sorted consistently (DEFAULT Is subset of ALL in the same relative order), so this question needs a default answer, if someone wants to tune that by hand, the rope is there... -- Viktor. From openssl-users at dukhovni.org Tue Dec 16 17:46:43 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 17:46:43 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216181519.0d0601f4@pc> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216181519.0d0601f4@pc> Message-ID: <20141216174643.GK25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 06:15:19PM +0100, Hanno B?ck wrote: > On Tue, 16 Dec 2014 17:11:34 +0100 > Hubert Kario wrote: > > > they don't differ... > > oh sorry, must've pasted the wrong string. > > But please ignore my first patch, I don't think this is optimal. I'll > do another one later. > > What I think is a sane approach is to leave the current code mostly as > it is, just add one further sorting step that will bring GCM ciphers in > front of non-gcm ones. > I think that should give the desired result. We don't need such a "sorting step". If you want "@STRENGTH" to put AEAD first, then adjust the strength ratings. We could define a few functions of (algorithm, keylength, mode) that return an effective strength. Some new keywords would choose an alternative effective strength function. There should be one (stable) sorting pass, and no after-the-fact reordering. -- Viktor. From nico at cryptonector.com Tue Dec 16 17:57:57 2014 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Dec 2014 11:57:57 -0600 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> Message-ID: <20141216175753.GB3241@localhost> On Tue, Dec 16, 2014 at 12:26:32PM -0500, Salz, Rich wrote: > > In particular there MUST NOT be any fragile hand-tuning. All ordering needs > > to be based on general principles. > > This is not a universally-held view. I think the key word is "fragile", not "hand-tuning". Subtracting (in local configuration) algorithms from a keyword denoting all known-strong algorithms is hand-tuning, but not fragile hand-tuning. Nico -- From rsalz at akamai.com Tue Dec 16 18:04:17 2014 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Dec 2014 13:04:17 -0500 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216175753.GB3241@localhost> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> <20141216175753.GB3241@localhost> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F348@USMBX1.msg.corp.akamai.com> > Subtracting (in local configuration) algorithms from a keyword denoting all > known-strong algorithms is hand-tuning, but not fragile hand-tuning. Three years ago RC4 was known-strong. Two years ago DES-CBC was known-strong. Now we only have AES-GCM. At what point do we think ChaCha/Poly is known-strong, and who gets to make that call? Dan? Adam? Who said "these are known-strong" and when did they say it, and are they still correct? And where and how does a system admin find those things out. From nico at cryptonector.com Tue Dec 16 17:55:37 2014 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Dec 2014 11:55:37 -0600 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216171701.GH25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> Message-ID: <20141216175532.GA3241@localhost> On Tue, Dec 16, 2014 at 05:17:01PM +0000, Viktor Dukhovni wrote: > In particular there MUST NOT be any fragile hand-tuning. All > ordering needs to be based on general principles. +1. > One might for example say that any CBC cipher at 128+ bits gets a > baseline sorting strength of 128 bits. One might then apply either > "@STRENGTH" or "@SPEED" (new), the first of which adds "1" to any > CBC cipher whose key is longer than 128-bits, the second to those > that are equal to "128" bits. > > With AES AEAD the baseline could be "129", with similar "STRENGTH" > vs. "SPEED" boosts. Which would ensure that AEAD at 128 beats CBC at 256. > > However, where do we fit ChaCha20/Poly-1305? Again, not hand-placement, > but some extensible algorithm. Any algorithm numeric strength assignments should be baked into the library, or perhaps configurable in a configuration file. The should not be known to applications. Ditto for any computaiton of overall strength of cipher-mode combinations. Internally using such numeric strength assignments is fine. In particular I want you to avoid the problem that Cyrus SASL had (and still has) with the "security strength factor (SSF)", where entire security mechanisms get boiled down to a single numeric strength factor even though a mechanism might negotiate cryptographic algorithms, and where applications end up hardcoding SSF values for things like Kerberos V5 (which has "SSF" of 56, because initially Kerberos V5 only supported 1DES). This is a horrible problem to have. Nico -- From nico at cryptonector.com Tue Dec 16 18:23:36 2014 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Dec 2014 12:23:36 -0600 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F348@USMBX1.msg.corp.akamai.com> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> <20141216175753.GB3241@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F348@USMBX1.msg.corp.akamai.com> Message-ID: <20141216182329.GC3241@localhost> On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote: > > Subtracting (in local configuration) algorithms from a keyword denoting all > > known-strong algorithms is hand-tuning, but not fragile hand-tuning. > > Three years ago RC4 was known-strong. Two years ago DES-CBC was > known-strong. Now we only have AES-GCM. At what point do we think > ChaCha/Poly is known-strong, and who gets to make that call? Dan? > Adam? Changing the internal relative strength weighings of these requires pushing out new code. Something that... happens all the time. I'm not against local configuration of these things as, say, a temporary override while waiting for patches. The configuration needs to be simple and not fragile. Subtracting from named sets of algorithms and sorting by desired attributes (speed, strength), is a non-fragile way to specify administrative preferences. Assiging numeric algorithm strength in a config file is fragile but acceptable for emergencies. > Who said "these are known-strong" and when did they say it, and are > they still correct? And where and how does a system admin find those > things out. This is why I'm advising against exposing any sort of numeric algorithm strength assessments to _applications_: once those are baked in in the application they can't be changed. I realize that there was no proposal to do so. However, any time numeric algorithm strength assessments are discussed is also a good time to warn others to avoid the SASL SSF mistake. Nico -- From openssl-users at dukhovni.org Tue Dec 16 18:26:50 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 18:26:50 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216175532.GA3241@localhost> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> Message-ID: <20141216182650.GM25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 11:55:37AM -0600, Nico Williams wrote: > Internally using such numeric strength assignments is fine. > > In particular I want you to avoid the problem that Cyrus SASL had (and > still has) with the "security strength factor (SSF)", where entire > security mechanisms get boiled down to a single numeric strength factor > even though a mechanism might negotiate cryptographic algorithms, and > where applications end up hardcoding SSF values for things like Kerberos > V5 (which has "SSF" of 56, because initially Kerberos V5 only supported > 1DES). This is a horrible problem to have. Internally OpenSSL has a multi-dimensional property matrix, and preferences between numerically equal ciphers are based on other properties. The (stable) numeric sorting just re-arranges blocks of ciphers already sorted by other means. Thus preference for PFS already puts kEECDH and kDHE ahead of kRSA for otherwise equally strong ciphers. When the user choose a group of ciphers to add to a cipherlist, the members of the group retain their relative order. However, there are interesting games that can be played with: aRSA:-kRSA:ALL:@STRENGTH (prefers kRSA over PFS). which perturb the order, because the most recenly removed elements end up at the top of the list when "ALL" is added. So the relative preferences of various properties can be changed. The SASL problem mostly does not bite OpenSSL, However, @STRENGTH (which is often needed) is not sufficiently tunable, it is not eas to prefer AES-128 with AEAD over 256 with CBC. For that we need some new mappings that produce slight different "effective" stengths. -- Viktor. From nico at cryptonector.com Tue Dec 16 18:43:13 2014 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Dec 2014 12:43:13 -0600 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216182650.GM25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> Message-ID: <20141216184311.GD3241@localhost> On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote: > Internally OpenSSL has a multi-dimensional property matrix, and > preferences between numerically equal ciphers are based on other > properties. The (stable) numeric sorting just re-arranges blocks > of ciphers already sorted by other means. Thus preference for PFS > already puts kEECDH and kDHE ahead of kRSA for otherwise equally > strong ciphers. > > When the user choose a group of ciphers to add to a cipherlist, > the members of the group retain their relative order. However, > there are interesting games that can be played with: > > aRSA:-kRSA:ALL:@STRENGTH > > (prefers kRSA over PFS). > > which perturb the order, because the most recenly removed elements > end up at the top of the list when "ALL" is added. So the relative > preferences of various properties can be changed. Iterating subtaction and addition seems like a fragile way to indicate preference. > The SASL problem mostly does not bite OpenSSL, However, @STRENGTH > (which is often needed) is not sufficiently tunable, it is not eas > to prefer AES-128 with AEAD over 256 with CBC. For that we need > some new mappings that produce slight different "effective" stengths. My preference would be: subtract undesired algorithms from a named set, then specify order of preference via some method other than iteratively adding and subtracting algorithms. Something like: DEFAULT:-FOO128:::PFS,AEAD,speed,strength (Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed, strength.) Preferences should affect the order in which cipher suites are advertised/picked, not which ones are advertised. Algorithms that are not desired should not be advertised/used. Nico -- From openssl-users at dukhovni.org Tue Dec 16 18:56:14 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 18:56:14 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216184311.GD3241@localhost> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> Message-ID: <20141216185614.GN25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 12:43:13PM -0600, Nico Williams wrote: > My preference would be: subtract undesired algorithms from a named set, > then specify order of preference via some method other than iteratively > adding and subtracting algorithms. Something like: > > DEFAULT:-FOO128:::PFS,AEAD,speed,strength > > (Whatever is in DEFAULT minus FOO128, sort by PFS, AEAD, speed, > strength.) I agree that iterative add/subtract reording is not for most mortals, however, the above is worse. Absolute preference for PFS regardless of key length seems unwise. Do you *really* want: ADH-DES-CBC-SHA SSLv3 Kx=DH Au=None Enc=DES(56) Mac=SHA1 ahead of a non-PFS AES-256? The effective strength MUST come first, but there need to be a few ways to squash "strong-enough" 128/256 ciphers so that other factors can dominate. One way to do that is to set an upper-bound on the effective bit length "MAXEFECTIVE=128", so that nothing is considered stronger than 128, and then other factors come into play. Thus @SPEED would sort fastest first which combined with an "@STENGTH" capped at 128, gives a sensible outcome for those wanting an adequate, but performant 128-bit outcome, with AEAD first, ... And the browsers should implement SHA-384, and why the hell are we using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely the SHA256 HMAC construction has adequate strength in this context? -- Viktor. From kurt at roeckx.be Tue Dec 16 19:37:42 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Dec 2014 20:37:42 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216182329.GC3241@localhost> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F30F@USMBX1.msg.corp.akamai.com> <20141216175753.GB3241@localhost> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F348@USMBX1.msg.corp.akamai.com> <20141216182329.GC3241@localhost> Message-ID: <20141216193742.GA11464@roeckx.be> On Tue, Dec 16, 2014 at 12:23:36PM -0600, Nico Williams wrote: > On Tue, Dec 16, 2014 at 01:04:17PM -0500, Salz, Rich wrote: > > > Subtracting (in local configuration) algorithms from a keyword denoting all > > > known-strong algorithms is hand-tuning, but not fragile hand-tuning. > > > > Three years ago RC4 was known-strong. Two years ago DES-CBC was > > known-strong. Now we only have AES-GCM. At what point do we think > > ChaCha/Poly is known-strong, and who gets to make that call? Dan? > > Adam? > > Changing the internal relative strength weighings of these requires > pushing out new code. Something that... happens all the time. It's not because we make a release that everybody is going to switch to it. Some people are still using 0.9.7. Kurt From kurt at roeckx.be Tue Dec 16 19:46:35 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Dec 2014 20:46:35 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216185614.GN25666@mournblade.imrryr.org> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <20141216185614.GN25666@mournblade.imrryr.org> Message-ID: <20141216194635.GB11464@roeckx.be> On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote: > And the browsers should implement SHA-384, and why the hell are we > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely > the SHA256 HMAC construction has adequate strength in this context? With GCM the collision resistance is important and SHA-256 only provides an 128 bit strength for that. Kurt From ynir.ietf at gmail.com Tue Dec 16 19:48:53 2014 From: ynir.ietf at gmail.com (Yoav Nir) Date: Tue, 16 Dec 2014 21:48:53 +0200 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216182803.0044e4a4@pc> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216182803.0044e4a4@pc> Message-ID: <4901E0A7-3990-4FFD-8EA6-60A15A3328B2@gmail.com> > On Dec 16, 2014, at 7:28 PM, Hanno B?ck wrote: > > On Tue, 16 Dec 2014 17:17:01 +0000 > Viktor Dukhovni wrote: > >> However, where do we fit ChaCha20/Poly-1305? Again, not >> hand-placement, but some extensible algorithm. > > How about this simpler criterion: > AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with > it. > > (this doesn't answer whether chacha20-poly1305 or aes-gcm should be > considered "better", but I don't know if there is a clear consensus on > that) Agree about AEAD before non-AEAD. As for ChaCha20 vs AES-GCM, as long as we don?t have evidence that on is significantly weaker than the other, I don?t think preferences should depend on security arguments, but on performance. Unfortunately , this is difficult to determine, because AES-GCM is faster on modern Intel processors, but slower on older processors and on ARM. It really depends on the application which is preferable. If we don?t want preference to be user-determined, I guess AES-GCM is more likely to be the preferred cipher for most servers. Yoav From openssl-users at dukhovni.org Tue Dec 16 19:57:08 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 19:57:08 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216194635.GB11464@roeckx.be> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <20141216185614.GN25666@mournblade.imrryr.org> <20141216194635.GB11464@roeckx.be> Message-ID: <20141216195708.GR25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote: > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote: > > And the browsers should implement SHA-384, and why the hell are we > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely > > the SHA256 HMAC construction has adequate strength in this context? > > With GCM the collision resistance is important and SHA-256 > only provides an 128 bit strength for that. I've not looked into this, can you elaborate (citation)? Which attacker controls the SHA2-256 inputs to the TLS PRF? Why are collisions rather than 2nd preimages the relevant issue? Though of course with AEAD the PRF is not used for a bulk data checksum, so its performance is largely irrelevant. Why aren't the browsers implementing the AESGCM256 + SHA384 variants? -- Viktor. From hkario at redhat.com Tue Dec 16 20:50:32 2014 From: hkario at redhat.com (Hubert Kario) Date: Tue, 16 Dec 2014 21:50:32 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216184311.GD3241@localhost> References: <20141216021840.5904747b@pc> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> Message-ID: <6858143.UD9kZsoOxX@pintsize.usersys.redhat.com> On Tuesday 16 December 2014 12:43:13 Nico Williams wrote: > On Tue, Dec 16, 2014 at 06:26:50PM +0000, Viktor Dukhovni wrote: > > Internally OpenSSL has a multi-dimensional property matrix, and > > preferences between numerically equal ciphers are based on other > > properties. The (stable) numeric sorting just re-arranges blocks > > of ciphers already sorted by other means. Thus preference for PFS > > already puts kEECDH and kDHE ahead of kRSA for otherwise equally > > strong ciphers. > > > > When the user choose a group of ciphers to add to a cipherlist, > > the members of the group retain their relative order. However, > > > > there are interesting games that can be played with: > > aRSA:-kRSA:ALL:@STRENGTH > > > > (prefers kRSA over PFS). > > > > which perturb the order, because the most recenly removed elements > > end up at the top of the list when "ALL" is added. So the relative > > preferences of various properties can be changed. > > Iterating subtaction and addition seems like a fragile way to indicate > preference. > > > The SASL problem mostly does not bite OpenSSL, However, @STRENGTH > > (which is often needed) is not sufficiently tunable, it is not eas > > to prefer AES-128 with AEAD over 256 with CBC. For that we need > > some new mappings that produce slight different "effective" stengths. > > My preference would be: subtract undesired algorithms from a named set, > then specify order of preference via some method other than iteratively > adding and subtracting algorithms. Something like: > > DEFAULT:-FOO128:::PFS,AEAD,speed,strength > The more I think about it, the more I like it. BTW: the way the sorting is currently implemented, it would just be a question of defining (in addition to currently present @STRENGTH) @PFS, @AEAD, @SPEED sorting orders (maybe also @STRENGTH128 which explicitly assumes any effective key size above 128 is 128). That's because if there's one thing I don't like about my proposal from few months back, is that we essentially have to define one "true" order of importance, say which is more important: speed, pfs or AEAD. Let's say, for the sake of argument, that CBC mode is significantly broken, even in EtM mode (that's another can of worms[1]), then many people will want to prioritise *non-PFS* versions of AEAD ciphers above any other ciphers. And they will want to do it for the same reason people currently leave RC4 in. 1 - by another can of worms I mean: what if it's broken only in MtE mode? how to specify different ciphers depending on presence of this extension, so that in MtE only AEAD ciphers are available while if EtM is on, the list gains CBC ciphers? This is similar to the problem with BEAST: ordering with RC4 at the front for TLS1.0 is sort-of OK, not so much for TLSv1.1 and later... -- Regards, Hubert Kario From nico at cryptonector.com Tue Dec 16 20:58:38 2014 From: nico at cryptonector.com (Nico Williams) Date: Tue, 16 Dec 2014 14:58:38 -0600 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <6858143.UD9kZsoOxX@pintsize.usersys.redhat.com> References: <20141216021840.5904747b@pc> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <6858143.UD9kZsoOxX@pintsize.usersys.redhat.com> Message-ID: <20141216205832.GH3241@localhost> On Tue, Dec 16, 2014 at 09:50:32PM +0100, Hubert Kario wrote: > > My preference would be: subtract undesired algorithms from a named set, > > then specify order of preference via some method other than iteratively > > adding and subtracting algorithms. Something like: > > > > DEFAULT:-FOO128:::PFS,AEAD,speed,strength I would add that this would work like one would expect, and that speed,strength would give [potentially] different results than strength,speed, as one would expect. > Let's say, for the sake of argument, that CBC mode is significantly broken, > even in EtM mode (that's another can of worms[1]), then many people will want > to prioritise *non-PFS* versions of AEAD ciphers above any other ciphers. And > they will want to do it for the same reason people currently leave RC4 in. Right. Any crypto is better than no crypto (or, rather, the identity ciphersuite), but the weak crypto has to go last. Of course, for one-offs like this hypothetical one might want a way to indicate that some algorithms are least preferred and others most, not just sets of algorithms. > 1 - by another can of worms I mean: what if it's broken only in MtE > mode? how to specify different ciphers depending on presence of this > extension, so that in MtE only AEAD ciphers are available while if > EtM is on, the list gains CBC ciphers? This is similar to the problem > with BEAST: ordering with RC4 at the front for TLS1.0 is sort-of OK, > not so much for TLSv1.1 and later... Specifying ciphersuites and preference on a per-protocol version basis would help. Specifying in more context-dependent ways would be nice but now you'd need a way to name/identify the context. Nico -- From mancha1 at zoho.com Tue Dec 16 21:00:04 2014 From: mancha1 at zoho.com (mancha) Date: Tue, 16 Dec 2014 21:00:04 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216182803.0044e4a4@pc> References: <20141216021840.5904747b@pc> <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216182803.0044e4a4@pc> Message-ID: <20141216210004.GA30141@zoho.com> On Tue, Dec 16, 2014 at 06:28:03PM +0100, Hanno B?ck wrote: > On Tue, 16 Dec 2014 17:17:01 +0000 > Viktor Dukhovni wrote: > > > However, where do we fit ChaCha20/Poly-1305? Again, not > > hand-placement, but some extensible algorithm. > > How about this simpler criterion: > AEAD always beats non-AEAD. GCM and poly1305 are both AEAD. Done with > it. Has there been significant cryptanalysis done on ChaCha20-Poly1305? My quick scan reveals a dearth of peer-reviewed literature. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rsalz at akamai.com Tue Dec 16 21:43:21 2014 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Dec 2014 16:43:21 -0500 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216205832.GH3241@localhost> References: <20141216021840.5904747b@pc> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <6858143.UD9kZsoOxX@pintsize.usersys.redhat.com> <20141216205832.GH3241@localhost> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F458@USMBX1.msg.corp.akamai.com> There's clearly only one solution: I'll implement a DWIM keyword in OpenSSL 1.1 Maybe @BEST sorting order. It's hard. You aren't doing people a service by attempting magic. -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From kurt at roeckx.be Tue Dec 16 21:48:08 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 16 Dec 2014 22:48:08 +0100 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216195708.GR25666@mournblade.imrryr.org> References: <1804150.iSFSfh8M7I@pintsize.usersys.redhat.com> <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <20141216185614.GN25666@mournblade.imrryr.org> <20141216194635.GB11464@roeckx.be> <20141216195708.GR25666@mournblade.imrryr.org> Message-ID: <20141216214808.GA32502@roeckx.be> On Tue, Dec 16, 2014 at 07:57:08PM +0000, Viktor Dukhovni wrote: > On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote: > > > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote: > > > And the browsers should implement SHA-384, and why the hell are we > > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely > > > the SHA256 HMAC construction has adequate strength in this context? > > > > With GCM the collision resistance is important and SHA-256 > > only provides an 128 bit strength for that. > > I've not looked into this, can you elaborate (citation)? Which > attacker controls the SHA2-256 inputs to the TLS PRF? Why are > collisions rather than 2nd preimages the relevant issue? I think the best reference I can find at this time is: http://www.ietf.org/mail-archive/web/tls/current/msg13313.html But I'm sure I can find others if needed. Kurt From openssl-users at dukhovni.org Tue Dec 16 21:58:10 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 16 Dec 2014 21:58:10 +0000 Subject: [openssl-dev] Circumstances cause CBC often to be preferred over GCM modes In-Reply-To: <20141216214808.GA32502@roeckx.be> References: <20141216161809.27985b23@pc> <54570883.c9iYCXndC7@pintsize.usersys.redhat.com> <20141216171701.GH25666@mournblade.imrryr.org> <20141216175532.GA3241@localhost> <20141216182650.GM25666@mournblade.imrryr.org> <20141216184311.GD3241@localhost> <20141216185614.GN25666@mournblade.imrryr.org> <20141216194635.GB11464@roeckx.be> <20141216195708.GR25666@mournblade.imrryr.org> <20141216214808.GA32502@roeckx.be> Message-ID: <20141216215810.GU25666@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 10:48:08PM +0100, Kurt Roeckx wrote: > On Tue, Dec 16, 2014 at 07:57:08PM +0000, Viktor Dukhovni wrote: > > On Tue, Dec 16, 2014 at 08:46:35PM +0100, Kurt Roeckx wrote: > > > > > On Tue, Dec 16, 2014 at 06:56:14PM +0000, Viktor Dukhovni wrote: > > > > And the browsers should implement SHA-384, and why the hell are we > > > > using SHA-384 with AES256-GCM instead of SHA-256 anyway? Surely > > > > the SHA256 HMAC construction has adequate strength in this context? > > > > > > With GCM the collision resistance is important and SHA-256 > > > only provides an 128 bit strength for that. > > > > I've not looked into this, can you elaborate (citation)? Which > > attacker controls the SHA2-256 inputs to the TLS PRF? Why are > > collisions rather than 2nd preimages the relevant issue? > > I think the best reference I can find at this time is: > http://www.ietf.org/mail-archive/web/tls/current/msg13313.html > > But I'm sure I can find others if needed. I believe the author of that message is mistaken. -- Viktor. From dthompson at prinpay.com Tue Dec 16 22:34:07 2014 From: dthompson at prinpay.com (Dave Thompson) Date: Tue, 16 Dec 2014 17:34:07 -0500 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format In-Reply-To: <5490607D.10509@gmail.com> References: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> <5490607D.10509@gmail.com> Message-ID: <005401d01980$697d6c00$3c784400$@prinpay.com> > From: openssl-dev On Behalf Of Douglas E Engert > Sent: Tuesday, December 16, 2014 11:40 > On 12/16/2014 12:18 AM, Philip Prindeville wrote: > > Is there an easy way to get at the parameter 'y' (DSA->pub_key, which is a > BIGNUM *) in ASN.1 format? (See (2) below.) > > Better yet, how to take that and pass it to ASN_item_digest()? > > > > Also, there's some confusion (at least for me) about what constitutes > DSAPublicKey. According to RFC-5912 you have: > > DSA-Params ::= > > DSAPublicKey ::= INTEGER -- public key, y > > so I'd assume that i2d_DSAPublicKey() would generate a DER string > containing the serialization of a single ASN.1 object, i.e. the INTEGER > containing 'y' or dsa->pub_key as the serialized ASN representation of that > BIGNUM. > > > > Alas, it doesn't. > > I would assume it would do what you say. People confuse what is in a > SubjectPublicKeyInfo > which includes an algorithm oid, parameters and the public key. > > The same type of confusion can occur with ECC. > The OpenSSL implementation of DSAPublicKey has some arcana in it that I haven't seen elsewhere. I suspect this may be because DSA was the first parameterized (PK?) cipher and broke new territory. See below. > PKCS#15 has ASN.1 definitions that might help, and it referes to ANSI X9 > documents. > > If I run test/dsatest for instance and I write out the generated DSA key, > then parse it, I get Note dsatest's main function is to test that the *parameter* generation algorithm, specified by FIPS 186 to be reproducible and thus (provably?) nothing-up-my-sleeve, works. For testing keys it would be simpler to just use some fixed (but valid) params. But anyway: > > $ openssl asn1parse -in dsa.der -inform DER -i > > 0:d=0 hl=3 l= 222 cons: SEQUENCE > > 3:d=1 hl=2 l= 64 prim: INTEGER > :18CF7F66E23221AEA14DB900DA06BE46A91DF113D490C3C6A0C57EEAEE56 > DF1E9059A541445CFCBE1B63E8197199C0C9FD25A7CCE3354CC1077D577C3 > 112A6CA > > 69:d=1 hl=2 l= 65 prim: INTEGER > :8DF2A494492276AA3D25759BB06869CBEAC0D83AFB8D0CF7CBB8324F0D7 > 882E5D0762FC5B7210EAFC2E9ADAC32AB7AAC49693DFBF83724C2EC0736E > E31C80291 > > 136:d=1 hl=2 l= 21 prim: INTEGER > :C773218C737EC8EE993B4F2DED30F48EDACE915F > > 159:d=1 hl=2 l= 64 prim: INTEGER > :626D027839EA0A13413163A55B4CB500299D5522956CEFCB3BFF10F399CE > 2C2E71CB9DE5FA24BABF58E5B79521925C9CC42E9F6F464B088CC572AF53E > 6D78802 > > $ > > It is not clear to me where the above is defined. > > > is the result of calling i2d_DSAPublicKey() and writing that to a file. HERE'S THE TRICKY BIT: It's defined where you would expect, in dsa/dsa_asn1.c . But it's defined as a "choice" that does either the standard INTEGER (from internal BIGNUM) *OR* the above SEQUENCE which is named 'dsa_pub_internal' suggesting that it should be internal to OpenSSL i.e. not interoperable or standard, but not explained that I can find. Anyway, to get the standard form apparently you need to set dsa->write_params to 0 (false) which is done *for the SPKI form* in dsa_ameth.c dsa_pub_encode. > > Calling i2d_DSA_PUBKEY_fp() results in something else: > That appears to be a SubjectPublicKeyInfo (SPKI) , with algorithm ID, > parameters, and the public key in the bit string. Yes. PUBKEY is effectively the OpenSSL name for SPKI. There are also RSA_PUBKEY, EC_PUBKEY, and generic PUBKEY routines. > But as you say below, the bit string looks like a SPKI! No he doesn't and it doesn't. > > Using dumpasn1 I find out that the BIT STRING at the end is actually: > > > > $ dumpasn1 -a -d -z -h -l dsa5.der > > <30 81 F0> > > 0 240: SEQUENCE { > > <30 81 A8> > > 3 168: . SEQUENCE { > > <06 07> > > 6 7: . . OBJECT IDENTIFIER dsa (1 2 840 10040 4 1) > > : . . . (ANSI X9.57 algorithm) > > <30 81 9C> > > 15 156: . . SEQUENCE { > > <02 41> > > 18 65: . . . INTEGER > > : . . . . 00 8D F2 A4 94 49 22 76 AA 3D 25 75 9B B0 68 69 > > : . . . . CB EA C0 D8 3A FB 8D 0C F7 CB B8 32 4F 0D 78 82 > > : . . . . E5 D0 76 2F C5 B7 21 0E AF C2 E9 AD AC 32 AB 7A > > : . . . . AC 49 69 3D FB F8 37 24 C2 EC 07 36 EE 31 C8 02 > > : . . . . 91 > > <02 15> > > 85 21: . . . INTEGER > > : . . . . 00 C7 73 21 8C 73 7E C8 EE 99 3B 4F 2D ED 30 F4 > > : . . . . 8E DA CE 91 5F > > <02 40> > > 108 64: . . . INTEGER > > : . . . . 62 6D 02 78 39 EA 0A 13 41 31 63 A5 5B 4C B5 00 > > : . . . . 29 9D 55 22 95 6C EF CB 3B FF 10 F3 99 CE 2C 2E > > : . . . . 71 CB 9D E5 FA 24 BA BF 58 E5 B7 95 21 92 5C 9C > > : . . . . C4 2E 9F 6F 46 4B 08 8C C5 72 AF 53 E6 D7 88 02 > > : . . . } > > : . . } > > <03 43> > > 174 67: . BIT STRING, encapsulates { > > <02 40> > > 177 64: . . INTEGER > > : . . . 18 CF 7F 66 E2 32 21 AE A1 4D B9 00 DA 06 BE 46 > > : . . . A9 1D F1 13 D4 90 C3 C6 A0 C5 7E EA EE 56 DF 1E > > : . . . 90 59 A5 41 44 5C FC BE 1B 63 E8 19 71 99 C0 C9 > > : . . . FD 25 A7 CC E3 35 4C C1 07 7D 57 7C 31 12 A6 CA > > : . . } > > : . } See? Starting at 174 BITSTRING containing DER/BER for INTEGER. > > Oddly, though, if I define: > > > > int i2d_DSAPublicKey_fp(FILE *fp, DSA *dsa) > > { > > return ASN1_i2d_fp_of_const(DSA,i2d_DSAPublicKey,fp,dsa); > > } > > > > and call that, it correctly writes out 'y' (dsa->pub_key) as: > > which I'm happy about, but don't quite understand. > > For me that code writes the 'internal' SEQUENCE, consistent with others, UNLESS I previously within the same program call i2d_DSA_PUBKEY (perhaps indirectly such as PEM_write_PUBKEY) or clear write_params. Did you maybe do the former of these? > > So, a few questions: > > > > (1) what's the quick way to, given a DSA *, compute a hash (given an > EVP_MD *) over dsa->pub_key as an ASN.1 primitive? I tried: > > > > ASN1_item_digest(ASN1_ITEM_ref(BIGNUM), mdtype, dsa->pub_key, md, > mdlen); > > > > but it's giving me highly dubious results. > > I wouldn't poke around in internals like that, I would just i2d to a buffer and hash the buffer. 32 bytes of memory costs about $.000001 . I'm not sure even bitcoin divides small enough to make that detectable. (Alternatively one could get a cert for the key from a CA that uses SKId which is conventionally the hash of the "raw" pubkey. ) > > (2) where is the ASN.1 module definition which corresponds to the format > used by i2d_DSA_PUBKEY_fp()? > > If you mean the ASN.1 source, RFC 5280 augmented by IIRC 3279, which got them from (CCITT) X.509 and (ANSI) X9.something, in addition to Douglas's answer of PKCS#15. If you mean the data the OpenSSL code uses to do ASN.1, generic PUBKEY=X509_PUBKEY=SPKI is in asn1/x_pubkey.c, and the DSA-specific part is in dsa/dsa_asn1.c . > > (3) is there a way to generate a pk-dsa serialization in the library or do I > have to muster this by hand? > > > > (4) why does i2d_DSAPublicKey() give you its current results and not the > DER representation of 'y' (dsa->pub_key)? > > See above. From rt at openssl.org Tue Dec 16 23:02:42 2014 From: rt at openssl.org (Tim Hudson via RT) Date: Wed, 17 Dec 2014 00:02:42 +0100 Subject: [openssl-dev] [openssl.org #2459] ecdsa_method declaration prevents use in implementing a dynamic engine In-Reply-To: References: Message-ID: Note: the interface suggested by Doug was added by Steve Henson into master in commit 94c2f77a62be7079ab1893ab14b18a30157c4532 and OpenSSL 1.0.2 in commit 7c23127fde8fe94af914961eb7702caa7f256a05 and {set,get}_app_data into master in commit 387b844ffdc79b733be0b1dbaddd2ac64a6c1192 and OpenSSL 1.0.2 in commit 654ae3d6ad61367060ffc20db11c7cf86b8f95b8 Currently there is no init or finish function in the method. Tim. From dthompson at prinpay.com Tue Dec 16 23:14:22 2014 From: dthompson at prinpay.com (Dave Thompson) Date: Tue, 16 Dec 2014 18:14:22 -0500 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format In-Reply-To: <005401d01980$697d6c00$3c784400$@prinpay.com> References: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> <5490607D.10509@gmail.com> <005401d01980$697d6c00$3c784400$@prinpay.com> Message-ID: <005501d01986$09094960$1b1bdc20$@prinpay.com> > [DSAPublicKey] defined where you would expect, in dsa/dsa_asn1.c . > But it's defined as a "choice" that does either the standard INTEGER > (from internal BIGNUM) *OR* the above SEQUENCE which is named > 'dsa_pub_internal' suggesting that it should be internal to OpenSSL > i.e. not interoperable or standard, but not explained that I can find. > > Anyway, to get the standard form apparently you need to set > dsa->write_params to 0 (false) which is done *for the SPKI form* > in dsa_ameth.c dsa_pub_encode. > Argh! Too obvious! It's in the manpage for i2d_DSAPublicKey although IMO slightly overstated; the 0 format is standard AFAICT. From dev+openssl at seantek.com Wed Dec 17 10:37:08 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Wed, 17 Dec 2014 02:37:08 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats Message-ID: <54915CD4.1050805@seantek.com> Hi OpenSSL devs: I am putting the finishing touches on an Internet-Draft for textual encodings of security structures , which OpenSSL refers to as the "PEM format". While reviewing OpenSSL's behavior, I noticed a few esoteric labels (see pem.h): #define PEM_STRING_X509_PAIR "CERTIFICATE PAIR" (note, this is supposed to encapsulate a CertificatePair structure from X.509) #define PEM_STRING_SSL_SESSION "SSL SESSION PARAMETERS" #define PEM_STRING_PARAMETERS "PARAMETERS" (note, this label does not have any algorithms in it, so I presume it refers to some kind of generic parameter structure) Do these labels have practical use? I have not seen them in the wild. Why are they in OpenSSL? Are they ever used for interchange with other implementations, or are they specific to OpenSSL's own purposes? Thanks, Sean From kurt at roeckx.be Wed Dec 17 11:34:32 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 17 Dec 2014 12:34:32 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54915CD4.1050805@seantek.com> References: <54915CD4.1050805@seantek.com> Message-ID: <20141217113432.GA29282@roeckx.be> On Wed, Dec 17, 2014 at 02:37:08AM -0800, Sean Leonard wrote: > Hi OpenSSL devs: > > I am putting the finishing touches on an Internet-Draft for textual > encodings of security structures > , which OpenSSL > refers to as the "PEM format". > > While reviewing OpenSSL's behavior, I noticed a few esoteric labels (see > pem.h): > #define PEM_STRING_X509_PAIR "CERTIFICATE PAIR" > (note, this is supposed to encapsulate a CertificatePair structure from > X.509) > #define PEM_STRING_SSL_SESSION "SSL SESSION PARAMETERS" > #define PEM_STRING_PARAMETERS "PARAMETERS" > (note, this label does not have any algorithms in it, so I presume it > refers to some kind of generic parameter structure) > > Do these labels have practical use? I have not seen them in the wild. Why > are they in OpenSSL? Are they ever used for interchange with other > implementations, or are they specific to OpenSSL's own purposes? I know that the ssl session parameters can be read and written by s_client and sess_id. It can be used to resume a session. applications can store the session information in a database or something like that to later be able to resume the session. But I don't think anything uses it without openssl. It's stored in an SSL_SESSION_ASN1 which is an internal only structure that can changed between versions. Only the version that has written that should be able to read it. Kurt From rt at openssl.org Wed Dec 17 13:32:13 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Dec 2014 14:32:13 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: Hi, As far as I can tell, the problem should be fixed as off commit 8bc8450a26329e3c890df60026f969e7caabff3d (for the 1.0.2 branch, I did apply the same changes to master and 1.0.1 branch as well). I went through all the available xxx_DEBUG macros to make sure they'd all be clear (at least with gcc). Cheers, Richard On Fri Dec 12 20:06:48 2014, steck at stecksoft.com wrote: > Hi, > > I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured > with some xxx_DEBUG > flags, which results in a compile failure in ssl/t1_enc.c. See the > attached testlog for > the exact flags used. > > Application details: N/A > > Problem Description: > > These compile-time (warnings and) errors: > -- > t1_enc.c: In function ?tls1_enc?: > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?long unsigned int? [-Wformat=] > ds->cipher->iv_len); > ^ > t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, > but argument 5 has type ?long unsigned int? [-Wformat=] > t1_enc.c: In function ?tls1_mac?: > t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) > {unsigned int z; for (z=0; z ",mac_sec[z]); printf("\n"); } > ^ > t1_enc.c:1075:59: note: each undeclared identifier is reported only > once for each function it appears in > t1_enc.c:1079:44: error: ?buf? undeclared (first use in this function) > {int z; for (z=0; z<5; z++) printf("%02X ",buf[z]); printf("\n"); } > ^ > t1_enc.c: In function ?tls1_export_keying_material?: > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 4 has type ?size_t? [-Wformat=] > printf ("tls1_export_keying_material(%p,%p,%d,%s,%d,%p,%d)\n", s, > out, olen, label, llen, context, contextlen); > ^ > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 6 has type ?size_t? [-Wformat=] > t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, > but argument 8 has type ?size_t? [-Wformat=] > -- > > Stack traceback: N/A > > -- Paul -- Richard Levitte levitte at openssl.org From rt at openssl.org Wed Dec 17 13:51:39 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 17 Dec 2014 14:51:39 +0100 Subject: [openssl-dev] [openssl.org #3631] Bug in the binary search in OBJ_bsearch_ex_ in obj_dat.c (1.0.1j) In-Reply-To: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> References: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> Message-ID: Are you using OBJ_bsearch_ex_ directly from your code? It seems to me that you have misunderstood how it works. size is the size of one element of your array, num is the number of elements. The actual size of the array (in bytes) should then be size*num, and you need to make sure that it is. I would, however, recommend that you don't call this function directly, and instead use the macro OBJ_bsearch_ex, which will calculate the element size properly for you, given a type that you give it. On Fri Dec 12 17:52:07 2014, matthias.mucha at jojema.de wrote: > Hello, > > I strapped down OpenSSL 1.0.1j to only the PEM to RSA, BIO and RSA > public > decrypt functions. So a bug in the binary search in appeared: > > Current code: > > const void *OBJ_bsearch_ex_(const void *key, const void *base_, int > num, > int size, > int (*cmp)(const void *, const void *), > int flags) > { > const char *base=base_; > int l,h,i=0,c=0; > const char *p = NULL; > > if (num == 0) return(NULL); > l=0; > h=num; > while (l < h) > { > i=(l+h)/2; > p= &(base[i*size]); > c=(*cmp)(key,p); > if (c < 0) > h=i; > else if (c > 0) > l=i+1; > else > break; > } > > > [...] > > My case: size = 4 > num = 4 > > In the first round i evaluates to 2 which can not be divided by size > and lets p > escape the frame for the pointers, which results in a segfault. > > General case: > > This will fail for every case where num < (size * 2) > > > My fix: > > const void *OBJ_bsearch_ex_(const void *key, const void *base_, int > num, > int size, > int (*cmp)(const void *, const void *), > int flags) > { > const char *base=base_; > int l,h,i=0,c=0; > const char *p = NULL; > > if (num == 0) return(NULL); > if (num < size*2) { > while(i { > p=&(base[i*size]); > c=(*cmp)(key,p); > if (!c) break; > else ++i; > } > } > else { > l=0; > h=num; > while (l < h) > { > i=(l+h)/2; > p= &(base[i*size]); > c=(*cmp)(key,p); > if (c < 0) > h=i; > else if (c > 0) > l=i+1; > else > break; > } > } > > [...] > > Regards > > Matthias Mucha > -- Richard Levitte levitte at openssl.org From vadim at mbdsys.com Wed Dec 17 14:05:52 2014 From: vadim at mbdsys.com (Vadim Lebedev) Date: Wed, 17 Dec 2014 14:05:52 +0000 (UTC) Subject: [openssl-dev] =?utf-8?q?Possible_bug_in_crypto/evp/e=5Faes=2Ec=3A?= =?utf-8?q?aes=5Fcbc=5Fcipher?= Message-ID: Hello, I'was tracking a segfault in EVP_OpneUdate and stumbled on following: static int aes_cbc_cipher(EVP_CIPHER_CTX *ctx,unsigned char *out, const unsigned char *in, size_t len) { EVP_AES_KEY *dat = (EVP_AES_KEY *)ctx->cipher_data; if (dat->stream.cbc) (*dat->stream.cbc)(in,out,len,&dat->ks,ctx->iv,ctx->encrypt); else if (ctx->encrypt) CRYPTO_cbc128_encrypt(in,out,len,&dat->ks,ctx->iv,dat->block); else CRYPTO_cbc128_encrypt(in,out,len,&dat->ks,ctx->iv,dat->block); return 1; } I think that the second call to CRYPTO_cbc128_encrypt should be actually to CRYPTO_cbc128_decrypt. Any feedback please? Thanks Vadim From appro at openssl.org Wed Dec 17 14:35:13 2014 From: appro at openssl.org (Andy Polyakov) Date: Wed, 17 Dec 2014 15:35:13 +0100 Subject: [openssl-dev] Possible bug in crypto/evp/e_aes.c:aes_cbc_cipher In-Reply-To: References: Message-ID: <549194A1.6010406@openssl.org> Hi, > I'was tracking a segfault in EVP_OpneUdate and stumbled on following: > > static int aes_cbc_cipher(EVP_CIPHER_CTX *ctx,unsigned char *out, > const unsigned char *in, size_t len) > { > EVP_AES_KEY *dat = (EVP_AES_KEY *)ctx->cipher_data; > > if (dat->stream.cbc) > (*dat->stream.cbc)(in,out,len,&dat->ks,ctx->iv,ctx->encrypt); > else if (ctx->encrypt) > CRYPTO_cbc128_encrypt(in,out,len,&dat->ks,ctx->iv,dat->block); > else > CRYPTO_cbc128_encrypt(in,out,len,&dat->ks,ctx->iv,dat->block); > > return 1; > } > > > I think that the second call to CRYPTO_cbc128_encrypt should be actually to > CRYPTO_cbc128_decrypt. Yes, it's a typo, and it was fixed in development branches. One naturally wonders how did it work? The truth is that that call is never made, because dat->stream.cbc is always initialized. At least was so far. From tarunpolisetti at gmail.com Wed Dec 17 15:06:45 2014 From: tarunpolisetti at gmail.com (T@Run..............! Polisetty) Date: Wed, 17 Dec 2014 20:36:45 +0530 Subject: [openssl-dev] Coredump in Openssl Library Message-ID: Hai All, I am reporting one coredump when using openssl library Can anyone have some idea on it. hread 1 (Thread 28457): #0 0x00007f1871bb61b5 in raise () from /lib/libc.so.6 #1 0x00007f1871bb8fc0 in abort () from /lib/libc.so.6 #2 0x00007f1871bec5bb in ?? () from /lib/libc.so.6 #3 0x00007f1871bf5e16 in ?? () from /lib/libc.so.6 #4 0x00007f1871bfab8c in free () from /lib/libc.so.6 #5 0x00007f187721c6b8 in CRYPTO_realloc_clean () from /usr/lib/libcrypto.so.1.0.0 #6 0x00007f187727e8c5 in BUF_MEM_grow_clean () from /usr/lib/libcrypto.so.1.0.0 #7 0x00007f187727fde7 in mem_write () from /usr/lib/libcrypto.so.1.0.0 #8 0x00007f187727eec9 in BIO_write () from /usr/lib/libcrypto.so.1.0.0 Regards Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Dec 17 16:34:13 2014 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Dec 2014 11:34:13 -0500 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141217113432.GA29282@roeckx.be> References: <54915CD4.1050805@seantek.com> <20141217113432.GA29282@roeckx.be> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F655@USMBX1.msg.corp.akamai.com> > > I am putting the finishing touches on an Internet-Draft for textual > > encodings of security structures > > , which > > OpenSSL refers to as the "PEM format". Cool. You know why it's called PEM format, right? (RFC 1115 et al) > > #define PEM_STRING_X509_PAIR "CERTIFICATE PAIR" > > (note, this is supposed to encapsulate a CertificatePair structure > > from X.509) This is not used anywhere in openssl. I just removed it and did a build :) The fact that the fields are named forward and backward, makes me think it was intended for SSL/TLS use. But as I said it's not used and I'll remove it soon. > > #define PEM_STRING_SSL_SESSION "SSL SESSION PARAMETERS" As Kurt said, this is for internal use only, no guarantee it works across any two revisions. > > #define PEM_STRING_PARAMETERS "PARAMETERS" > > (note, this label does not have any algorithms in it, so I presume > > it refers to some kind of generic parameter structure) It's used to encode arbitrary parameters for ENGINE, which is OpenSSL's crypto-hardware abstraction. From erwann.abalea at opentrust.com Wed Dec 17 17:13:49 2014 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 17 Dec 2014 18:13:49 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F655@USMBX1.msg.corp.akamai.com> References: <54915CD4.1050805@seantek.com> <20141217113432.GA29282@roeckx.be> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F655@USMBX1.msg.corp.akamai.com> Message-ID: <5491B9CD.5090407@opentrust.com> Le 17/12/2014 17:34, Salz, Rich a ?crit : >>> #define PEM_STRING_X509_PAIR "CERTIFICATE PAIR" >>> (note, this is supposed to encapsulate a CertificatePair structure >>> from X.509) > This is not used anywhere in openssl. I just removed it and did a build :) The fact that the fields are named forward and backward, makes me think it was intended for SSL/TLS use. But as I said it's not used and I'll remove it soon. It's an object type defined in X.509 to support cross-certification. It can be used as an LDAP attribute (see RFC4523, section 2.3, CertificatePair). I haven't seen it used, and it doesn't need to have a PEM representation (LDAP requires a binary transmission). From steve at openssl.org Wed Dec 17 18:00:06 2014 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 17 Dec 2014 18:00:06 +0000 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54915CD4.1050805@seantek.com> References: <54915CD4.1050805@seantek.com> Message-ID: <20141217180006.GA15403@openssl.org> On Wed, Dec 17, 2014, Sean Leonard wrote: > #define PEM_STRING_PARAMETERS "PARAMETERS" > (note, this label does not have any algorithms in it, so I presume > it refers to some kind of generic parameter structure) > It's used internally to indicate to the PEM routines that it should accept any kind of algorithm parameters and set up an EVP_PKEY structure appropriately. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From philipp_subx at redfish-solutions.com Wed Dec 17 18:29:39 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 17 Dec 2014 11:29:39 -0700 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format In-Reply-To: <005501d01986$09094960$1b1bdc20$@prinpay.com> References: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> <5490607D.10509@gmail.com> <005401d01980$697d6c00$3c784400$@prinpay.com> <005501d01986$09094960$1b1bdc20$@prinpay.com> Message-ID: On Dec 16, 2014, at 4:14 PM, Dave Thompson wrote: >> [DSAPublicKey] defined where you would expect, in dsa/dsa_asn1.c . >> But it's defined as a "choice" that does either the standard INTEGER >> (from internal BIGNUM) *OR* the above SEQUENCE which is named >> 'dsa_pub_internal' suggesting that it should be internal to OpenSSL >> i.e. not interoperable or standard, but not explained that I can find. >> >> Anyway, to get the standard form apparently you need to set >> dsa->write_params to 0 (false) which is done *for the SPKI form* >> in dsa_ameth.c dsa_pub_encode. >> > Argh! Too obvious! It's in the manpage for i2d_DSAPublicKey > although IMO slightly overstated; the 0 format is standard AFAICT. Okay, so why does DSA_new_method() set write_params to 1? -Philip From dev+openssl at seantek.com Wed Dec 17 18:55:47 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Wed, 17 Dec 2014 10:55:47 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F655@USMBX1.msg.corp.akamai.com> References: <54915CD4.1050805@seantek.com> <20141217113432.GA29282@roeckx.be> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F655@USMBX1.msg.corp.akamai.com> Message-ID: <5491D1B3.3060409@seantek.com> On 12/17/2014 8:34 AM, Salz, Rich wrote: >>> I am putting the finishing touches on an Internet-Draft for textual >>> encodings of security structures >>> , which >>> OpenSSL refers to as the "PEM format". > Cool. You know why it's called PEM format, right? (RFC 1115 et al) Yes--that is discussed in the I-D. (Which renames it to "textual encoding", since it's actually not PEM...but I know that "PEM" is ingrained throughout OpenSSL so I won't advocate to this list to try to change the term in the software. :-) ) > >>> #define PEM_STRING_X509_PAIR "CERTIFICATE PAIR" >>> >>> #define PEM_STRING_SSL_SESSION "SSL SESSION PARAMETERS" Ok--so it's clear that these are not intended for interchange. I can cross them off the list. Thanks! Sean From dev+openssl at seantek.com Wed Dec 17 18:56:34 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Wed, 17 Dec 2014 10:56:34 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141217180006.GA15403@openssl.org> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> Message-ID: <5491D1E2.30604@seantek.com> On 12/17/2014 10:00 AM, Dr. Stephen Henson wrote: > On Wed, Dec 17, 2014, Sean Leonard wrote: > >> #define PEM_STRING_PARAMETERS "PARAMETERS" >> (note, this label does not have any algorithms in it, so I presume >> it refers to some kind of generic parameter structure) >> > It's used internally to indicate to the PEM routines that it should accept any > kind of algorithm parameters and set up an EVP_PKEY structure appropriately. Okay--so this one also sounds like it is not meant for interchange. I can cross this one off the list as well. Thanks! For reference for the group (in case you didn't take a look at the draft), the draft documents the following labels: CERTIFICATE X509 CRL CERTIFICATE REQUEST PKCS7 CMS PRIVATE KEY ENCRYPTED PRIVATE KEY ATTRIBUTE CERTIFICATE PUBLIC KEY as well as some other labels like "NEW CERTIFICATE REQUEST" for compatibility. Sean From rsalz at akamai.com Wed Dec 17 19:04:44 2014 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 17 Dec 2014 14:04:44 -0500 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <5491D1E2.30604@seantek.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> Probably also worth documenting the legacy "RSA PRIVATE KEY" defined by openssl and used mainly in legacy pre-pkcs8 support -- Principal Security Engineer, Akamai Technologies IM: rsalz at jabber.me Twitter: RichSalz From philipp_subx at redfish-solutions.com Wed Dec 17 19:08:21 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 17 Dec 2014 12:08:21 -0700 Subject: [openssl-dev] Retrieving DSA public key (Y) in ASN.1 format In-Reply-To: <005401d01980$697d6c00$3c784400$@prinpay.com> References: <68396A72-B7C8-41FC-9B79-F8A970C410C7@redfish-solutions.com> <5490607D.10509@gmail.com> <005401d01980$697d6c00$3c784400$@prinpay.com> Message-ID: <22454A5D-16AA-4435-BEB2-AC9B1009C643@redfish-solutions.com> On Dec 16, 2014, at 3:34 PM, Dave Thompson wrote: > >>> So, a few questions: >>> >>> (1) what's the quick way to, given a DSA *, compute a hash (given an >> EVP_MD *) over dsa->pub_key as an ASN.1 primitive? I tried: >>> >>> ASN1_item_digest(ASN1_ITEM_ref(BIGNUM), mdtype, dsa->pub_key, md, >> mdlen); >>> >>> but it's giving me highly dubious results. >>> > I wouldn't poke around in internals like that, I would just i2d to a buffer > and hash the buffer. 32 bytes of memory costs about $.000001 . > I'm not sure even bitcoin divides small enough to make that detectable. > > (Alternatively one could get a cert for the key from a CA that uses SKId > which is conventionally the hash of the "raw" pubkey. ) Well, I was hoping to upstream it into library so that if it uses the internals it shouldn?t be a bad thing. I was likewise hoping to avoid any unnecessary copies, since I can think of at least one scenario where a large database of keys is loaded up at startup and then indexed by hash, so I don?t want to take longer than necessary generating those hashes. -Philip From philipp_subx at redfish-solutions.com Wed Dec 17 19:16:11 2014 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Wed, 17 Dec 2014 12:16:11 -0700 Subject: [openssl-dev] Coredump in Openssl Library In-Reply-To: References: Message-ID: <631FFB93-1D88-4AD4-823B-3BD68648279C@redfish-solutions.com> On Dec 17, 2014, at 8:06 AM, T at Run..............! Polisetty wrote: > Hai All, > > I am reporting one coredump when using openssl library > > Can anyone have some idea on it. > > hread 1 (Thread 28457): > > #0 0x00007f1871bb61b5 in raise () from /lib/libc.so.6 > > #1 0x00007f1871bb8fc0 in abort () from /lib/libc.so.6 > > #2 0x00007f1871bec5bb in ?? () from /lib/libc.so.6 > > #3 0x00007f1871bf5e16 in ?? () from /lib/libc.so.6 > > #4 0x00007f1871bfab8c in free () from /lib/libc.so.6 > > #5 0x00007f187721c6b8 in CRYPTO_realloc_clean () > > from /usr/lib/libcrypto.so.1.0.0 > > #6 0x00007f187727e8c5 in BUF_MEM_grow_clean () > > from /usr/lib/libcrypto.so.1.0.0 > > #7 0x00007f187727fde7 in mem_write () from /usr/lib/libcrypto.so.1.0.0 > > #8 0x00007f187727eec9 in BIO_write () from /usr/lib/libcrypto.so.1.0.0 > > > > Regards > > Satya > > Offsets alone are pretty much meaningless, especially since we don?t know (a) what architecture this is, (b) what version this is, (c) if this is a debug or optimized build, (d) what the line numbers are, (e) what platform you?re running this one, (f) if any patches have been applied, (g) what you were doing at the time that the coredump happened, (h) what data can reliably reproduce this? At a minimum, please provide (d) and (h). If you?re using a production build in a fairly mainstream distro, there should be a package containing debug symbols that you can install corresponding to the library packaging (usually suffixed -dbg, -debug, or -devel). Also, don?t cross-post to -dev and -users. -Philip -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Dec 17 19:17:09 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 17 Dec 2014 19:17:09 +0000 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <5491D1E2.30604@seantek.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> Message-ID: <20141217191709.GD25666@mournblade.imrryr.org> On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote: > For reference for the group (in case you didn't take a look at the draft), > the draft documents the following labels: > > CERTIFICATE > ... Perhaps also "TRUSTED CERTIFICATE"? crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE" -- Viktor. From erwann.abalea at opentrust.com Wed Dec 17 19:34:52 2014 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 17 Dec 2014 20:34:52 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141217191709.GD25666@mournblade.imrryr.org> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> Message-ID: <5491DADC.2020809@opentrust.com> Le 17/12/2014 20:17, Viktor Dukhovni a ?crit : > On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote: > >> For reference for the group (in case you didn't take a look at the draft), >> the draft documents the following labels: >> >> CERTIFICATE >> ... > Perhaps also "TRUSTED CERTIFICATE"? > > crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE" It's specific to OpenSSL. From rt at openssl.org Wed Dec 17 20:18:28 2014 From: rt at openssl.org (Paul A. Steckler via RT) Date: Wed, 17 Dec 2014 21:18:28 +0100 Subject: [openssl-dev] [openssl.org #3635] Build error with 1.0.2-beta3 In-Reply-To: References: Message-ID: Many thanks! -- Paul On Wed, Dec 17, 2014 at 5:32 AM, Richard Levitte via RT wrote: > Hi, > > As far as I can tell, the problem should be fixed as off commit > 8bc8450a26329e3c890df60026f969e7caabff3d (for the 1.0.2 branch, I did apply the > same changes to master and 1.0.1 branch as well). I went through all the > available xxx_DEBUG macros to make sure they'd all be clear (at least with > gcc). > > Cheers, > Richard > > On Fri Dec 12 20:06:48 2014, steck at stecksoft.com wrote: >> Hi, >> >> I'm trying to build 1.0.2-beta3 on Fedora 20 x86_64. I've configured >> with some xxx_DEBUG >> flags, which results in a compile failure in ssl/t1_enc.c. See the >> attached testlog for >> the exact flags used. >> >> Application details: N/A >> >> Problem Description: >> >> These compile-time (warnings and) errors: >> -- >> t1_enc.c: In function ?tls1_enc?: >> t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, >> but argument 4 has type ?long unsigned int? [-Wformat=] >> ds->cipher->iv_len); >> ^ >> t1_enc.c:843:4: warning: format ?%d? expects argument of type ?int?, >> but argument 5 has type ?long unsigned int? [-Wformat=] >> t1_enc.c: In function ?tls1_mac?: >> t1_enc.c:1075:59: error: ?mac_sec? undeclared (first use in this function) >> {unsigned int z; for (z=0; z> ",mac_sec[z]); printf("\n"); } >> ^ >> t1_enc.c:1075:59: note: each undeclared identifier is reported only >> once for each function it appears in >> t1_enc.c:1079:44: error: ?buf? undeclared (first use in this function) >> {int z; for (z=0; z<5; z++) printf("%02X ",buf[z]); printf("\n"); } >> ^ >> t1_enc.c: In function ?tls1_export_keying_material?: >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 4 has type ?size_t? [-Wformat=] >> printf ("tls1_export_keying_material(%p,%p,%d,%s,%d,%p,%d)\n", s, >> out, olen, label, llen, context, contextlen); >> ^ >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 6 has type ?size_t? [-Wformat=] >> t1_enc.c:1176:2: warning: format ?%d? expects argument of type ?int?, >> but argument 8 has type ?size_t? [-Wformat=] >> -- >> >> Stack traceback: N/A >> >> -- Paul > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Wed Dec 17 22:26:18 2014 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 17 Dec 2014 23:26:18 +0100 Subject: [openssl-dev] [openssl.org #3544] Remove MWERKS support In-Reply-To: References: Message-ID: MWERKS added back to nw_rand.c -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Thu Dec 18 03:54:58 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Thu, 18 Dec 2014 04:54:58 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Thanks! Great! 6000 calls. No crashes or leaks.... only messages like this in asterisk [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x298c1d68' due to reason 'digest check failed', terminating [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x29d16508' due to reason 'digest check failed', terminating [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: DTLS failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest check failed', terminating But 99% call go normal. We will test on production server and high load. Thanks! 2014-12-16 14:46 GMT+03:00 Matt Caswell via RT : > > On Mon Dec 15 13:39:43 2014, v.badalyan at open-bs.ru wrote: > > Got assert > > d1_both.c(296): OpenSSL internal error, assertion failed: s->init_num == > > (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > > > To confirm: you did retain your change to check the return value from > dtls1_output_cert_chain? > > The official patch for that issue is here: > > https://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=9beb948c0dae6056caddf46a9aa099e18905d184 > > Matt > > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From normw at gknw.net Thu Dec 18 06:03:47 2014 From: normw at gknw.net (NormW) Date: Thu, 18 Dec 2014 17:03:47 +1100 Subject: [openssl-dev] [openssl.org #3544] Remove MWERKS support In-Reply-To: References: Message-ID: <54926E43.4070402@gknw.net> Thanks! Norm On 18/12/2014 9:26 AM, Rich Salz via RT wrote: > MWERKS added back to nw_rand.c > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > From rt at openssl.org Thu Dec 18 06:12:07 2014 From: rt at openssl.org (NormW via RT) Date: Thu, 18 Dec 2014 07:12:07 +0100 Subject: [openssl-dev] [openssl.org #3544] Remove MWERKS support In-Reply-To: <54926E43.4070402@gknw.net> References: <54926E43.4070402@gknw.net> Message-ID: Thanks! Norm On 18/12/2014 9:26 AM, Rich Salz via RT wrote: > MWERKS added back to nw_rand.c > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > From dev+openssl at seantek.com Thu Dec 18 06:48:23 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Wed, 17 Dec 2014 22:48:23 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> Message-ID: <549278B7.8060304@seantek.com> On 12/17/2014 11:04 AM, Salz, Rich wrote: > Probably also worth documenting the legacy "RSA PRIVATE KEY" defined by openssl and used mainly in legacy pre-pkcs8 support There is a paragraph on "algorithm agility"; the legacy labels (like RSA PRIVATE KEY) are not mentioned because for interchange, PKCS #8 is perfectly reasonable and is algorithm-agile. IIRC, there are some implementations out there (by that I mean certain well-known certification authorities that I will not name) that specifically look for "RSA PRIVATE KEY", and measure key strength by looking at the length of the blob. This method prevents other algorithms (e.g., ECC) from being used, and when other algorithms (e.g., ECC) are used, the key gets rejected for no other reason than because the key appears to be too "small" and therefore weak. Sean From kurt at roeckx.be Thu Dec 18 09:42:28 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Thu, 18 Dec 2014 10:42:28 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <5491DADC.2020809@opentrust.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> Message-ID: <20141218094228.GA2150@roeckx.be> On Wed, Dec 17, 2014 at 08:34:52PM +0100, Erwann Abalea wrote: > Le 17/12/2014 20:17, Viktor Dukhovni a ?crit : > >On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote: > > > >>For reference for the group (in case you didn't take a look at the draft), > >>the draft documents the following labels: > >> > >>CERTIFICATE > >>... > >Perhaps also "TRUSTED CERTIFICATE"? > > > > crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE" > > It's specific to OpenSSL. And it would be useful if it wasn't. Kurt From fedor at indutny.com Thu Dec 18 09:49:14 2014 From: fedor at indutny.com (Fedor Indutny) Date: Thu, 18 Dec 2014 16:49:14 +0700 Subject: [openssl-dev] [PATCH] x509: skip certs if in alternative cert chain Message-ID: In situations like [0] the server may provide alternative certificate chain, which is no longer valid in the current certificate store. In fact the issuer of the leaf (or some intermediate) cert is known and trusted, but the alternative chain certs that are sent by server are not trusted, thus leading to `ctx->get_issuer(...)` return 0. This patch changes the default behavior from "borking out the whole sent chain" to "pop as much certs as needed to make it work". Basically, it pops the last cert and checks if the previous has known issuer. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 NOTE: Possibly duplicate, I didn't get a reply from openssl-bugs@ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJUkm/WAAoJENcGPM4Zt+iQO1UQAIIWnbOwB4DG3rT2E3GFQ3JU gk2LFDFhrWgCmTPLki8TDkR664SimPYcMsI9Vg0v3v5PecQQaW2O/BLDYEJiZ07E 2nSQCI8APp10jIdt0QUmehP4uHYAYkGxOBnGzypsrXFz2N5MV4XJG1jUZOsgIgod yZ2Vg8xTejnYrSJ/JfSNTBZy3s20wXDqh06TWNt6rn5o/AsT5l6/JVvC7Vi1DnNu LcddPrCm2tiaUqVQP+Kn5tfYKGhACTGjnCi89t67rYYbZwxLN2YpgspB3Kv8aR4P WMofhpZocAZ/uBQcshWe/ExiFsJESQazmM5KYLrVrLsa/hWYLx2E6Dl/N+6IvsUX 8eoG0QFa25iTRv+gLxXEiKca6EPuOWBm6kcz169nyogKBRBzASk3DMwK6TdOfiXI 5uw3zBByiI/DDaBQW62x1KTkTfrcg0pWZHurEVrSK7USr2nGLxI87IWq/e6kcd6x QbkWmOY5qGoRVoBPjxeVowd5EfyaH2cM7bJLqXcNncYAEmIpvTUEN6YFbyUg2Nuc DaqSUx6UrPOo3M2kyiqDdGz75Xq57ncWByvJ4Dj8DNqyxOliFG8Mldz7vDUYFbHt aKR2UqehGsYZbnw/mFDRRtQ2WliB/BEtjISVKl7KPNgkv5twrZF7fMU/Oh3Mf7pe Jiw6SKPj0JctQF8xpO5J =4E+B -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-x509-skip-certs-if-in-alternative-cert-chain.patch Type: application/octet-stream Size: 1828 bytes Desc: not available URL: From rt at openssl.org Thu Dec 18 10:10:36 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 18 Dec 2014 11:10:36 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote: > Thanks! Great! > 6000 calls. No crashes or leaks.... only messages like this in > asterisk > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: > DTLS > failure occurred on RTP instance '0x298c1d68' due to reason 'digest > check > failed', terminating > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: > DTLS > failure occurred on RTP instance '0x29d16508' due to reason 'digest > check > failed', terminating > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: > DTLS > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest > check > failed', terminating > > But 99% call go normal. We will test on production server and high > load. Good news. Let me know how the testing goes in production so that I can (hopefully) close the ticket. Matt From ramyken at seznam.cz Thu Dec 18 10:16:46 2014 From: ramyken at seznam.cz (ramyken) Date: Thu, 18 Dec 2014 03:16:46 -0700 (MST) Subject: [openssl-dev] pkcs#7 signed data issue Message-ID: <1418897806973-55518.post@n7.nabble.com> Hi, i am trying to create pkcs#7 signed data structure and i have a problem when using NID_pkcs7_signed (signedData content type) in PKCS7_content_new function like this: PKCS7_content_new(p7, NID_pkcs7_signed) because when my app then calls PKCS7_dataFinal(p7,p7bio) i get a null pointer in this construction (inside the scope of PKCS7_dataFinal/pkcs7_doit.c function): .... case NID_pkcs7_signed: si_sk=p7->d.sign->signer_info; os=PKCS7_get_octet_string(p7->d.sign->contents); <------ NULL pointer returned to os /* If detached data then the content is excluded */ if(PKCS7_type_is_data(p7->d.sign->contents) && p7->detached) { M_ASN1_OCTET_STRING_free(os); p7->d.sign->contents->d.data = NULL; } break; .... where PKCS7_get_octet_string(p7->d.sign->contents) gives NULL into os variable and my app then crashes in the following condition when accesses os->flags: if (!PKCS7_is_detached(p7) && !(os->flags & ASN1_STRING_FLAG_NDEF)). I know that this happens because PKCS7_get_octet_string and PKCS7_type_is_other functions serves NID_pkcs7_signed type badly. I am currently using openssl-1.0.1g, bad the problem is also in the latest code as well. Has anybody already tried to solve this? thanks and regards, Ken -- View this message in context: http://openssl.6102.n7.nabble.com/pkcs-7-signed-data-issue-tp55518.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From rsalz at akamai.com Thu Dec 18 12:41:39 2014 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 18 Dec 2014 07:41:39 -0500 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <549278B7.8060304@seantek.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> <549278B7.8060304@seantek.com> Message-ID: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F83C@USMBX1.msg.corp.akamai.com> Are you trying to be proscriptive (say what people should use) or descriptive (document what is in use)? Yes, PKCS8-based PRIVATE KEY is better. But RSA PRIVATE KEY is in (wide) use and should be described. From rt at openssl.org Thu Dec 18 14:31:49 2014 From: rt at openssl.org (Fedor Indutny via RT) Date: Thu, 18 Dec 2014 15:31:49 +0100 Subject: [openssl-dev] [openssl.org #3637] [PATCH] x509: skip certs if in alternative cert chain In-Reply-To: References: Message-ID: In situations like [0] the server may provide alternative certificate chain, which is no longer valid in the current certificate store. In fact the issuer of the leaf (or some intermediate) cert is known and trusted, but the alternative chain certs that are sent by server are not trusted, thus leading to `ctx->get_issuer(...)` return 0. This patch changes the default behavior from "borking out the whole sent chain" to "pop as much certs as needed to make it work". Basically, it pops the last cert and checks if the previous has known issuer. [0]: https://bugzilla.mozilla.org/show_bug.cgi?id=986005#c4 -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJUkm/WAAoJENcGPM4Zt+iQO1UQAIIWnbOwB4DG3rT2E3GFQ3JU gk2LFDFhrWgCmTPLki8TDkR664SimPYcMsI9Vg0v3v5PecQQaW2O/BLDYEJiZ07E 2nSQCI8APp10jIdt0QUmehP4uHYAYkGxOBnGzypsrXFz2N5MV4XJG1jUZOsgIgod yZ2Vg8xTejnYrSJ/JfSNTBZy3s20wXDqh06TWNt6rn5o/AsT5l6/JVvC7Vi1DnNu LcddPrCm2tiaUqVQP+Kn5tfYKGhACTGjnCi89t67rYYbZwxLN2YpgspB3Kv8aR4P WMofhpZocAZ/uBQcshWe/ExiFsJESQazmM5KYLrVrLsa/hWYLx2E6Dl/N+6IvsUX 8eoG0QFa25iTRv+gLxXEiKca6EPuOWBm6kcz169nyogKBRBzASk3DMwK6TdOfiXI 5uw3zBByiI/DDaBQW62x1KTkTfrcg0pWZHurEVrSK7USr2nGLxI87IWq/e6kcd6x QbkWmOY5qGoRVoBPjxeVowd5EfyaH2cM7bJLqXcNncYAEmIpvTUEN6YFbyUg2Nuc DaqSUx6UrPOo3M2kyiqDdGz75Xq57ncWByvJ4Dj8DNqyxOliFG8Mldz7vDUYFbHt aKR2UqehGsYZbnw/mFDRRtQ2WliB/BEtjISVKl7KPNgkv5twrZF7fMU/Oh3Mf7pe Jiw6SKPj0JctQF8xpO5J =4E+B -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-x509-skip-certs-if-in-alternative-cert-chain.patch Type: application/octet-stream Size: 1828 bytes Desc: not available URL: From rt at openssl.org Fri Dec 19 09:18:11 2014 From: rt at openssl.org (Piotr Sikora via RT) Date: Fri, 19 Dec 2014 10:18:11 +0100 Subject: [openssl-dev] [openssl.org #3638] [PATCH] Fix build with -DOPENSSL_NO_SRTP In-Reply-To: References: Message-ID: Hey guys, 1.0.2-stable and master are currently broken when building with -DOPENSSL_NO_SRTP. Attached patches fix that. Best regards, Piotr Sikora -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSSL_1_0_2__Fix-build-with-DOPENSSL_NO_SRTP.patch Type: application/octet-stream Size: 7489 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenSSL_master__Fix-build-with-DOPENSSL_NO_SRTP.patch Type: application/octet-stream Size: 7555 bytes Desc: not available URL: From dev+openssl at seantek.com Fri Dec 19 10:33:10 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Fri, 19 Dec 2014 02:33:10 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F83C@USMBX1.msg.corp.akamai.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> <549278B7.8060304@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F83C@USMBX1.msg.corp.akamai.com> Message-ID: <5493FEE6.3070604@seantek.com> On 12/18/2014 4:41 AM, Salz, Rich wrote: > Are you trying to be proscriptive (say what people should use) or descriptive (document what is in use)? > > Yes, PKCS8-based PRIVATE KEY is better. But RSA PRIVATE KEY is in (wide) use and should be described. I am trying to be proscriptively descriptive about what is in use and will lead to (continued) interoperability. In the case of the * PRIVATE KEY labels, not a lot of crypto software supports it. The two biggest ones that I know of are OpenSSL and PolarSSL. (To my knowledge PolarSSL only supports "RSA PRIVATE KEY" and "EC PRIVATE KEY"--all others need to be in "PRIVATE KEY" PKCS #8 format.) These two OSS implementations may in fact "dominate" the market but only a certain market segment (namely web servers, and by extension, the web interfaces to web servers by web hosting companies). If you want to import a private key into Mac OS X, Mozilla NSS, Microsoft CryptoAPI, or the Java VM, you need to package it up (typically with a certificate) in a PKCS #12 file. PKCS #1 is an IETF (adopted) standard but PKCS #1 doesn't prescribe the "RSA PRIVATE KEY" label; it only defines the ASN.1 (BER/DER) representation. And PKCS #1 is no more or less a standard than the other IETF documents for the other key types, like Diffie-Hellman, ECC, etc. Anyway, the document was approved so it should be published with *minor* changes as an RFC soon. I am loathe to add new labels/formats; I am not convinced the threshold is met here. Cheers, Sean From dthompson at prinpay.com Fri Dec 19 10:50:25 2014 From: dthompson at prinpay.com (Dave Thompson) Date: Fri, 19 Dec 2014 05:50:25 -0500 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F83C@USMBX1.msg.corp.akamai.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F6DC@USMBX1.msg.corp.akamai.com> <549278B7.8060304@seantek.com> <2A0EFB9C05D0164E98F19BB0AF3708C71D54F0F83C@USMBX1.msg.corp.akamai.com> Message-ID: <001701d01b79$9e430710$dac91530$@prinpay.com> > From: openssl-dev On Behalf Of Salz, Rich > Sent: Thursday, December 18, 2014 07:42 > Are you trying to be proscriptive (say what people should use) or descriptive > (document what is in use)? > > Yes, PKCS8-based PRIVATE KEY is better. But RSA PRIVATE KEY is in (wide) > use and should be described. > E.g. Wireshark uses -- or did when I looked a few versions ago -- only the legacy RSA PRIVATE KEY form or PKCS12 not the PKCS8 PRIVATE KEY form. (PEM_read_*PrivateKey silently handles either legacy or PKCS8, but Wireshark doesn't use OpenSSL it uses GnuTLS.) There are also legacy DSA PRIVATE KEY and EC PRIVATE KEY. On the whole these algorithms and keys were not used as much as RSA in the past (EC is now rising) but they were used and may still exist. Technically there are legacy formats and IMPLEMENT_PEM routines for specific RSA,DSA,EC PUBLIC KEY. But "PUBKEY" (SPKI) has been default for at least 10 years, so these are probably very very little used. From dkg at fifthhorseman.net Fri Dec 19 13:47:55 2014 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 19 Dec 2014 08:47:55 -0500 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141218094228.GA2150@roeckx.be> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> Message-ID: <54942C8B.3070209@fifthhorseman.net> On 12/18/2014 04:42 AM, Kurt Roeckx wrote: > On Wed, Dec 17, 2014 at 08:34:52PM +0100, Erwann Abalea wrote: >> Le 17/12/2014 20:17, Viktor Dukhovni a ?crit : >>> On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote: >>> >>>> For reference for the group (in case you didn't take a look at the draft), >>>> the draft documents the following labels: >>>> >>>> CERTIFICATE >>>> ... >>> Perhaps also "TRUSTED CERTIFICATE"? >>> >>> crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE" >> >> It's specific to OpenSSL. > > And it would be useful if it wasn't. It might be useful, but getting the semantics right of what "TRUSTED CERTIFICATE" actually means is a non-trivial task. I'm not convinced that OpenSSL's interpretation of it is particularly useful in many common contexts. Does OpenSSL have documented someplace exactly what it means to have a "TRUSTED CERTIFICATE"? For example, say we're talking about a certificate that i am willing to accept for the peer foo.example. If i mark it TRUSTED and it has another SubjectAltName of bar.example, will OpenSSL subsequently accept it for bar.example as well? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 949 bytes Desc: OpenPGP digital signature URL: From dev+openssl at seantek.com Fri Dec 19 15:02:29 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Fri, 19 Dec 2014 07:02:29 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54942C8B.3070209@fifthhorseman.net> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> Message-ID: <54943E05.5040402@seantek.com> On 12/19/2014 5:47 AM, Daniel Kahn Gillmor wrote: > On 12/18/2014 04:42 AM, Kurt Roeckx wrote: >> On Wed, Dec 17, 2014 at 08:34:52PM +0100, Erwann Abalea wrote: >>> Le 17/12/2014 20:17, Viktor Dukhovni a ?crit : >>>> On Wed, Dec 17, 2014 at 10:56:34AM -0800, Sean Leonard wrote: >>>> >>>>> For reference for the group (in case you didn't take a look at the draft), >>>>> the draft documents the following labels: >>>>> >>>>> CERTIFICATE >>>>> ... >>>> Perhaps also "TRUSTED CERTIFICATE"? >>>> >>>> crypto/pem/pem.h:#define PEM_STRING_X509_TRUSTED "TRUSTED CERTIFICATE" >>> It's specific to OpenSSL. >> And it would be useful if it wasn't. > It might be useful, but getting the semantics right of what "TRUSTED > CERTIFICATE" actually means is a non-trivial task. I'm not convinced > that OpenSSL's interpretation of it is particularly useful in many > common contexts. > > Does OpenSSL have documented someplace exactly what it means to have a > "TRUSTED CERTIFICATE"? > > For example, say we're talking about a certificate that i am willing to > accept for the peer foo.example. If i mark it TRUSTED and it has > another SubjectAltName of bar.example, will OpenSSL subsequently accept > it for bar.example as well? I actually wrote something up in an e-mail to the IESG a few days ago......... The headers that OpenSSL recognizes in various portions include those found in: /crypto/pem/pem.h [SNIP] There is also a "TRUSTED CERTIFICATE" label that OpenSSL uses...I believe this is a vendor-specific extension but now that I am spelunking through the source code I see that it could be abused. Relevant source code/comments say: https://www.openssl.org/docs/apps/x509.html A*trusted certificate*is an ordinary certificate which has several additional pieces of information attached to it such as the permitted and prohibited uses of the certificate and an "alias". Normally when a certificate is being verified at least one certificate must be "trusted". By default a trusted certificate must be stored locally and must be a root CA: any certificate chain ending in this CA is then usable for any purpose. Trust settings currently are only used with a root CA. They allow a finer control over the purposes the root CA can be used for. For example a CA may be trusted for SSL client but not SSL server use. See the description of the*verify*utility for more information on the meaning of trust settings. Future versions of OpenSSL will recognize trust settings on any certificate: not just root CAs. *) Extensive changes to support certificate auxiliary information. This involves the use of X509_CERT_AUX structure and X509_AUX functions. An X509_AUX function such as PEM_read_X509_AUX() can still read in a certificate file in the usual way but it will also read in any additional "auxiliary information". By doing things this way a fair degree of compatibility can be retained: existing certificates can have this information added using the new 'x509' options. Current auxiliary information includes an "alias" and some trust settings. The trust settings will ultimately be used in enhanced certificate chain verification routines: currently a certificate can only be trusted if it is self signed and then it is trusted for all purposes. [Steve Henson] /* X509_CERT_AUX routines. These are used to encode additional * user modifiable data about a certificate. This data is * appended to the X509 encoding when the *_X509_AUX routines * are used. This means that the "traditional" X509 routines * will simply ignore the extra data. */ ASN1_SEQUENCE(X509_CERT_AUX) = { ASN1_SEQUENCE_OF_OPT(X509_CERT_AUX, trust, ASN1_OBJECT), ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, reject, ASN1_OBJECT, 0), ASN1_OPT(X509_CERT_AUX, alias, ASN1_UTF8STRING), ASN1_OPT(X509_CERT_AUX, keyid, ASN1_OCTET_STRING), ASN1_IMP_SEQUENCE_OF_OPT(X509_CERT_AUX, other, X509_ALGOR, 1) } ASN1_SEQUENCE_END(X509_CERT_AUX) From openssl-users at dukhovni.org Fri Dec 19 15:05:32 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Dec 2014 15:05:32 +0000 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54942C8B.3070209@fifthhorseman.net> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> Message-ID: <20141219150531.GB24649@mournblade.imrryr.org> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: > Does OpenSSL have documented someplace exactly what it means to have a > "TRUSTED CERTIFICATE"? It is a certificate + auxiliary data which specifies a friendly name plus a set of EKUs. > For example, say we're talking about a certificate that i am willing to > accept for the peer foo.example. If i mark it TRUSTED and it has > another SubjectAltName of bar.example, will OpenSSL subsequently accept > it for bar.example as well? http://marc.info/?l=openssl-dev&m=115218769327835&w=2 There is no explicit association with a particular peer, it is up to the application to add corresponding "trusted certificates" to the store when validating particular peers for which such certificates have been configured. If such a certificate is added to the default store, then it will apply to all cases with a matching EKU. -- Viktor. From openssl-users at dukhovni.org Fri Dec 19 15:09:07 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 19 Dec 2014 15:09:07 +0000 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54943E05.5040402@seantek.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <54943E05.5040402@seantek.com> Message-ID: <20141219150906.GC24649@mournblade.imrryr.org> On Fri, Dec 19, 2014 at 07:02:29AM -0800, Sean Leonard wrote: > There is also a "TRUSTED CERTIFICATE" label that OpenSSL uses...I believe > this is a vendor-specific extension but now that I am spelunking through the > source code I see that it could be abused. Relevant source code/comments > say: > https://www.openssl.org/docs/apps/x509.html What is this "abuse" you speak of. No remote actor injects "trusted certificates" into the verifier's list of trust anchors. Trusted certificates are actually "less trusted" certificates, in that their set of EKUs is potentially constrained. -- Viktor. From rt at openssl.org Fri Dec 19 16:08:29 2014 From: rt at openssl.org (Matthias Mucha via RT) Date: Fri, 19 Dec 2014 17:08:29 +0100 Subject: [openssl-dev] [openssl.org #3631] Bug in the binary search in OBJ_bsearch_ex_ in obj_dat.c (1.0.1j) In-Reply-To: <54944D6F.2070308@jojema.de> References: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> <54944D6F.2070308@jojema.de> Message-ID: No, i commented out the RSA encrypt routines and several other things that i can't/don't use. This resulted in a smaller array to search, which led me to this problem. I know it's no problem if you use OpenSSL the normal way. I don't call it from my code. My code only calls methods available in the OpenSSL API. Am 17.12.2014 14:51, schrieb Richard Levitte via RT: > Are you using OBJ_bsearch_ex_ directly from your code? It seems to me that you > have misunderstood how it works. size is the size of one element of your array, > num is the number of elements. The actual size of the array (in bytes) should > then be size*num, and you need to make sure that it is. > > I would, however, recommend that you don't call this function directly, and > instead use the macro OBJ_bsearch_ex, which will calculate the element size > properly for you, given a type that you give it. > > On Fri Dec 12 17:52:07 2014, matthias.mucha at jojema.de wrote: >> Hello, >> >> I strapped down OpenSSL 1.0.1j to only the PEM to RSA, BIO and RSA >> public >> decrypt functions. So a bug in the binary search in appeared: >> >> Current code: >> >> const void *OBJ_bsearch_ex_(const void *key, const void *base_, int >> num, >> int size, >> int (*cmp)(const void *, const void *), >> int flags) >> { >> const char *base=base_; >> int l,h,i=0,c=0; >> const char *p = NULL; >> >> if (num == 0) return(NULL); >> l=0; >> h=num; >> while (l < h) >> { >> i=(l+h)/2; >> p= &(base[i*size]); >> c=(*cmp)(key,p); >> if (c < 0) >> h=i; >> else if (c > 0) >> l=i+1; >> else >> break; >> } >> >> >> [...] >> >> My case: size = 4 >> num = 4 >> >> In the first round i evaluates to 2 which can not be divided by size >> and lets p >> escape the frame for the pointers, which results in a segfault. >> >> General case: >> >> This will fail for every case where num < (size * 2) >> >> >> My fix: >> >> const void *OBJ_bsearch_ex_(const void *key, const void *base_, int >> num, >> int size, >> int (*cmp)(const void *, const void *), >> int flags) >> { >> const char *base=base_; >> int l,h,i=0,c=0; >> const char *p = NULL; >> >> if (num == 0) return(NULL); >> if (num < size*2) { >> while(i> { >> p=&(base[i*size]); >> c=(*cmp)(key,p); >> if (!c) break; >> else ++i; >> } >> } >> else { >> l=0; >> h=num; >> while (l < h) >> { >> i=(l+h)/2; >> p= &(base[i*size]); >> c=(*cmp)(key,p); >> if (c < 0) >> h=i; >> else if (c > 0) >> l=i+1; >> else >> break; >> } >> } >> >> [...] >> >> Regards >> >> Matthias Mucha >> > > -- > Richard Levitte > levitte at openssl.org > From kurt at roeckx.be Fri Dec 19 19:35:02 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 19 Dec 2014 20:35:02 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141219150531.GB24649@mournblade.imrryr.org> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> Message-ID: <20141219193502.GA2538@roeckx.be> On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: > On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: > > > Does OpenSSL have documented someplace exactly what it means to have a > > "TRUSTED CERTIFICATE"? > > It is a certificate + auxiliary data which specifies a friendly name > plus a set of EKUs. Mozilla provides a list of root certificates and that includes at least the trust settings for that certificate. In Debian we then extract the certificates from that so that it can be used by applications that need to have a list of trusted CAs. However those trust settings are removed because not everything that wants to use those certificates understands the trusted certificate. It would be useful to have a standardised format. Kurt From dev+openssl at seantek.com Fri Dec 19 22:52:16 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Fri, 19 Dec 2014 14:52:16 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141219193502.GA2538@roeckx.be> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> <20141219193502.GA2538@roeckx.be> Message-ID: <828D902F-4072-4421-82E5-5B721064C381@seantek.com> On Dec 19, 2014, at 11:35 AM, Kurt Roeckx wrote: > On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: >> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: >> >>> Does OpenSSL have documented someplace exactly what it means to have a >>> "TRUSTED CERTIFICATE"? >> >> It is a certificate + auxiliary data which specifies a friendly name >> plus a set of EKUs. > > Mozilla provides a list of root certificates and that includes at > least the trust settings for that certificate. What exactly is the Mozilla (NSS) format? How does it differ from the OpenSSL format? Sean From openssl-dev at openssl.org Fri Dec 19 23:34:42 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Fri, 19 Dec 2014 18:34:42 -0500 Subject: [openssl-dev] TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (5.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [194.97.152.144 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Fri, 19 Dec 2014 18:34:42 -0500 Size: 1730 URL: From steve at openssl.org Sat Dec 20 14:29:44 2014 From: steve at openssl.org (Dr. Stephen Henson) Date: Sat, 20 Dec 2014 14:29:44 +0000 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <828D902F-4072-4421-82E5-5B721064C381@seantek.com> References: <54915CD4.1050805@seantek.com> <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> <20141219193502.GA2538@roeckx.be> <828D902F-4072-4421-82E5-5B721064C381@seantek.com> Message-ID: <20141220142944.GA12832@openssl.org> On Fri, Dec 19, 2014, Sean Leonard wrote: > > On Dec 19, 2014, at 11:35 AM, Kurt Roeckx wrote: > > > On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: > >> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: > >> > >>> Does OpenSSL have documented someplace exactly what it means to have a > >>> "TRUSTED CERTIFICATE"? > >> > >> It is a certificate + auxiliary data which specifies a friendly name > >> plus a set of EKUs. > > > > Mozilla provides a list of root certificates and that includes at > > least the trust settings for that certificate. > > What exactly is the Mozilla (NSS) format? How does it differ from the OpenSSL format? > The last time I checked NSS stored the trust data in a database (Berkeley DB) and the trust attributes could be accessed via PKCS#11. I'm not aware of any way to export the certificates to a file which retains the trust settings. I'm not aware of any standard for trust settings. There certainly wasn't one when this was added to OpenSSL. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Dec 20 14:49:18 2014 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 20 Dec 2014 15:49:18 +0100 Subject: [openssl-dev] [openssl.org #3470] [BUG] DTLS abort In-Reply-To: <24ee468b-28a9-4230-84d1-b84a99669a08@default> References: <24ee468b-28a9-4230-84d1-b84a99669a08@default> Message-ID: Ticket resolved. Thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sat Dec 20 19:14:25 2014 From: rt at openssl.org (Martin Kaiser via RT) Date: Sat, 20 Dec 2014 20:14:25 +0100 Subject: [openssl-dev] [openssl.org #3639] document the -no_comp command line option In-Reply-To: <20141220152505.GA4409@reykholt.kaiser.cx> References: <20141220152505.GA4409@reykholt.kaiser.cx> Message-ID: Dear all, both s_client and s_server support the -no_comp option to disable SSL/TLS-level compression. This is quite handy for testing but it's not listed in the man pages. The attached patch adds -no_comp to the man pages and usage outputs. Best regards, Martin -------------- next part -------------- A non-text attachment was scrubbed... Name: no_comp.patch Type: text/x-diff Size: 2856 bytes Desc: not available URL: From openssl-dev at openssl.org Sat Dec 20 09:44:39 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Sat, 20 Dec 2014 04:44:39 -0500 Subject: [openssl-dev] TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (5.7 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [194.97.152.144 listed in wl.mailspike.net] 0.5 DATE_IN_PAST_24_48 Date: is 24 to 48 hours before Received: date 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Sat, 20 Dec 2014 04:44:39 -0500 Size: 1626 URL: From kurt at roeckx.be Sun Dec 21 16:33:42 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Sun, 21 Dec 2014 17:33:42 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141220142944.GA12832@openssl.org> References: <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> <20141219193502.GA2538@roeckx.be> <828D902F-4072-4421-82E5-5B721064C381@seantek.com> <20141220142944.GA12832@openssl.org> Message-ID: <20141221163341.GA20767@roeckx.be> On Sat, Dec 20, 2014 at 02:29:44PM +0000, Dr. Stephen Henson wrote: > On Fri, Dec 19, 2014, Sean Leonard wrote: > > > > > On Dec 19, 2014, at 11:35 AM, Kurt Roeckx wrote: > > > > > On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: > > >> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: > > >> > > >>> Does OpenSSL have documented someplace exactly what it means to have a > > >>> "TRUSTED CERTIFICATE"? > > >> > > >> It is a certificate + auxiliary data which specifies a friendly name > > >> plus a set of EKUs. > > > > > > Mozilla provides a list of root certificates and that includes at > > > least the trust settings for that certificate. > > > > What exactly is the Mozilla (NSS) format? How does it differ from the OpenSSL format? > > > > The last time I checked NSS stored the trust data in a database (Berkeley DB) > and the trust attributes could be accessed via PKCS#11. I'm not aware of any > way to export the certificates to a file which retains the trust settings. > > I'm not aware of any standard for trust settings. There certainly wasn't > one when this was added to OpenSSL. The source is actually a text file you can see here: https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt As far as I know they turn the file into a database, not the other way around. Kurt From dev+openssl at seantek.com Sun Dec 21 20:39:02 2014 From: dev+openssl at seantek.com (Sean Leonard) Date: Sun, 21 Dec 2014 12:39:02 -0800 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <20141221163341.GA20767@roeckx.be> References: <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> <20141219193502.GA2538@roeckx.be> <828D902F-4072-4421-82E5-5B721064C381@seantek.com> <20141220142944.GA12832@openssl.org> <20141221163341.GA20767@roeckx.be> Message-ID: <54972FE6.2090200@seantek.com> On 12/21/2014 8:33 AM, Kurt Roeckx wrote: > On Sat, Dec 20, 2014 at 02:29:44PM +0000, Dr. Stephen Henson wrote: >> On Fri, Dec 19, 2014, Sean Leonard wrote: >> >>> On Dec 19, 2014, at 11:35 AM, Kurt Roeckx wrote: >>> >>>> On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: >>>>> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: >>>>> >>>>>> Does OpenSSL have documented someplace exactly what it means to have a >>>>>> "TRUSTED CERTIFICATE"? >>>>> It is a certificate + auxiliary data which specifies a friendly name >>>>> plus a set of EKUs. >>>> Mozilla provides a list of root certificates and that includes at >>>> least the trust settings for that certificate. >>> What exactly is the Mozilla (NSS) format? How does it differ from the OpenSSL format? >>> >> The last time I checked NSS stored the trust data in a database (Berkeley DB) >> and the trust attributes could be accessed via PKCS#11. I'm not aware of any >> way to export the certificates to a file which retains the trust settings. >> >> I'm not aware of any standard for trust settings. There certainly wasn't >> one when this was added to OpenSSL. > The source is actually a text file you can see here: > https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt > > As far as I know they turn the file into a database, not the other > way around. Ok. Overall I am not convinced that trust settings are the proper subject of interchange between different products. There is a standard validation algorithm (RFC 5280, etc.); however, the algorithm is super-complicated and very few people implement all of its permutations, especially things related to the esoteric name types and name constraints (who implements directory name constraints, for example??). There is also ambiguity/non-standardization around how EKU trust settings are propagated/enforced. If you wanted to record this information, I believe that PKCS #12 is the right format for the job. PKCS #12 is convoluted and a lot of people hate it for good reasons, but PKCS #12 allows you to transmit arbitrary attributes alongside certificates, private keys, and other crypto objects. Thus if you want to annotate a certificate with a friendly name (alias) or a special key identifier, there are interoperable ways to do that. The complicated part then becomes what trust settings are interoperable, not the particular packaging format involved. draft-josefsson-pkix-textual prohibits header annotations inside the textual format, because they are not interoperable. (This is a departure from PEM [RFC1421], which is based on e-mail messages, which allows for headers prior to the base64-encoded body.) Other non-pkix-textual formats, such as the OpenSSH Public Key File Format [RFC4716], make extensive use of headers. On that point, that was another reason why I did not include RSA PRIVATE KEY. For the command: openssl genrsa -aes256 2048 You get: Generating RSA private key, 2048 bit long modulus ...........+++ ..................................................+++ e is 65537 (0x10001) Enter pass phrase: Verifying - Enter pass phrase: -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,5CD4A83156BC97F69CD537D5A2AC1B53 k1QsZFahAmPsiiZUNy4q4njus3QYEtwBmCuGb1Q1d6mpqtLiokv+hdDwk9i/POtV ... -----END RSA PRIVATE KEY----- ...this is (basically) RFC 1421 PEM format, which is not the same as pkix-textual. Another way to do it would be for a product to have one product-specific root "certificate", which then has subordinate "certificates" that have all of the RFC 5280-compliant constraints applied to them and that are used as cross-certificates for the actual root CA certificates. Thus if you wanted to restrict Acme Corp's certs to *.acme.com and the Government of the People's Republic of China's certificates to *.cn (DNS) and *@*.cn (e-mail), you would create a master root OpenSSL product "certificate", and issue subordinate CA certs to the "real" roots. I put "certificate" in quotes above because the implementation should not expose the root product "certificate" or the subordinate "certificates" on the wire (as might be done with TLS or CMS/S/MIME). They are not supposed to be real "certificates" but rather just a way to reuse most of the validation code. Sean From rt at openssl.org Mon Dec 22 08:06:04 2014 From: rt at openssl.org (=?UTF-8?B?VGltbyBUZXLDpHM=?= via RT) Date: Mon, 22 Dec 2014 09:06:04 +0100 Subject: [openssl-dev] [openssl.org #3505] rewrite c_rehash in C In-Reply-To: <20141222094114.77b65ef1@vostro> References: <20140826080238.3ff27321@vostro> <2A0EFB9C05D0164E98F19BB0AF3708C7185A847858@USMBX1.msg.corp.akamai.com> <20140826194406.572246e0@vostro> <2A0EFB9C05D0164E98F19BB0AF3708C7185A847AAE@USMBX1.msg.corp.akamai.com> <20141001143918.2bac2d18@vostro> <20141222094114.77b65ef1@vostro> Message-ID: Find attached first draft of patch that adds it as openssl 'app'. This is against latest stable release, but should be easily ported to master. I can also rebase in future against the git branch of choice. Please review. I might have also missed something when modifying the build system changes, as I'm not fully familiar with it yet. Thanks, Timo -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-rehash.patch Type: text/x-patch Size: 11669 bytes Desc: not available URL: From erwann.abalea at opentrust.com Mon Dec 22 10:13:06 2014 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Mon, 22 Dec 2014 11:13:06 +0100 Subject: [openssl-dev] OpenSSL and certain PEM formats In-Reply-To: <54972FE6.2090200@seantek.com> References: <20141217180006.GA15403@openssl.org> <5491D1E2.30604@seantek.com> <20141217191709.GD25666@mournblade.imrryr.org> <5491DADC.2020809@opentrust.com> <20141218094228.GA2150@roeckx.be> <54942C8B.3070209@fifthhorseman.net> <20141219150531.GB24649@mournblade.imrryr.org> <20141219193502.GA2538@roeckx.be> <828D902F-4072-4421-82E5-5B721064C381@seantek.com> <20141220142944.GA12832@openssl.org> <20141221163341.GA20767@roeckx.be> <54972FE6.2090200@seantek.com> Message-ID: <5497EEB2.9000701@opentrust.com> Le 21/12/2014 21:39, Sean Leonard a ?crit : > On 12/21/2014 8:33 AM, Kurt Roeckx wrote: >> On Sat, Dec 20, 2014 at 02:29:44PM +0000, Dr. Stephen Henson wrote: >>> On Fri, Dec 19, 2014, Sean Leonard wrote: >>> >>>> On Dec 19, 2014, at 11:35 AM, Kurt Roeckx wrote: >>>> >>>>> On Fri, Dec 19, 2014 at 03:05:32PM +0000, Viktor Dukhovni wrote: >>>>>> On Fri, Dec 19, 2014 at 08:47:55AM -0500, Daniel Kahn Gillmor wrote: >>>>>> >>>>>>> Does OpenSSL have documented someplace exactly what it means to >>>>>>> have a >>>>>>> "TRUSTED CERTIFICATE"? >>>>>> It is a certificate + auxiliary data which specifies a friendly name >>>>>> plus a set of EKUs. >>>>> Mozilla provides a list of root certificates and that includes at >>>>> least the trust settings for that certificate. >>>> What exactly is the Mozilla (NSS) format? How does it differ from >>>> the OpenSSL format? >>>> >>> The last time I checked NSS stored the trust data in a database >>> (Berkeley DB) >>> and the trust attributes could be accessed via PKCS#11. I'm not >>> aware of any >>> way to export the certificates to a file which retains the trust >>> settings. >>> >>> I'm not aware of any standard for trust settings. There certainly >>> wasn't >>> one when this was added to OpenSSL. >> The source is actually a text file you can see here: >> https://mxr.mozilla.org/mozilla-central/source/security/nss/lib/ckfw/builtins/certdata.txt >> >> >> As far as I know they turn the file into a database, not the other >> way around. > > Ok. > > Overall I am not convinced that trust settings are the proper subject > of interchange between different products. There is a standard > validation algorithm (RFC 5280, etc.); however, the algorithm is > super-complicated and very few people implement all of its > permutations, especially things related to the esoteric name types and > name constraints (who implements directory name constraints, for > example??). OpenSSL implements it, so does Microsoft. I don't know if NSS::libpkix implements it, I'm sure NSS:pkix (its recent successor) doesn't. Apple doesn't know about NameConstraints. I don't know about GnuTLS, but I doubt it does. > There is also ambiguity/non-standardization around how EKU trust > settings are propagated/enforced. This is a step first taken by Microsoft for public CAs, recently adopted by Mozilla. It's completely non standard. The function offered by this "EKU constraints" logic is normally offered by the CertificatePolicies extension, but: - it was only used to distinguish EV TLS certs from the rest - it's very hard to make it work in practice when considering a lot of public CAs and different usages [...] > Another way to do it would be for a product to have one > product-specific root "certificate", which then has subordinate > "certificates" that have all of the RFC 5280-compliant constraints > applied to them and that are used as cross-certificates for the actual > root CA certificates. Thus if you wanted to restrict Acme Corp's certs > to *.acme.com and the Government of the People's Republic of China's > certificates to *.cn (DNS) and *@*.cn (e-mail), you would create a > master root OpenSSL product "certificate", and issue subordinate CA > certs to the "real" roots. Something like this? NameConstraints { permittedSubTrees { { base.dNSName: "cn" }, { base.emailAddress: "cn" }, { base.emailAddress: ".cn" } } } It doesn't restrict IP addresses, it also doesn't address restrictions on the type of certificate use (CP/EKU/...). From rt at openssl.org Mon Dec 22 11:50:09 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 12:50:09 +0100 Subject: [openssl-dev] [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function In-Reply-To: References: <5476EFF4.2020305@openssl.org> <5476F082.7060201@openssl.org> Message-ID: On Thu Nov 27 16:59:36 2014, praveen at viptela.com wrote: > Thanks Matt. Will keep you posted on 1. > > Coming back to the original crash. Here is some update. > > Our server started seeing the crash and leaks, after our negative stress > testing suite added some pmtu testcases. i.e., during 1000s of connections > the underlying mtu(s) were changed (very low - to high) randomly and > frequently. Once we reduced the frequency the server held up. Does that > give u some clue ? Hi Praveen Are you still experiencing thse problems? There have been some significant commits in the stable branch recently with regards to DTLS mtu handing which might address your issues. Matt From rt at openssl.org Mon Dec 22 12:05:34 2014 From: rt at openssl.org (Praveen Kariyanahalli via RT) Date: Mon, 22 Dec 2014 13:05:34 +0100 Subject: [openssl-dev] [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function In-Reply-To: References: <5476EFF4.2020305@openssl.org> <5476F082.7060201@openssl.org> Message-ID: Hi Matt No, we have not hit this issue for a while now. You can close the ticket. Thanks for following up. Just to make sure, we won't hit these issues . . We will upgrade to the latest stable version. Regards Praveen On Dec 22, 2014 3:50 AM, "Matt Caswell via RT" wrote: > On Thu Nov 27 16:59:36 2014, praveen at viptela.com wrote: > > Thanks Matt. Will keep you posted on 1. > > > > Coming back to the original crash. Here is some update. > > > > Our server started seeing the crash and leaks, after our negative stress > > testing suite added some pmtu testcases. i.e., during 1000s of > connections > > the underlying mtu(s) were changed (very low - to high) randomly and > > frequently. Once we reduced the frequency the server held up. Does that > > give u some clue ? > > Hi Praveen > > Are you still experiencing thse problems? There have been some significant > commits in the stable branch recently with regards to DTLS mtu handing > which > might address your issues. > > Matt > > From rt at openssl.org Mon Dec 22 12:09:21 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 13:09:21 +0100 Subject: [openssl-dev] [openssl.org #3608] SEGV Crash in dtls1_retransmit_message function In-Reply-To: References: Message-ID: On Mon Dec 22 13:05:34 2014, praveen at viptela.com wrote: > Hi Matt > > No, we have not hit this issue for a while now. You can close the ticket. > Thanks for following up. > > Just to make sure, we won't hit these issues . . We will upgrade to the > latest stable version. Ok. Closing this ticket. Just to clarify my previous comment...the mtu fixes are in the latest stable branch of *git*. They are not yet in a release. They will get rolled in next time we do a stable branch release. Matt From rt at openssl.org Mon Dec 22 12:26:35 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 13:26:35 +0100 Subject: [openssl-dev] [openssl.org #3623] faulting module ssleay32.dll, version 0.0.0.0, fault address 0x00010c8b. In-Reply-To: References: Message-ID: Hi Vijendra There is insufficient information from your description to determine whether this is a fault with OpenSSL or with your application. If this is still an issue for you, please raise it on the openssl-users email list. Since it cannot be determined that there is a problem OpenSSL itself I am closing this ticket for now. Regards Matt From rt at openssl.org Mon Dec 22 13:22:29 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Dec 2014 14:22:29 +0100 Subject: [openssl-dev] [openssl.org #3617] [PATCH] Improves certificates HOWTO doc In-Reply-To: References: Message-ID: Cool, thanks. I've applied your patch, it should be pushed pretty soon. On Mon Dec 01 10:43:29 2014, alok at squareup.com wrote: > Hey, > > The current documentation (hosted at > https://www.openssl.org/docs/HOWTO/certificates.txt) contains a few > spelling. It also contains placeholder references to documents which > now exist. Attached is my attempt to improve the doc. > > Alok -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 22 13:33:32 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Dec 2014 14:33:32 +0100 Subject: [openssl-dev] [openssl.org #3601] [PATCH] Improves the proxy certificates howto doc. In-Reply-To: References: Message-ID: Okie, applied, should appear in the repo pretty soon. On Sun Nov 30 09:22:17 2014, alok at squareup.com wrote: > Great. There is one minor typo left, patch attached. > > Alok > > On Fri, Nov 28, 2014 at 7:38 AM, Richard Levitte via RT > > wrote: > > > I just read them through, and it looks good, I just needed to do a > couple > > of > > layout adjustments. Committed. > > > > Thank you. > > > > On Sat Nov 15 11:17:51 2014, alok at squareup.com wrote: > > > Hi, > > > > > > The current documentation (hosted at > > > https://www.openssl.org/docs/HOWTO/proxy_certificates.txt) > contains a > > bunch > > > of spelling and grammar mistakes. I also found it hard to > understand some > > > paragraphs, so here is my attempt to improve its overall > readability. > > > > > > Alok > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 22 14:29:11 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Mon, 22 Dec 2014 15:29:11 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: Hmm... again asserts... s->init_num == 0 full backtrace attached... 2014-12-18 13:10 GMT+03:00 Matt Caswell via RT : > On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote: > > Thanks! Great! > > 6000 calls. No crashes or leaks.... only messages like this in > > asterisk > > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: > > DTLS > > failure occurred on RTP instance '0x298c1d68' due to reason 'digest > > check > > failed', terminating > > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: > > DTLS > > failure occurred on RTP instance '0x29d16508' due to reason 'digest > > check > > failed', terminating > > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: > > DTLS > > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest > > check > > failed', terminating > > > > But 99% call go normal. We will test on production server and high > > load. > > Good news. Let me know how the testing goes in production so that I can > (hopefully) close the ticket. > > Matt > > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: bt_full_2.zip Type: application/zip Size: 1670 bytes Desc: not available URL: From openssl-dev at openssl.org Sat Dec 20 09:07:38 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Sat, 20 Dec 2014 04:07:38 -0500 Subject: [openssl-dev] TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (5.2 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [194.97.152.144 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Sat, 20 Dec 2014 04:07:38 -0500 Size: 1626 URL: From rt at openssl.org Mon Dec 22 14:45:57 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 15:45:57 +0100 Subject: [openssl-dev] [openssl.org #3620] bug report ASN1_item_d2i causes memory leak In-Reply-To: References: Message-ID: On Tue Dec 02 22:50:07 2014, Luis.Garcia at csr.com wrote: > Hi, > > The bug list server of openssl is very slow to access, so I am not > sure if this bug has already been filed. > > When using the routine ASN1_item_d2i, the pointer passed as the "in" > variable gets modified in Whilst slightly unexpected behaviour this is indeed the documented API. See for example d2i_X509: https://www.openssl.org/docs/crypto/d2i_X509.html Closing this ticket. Matt From rt at openssl.org Mon Dec 22 14:52:15 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 15:52:15 +0100 Subject: [openssl-dev] [openssl.org #3611] Segmentation fault during SSL_free In-Reply-To: References: Message-ID: No response from OP so setting this ticket to stalled. Matt From rt at openssl.org Mon Dec 22 15:31:42 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Dec 2014 16:31:42 +0100 Subject: [openssl-dev] [openssl.org #3601] [PATCH] Improves the proxy certificates howto doc. In-Reply-To: References: Message-ID: Pushed, will appear in the next updates/releases from 1.0.1 and on. On Mon Dec 22 14:33:32 2014, levitte wrote: > Okie, applied, should appear in the repo pretty soon. > > On Sun Nov 30 09:22:17 2014, alok at squareup.com wrote: > > Great. There is one minor typo left, patch attached. > > > > Alok > > > > On Fri, Nov 28, 2014 at 7:38 AM, Richard Levitte via RT > > > > wrote: > > > > > I just read them through, and it looks good, I just needed to do a > > couple > > > of > > > layout adjustments. Committed. > > > > > > Thank you. > > > > > > On Sat Nov 15 11:17:51 2014, alok at squareup.com wrote: > > > > Hi, > > > > > > > > The current documentation (hosted at > > > > https://www.openssl.org/docs/HOWTO/proxy_certificates.txt) > > contains a > > > bunch > > > > of spelling and grammar mistakes. I also found it hard to > > understand some > > > > paragraphs, so here is my attempt to improve its overall > > readability. > > > > > > > > Alok > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 22 15:32:19 2014 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 22 Dec 2014 16:32:19 +0100 Subject: [openssl-dev] [openssl.org #3617] [PATCH] Improves certificates HOWTO doc In-Reply-To: References: Message-ID: Pushed, will appear in the next updates/releases from 1.0.1 and on. On Mon Dec 22 14:22:29 2014, levitte wrote: > Cool, thanks. I've applied your patch, it should be pushed pretty soon. > > On Mon Dec 01 10:43:29 2014, alok at squareup.com wrote: > > Hey, > > > > The current documentation (hosted at > > https://www.openssl.org/docs/HOWTO/certificates.txt) contains a few > > spelling. It also contains placeholder references to documents which > > now exist. Attached is my attempt to improve the doc. > > > > Alok > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org From rt at openssl.org Mon Dec 22 16:38:49 2014 From: rt at openssl.org (Shreyas Heranjal via RT) Date: Mon, 22 Dec 2014 17:38:49 +0100 Subject: [openssl-dev] [openssl.org #3611] Segmentation fault during SSL_free In-Reply-To: References: Message-ID: Hey Matt, Sorry, but we haven't hit this issue again in our code. I cleaned up some code with valgrind. Maybe that fixed some issues too. I will get back in touch with you if I come across this trace again. Thanks, Shreyas On Mon, Dec 22, 2014 at 6:52 AM, Matt Caswell via RT wrote: > No response from OP so setting this ticket to stalled. > > Matt > > From rt at openssl.org Mon Dec 22 16:41:59 2014 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 22 Dec 2014 17:41:59 +0100 Subject: [openssl-dev] [openssl.org #3611] Segmentation fault during SSL_free In-Reply-To: References: Message-ID: On Mon Dec 22 17:38:49 2014, shreyas at viptela.com wrote: > Hey Matt, > > Sorry, but we haven't hit this issue again in our code. I cleaned up some > code with valgrind. Maybe that fixed some issues too. I will get back in > touch with you if I come across this trace again. > Ok - thanks for the update Shreyas. I'll close this ticket for now. You can reopen it by replying to this message should this occur again. Regards Matt From rt at openssl.org Tue Dec 23 08:14:09 2014 From: rt at openssl.org (Luis Garcia via RT) Date: Tue, 23 Dec 2014 09:14:09 +0100 Subject: [openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak In-Reply-To: References: Message-ID: When using PKCS7_decrypt with the following parameters: BIO *bio = BIO_new(BIOS_s_mem()); PKCS7 pointer, EVP_PKEY pointer, X509 pointer, bio, 0. I am getting a memory leak of 568 bytes. I am developing on a linux OS with OpenSSL version 1.0.1e Let me know if I can provide any additional information. Thanks, Luis Enrique Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. From rt at openssl.org Tue Dec 23 09:52:58 2014 From: rt at openssl.org (Luis Garcia via RT) Date: Tue, 23 Dec 2014 10:52:58 +0100 Subject: [openssl-dev] [openssl.org #3640] Bug report: PKCS7_decrypt memory leak In-Reply-To: References: Message-ID: Just an update: I updated to the latest library available 1.0.1j and still got the same memory leak. Thanks, Luis Enrique ________________________________ From: Luis Garcia Sent: Monday, December 22, 2014 2:51 PM To: rt at openssl.org Subject: Bug report: PKCS7_decrypt memory leak When using PKCS7_decrypt with the following parameters: BIO *bio = BIO_new(BIOS_s_mem()); PKCS7 pointer, EVP_PKEY pointer, X509 pointer, bio, 0. I am getting a memory leak of 568 bytes. I am developing on a linux OS with OpenSSL version 1.0.1e Let me know if I can provide any additional information. Thanks, Luis Enrique Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom More information can be found at www.csr.com. Keep up to date with CSR on our technical blog, www.csr.com/blog, CSR people blog, www.csr.com/people, YouTube, www.youtube.com/user/CSRplc, Facebook, www.facebook.com/pages/CSR/191038434253534, or follow us on Twitter at www.twitter.com/CSR_plc. New for 2014, you can now access the wide range of products powered by aptX at www.aptx.com. From rt at openssl.org Tue Dec 23 13:53:32 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Tue, 23 Dec 2014 14:53:32 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: another crash. Double free. 2014-12-22 17:29 GMT+03:00 ???????? ??????? : > Hmm... again asserts... > s->init_num == 0 > > full backtrace attached... > > 2014-12-18 13:10 GMT+03:00 Matt Caswell via RT : > >> On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote: >> > Thanks! Great! >> > 6000 calls. No crashes or leaks.... only messages like this in >> > asterisk >> > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: >> > DTLS >> > failure occurred on RTP instance '0x298c1d68' due to reason 'digest >> > check >> > failed', terminating >> > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: >> > DTLS >> > failure occurred on RTP instance '0x29d16508' due to reason 'digest >> > check >> > failed', terminating >> > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: >> > DTLS >> > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest >> > check >> > failed', terminating >> > >> > But 99% call go normal. We will test on production server and high >> > load. >> >> Good news. Let me know how the testing goes in production so that I can >> (hopefully) close the ticket. >> >> Matt >> >> > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru -------------- next part -------------- A non-text attachment was scrubbed... Name: dlfree.zip Type: application/zip Size: 6430 bytes Desc: not available URL: From openssl at openssl.org Tue Dec 23 23:13:58 2014 From: openssl at openssl.org (OpenSSL) Date: Wed, 24 Dec 2014 00:13:58 +0100 Subject: [openssl-dev] OpenSSL 1.0.0 End Of Life Announcement Message-ID: <20141223231358.GA11866@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL 1.0.0 End Of Life Announcement ====================================== The OpenSSL Project is today making the following announcement: Support for version 1.0.0 will cease on 31st December 2015. No further releases of 1.0.0 will be made after that date. Security fixes only will be applied to 1.0.0 until then. Further details about the OpenSSL Release Strategy can be found here: https://www.openssl.org/about/releasestrat.html Yours, The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUmfUFAAoJENnE0m0OYESRxwsH/iTt11CUTKXj7IEJ6glp2TO4 EH8EaF1QJdh7nEDe71JHciEzLOJctEW+c8DSJUb54VmhxUAehSALQ4iU/SQGnlOK YZlg3jYhEE0WSfd+UtLsh6I5xK2l11z3fb3ncOlaqCHZMsuatFJRyZtKIKSIIFdG e/TaYmaZnBgTw3wQ9ThaVkeWGFTHtwlOyBIgbw9jF9DC7B/KRwpk7230/6Yv7Tz+ XDqeruYLiSj2IxW+hD1lWqoetLfHAWhvxSELjUxfH6BR5E/+kliDgHWlji/VfFl3 tl9OcAKbqUUVNMxYKDxgh7mkvdcATHrBoQ7spbR98EKG6QeNtVTYEEaCGFrYBIs= =tmun -----END PGP SIGNATURE----- From matt at openssl.org Tue Dec 23 23:49:51 2014 From: matt at openssl.org (Matt Caswell) Date: Tue, 23 Dec 2014 23:49:51 +0000 Subject: [openssl-dev] OpenSSL Release Strategy and Blog Message-ID: <5499FF9F.6040205@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement contained a link to the recently published OpenSSL Release Strategy that is available here: https://www.openssl.org/about/releasestrat.html I have put up a blog post on the thinking behind this strategy on the newly created OpenSSL Blog that you may (or may not!) find interesting. It can be found here: https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUmf+fAAoJENnE0m0OYESRtyoH+gPCygFa106fcsqTk2WhgUJi p9beEKsYTmBm7lgVcB4CrWBFPcXeEoVDnYCsv3dPngSaJo0h9NIzeJT6BjERXyxo wXOhm0EN6qbfCsecng6UWVdOorGUIe93+k7ZcyZ+21U9ydd60jIxJpBAK7QKO1jC 2T9W26VtGtgR2D7XxuZ7m8a+2WKTC+snpKKfUERZJ/eM306fnYJnIEvLw6ntupLe agv2kxYm3tKWi7LQcKn/OUo2JgcU60o+8M0s/KBshSe/R/EV1a5brUH7sHFH6wgS riHYTHvJ3QnDk1vwHlS2CPzdazMnhxBuXUJJ7d940BtsAHnL4l7Waf0e3e+YHsM= =SUZf -----END PGP SIGNATURE----- From dominyktiller at gmail.com Wed Dec 24 00:38:16 2014 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Wed, 24 Dec 2014 00:38:16 +0000 Subject: [openssl-dev] OpenSSL Release Strategy and Blog In-Reply-To: <5499FF9F.6040205@openssl.org> References: <5499FF9F.6040205@openssl.org> Message-ID: <549A0AF8.50409@gmail.com> Hey Matt, For some reason, this email is getting flagged as a bad signature by Enigmail. All of your previous emails checked out fine, but this one checked in with a big purple banner on it. Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 23/12/2014 23:49, Matt Caswell wrote: > > You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement > contained a link to the recently published OpenSSL Release Strategy that > is available here: > https://www.openssl.org/about/releasestrat.html > > I have put up a blog post on the thinking behind this strategy on the > newly created OpenSSL Blog that you may (or may not!) find interesting. > It can be found here: > https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ > > Matt > > > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From song.chen at siodata.com.cn Wed Dec 24 03:41:59 2014 From: song.chen at siodata.com.cn (chensong) Date: Tue, 23 Dec 2014 20:41:59 -0700 (MST) Subject: [openssl-dev] lh_OBJ_NAME_retrieve return NULL Message-ID: <1419392519332-55604.post@n7.nabble.com> hi everyone: i am working on verification signature of ECDMA-WITH-SHA256, i use openssl command tools of SMIME command can verify successfully(ver:1.0.1g), but my code got verified failure, and my code base is 1.0.1i, by tracking i found api of *lh_OBJ_NAME_retrieve* return NULL to lead to failure. my dev enviroment is vs2010. someone knows why this? thanx in advance Chen Song -- View this message in context: http://openssl.6102.n7.nabble.com/lh-OBJ-NAME-retrieve-return-NULL-tp55604.html Sent from the OpenSSL - Dev mailing list archive at Nabble.com. From yumkam at gmail.com Wed Dec 24 11:37:36 2014 From: yumkam at gmail.com (Yuriy Kaminskiy) Date: Wed, 24 Dec 2014 14:37:36 +0300 Subject: [openssl-dev] OpenSSL Release Strategy and Blog In-Reply-To: <549A0AF8.50409@gmail.com> References: <5499FF9F.6040205@openssl.org> <549A0AF8.50409@gmail.com> Message-ID: Dominyk Tiller wrote: > Hey Matt, > > For some reason, this email is getting flagged as a bad signature by > Enigmail. All of your previous emails checked out fine, but this one > checked in with a big purple banner on it. His user-agent messed up with line ending (wrapped overly long lines). Signature matched after replacing \n with space at end of lines 10, 9, 5, 4. > Sent from OS X. If you wish to communicate more securely my PGP Public > Key is 0x872524db9d74326c. > > On 23/12/2014 23:49, Matt Caswell wrote: >> You will have noticed that the OpenSSL 1.0.0 End Of Life Announcement >> contained a link to the recently published OpenSSL Release Strategy that >> is available here: >> https://www.openssl.org/about/releasestrat.html >> >> I have put up a blog post on the thinking behind this strategy on the >> newly created OpenSSL Blog that you may (or may not!) find interesting. >> It can be found here: >> https://www.openssl.org/blog/blog/2014/12/23/the-new-release-strategy/ From kurt at roeckx.be Wed Dec 24 10:26:27 2014 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 24 Dec 2014 11:26:27 +0100 Subject: [openssl-dev] OpenSSL Release Strategy and Blog In-Reply-To: <549A0AF8.50409@gmail.com> References: <5499FF9F.6040205@openssl.org> <549A0AF8.50409@gmail.com> Message-ID: <20141224102627.GA4550@roeckx.be> On Wed, Dec 24, 2014 at 12:38:16AM +0000, Dominyk Tiller wrote: > Hey Matt, > > For some reason, this email is getting flagged as a bad signature by > Enigmail. All of your previous emails checked out fine, but this one > checked in with a big purple banner on it. It verified without problems here (with mutt) Kurt From matt at openssl.org Thu Dec 25 00:02:59 2014 From: matt at openssl.org (Matt Caswell) Date: Thu, 25 Dec 2014 00:02:59 +0000 Subject: [openssl-dev] OpenSSL Release Strategy and Blog In-Reply-To: References: <5499FF9F.6040205@openssl.org> <549A0AF8.50409@gmail.com> Message-ID: <549B5433.2020206@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 24/12/14 11:37, Yuriy Kaminskiy wrote: > Dominyk Tiller wrote: >> Hey Matt, >> >> For some reason, this email is getting flagged as a bad signature >> by Enigmail. All of your previous emails checked out fine, but >> this one checked in with a big purple banner on it. > > His user-agent messed up with line ending (wrapped overly long > lines). Signature matched after replacing \n with space at end of > lines 10, 9, 5, 4. Ahhh...thanks. I've been trying to figure out what on earth happened. Seems to be a bug in Enigmail. I recently moved my email account to the new OpenSSL infrastructure. With my previous account I had Thunderbird set up to do plain text only email. With my new account I had neglected to untick the "HTML" option. Thunderbird seems to automatically break long lines in the composition editor when using plaintext, but not with HTML. I suspect that's why I've never had the problem before. Signing this email to check its working ok! Matt -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJUm1QzAAoJENnE0m0OYESRUeIH/2SE4NuRDlRudBy0VLARzqyr Aid/5xUy1rZwDER4aOH0TsHtkkQS16EjnMkaWXA3jtJ8wjLdDm1u1uCpnN8PSj3w iPVSowtEJNvWqj12uo7rGNoLDubIqoXkIn4sTVv/9pTvYk1ImhdIu4uCAs/33Y1s tR+3TaauldYVH9gO24XDVt2i1Zv6gnf+BIJ0iVNcXk+JrRzsJjsfcjFfo0TLh6Hj 3D2lVM+RYsvwsYh9ZPWM7uK1ehLhpmDUAGQxkHQr5gxWSzDY6sc9+E+V4dB65MXl V10nrnJbsT2J2IqqxnOCXhWn+1Sz0pAvhpVmpTgWfI4ckuy20k31bzJ6mWbxab0= =Jrwi -----END PGP SIGNATURE----- From rt at openssl.org Thu Dec 25 02:58:29 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Thu, 25 Dec 2014 03:58:29 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: New place crash (gdb) bt #0 0x00000037c9e32625 in raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 #1 0x00000037c9e33e05 in abort () at abort.c:92 #2 0x0000003dbac69e3f in OpenSSLDie (file=, line=, assertion=) at cryptlib.c:923 #3 0x0000003dbb03c220 in do_dtls1_write (s=0x7fff34010940, type=22, buf=0x7fff1c0ac007 "\v", len=243, create_empty_fragment=0) at d1_pkt.c:1484 #4 0x0000003dbb03faf1 in dtls1_do_write (s=0x7fff34010940, type=22) at d1_both.c:378 #5 0x0000003dbb038e07 in dtls1_accept (s=0x7fff34010940) at d1_srvr.c:426 #6 0x0000003dbb03d8ad in dtls1_read_bytes (s=0x7fff34010940, type=23, buf=0x7fff34059488 "\026\376\377", len=121, peek=0) at d1_pkt.c:787 #7 0x0000003dbb027ed0 in ssl3_read_internal (s=0x7fff34010940, buf=0x7fff34059488, len=121, peek=0) at s3_lib.c:4273 #8 0x00007fff9e952ef5 in __rtp_recvfrom (instance=0x7fff3405f288, buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370, rtcp=0) at res_rtp_asterisk.c:2019 #9 0x00007fff9e95331f in rtp_recvfrom (instance=0x7fff3405f288, buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370) at res_rtp_asterisk.c:2094 #10 0x00007fff9e95c621 in ast_rtp_read (instance=0x7fff3405f288, rtcp=0) at res_rtp_asterisk.c:4127 #11 0x0000000000551bcf in ast_rtp_instance_read (instance=0x7fff3405f288, rtcp=0) at rtp_engine.c:314 #12 0x00007fffb2ae07cd in sip_rtp_read (ast=0x7fff340ab648, p=0x7fff3402f588, faxdetect=0x7fff9aa1e604) at chan_sip.c:8192 #13 0x00007fffb2ae0f7c in sip_read (ast=0x7fff340ab648) at chan_sip.c:8289 #14 0x000000000047cb05 in __ast_read (chan=0x7fff340ab648, dropaudio=0) at channel.c:4054 #15 0x000000000047e8ae in ast_read (chan=0x7fff340ab648) at channel.c:4408 #16 0x00007fffa716ba1a in wait_for_answer (in=0x7fff340ab648, out_chans=0x7fff9aa20970, to=0x7fff9aa2096c, peerflags=0x7fff9aa20ec0, opt_args=0x7fff9aa201b0, pa=0x7fff9aa20290, num_in=0x7fff9aa20950, result=0x7fff9aa2028c, dtmf_progress=0x0, ignore_cc=1, forced_clid=0x7fff9aa20060, stored_clid=0x7fff9aa20010) at app_dial.c:1562 #17 0x00007fffa7170f70 in dial_exec_full (chan=0x7fff340ab648, data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt", peerflags=0x7fff9aa20ec0, continue_exec=0x0) at app_dial.c:2683 #18 0x00007fffa7173789 in dial_exec (chan=0x7fff340ab648, data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at app_dial.c:3130 #19 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0x106f200, data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at pbx.c:1622 #20 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0, context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", priority=22, label=0x0, callerid=0x7fff1c05dc70 "74996051913", action=E_SPAWN, found=0x7fff9aa2578c, combined_find_spawn=1) at pbx.c:4915 #21 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648, context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", priority=22, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2578c, combined_find_spawn=1) at pbx.c:6037 #22 0x00007fffab3f20b0 in _macro_exec (chan=0x7fff340ab648, data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off", exclusive=0) at app_macro.c:412 #23 0x00007fffab3f3342 in macro_exec (chan=0x7fff340ab648, data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at app_macro.c:585 #24 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0xfbc430, data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at pbx.c:1622 #25 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0, context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", priority=5, label=0x0, callerid=0x7fff1c05dc70 "74996051913", action=E_SPAWN, found=0x7fff9aa2ab70, combined_find_spawn=1) at pbx.c:4915 #26 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648, context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", priority=5, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2ab70, combined_find_spawn=1) at pbx.c:6037 #27 0x000000000053aebc in __ast_pbx_run (c=0x7fff340ab648, args=0x0) at pbx.c:6512 #28 0x000000000053c999 in pbx_thread (data=0x7fff340ab648) at pbx.c:6842 #29 0x00000000005990d5 in dummy_start (data=0x7fff34018e00) at utils.c:1223 #30 0x00000037ca2079d1 in start_thread (arg=0x7fff9aa2b700) at pthread_create.c:301 #31 0x00000037c9ee89dd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 2014-12-23 16:53 GMT+03:00 ???????? ??????? : > another crash. Double free. > > > > > 2014-12-22 17:29 GMT+03:00 ???????? ??????? : > >> Hmm... again asserts... >> s->init_num == 0 >> >> full backtrace attached... >> >> 2014-12-18 13:10 GMT+03:00 Matt Caswell via RT : >> >>> On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote: >>> > Thanks! Great! >>> > 6000 calls. No crashes or leaks.... only messages like this in >>> > asterisk >>> > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: >>> > DTLS >>> > failure occurred on RTP instance '0x298c1d68' due to reason 'digest >>> > check >>> > failed', terminating >>> > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: >>> > DTLS >>> > failure occurred on RTP instance '0x29d16508' due to reason 'digest >>> > check >>> > failed', terminating >>> > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: >>> > DTLS >>> > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest >>> > check >>> > failed', terminating >>> > >>> > But 99% call go normal. We will test on production server and high >>> > load. >>> >>> Good news. Let me know how the testing goes in production so that I can >>> (hopefully) close the ticket. >>> >>> Matt >>> >>> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From dominyktiller at gmail.com Thu Dec 25 03:12:56 2014 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Thu, 25 Dec 2014 03:12:56 +0000 Subject: [openssl-dev] OpenSSL Release Strategy and Blog In-Reply-To: <549B5433.2020206@openssl.org> References: <5499FF9F.6040205@openssl.org> <549A0AF8.50409@gmail.com> <549B5433.2020206@openssl.org> Message-ID: <549B80B8.8060302@gmail.com> Yup, Seems to be working fine now. "Part of the message signed. Key ID 0x0E604491/ Signed on 25/12/2014 00:02". Cheers, and Merry Christmas, Dom Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 25/12/2014 00:02, Matt Caswell wrote: > > > On 24/12/14 11:37, Yuriy Kaminskiy wrote: >> Dominyk Tiller wrote: >>> Hey Matt, >>> >>> For some reason, this email is getting flagged as a bad signature >>> by Enigmail. All of your previous emails checked out fine, but >>> this one checked in with a big purple banner on it. > >> His user-agent messed up with line ending (wrapped overly long >> lines). Signature matched after replacing \n with space at end of >> lines 10, 9, 5, 4. > > Ahhh...thanks. I've been trying to figure out what on earth happened. > Seems to be a bug in Enigmail. > > I recently moved my email account to the new OpenSSL infrastructure. > With my previous account I had Thunderbird set up to do plain text > only email. With my new account I had neglected to untick the "HTML" > option. Thunderbird seems to automatically break long lines in the > composition editor when using plaintext, but not with HTML. I suspect > that's why I've never had the problem before. > > Signing this email to check its working ok! > > Matt > > _______________________________________________ > openssl-dev mailing list > openssl-dev at openssl.org > https://mta.opensslfoundation.net/mailman/listinfo/openssl-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From openssl-dev at openssl.org Sat Dec 20 09:25:41 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Sat, 20 Dec 2014 04:25:41 -0500 Subject: [openssl-dev] TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (7.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] 2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received: date 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.0 HTML_MESSAGE BODY: HTML included in message 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Sat, 20 Dec 2014 04:25:41 -0500 Size: 1626 URL: From openssl-dev at openssl.org Fri Dec 19 21:16:45 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Fri, 19 Dec 2014 16:16:45 -0500 Subject: [openssl-dev] TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (7.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] 2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received: date 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 0.0 HTML_MESSAGE BODY: HTML included in message 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Fri, 19 Dec 2014 16:16:45 -0500 Size: 1626 URL: From rt at openssl.org Thu Dec 25 11:24:50 2014 From: rt at openssl.org (=?UTF-8?B?0JLRj9GH0LXRgdC70LDQsiDQkdCw0LTQsNC70Y/QvQ==?= via RT) Date: Thu, 25 Dec 2014 12:24:50 +0100 Subject: [openssl-dev] [openssl.org #3592] bug report. Crash. Critical? Security bug? In-Reply-To: References: Message-ID: i found that Asterisk do corruption in SSL. I will fix it and replay to you 2014-12-25 5:58 GMT+03:00 ???????? ??????? : > New place crash > > (gdb) bt > > #0 0x00000037c9e32625 in raise (sig=6) at > ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > > #1 0x00000037c9e33e05 in abort () at abort.c:92 > > #2 0x0000003dbac69e3f in OpenSSLDie (file=, > line=, assertion=) at > cryptlib.c:923 > > #3 0x0000003dbb03c220 in do_dtls1_write (s=0x7fff34010940, type=22, > buf=0x7fff1c0ac007 "\v", len=243, create_empty_fragment=0) at d1_pkt.c:1484 > > #4 0x0000003dbb03faf1 in dtls1_do_write (s=0x7fff34010940, type=22) at > d1_both.c:378 > > #5 0x0000003dbb038e07 in dtls1_accept (s=0x7fff34010940) at d1_srvr.c:426 > > #6 0x0000003dbb03d8ad in dtls1_read_bytes (s=0x7fff34010940, type=23, > buf=0x7fff34059488 "\026\376\377", len=121, peek=0) at d1_pkt.c:787 > > #7 0x0000003dbb027ed0 in ssl3_read_internal (s=0x7fff34010940, > buf=0x7fff34059488, len=121, peek=0) at s3_lib.c:4273 > > #8 0x00007fff9e952ef5 in __rtp_recvfrom (instance=0x7fff3405f288, > buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370, rtcp=0) at > res_rtp_asterisk.c:2019 > > #9 0x00007fff9e95331f in rtp_recvfrom (instance=0x7fff3405f288, > buf=0x7fff34059488, size=8192, flags=0, sa=0x7fff9aa1e370) at > res_rtp_asterisk.c:2094 > > #10 0x00007fff9e95c621 in ast_rtp_read (instance=0x7fff3405f288, rtcp=0) > at res_rtp_asterisk.c:4127 > > #11 0x0000000000551bcf in ast_rtp_instance_read (instance=0x7fff3405f288, > rtcp=0) at rtp_engine.c:314 > > #12 0x00007fffb2ae07cd in sip_rtp_read (ast=0x7fff340ab648, > p=0x7fff3402f588, faxdetect=0x7fff9aa1e604) at chan_sip.c:8192 > > #13 0x00007fffb2ae0f7c in sip_read (ast=0x7fff340ab648) at chan_sip.c:8289 > > #14 0x000000000047cb05 in __ast_read (chan=0x7fff340ab648, dropaudio=0) at > channel.c:4054 > > #15 0x000000000047e8ae in ast_read (chan=0x7fff340ab648) at channel.c:4408 > > #16 0x00007fffa716ba1a in wait_for_answer (in=0x7fff340ab648, > out_chans=0x7fff9aa20970, to=0x7fff9aa2096c, peerflags=0x7fff9aa20ec0, > opt_args=0x7fff9aa201b0, pa=0x7fff9aa20290, num_in=0x7fff9aa20950, > result=0x7fff9aa2028c, > > dtmf_progress=0x0, ignore_cc=1, forced_clid=0x7fff9aa20060, > stored_clid=0x7fff9aa20010) at app_dial.c:1562 > > #17 0x00007fffa7170f70 in dial_exec_full (chan=0x7fff340ab648, > data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt", peerflags=0x7fff9aa20ec0, > continue_exec=0x0) at app_dial.c:2683 > > #18 0x00007fffa7173789 in dial_exec (chan=0x7fff340ab648, > data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at app_dial.c:3130 > > #19 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0x106f200, > data=0x7fff9aa23120 "SIP/sbc/79139601839,300,Tt") at pbx.c:1622 > > #20 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0, > context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", > priority=22, label=0x0, callerid=0x7fff1c05dc70 "74996051913", > action=E_SPAWN, > > found=0x7fff9aa2578c, combined_find_spawn=1) at pbx.c:4915 > > #21 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648, > context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", > priority=22, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2578c, > combined_find_spawn=1) > > at pbx.c:6037 > > #22 0x00007fffab3f20b0 in _macro_exec (chan=0x7fff340ab648, > data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off", exclusive=0) at > app_macro.c:412 > > #23 0x00007fffab3f3342 in macro_exec (chan=0x7fff340ab648, > data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at app_macro.c:585 > > #24 0x000000000052b7dd in pbx_exec (c=0x7fff340ab648, app=0xfbc430, > data=0x7fff9aa28490 "dialout-trunk,4,79139601839,,off") at pbx.c:1622 > > #25 0x0000000000536284 in pbx_extension_helper (c=0x7fff340ab648, con=0x0, > context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", > priority=5, label=0x0, callerid=0x7fff1c05dc70 "74996051913", > action=E_SPAWN, > > found=0x7fff9aa2ab70, combined_find_spawn=1) at pbx.c:4915 > > #26 0x000000000053971f in ast_spawn_extension (c=0x7fff340ab648, > context=0x7fff340ac498 "macro-dialout-trunk", exten=0x7fff340ac4e8 "s", > priority=5, callerid=0x7fff1c05dc70 "74996051913", found=0x7fff9aa2ab70, > combined_find_spawn=1) > > at pbx.c:6037 > > #27 0x000000000053aebc in __ast_pbx_run (c=0x7fff340ab648, args=0x0) at > pbx.c:6512 > > #28 0x000000000053c999 in pbx_thread (data=0x7fff340ab648) at pbx.c:6842 > > #29 0x00000000005990d5 in dummy_start (data=0x7fff34018e00) at utils.c:1223 > > #30 0x00000037ca2079d1 in start_thread (arg=0x7fff9aa2b700) at > pthread_create.c:301 > > #31 0x00000037c9ee89dd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:115 > > 2014-12-23 16:53 GMT+03:00 ???????? ??????? : > >> another crash. Double free. >> >> >> >> >> 2014-12-22 17:29 GMT+03:00 ???????? ??????? : >> >>> Hmm... again asserts... >>> s->init_num == 0 >>> >>> full backtrace attached... >>> >>> 2014-12-18 13:10 GMT+03:00 Matt Caswell via RT : >>> >>>> On Thu Dec 18 04:54:57 2014, v.badalyan at open-bs.ru wrote: >>>> > Thanks! Great! >>>> > 6000 calls. No crashes or leaks.... only messages like this in >>>> > asterisk >>>> > [2014-12-18 04:59:20] ERROR[31074][C-000013d4] res_rtp_asterisk.c: >>>> > DTLS >>>> > failure occurred on RTP instance '0x298c1d68' due to reason 'digest >>>> > check >>>> > failed', terminating >>>> > [2014-12-18 04:59:28] ERROR[31081][C-000013d7] res_rtp_asterisk.c: >>>> > DTLS >>>> > failure occurred on RTP instance '0x29d16508' due to reason 'digest >>>> > check >>>> > failed', terminating >>>> > [2014-12-18 05:04:07] ERROR[31881][C-0000142d] res_rtp_asterisk.c: >>>> > DTLS >>>> > failure occurred on RTP instance '0x29fe0ac8' due to reason 'digest >>>> > check >>>> > failed', terminating >>>> > >>>> > But 99% call go normal. We will test on production server and high >>>> > load. >>>> >>>> Good news. Let me know how the testing goes in production so that I can >>>> (hopefully) close the ticket. >>>> >>>> Matt >>>> >>>> >>> >>> >>> -- >>> ? ?????????, >>> ??????? ???????? ????????? >>> >>> ??? "???????? ??????-???????" >>> ??????????? ???????? >>> +7 (495) 666-0-111 >>> http://www.open-bs.ru >>> >> >> >> >> -- >> ? ?????????, >> ??????? ???????? ????????? >> >> ??? "???????? ??????-???????" >> ??????????? ???????? >> +7 (495) 666-0-111 >> http://www.open-bs.ru >> > > > > -- > ? ?????????, > ??????? ???????? ????????? > > ??? "???????? ??????-???????" > ??????????? ???????? > +7 (495) 666-0-111 > http://www.open-bs.ru > -- ? ?????????, ??????? ???????? ????????? ??? "???????? ??????-???????" ??????????? ???????? +7 (495) 666-0-111 http://www.open-bs.ru From rt at openssl.org Fri Dec 26 11:18:22 2014 From: rt at openssl.org (kruegerb via RT) Date: Fri, 26 Dec 2014 12:18:22 +0100 Subject: [openssl-dev] [openssl.org #3641] [PATCH] EC_KEY_generate always overwrites private key All OS 1.0.1j In-Reply-To: <549A465A.1070809@ix.netcom.com> References: <549A465A.1070809@ix.netcom.com> Message-ID: The do-while loop that uses BN_rand_range to set the private key is outside of and following the block that tests if the private key is set. This results in the private key always being set to a random value even when a private key has been provided. The proposed patch is to move the do-while loop inside the private key test for NULL block. See attached. -------------- next part -------------- int EC_KEY_generate_key(EC_KEY *eckey) { int ok = 0; BN_CTX *ctx = NULL; BIGNUM *priv_key = NULL, *order = NULL; EC_POINT *pub_key = NULL; #ifdef OPENSSL_FIPS if (FIPS_mode()) return FIPS_ec_key_generate_key(eckey); #endif if (!eckey || !eckey->group) { ECerr(EC_F_EC_KEY_GENERATE_KEY, ERR_R_PASSED_NULL_PARAMETER); return 0; } if ((order = BN_new()) == NULL) goto err; if ((ctx = BN_CTX_new()) == NULL) goto err; if (eckey->priv_key == NULL) { priv_key = BN_new(); if (priv_key == NULL) goto err; do if (!BN_rand_range(priv_key, order)) goto err; while (BN_is_zero(priv_key)); } else priv_key = eckey->priv_key; if (!EC_GROUP_get_order(eckey->group, order, ctx)) goto err; if (eckey->pub_key == NULL) { pub_key = EC_POINT_new(eckey->group); if (pub_key == NULL) goto err; } else pub_key = eckey->pub_key; if (!EC_POINT_mul(eckey->group, pub_key, priv_key, NULL, NULL, ctx)) goto err; eckey->priv_key = priv_key; eckey->pub_key = pub_key; ok=1; err: if (order) BN_free(order); if (pub_key != NULL && eckey->pub_key == NULL) EC_POINT_free(pub_key); if (priv_key != NULL && eckey->priv_key == NULL) BN_free(priv_key); if (ctx != NULL) BN_CTX_free(ctx); return(ok); } From rt at openssl.org Fri Dec 26 11:19:01 2014 From: rt at openssl.org (Sameer Joshi via RT) Date: Fri, 26 Dec 2014 12:19:01 +0100 Subject: [openssl-dev] [openssl.org #3642] Bug in OpenSSL 1.0.1j version: Decode error in TLS 1.2 handshake failure from client In-Reply-To: References: Message-ID: Hi, I see a problem in OpenSSL code and want to confirm if this has been already reported as a bug or not. If the server sends CertificateRequest during TLS handshake in case of TLS1.2, the Client processes this request in method ssl3_get_certificate_request(SSL* s). While processing the request it calls tls1_process_sigalgs() method to process the signature algorithms. In this method tls1_process_sigalgs(), its being checked if the s->cert pointer is NULL . This actually means the check whether the client has its own certificate or not. In case the pointer is NULL, indicating the client does not have certificate, the function returns zero or failure. TLS handshake fails here with "decode error" owing to SSL_R_SIGNATURE_ALGORITHMS_ERROR. However according to TLS1.2 RFC, its perfectly legal to not have client certificate, in which case, the client can send empty Certificate message to server. Its upto server to accept or reject the client certificate. Due to the above code in tls1_process_sigalgs(), TLS1.2 clients which do not have their own certificate and get CertificateRequest from server are failing to complete TLS handshake. I think this needs to be fixed. If needed I also have patch ready, which I will be happy to contribute. Regards, Sameer Joshi From kgoldman at us.ibm.com Fri Dec 26 15:42:41 2014 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 26 Dec 2014 10:42:41 -0500 Subject: [openssl-dev] Making openssl structures opaque Message-ID: In response to the notice that openssl will be making many structures opaque, it was suggested that I post some requirements I have for the RSA structure. I currently perform these by operating directly on the structure. I would need an API equivalent. - Generate a key pair and return n,p,q,d - Generate the public key structure from n,e - Generate the private key structure from n,e,d From openssl-dev at openssl.org Sat Dec 20 08:41:21 2014 From: openssl-dev at openssl.org (openssl-dev at openssl.org) Date: Sat, 20 Dec 2014 03:41:21 -0500 Subject: [openssl-dev] *****SPAM***** TMN - Receber aqui os MMS que lhe enviarem Message-ID: Spam detection software, running on the system "mta", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: [...] Content analysis details: (7.3 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: imgbox.com] 2.1 DATE_IN_PAST_96_XX Date: is 96 hours or more before Received: date 0.0 NORMAL_HTTP_TO_IP URI: Uses a dotted-decimal IP address in URL 1.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.3 HTML_IMAGE_ONLY_04 BODY: HTML: images with 0-400 bytes of words 0.0 HTML_MESSAGE BODY: HTML included in message 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag 0.1 HTML_SHORT_LINK_IMG_1 HTML is very short with a linked image 0.0 T_REMOTE_IMAGE Message contains an external image 3.0 TO_EQ_FM_HTML_ONLY To == From and HTML only The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor. -------------- next part -------------- An embedded message was scrubbed... From: openssl-dev at openssl.org Subject: TMN - Receber aqui os MMS que lhe enviarem Date: Sat, 20 Dec 2014 03:41:21 -0500 Size: 1626 URL: From rt at openssl.org Mon Dec 29 19:10:11 2014 From: rt at openssl.org (Yuhong Bao via RT) Date: Mon, 29 Dec 2014 20:10:11 +0100 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: Message-ID: As a warning, the Equifax root expires in August 2018 and hopefully will removed from Mozilla soon. Right now GeoTrust is still promoting the use of their GeoTrust to Equifax cross-certificate, and they do issue four year certificates. From openssl-users at dukhovni.org Tue Dec 30 06:49:16 2014 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 30 Dec 2014 06:49:16 +0000 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <3595461.LrVInOj3RS@pintsize.usersys.redhat.com> References: <1418660643.31261.25.camel@vespa.frost.loc> <20141215163242.GW25666@mournblade.imrryr.org> <3595461.LrVInOj3RS@pintsize.usersys.redhat.com> Message-ID: <20141230064916.GQ24649@mournblade.imrryr.org> On Tue, Dec 16, 2014 at 03:02:22PM +0100, Hubert Kario wrote: > > DANE TLSA PKIX-TA(0) records can designate the digest of a trust > > anchor selected by the server operator. When TLS server transmits > > a corresponding certificate chain it may not be safe to replace > > that chain with a shorter chain, because the shorter chain may not > > employ the designated trust anchor, causing DANE TLSA checks to > > fail. > > But then why would you use the PKIX chain builder with system root store? With certificate usage PKIX-TA(0) that's exactly what one is supposed to do. You're confusing PKIX-TA(0) with DANE-TA(2). > If you use DANE with CA digest, then the server needs to send all > certificates, so you just need to validate the chain you have - you don't > have See above. -- Viktor. From Satish.KumarYarru at cognizant.com Tue Dec 30 08:50:33 2014 From: Satish.KumarYarru at cognizant.com (Satish.KumarYarru at cognizant.com) Date: Tue, 30 Dec 2014 08:50:33 +0000 Subject: [openssl-dev] unloading certificates Message-ID: Hi Is there any way to unload client certificate and private key from SSL context? I could not find any openss api to unload client cert from SSL object. Pls help me regarding this.. Regards, Satish This e-mail and any files transmitted with it are for the sole use of the intended recipient(s) and may contain confidential and privileged information. If you are not the intended recipient(s), please reply to the sender and destroy all copies of the original message. Any unauthorized review, use, disclosure, dissemination, forwarding, printing or copying of this email, and/or any action taken in reliance on the contents of this e-mail is strictly prohibited and may be unlawful. Where permitted by applicable law, this e-mail and other e-mail communications sent to and from Cognizant e-mail addresses may be monitored. From rt at openssl.org Tue Dec 30 16:08:03 2014 From: rt at openssl.org (Kurt Roeckx via RT) Date: Tue, 30 Dec 2014 17:08:03 +0100 Subject: [openssl-dev] [openssl.org #3629] Bug report: "run" in speed.c should be declared as volatile In-Reply-To: <20141230160751.GA1057@roeckx.be> References: <005f01d014ea$ad5c3b30$0814b190$@codeaurora.org> <20141211212401.GA32213@roeckx.be> <20141230160751.GA1057@roeckx.be> Message-ID: On Thu, Dec 11, 2014 at 10:24:08PM +0100, Kurt Roeckx via RT wrote: > Yes, global variables used in signal handlers should be volatile. It has been fixed in 1.0.1+ Kurt From rt at openssl.org Wed Dec 31 14:42:19 2014 From: rt at openssl.org (christian mock via RT) Date: Wed, 31 Dec 2014 15:42:19 +0100 Subject: [openssl-dev] [openssl.org #3643] SSL_CTX_set_tmp_dh_callback doc misleading WRT "keylength" param In-Reply-To: <20141230160136.GA22775@tahina.priv.at> References: <20141230160136.GA22775@tahina.priv.at> Message-ID: The documentation for SSL_CTX_set_tmp_dh_callback and SSL_set_tmp_dh_callback is misleading with regard to the "keylength" parameter provided to the callback. The documentation and the example imply that the "keylength" parameter will be adequate to whatever the used RSA key is, when in reality they can only ever take the values 512 or 1024 (The same seems to apply for the ECDH callback, although I'm not 100% positive). Although one could argue that it is not stated explicitely, this seems to be a widespread misunderstanding; the EXAMPLE section in doc/ssl/SSL_CTX_set_tmp_dh_callback.pod falls into this trap, as did the INN2 TLS code, and probably also Apache until they fixed it in 2.4.7. Also, a recent paper (http://www.w2spconf.com/2014/papers/TLS.pdf) finds "we discovered that 82.9% of the servers supporting DHE used Diffie-Hellman parameters that are weaker than their RSA signature strengths." So I think this is a real-world security problem. Details (in 1.0.1j): When calling the callback, the "keylength" parameter is generated thusly (s3_srvr.c:1632): SSL_C_EXPORT_PKEYLENGTH(s->s3->tmp.new_cipher)); which can only ever return 512 or 1024 (ssl_locl.h:439): #define SSL_EXPORT_PKEYLENGTH(a) (SSL_IS_EXPORT40(a) ? 512 : 1024) #define SSL_C_EXPORT_PKEYLENGTH(c) SSL_EXPORT_PKEYLENGTH((c)->algo_strength) Regards, cm. -- >I walked past a church last week and noticed a small sign >indicating "Low Mass" early in the morning. They worship $DIETY, for they are seekers of the Lite. -- Jeffrey M. Vinocur and Anthony de Boer From rt at openssl.org Wed Dec 31 17:31:23 2014 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 31 Dec 2014 18:31:23 +0100 Subject: [openssl-dev] [openssl.org #3562] leading dots in nameConstraints ... bug report and patch In-Reply-To: <543B2685.3070801@av8n.com> References: <543B2685.3070801@av8n.com> Message-ID: This patch from Steve Henson seems better and a good candidate for 1.0.2 and master: > diff --git a/crypto/x509v3/v3_ncons.c b/crypto/x509v3/v3_ncons.c index > 26a6f67..9b7ca88 100644 > --- a/crypto/x509v3/v3_ncons.c > +++ b/crypto/x509v3/v3_ncons.c > @@ -405,7 +405,7 @@ static int nc_dns(ASN1_IA5STRING *dns, ASN1_IA5STRING *base) > if (dns->length > base->length) > { > dnsptr += dns->length - base->length; > - if (dnsptr[-1] != '.') > + if (*baseptr != '.' && dnsptr[-1] != '.') > return X509_V_ERR_PERMITTED_VIOLATION; > } > > -- Rich Salz, OpenSSL dev team; rsalz at openssl.org