From rt at openssl.org Wed Apr 1 09:04:12 2015 From: rt at openssl.org (=?UTF-8?B?0JXQs9C+0YAg0JvRjtCx0LjQvNC+0LI=?= via RT) Date: Wed, 1 Apr 2015 11:04:12 +0200 Subject: [openssl-dev] [openssl.org #3776] Memory corruption in X509_VERIFY_PARAM_new In-Reply-To: References: Message-ID: Hi, Bug report for OpenSSL 1.0.2a. Possible memory corruption. In x509_vpm.c at function X509_VERIFY_PARAM_new: paramid = OPENSSL_malloc(sizeof(X509_VERIFY_PARAM)); must be replaced: paramid = OPENSSL_malloc(sizeof(X509_VERIFY_PARAM_ID)); Best regards, Egor From steve at openssl.org Wed Apr 1 11:20:33 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 1 Apr 2015 11:20:33 +0000 Subject: [openssl-dev] Heap corruption in asn1_item_ex_combine_new() In-Reply-To: <551A94D5.2040507@freelan.org> References: <551A94D5.2040507@freelan.org> Message-ID: <20150401112033.GA16729@openssl.org> On Tue, Mar 31, 2015, Julien Kauffmann wrote: > > Basically what happens is that, somewhere inside the call to > PEM_write_bio_ECPrivateKey(), an ASN1 sequence of 3 elements is > allocated. The corresponding code is as follow (in > crypto/asn1/tasn_new.c:181): > > if (!combine) { > *pval = OPENSSL_malloc(it->size); > if (!*pval) > goto memerr; > memset(*pval, 0, it->size); > asn1_do_lock(pval, 0, it); > asn1_enc_init(pval, it); > } > for (i = 0, tt = it->templates; i < it->tcount; tt++, i++) { > pseqval = asn1_get_field_ptr(pval, tt); > if (!ASN1_template_new(pseqval, tt)) > goto memerr; > } > > In the sample I gave, at some point OPENSSL_malloc allocates 12 > bytes for a 3-elements ASN1 SEQUENCE. The for-loop then initializes > every element: ASN1_template_new() calls in turn > asn1_item_ex_combine_new() which, at line 103, does: > Can you determine the value of it->sname where this happens? That will indicate the precise structure where this is a problem. From your description I'd say it is X9_62_PENTANOMIAL. > if (!combine) > *pval = NULL; > > The problem is that pval at this point points to an element of the > SEQUENCE that is only 4 bytes long. On 64 bits systems this causes > the next 4 bytes to be set to 0x00000000. For the first two elements > of the sequence, this gets recovered by the next element being > initialized. However for the last element, this affectation happens > to write 4 bytes past the allocated memory, corrupting the heap. > This should only be a problem where sizeof(long) < sizeof(ASN1_VALUE *) on many 64 bit platforms they are the same. I'd guess this is 64 bit Windows you're testing on? > I'm not sure what is the best place to fix this. Do you have any hints ? > I'll look into it. In the meantime I'd suggest you add a call to use the named curve version of EC parameters: this is only a problem with the explicit form which is very rarely used but for historical compatibility reasons it is the default. If you want to use the key for TLS you need the named curve form anyway. To do this call: EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE); Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Wed Apr 1 11:26:06 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 1 Apr 2015 11:26:06 +0000 Subject: [openssl-dev] Heap corruption in asn1_item_ex_combine_new() In-Reply-To: <551A94D5.2040507@freelan.org> References: <551A94D5.2040507@freelan.org> Message-ID: <20150401112606.GA16992@openssl.org> On Tue, Mar 31, 2015, Julien Kauffmann wrote: > > if (!combine) > *pval = NULL; > I'd suggest deleting the two lines above. The structure should be cleared without this and the above line is wrong for non pointer fields anyway. 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 Apr 1 16:47:52 2015 From: rt at openssl.org (Erik Tews via RT) Date: Wed, 1 Apr 2015 18:47:52 +0200 Subject: [openssl-dev] [openssl.org #3777] [BUG] broken links in the README file for US bug reporting In-Reply-To: <1427892050.4373.2.camel@datenzone.de> References: <1427892050.4373.2.camel@datenzone.de> Message-ID: Hello The openssl README file contains two links for reporting bugs from the US, namely: http://www.bis.doc.gov/Encryption/PubAvailEncSourceCodeNofify.html http://w3.access.gpo.gov/bis/ear/pdf/740.pdf Both result currently in an HTTP 404 error. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rt at openssl.org Wed Apr 1 16:48:00 2015 From: rt at openssl.org (Erik Tews via RT) Date: Wed, 1 Apr 2015 18:48:00 +0200 Subject: [openssl-dev] [openssl.org #3778] [PATCH] change RSA modulus length to 2048 in all examples for req In-Reply-To: <1427893868.4373.5.camel@datenzone.de> References: <1427893868.4373.5.camel@datenzone.de> Message-ID: Hi The manpage for the req command stills shows examples with a 1024 bit modulus for RSA. Since RSA with a 1024 bit modulus length is decpredated, I suggest to change the examples to 2048 bit. I have created a git commit and a git pull request for that change. https://github.com/openssl/openssl/pull/253 https://github.com/eriktews/openssl/commit/2b1814827e0a75bad1ef837eee7412f2aa4564cf Attached is also a patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: keysize.patch Type: text/x-patch Size: 1292 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From rt at openssl.org Wed Apr 1 16:48:06 2015 From: rt at openssl.org (Erik Tews via RT) Date: Wed, 1 Apr 2015 18:48:06 +0200 Subject: [openssl-dev] [openssl.org #3779] [BUG][PATCH] Remove the second occurrence of -subj in the req man page In-Reply-To: <1427894138.4373.7.camel@datenzone.de> References: <1427894138.4373.7.camel@datenzone.de> Message-ID: Hi The -subj parameter appears twice in the manpage of req for no reasons I am aware of. This patch removes the second occurrence of the -subj parameter. I have created a git commit and a git pull request for that change. https://github.com/openssl/openssl/pull/254 https://github.com/eriktews/openssl/commit/b338c639fcfbbaf5443598cf028da11dbfe79cd2 Attached is also a patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: subj.patch Type: text/x-patch Size: 831 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From hanno at hboeck.de Wed Apr 1 17:32:58 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Wed, 1 Apr 2015 19:32:58 +0200 Subject: [openssl-dev] Merging Gentoo patches on OpenSSL Message-ID: <20150401193258.7a697ee7@pc1.fritz.box> Hello, The Gentoo package for OpenSSL currently has a number of patches. The last OpenSSL 1.0.2a update took a bit longer due to that - patches had to be adjusted first. I think most (if not all) of these patches should just be incorporated into OpenSSL itself, as they're not Gentoo-specific. Minor fixes, built system improvements etc. Most of them have been submitted to the openssl rt in the past, but got no reaction so far. What can we do to work on merging them? Would you prefer git pull requests? Some examples: Let Makefiles respect LDFLAGS: https://rt.openssl.org/Ticket/Display.html?id=3332&user=guest&pass=guest Fix parallel builds: https://rt.openssl.org/Ticket/Display.html?id=2084&user=guest&pass=guest Build fix of 64 bit on 32 bit systems: https://bugs.gentoo.org/show_bug.cgi?id=542618 -- 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 brian at briansmith.org Wed Apr 1 20:53:10 2015 From: brian at briansmith.org (Brian Smith) Date: Wed, 1 Apr 2015 10:53:10 -1000 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: Emilia K?sper wrote: > On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith wrote: >> If OpenSSL's client code were changed to always use an empty session >> ID when attempting resumption using a session ticket, then the >> EAP-FAST case wouldn't be different from the general session ticket >> resumption case. I think that this is a cleaner approach. > > 1) The way EAP-FAST diverges from 5246 and 5077 is indeed quite > unfortunate. The lookahead is messy, and hard to get right - I don't want > another "early CCS" due to lack of determinism in the state machine. Setting > the session ID is much cleaner. So, I'd rather put in a workaround that is > specific to EAP-FAST and doesn't affect regular handshakes. The added complexity of having a special case for EAP-FAST seems worse to me. After all, it's not OK to have EAP-FAST be non-secure, and so it is important to have the no-session-ID case be correct regardless. > 2) Removing the session ID upon resumption would be a big change in > behaviour that I don't think would qualify for a stable branch anyway unless > there was a security or regression issue behind it. Fair enough. I have no idea what the compatibility problems might arise. If I have some time, I might try to change one of the web browsers to do this, to see what happens. If I do, I'll report back. Cheers, Brian From rt at openssl.org Wed Apr 1 21:27:40 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 1 Apr 2015 23:27:40 +0200 Subject: [openssl-dev] [openssl.org #3775] BUG REPORT: misspelled UNKOWN in the source code In-Reply-To: <49480E6BCE32784D89E6AC37C0A0C11B150DF9AA@G4W3222.americas.hpqcorp.net> References: <49480E6BCE32784D89E6AC37C0A0C11B150DF9AA@G4W3222.americas.hpqcorp.net> Message-ID: On Tue Mar 31 18:51:49 2015, apevnev at hp.com wrote: > Hi! > > This is no impact but it would be nice to have UNKNOWN spelled right. Thank > you! > > /home/pevnev/tmp/openssl-1.0.2a/crypto/asn1 > > [pevnev at blessed03 asn1]$ grep UNKOWN * > > asn1_err.c: {ERR_REASON(ASN1_R_UNKOWN_FORMAT), "unknown format"}, > asn1_gen.c: ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT); > asn1.h:# define ASN1_R_UNKOWN_FORMAT 195 > Hi Andrey This is a known (!) issue. It has been fixed in the latest development version, but as this is part of the public API and has no real negative impact it was decided to leave it for the 1.0.x series. Matt From rt at openssl.org Wed Apr 1 21:40:49 2015 From: rt at openssl.org (Pevnev, Andrey via RT) Date: Wed, 1 Apr 2015 23:40:49 +0200 Subject: [openssl-dev] [openssl.org #3775] BUG REPORT: misspelled UNKOWN in the source code In-Reply-To: <49480E6BCE32784D89E6AC37C0A0C11B150E5A83@G4W3222.americas.hpqcorp.net> References: <49480E6BCE32784D89E6AC37C0A0C11B150DF9AA@G4W3222.americas.hpqcorp.net> <49480E6BCE32784D89E6AC37C0A0C11B150E5A83@G4W3222.americas.hpqcorp.net> Message-ID: Got it, thanks! -----Original Message----- From: Matt Caswell via RT [mailto:rt at openssl.org] Sent: Wednesday, April 1, 2015 4:28 PM To: Pevnev, Andrey Cc: openssl-dev at openssl.org Subject: [openssl.org #3775] BUG REPORT: misspelled UNKOWN in the source code On Tue Mar 31 18:51:49 2015, apevnev at hp.com wrote: > Hi! > > This is no impact but it would be nice to have UNKNOWN spelled right. > Thank you! > > /home/pevnev/tmp/openssl-1.0.2a/crypto/asn1 > > [pevnev at blessed03 asn1]$ grep UNKOWN * > > asn1_err.c: {ERR_REASON(ASN1_R_UNKOWN_FORMAT), "unknown format"}, > asn1_gen.c: ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKOWN_FORMAT); asn1.h:# > define ASN1_R_UNKOWN_FORMAT 195 > Hi Andrey This is a known (!) issue. It has been fixed in the latest development version, but as this is part of the public API and has no real negative impact it was decided to leave it for the 1.0.x series. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 6184 bytes Desc: not available URL: From matt at openssl.org Wed Apr 1 21:43:58 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 01 Apr 2015 22:43:58 +0100 Subject: [openssl-dev] Merging Gentoo patches on OpenSSL In-Reply-To: <20150401193258.7a697ee7@pc1.fritz.box> References: <20150401193258.7a697ee7@pc1.fritz.box> Message-ID: <551C669E.4030107@openssl.org> On 01/04/15 18:32, Hanno B?ck wrote: > Hello, > > The Gentoo package for OpenSSL currently has a number of patches. > The last OpenSSL 1.0.2a update took a bit longer due to that - > patches had to be adjusted first. How many patches are you talking about? > > I think most (if not all) of these patches should just be > incorporated into OpenSSL itself, as they're not Gentoo-specific. > Minor fixes, built system improvements etc. Most of them have been > submitted to the openssl rt in the past, but got no reaction so > far. > > What can we do to work on merging them? Would you prefer git pull > requests? > > Some examples: > > Let Makefiles respect LDFLAGS: > https://rt.openssl.org/Ticket/Display.html?id=3332&user=guest&pass=guest This > one says its been applied and is marked as resolved. Are you saying its not? Mind you it doesn't seem to be about LDFLAGS so perhaps you meant a different one? > > Fix parallel builds: > https://rt.openssl.org/Ticket/Display.html?id=2084&user=guest&pass=guest That > one also says its been applied and is marked as resolved? > > Build fix of 64 bit on 32 bit systems: > https://bugs.gentoo.org/show_bug.cgi?id=542618 > Matt From cloos at jhcloos.com Wed Apr 1 22:06:35 2015 From: cloos at jhcloos.com (James Cloos) Date: Wed, 01 Apr 2015 18:06:35 -0400 Subject: [openssl-dev] Merging Gentoo patches on OpenSSL In-Reply-To: <551C669E.4030107@openssl.org> (Matt Caswell's message of "Wed, 01 Apr 2015 22:43:58 +0100") References: <20150401193258.7a697ee7@pc1.fritz.box> <551C669E.4030107@openssl.org> Message-ID: MC> This one says its been applied and is marked as resolved. Are you MC> saying its not? Mind you it doesn't seem to be about LDFLAGS so MC> perhaps you meant a different one? The openssl-1.0.0a-ldflags.patch still applies to master. As does openssl-1.0.2a-x32-asm.patch. MC> That one also says its been applied and is marked as resolved? Most of the hunks in Gentoo's openssl-1.0.2a-parallel-build.patch also still apply to master. (9 of 17.) And 17 of 27 hunks of openssl-1.0.2-ipv6.patch also still apply. (That is based on the 7 patches in Gentoo's openssl-1.0.2a.ebuild.) -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From julien.kauffmann at freelan.org Thu Apr 2 03:01:49 2015 From: julien.kauffmann at freelan.org (Julien Kauffmann) Date: Wed, 01 Apr 2015 23:01:49 -0400 Subject: [openssl-dev] Heap corruption in asn1_item_ex_combine_new() In-Reply-To: <20150401112606.GA16992@openssl.org> References: <551A94D5.2040507@freelan.org> <20150401112606.GA16992@openssl.org> Message-ID: <551CB11D.8000409@freelan.org> Hi, I can confirm that removing those two lines solves the problem. I actually already tried to add this: EC_GROUP_set_asn1_flag(group, OPENSSL_EC_NAMED_CURVE); but while it solved the problem for writing the key, the problem would still arise while parsing a key generated without the flag (the same heap corruption). Anyway, seems to be solved ! Is this change already merged upstream ? Do I need to create a ticket/make a pull request for this ? Thank you. Julien Kauffmann. Le 01/04/2015 07:26, Dr. Stephen Henson a ?crit : > On Tue, Mar 31, 2015, Julien Kauffmann wrote: > >> if (!combine) >> *pval = NULL; >> > I'd suggest deleting the two lines above. The structure should be cleared > without this and the above line is wrong for non pointer fields anyway. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4276 bytes Desc: Signature cryptographique S/MIME URL: From cchui at bloomberg.net Thu Apr 2 19:41:09 2015 From: cchui at bloomberg.net (Yuk Chui (BLOOMBERG/ 731 LEX)) Date: Thu, 2 Apr 2015 19:41:09 -0000 Subject: [openssl-dev] =?utf-8?q?PKCS7=5FNOCHAIN?= Message-ID: <551D9B550112059A03640012_0_6775@p868> Hi all: I've tried to use PCKS7_Verify to verify the sign object and the certificates. If flags == 0, the call will execute X509_STORE_CTX_set_default(&cert_ctx, "smime_sign"). On the other hand, if flags == PKCS7_NOCHAIN, X509_STORE_CTX_set_default(&cert_ctx, "smime_sign") won't be run. Is this a bug or simply a feature? Thank you for your help. - Christine From chenyt at cs.sjtu.edu.cn Fri Apr 3 01:10:15 2015 From: chenyt at cs.sjtu.edu.cn (Yuting Chen) Date: Thu, 2 Apr 2015 18:10:15 -0700 Subject: [openssl-dev] Why the issuer cannot be found? Message-ID: I used OpenSSL to verify a certificate file (file3.pem) against another certificate file (file4.pem). OpenSSL reports that it cannot find the issuer of the cert in file3.pem; while when I displays file3.pem and file4.pem, it appears that the issuer of the cert in file3.pem is the same as the subject of the cert in file4.pem. Did I miss anything? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: file3.pem Type: application/x-x509-ca-cert Size: 2244 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: file4.pem Type: application/x-x509-ca-cert Size: 1099 bytes Desc: not available URL: From rt at openssl.org Fri Apr 3 05:54:38 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Fri, 3 Apr 2015 07:54:38 +0200 Subject: [openssl-dev] [PATCH] [openssl.org #2558] [patch] make windres controllable via build env var settings In-Reply-To: <1428040444-30085-1-git-send-email-vapier@gentoo.org> References: <1428040444-30085-1-git-send-email-vapier@gentoo.org> Message-ID: atm, the windres code in openssl is only usable via the cross-compile prefix option unlike all the other build tools. So add support for the standard $RC / $WINDRES env vars as well. --- Configure | 3 +++ Makefile.org | 2 ++ Makefile.shared | 2 +- 3 files changed, 6 insertions(+), 1 deletion(-) diff --git a/Configure b/Configure index 97c2573..c137a4c 100755 --- a/Configure +++ b/Configure @@ -1307,6 +1307,7 @@ my $shared_ldflag = $table{$target}->{shared_ldflag}; my $shared_extension = $table{$target}->{shared_extension}; my $ranlib = $ENV{'RANLIB'} || $table{$target}->{ranlib}; my $ar = $ENV{'AR'} || "ar"; +my $windres = $ENV{'RC'} || $ENV{'WINDRES'} || "windres"; my $arflags = $table{$target}->{arflags}; my $multilib = $table{$target}->{multilib}; @@ -1774,12 +1775,14 @@ while () s/^AR=\s*/AR= \$\(CROSS_COMPILE\)/; s/^NM=\s*/NM= \$\(CROSS_COMPILE\)/; s/^RANLIB=\s*/RANLIB= \$\(CROSS_COMPILE\)/; + s/^WINDRES=\s*/WINDRES= \$\(CROSS_COMPILE\)/; s/^MAKEDEPPROG=.*$/MAKEDEPPROG= \$\(CROSS_COMPILE\)$cc/ if $cc eq "gcc"; } else { s/^CC=.*$/CC= $cc/; s/^AR=\s*ar/AR= $ar/; s/^RANLIB=.*/RANLIB= $ranlib/; + s/^WINDRES=.*/WINDRES= $windres/; s/^MAKEDEPPROG=.*$/MAKEDEPPROG= $cc/ if $cc eq "gcc" || ($cc eq 'cc' && $target =~ /darwin/); } s/^CFLAG=.*$/CFLAG= $cflags/; diff --git a/Makefile.org b/Makefile.org index f254d76..a6d9471 100644 --- a/Makefile.org +++ b/Makefile.org @@ -66,6 +66,7 @@ EXE_EXT= ARFLAGS= AR=ar $(ARFLAGS) r RANLIB= ranlib +WINDRES= windres NM= nm PERL= perl #RM= echo -- @@ -216,6 +217,7 @@ BUILDENV= PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' \ CC='$(CC)' CFLAG='$(CFLAG)' \ AS='$(CC)' ASFLAG='$(CFLAG) -c' \ AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)' \ + WINDRES='$(WINDRES)' \ CROSS_COMPILE='$(CROSS_COMPILE)' \ PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' \ SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ diff --git a/Makefile.shared b/Makefile.shared index babeb46..e8903ca 100644 --- a/Makefile.shared +++ b/Makefile.shared @@ -282,7 +282,7 @@ link_a.cygwin: fi; \ dll_name=$$SHLIB$$SHLIB_SOVER$$SHLIB_SUFFIX; \ $(PERL) util/mkrc.pl $$dll_name | \ - $(CROSS_COMPILE)windres -o rc.o; \ + $(WINDRES) -o rc.o; \ extras="$$extras rc.o"; \ ALLSYMSFLAGS='-Wl,--whole-archive'; \ NOALLSYMSFLAGS='-Wl,--no-whole-archive'; \ -- 2.3.4 From ranpengui at gmail.com Fri Apr 3 07:54:29 2015 From: ranpengui at gmail.com (pengui ran) Date: Fri, 3 Apr 2015 15:54:29 +0800 Subject: [openssl-dev] Does OpenSSL support Path Discovery Message-ID: Dear everyone, I am currently trying to test SSL implementations with PKITS. We already done the Path Validation part and trying to do the Path Discovery part. The questions is *I can't find the right APIs for Path Discovery. Does OpenSSL support Path Discovery*(automatically locate/download the intermediate certs CRLs) and verify the target cert? And does any other SSL implementations support this, like gnutls, polarssl? Please help, I am confused. Best regards, Ranpengui -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Apr 3 15:11:02 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Apr 2015 15:11:02 +0000 Subject: [openssl-dev] Does OpenSSL support Path Discovery In-Reply-To: References: Message-ID: <053a85b2ea2d44bc86881598dde7e2be@ustx2ex-dag1mb2.msg.corp.akamai.com> > The questions is?I can't find the right APIs for ?Path Discovery. Does?OpenSSL?support Path?Discovery(automatically locate/download the?intermediate?certs CRLs) and verify the target cert? No it does not automatically go out and fetch certificates. It's hard to do that securely. I don't know about other TLS implementations. From rsalz at akamai.com Fri Apr 3 19:53:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 3 Apr 2015 19:53:59 +0000 Subject: [openssl-dev] removing compression? Message-ID: I am thinking about removing compression and would like to know what the community thinks. At a minimum, I am going to remove the ability to add compression at run-time. This was never really documented. Moving forward, if someone wants to add a new compression scheme they will need to modify the OpenSSL source. This means COMP_METHOD becomes an internal datatype. But on a larger scale, does anyone use TLS compression? It has certainly caused problems with HTTP (see http://en.wikipedia.org/wiki/CRIME). And the best practice these days is to do it at the application layer, and feed the compressed bytes down to TLS. If this will cause problems for you, please post on the list, ideally within the next week. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From dkg at fifthhorseman.net Fri Apr 3 20:14:35 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 03 Apr 2015 16:14:35 -0400 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <87bnj5as0k.fsf@alice.fifthhorseman.net> On Fri 2015-04-03 15:53:59 -0400, Salz, Rich wrote: > I am thinking about removing compression and would like to know what > the community thinks. > > At a minimum, I am going to remove the ability to add compression at > run-time. This was never really documented. Moving forward, if > someone wants to add a new compression scheme they will need to modify > the OpenSSL source. This means COMP_METHOD becomes an internal > datatype. > > But on a larger scale, does anyone use TLS compression? It has > certainly caused problems with HTTP (see > http://en.wikipedia.org/wiki/CRIME). And the best practice these days > is to do it at the application layer, and feed the compressed bytes > down to TLS. I think this change is a good idea, Rich. Thanks for proposing it. --dkg From kurt at roeckx.be Sat Apr 4 14:08:11 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 4 Apr 2015 16:08:11 +0200 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <20150404140811.GA611@roeckx.be> On Fri, Apr 03, 2015 at 07:53:59PM +0000, Salz, Rich wrote: > > And the best practice these days is to do it at the application > layer, and feed the compressed bytes down to TLS. The BREACH attack makes use of that. Kurt From openssl-users at dukhovni.org Sat Apr 4 15:15:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 4 Apr 2015 15:15:06 +0000 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <20150404151505.GM17637@mournblade.imrryr.org> On Fri, Apr 03, 2015 at 07:53:59PM +0000, Salz, Rich wrote: > I am thinking about removing compression and would like to know > what the community thinks. At the very least drop "zlib-dynamic" support. This has caused "DLL-hell" on some platforms, when a dynamically loaded libz conflicts with a different statically compiled libz in another library. For example, some "ports" versions of FreeBSD Postfix with OpenSSL and MySQL crash in SSL_accept when compression is negotiated (because MySQL includes an internal libz in those builds). My own builds of OpenSSL have always (over a decade now) been "no-zlib". -- Viktor. From rt at openssl.org Sat Apr 4 18:36:56 2015 From: rt at openssl.org (Mike Frysinger via RT) Date: Sat, 4 Apr 2015 20:36:56 +0200 Subject: [openssl-dev] [openssl.org #3780] [PATCH] fix race when symlink shareds libs In-Reply-To: <1428038498-32629-1-git-send-email-vapier@gentoo.org> References: <1428038498-32629-1-git-send-email-vapier@gentoo.org> Message-ID: When the crypto/ssl targets attempt to build their shared libs, they run: cd ..; make libcrypto.so.1.0.0 The top level Makefile in turn runs the build-shared target for that lib. The build-shared target depends on both do_$(SHLIB_TARGET) & link-shared. When building in parallel, make is allowed to run both of these. They both run Makefile.shared for their respective targets: do_$(SHLIB_TARGET) -> link_a.linux-shared -> link_a.gnu -> ...; $(LINK_SO_A) -> $(LINK_SO) -> $(SYMLINK_SO) link-shared -> symlink.linux-shared -> symlink.gnu -> ...; $(SYMLINK_SO) The shell code for SYMLINK_SO attempts to do a [ -e lib ] check, but fails basic TOCTOU semantics. Depending on the load, that means two processes will run the sequence: rm -f libcrypto.so ln -s libcrypto.so.1.0.0 libcrypto.so Which obviously fails: ln: failed to create symbolic link 'libcrypto.so': File exists Since we know do_$(SHLIB_TARGET) will create the symlink for us, don't bother depending on link-shared at all in the top level Makefile when building things. Reported-by: Martin von Gagern URL: https://bugs.gentoo.org/545028 --- Makefile.org | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/Makefile.org b/Makefile.org index 890bfe4..576c60e 100644 --- a/Makefile.org +++ b/Makefile.org @@ -350,7 +350,10 @@ link-shared: libs="$$libs -l$$i"; \ done -build-shared: do_$(SHLIB_TARGET) link-shared +# The link target in Makefile.shared will create the symlink for us, so no need +# to call link-shared directly. Doing so will cause races with two processes +# trying to symlink the lib. +build-shared: do_$(SHLIB_TARGET) do_$(SHLIB_TARGET): @ set -e; libs='-L. $(SHLIBDEPS)'; for i in $(SHLIBDIRS); do \ -- 2.3.4 From rt at openssl.org Sat Apr 4 18:37:13 2015 From: rt at openssl.org (GiangTran via RT) Date: Sat, 4 Apr 2015 20:37:13 +0200 Subject: [openssl-dev] [openssl.org #3781] Possible bug In-Reply-To: References: Message-ID: Hello I am using openssl 1.0.2a on centos 5 2.6.18-194.el5, my project based on boost asio v1.55 I used NO SSLv2 and NO SSLv3 options, the server sometimes crashed with follow stacktrace Program terminated with signal 11, Segmentation fault. > #0 0x00000000005270dc in ssl3_get_client_hello () > (gdb) bt > #0 0x00000000005270dc in ssl3_get_client_hello () > #1 0x000000000052b99f in ssl3_accept () > #2 0x00000000005380d8 in ssl3_read_bytes () > #3 0x000000000053401b in ssl3_read () I think maybe there a bug here ? Thanks secmask -- secmask[at]gmail[dot]com From rsalz at akamai.com Sun Apr 5 00:06:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 5 Apr 2015 00:06:03 +0000 Subject: [openssl-dev] [openssl-users] removing compression? In-Reply-To: <55200B77.5060204@gmx.net> References: <55200B77.5060204@gmx.net> Message-ID: <8a72356eae914fa6bc7c512ea1337b34@ustx2ex-dag1mb2.msg.corp.akamai.com> > by randomly interspersing flush commands into the data stream (description > and example implementation https://github.com/wnyc/breach_buster)? > It's not perfect but for some use cases better than having no compression at > all. Flushing the stream seems like an application-level thing to do, and not something openssl generally does. It might be better than having no compression at all, the question is do we need compression in openssl at all? :) From rt at openssl.org Sun Apr 5 01:38:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 5 Apr 2015 03:38:44 +0200 Subject: [openssl-dev] [openssl.org #3581] POODLE - Is there a way for a central ciphers configuration In-Reply-To: References: Message-ID: Not a bug, but a question. The answer is "no" Or perhaps, not yet. See ticket 3299. But that covers ciphers, not SSL/TLS versions. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sun Apr 5 02:35:09 2015 From: rt at openssl.org (John Denker via RT) Date: Sun, 5 Apr 2015 04:35:09 +0200 Subject: [openssl-dev] [openssl.org #3771] patch: bug: s_client loop at 100% cpu In-Reply-To: <55209DA4.5000806@av8n.com> References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> <55209DA4.5000806@av8n.com> Message-ID: The attached patch makes the problem go away. The method of solution is simple and obvious. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-CPU-hogging-loop-don-t-try-to-read-when-EoF-alre.patch Type: text/x-patch Size: 1738 bytes Desc: not available URL: From leif.thuresson at foxt.com Sun Apr 5 12:48:03 2015 From: leif.thuresson at foxt.com (Leif Thuresson) Date: Sun, 05 Apr 2015 14:48:03 +0200 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <55212F03.6060809@foxt.com> I assume the questions is only about dropping compression in the TLS protocol? I have no problem with that, but I would like keep the ability to use compression in BIO filers so please don't drop zlib support all together. Thanks, /leif On 03/04/15 21:53, Salz, Rich wrote: > > I am thinking about removing compression and would like to know what > the community thinks. > > At a minimum, I am going to remove the ability to add compression at > run-time. This was never really documented. Moving forward, if > someone wants to add a new compression scheme they will need to modify > the OpenSSL source. This means COMP_METHOD becomes an internal datatype. > > But on a larger scale, does anyone use TLS compression? It has > certainly caused problems with HTTP (see > http://en.wikipedia.org/wiki/CRIME). And the best practice these days > is to do it at the application layer, and feed the compressed bytes > down to TLS. > > If this will cause problems for you, please post on the list, ideally > within the next week. > > Thanks. > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun Apr 5 18:51:07 2015 From: rt at openssl.org (John Denker via RT) Date: Sun, 5 Apr 2015 20:51:07 +0200 Subject: [openssl-dev] [openssl.org #3771] patch: bug: s_client loop at 100% cpu In-Reply-To: <552183F2.7050601@av8n.com> References: <53F7A00F.6090801@av8n.com> <55183F19.1020608@av8n.com> <55209DA4.5000806@av8n.com> <552183F2.7050601@av8n.com> Message-ID: Comment reformatted to comply with new OpenSSL coding style chapter 8 https://www.openssl.org/about/codingstyle.txt Functionality unchanged from previous patch. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-fix-CPU-hogging-loop-don-t-try-to-read-when-EoF-alre.patch Type: text/x-patch Size: 1665 bytes Desc: not available URL: From cristian.stoica at freescale.com Mon Apr 6 08:53:32 2015 From: cristian.stoica at freescale.com (Cristian Stoica) Date: Mon, 6 Apr 2015 11:53:32 +0300 Subject: [openssl-dev] [PATCH] remove double initialization of cryptodev engine Message-ID: <1428310412-11000-1-git-send-email-cristian.stoica@freescale.com> cryptodev engine is initialized together with the other engines in ENGINE_load_builtin_engines. The initialization done through OpenSSL_add_all_algorithms is redundant. Signed-off-by: Cristian Stoica --- crypto/engine/eng_all.c | 12 ------------ crypto/engine/engine.h | 4 ---- crypto/evp/c_all.c | 5 ----- util/libeay.num | 2 +- 4 files changed, 1 insertion(+), 22 deletions(-) diff --git a/crypto/engine/eng_all.c b/crypto/engine/eng_all.c index 7edf12e..8f5d1b2 100644 --- a/crypto/engine/eng_all.c +++ b/crypto/engine/eng_all.c @@ -125,15 +125,3 @@ void ENGINE_load_builtin_engines(void) #endif ENGINE_register_all_complete(); } - -#if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) -void ENGINE_setup_bsd_cryptodev(void) -{ - static int bsd_cryptodev_default_loaded = 0; - if (!bsd_cryptodev_default_loaded) { - ENGINE_load_cryptodev(); - ENGINE_register_all_complete(); - } - bsd_cryptodev_default_loaded = 1; -} -#endif diff --git a/crypto/engine/engine.h b/crypto/engine/engine.h index e81096a..1c70250 100644 --- a/crypto/engine/engine.h +++ b/crypto/engine/engine.h @@ -858,10 +858,6 @@ typedef int (*dynamic_bind_engine) (ENGINE *e, const char *id, */ void *ENGINE_get_static_state(void); -# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) -void ENGINE_setup_bsd_cryptodev(void); -# endif - /* BEGIN ERROR CODES */ /* * The following lines are auto generated by the script mkerr.pl. Any changes diff --git a/crypto/evp/c_all.c b/crypto/evp/c_all.c index a3ed00d..719e34d 100644 --- a/crypto/evp/c_all.c +++ b/crypto/evp/c_all.c @@ -82,9 +82,4 @@ void OPENSSL_add_all_algorithms_noconf(void) OPENSSL_cpuid_setup(); OpenSSL_add_all_ciphers(); OpenSSL_add_all_digests(); -#ifndef OPENSSL_NO_ENGINE -# if defined(__OpenBSD__) || defined(__FreeBSD__) || defined(HAVE_CRYPTODEV) - ENGINE_setup_bsd_cryptodev(); -# endif -#endif } diff --git a/util/libeay.num b/util/libeay.num index b594caf..9eb2423 100755 --- a/util/libeay.num +++ b/util/libeay.num @@ -2803,7 +2803,7 @@ BIO_indent 3242 EXIST::FUNCTION: BUF_strlcpy 3243 EXIST::FUNCTION: OpenSSLDie 3244 EXIST::FUNCTION: OPENSSL_cleanse 3245 EXIST::FUNCTION: -ENGINE_setup_bsd_cryptodev 3246 EXIST:__FreeBSD__:FUNCTION:ENGINE +ENGINE_setup_bsd_cryptodev 3246 NOEXIST::FUNCTION: ERR_release_err_state_table 3247 EXIST::FUNCTION:LHASH EVP_aes_128_cfb8 3248 EXIST::FUNCTION:AES FIPS_corrupt_rsa 3249 NOEXIST::FUNCTION: -- 2.3.5 From rt at openssl.org Mon Apr 6 12:45:15 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 6 Apr 2015 14:45:15 +0200 Subject: [openssl-dev] [openssl.org #3784] bug in v3_alt.c In-Reply-To: References: Message-ID: In crypto/x509v3/v3_alt.c, around line 603: - if (!ret) + if (!ret) { X509_NAME_free(nm); + nm = NULL; + } Kurt points out: This looks like a bugfix that needs to go to other branches. We probably shouldn't even touch gen in case of an error. / . From rt at openssl.org Mon Apr 6 12:45:10 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 6 Apr 2015 14:45:10 +0200 Subject: [openssl-dev] [openssl.org #3782] bug/leak in crypto/ec/ecp_smpl.c In-Reply-To: References: Message-ID: around line 135. The old code has a memory leak, only freeing the BN if it's NULL. - if (!group->field) - BN_free(group->field); - if (!group->a) - BN_free(group->a); - if (!group->b) - BN_free(group->b); + BN_free(group->field); + BN_free(group->a); + BN_free(group->b); . From rt at openssl.org Mon Apr 6 12:45:10 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 6 Apr 2015 14:45:10 +0200 Subject: [openssl-dev] [openssl.org #3783] missing null pointer check in x509_lu.c In-Reply-To: References: Message-ID: void X509_OBJECT_free_contents(X509_OBJECT *a) { + if (!a) + return; switch (a->type) { .... already done in master. From rt at openssl.org Mon Apr 6 12:45:25 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 6 Apr 2015 14:45:25 +0200 Subject: [openssl-dev] [openssl.org #3785] missing NULL check in X509_VERIFY_PARAM_free In-Reply-To: References: Message-ID: Need "if (!param) return;" at the start of X509_VERIFY_PARAM_free Found by Kurt while code-reviewing some of my changes on master. . From dkg at fifthhorseman.net Mon Apr 6 21:23:51 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 06 Apr 2015 17:23:51 -0400 Subject: [openssl-dev] Using TLSv1.2 In-Reply-To: References: Message-ID: <87iod954t4.fsf@alice.fifthhorseman.net> On Tue 2015-03-24 10:47:57 -0400, ?????? ????????? wrote: > I use the openssl library in the project and use client certificate > verification. When using protocol TLSv1.2 I have a problem with data > encryption, using the private key of the client certificate. This is due to > the fact that the certificate validation server selected encryption > algorithm that is not supported by the crypt used to encrypt the signature > on the client certificate (failure in method capi_rsa_sign of e_capi.c > file). > Now I have corrected the behavior as follows: > - the method ssl3_send_client_certificate after selecting a client > certificate makes cleaning pkeys [i].digest > - the method ssl_set_cert if pkeys [i] .digest not specified, specify it. > > After that I worked with an application protocol TLSv1.2 > > Is this correct or am I wrong to fix the library using openssl? I don't think what you're proposing here is the right thing to do. Also, your report above seems to talk about encryption algorithms but your code change talks about digest algorithms, so i think something is mixed up in terms of figuring out what the problem is and how to solve it. Maybe more details would help? Can you give an example of the client certificate you were trying to use, and/or a concrete example of a program that triggers the failure? If the certificate you're using is sensitive and you don't want to share it, can you describe a set of steps to recreate the error that you were running into (perhaps including generating the certificate itself)? --dkg From rt at openssl.org Tue Apr 7 07:23:33 2015 From: rt at openssl.org (Loganaden Velvindron via RT) Date: Tue, 7 Apr 2015 09:23:33 +0200 Subject: [openssl-dev] [openssl.org #3786] [PATCH] Check return value of CRYPTO_malloc In-Reply-To: References: Message-ID: Hi folks, As reported by Nicholas Lemonias: crypto_malloc() value is not checked in CRYPTO_strdup. Patch URL: http://elandsys.com/~logan/mem.c.diff Patch here: diff --git a/crypto/mem.c b/crypto/mem.c index 2ce3e89..b9badbf 100644 --- a/crypto/mem.c +++ b/crypto/mem.c @@ -364,6 +364,8 @@ void *CRYPTO_malloc(int num, const char *file, int line) char *CRYPTO_strdup(const char *str, const char *file, int line) { char *ret = CRYPTO_malloc(strlen(str) + 1, file, line); + if (ret == NULL) + return NULL; strcpy(ret, str); return ret; -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From darovskikh.andrei at gmail.com Tue Apr 7 13:06:02 2015 From: darovskikh.andrei at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCU0LDRgNC+0LLRgdC60LjRhQ==?=) Date: Tue, 7 Apr 2015 16:06:02 +0300 Subject: [openssl-dev] patch for capi_load_ssl_client_cert Message-ID: Hello. capi_load_ssl_client_cert function does not select the certificates that have a chain of issuers if the server transmits only the root certificate of the issuer. Attached patch fixes this error. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e_capi.c.patch Type: application/octet-stream Size: 4693 bytes Desc: not available URL: From alexey.melnikov at isode.com Tue Apr 7 16:00:19 2015 From: alexey.melnikov at isode.com (Alexey Melnikov) Date: Tue, 07 Apr 2015 17:00:19 +0100 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <5523FF13.4060408@isode.com> Hi Rich, On 03/04/2015 20:53, Salz, Rich wrote: > > I am thinking about removing compression and would like to know what > the community thinks. > > At a minimum, I am going to remove the ability to add compression at > run-time. This was never really documented. Moving forward, if > someone wants to add a new compression scheme they will need to modify > the OpenSSL source. This means COMP_METHOD becomes an internal datatype. > > But on a larger scale, does anyone use TLS compression? It has > certainly caused problems with HTTP (see > http://en.wikipedia.org/wiki/CRIME). And the best practice these days > is to do it at the application layer, and feed the compressed bytes > down to TLS. > > If this will cause problems for you, please post on the list, ideally > within the next week. > Isode is using TLS compression with IMAP and XMPP, so removing compression altogether would be an inconvenience. We don't use adding compression at run-time. Best Regards, Alexey -------------- next part -------------- An HTML attachment was scrubbed... URL: From tarunpolisetti at gmail.com Tue Apr 7 17:57:07 2015 From: tarunpolisetti at gmail.com (T@Run..............! Polisetty) Date: Tue, 7 Apr 2015 23:27:07 +0530 Subject: [openssl-dev] Getting Coredump While Free SSL in DTLS Handshake under Load Message-ID: Hai All, We are facing some issue while freeing ssl used for the DTLS handshake . We get this issue very rarely once in a while only. Backtrace is (gdb) bt #0 0x00007fefc4f90475 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fefc4f936f0 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fefc4fcb52b in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007fefc4fd4d76 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #4 0x00007fefcacd2747 in CRYPTO_free () from /usr/lib/x86_64-linux-gnu/libcrypto.so.1.0.0 #5 0x00007fefcb097485 in SSL_free () from /usr/lib/x86_64-linux-gnu/libssl.so.1.0.0 Could you please help out what could be the issue. Regards Satya -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Apr 7 22:43:47 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 8 Apr 2015 00:43:47 +0200 Subject: [openssl-dev] [openssl.org #3768] [BUG] using s_server with ECDHE-RSA is broken on OpenSSL 1.0.1m In-Reply-To: References: Message-ID: Fixed, thanks to a patch supplied by John Foley. Closing this ticket. Matt From cuoq at trust-in-soft.com Tue Apr 7 23:14:50 2015 From: cuoq at trust-in-soft.com (Pascal Cuoq) Date: Tue, 7 Apr 2015 23:14:50 +0000 Subject: [openssl-dev] Failure of MD_Init not checked in crypto/rand/md_rand.c Message-ID: <72AAB98F-1C61-4244-84B5-B26C837E2162@trust-in-soft.com> I tried to report this issue one week ago through RT, but failed somehow. I didn't insist because I then noticed that the issue had already been reported as: https://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3159 However, the patch provided in that report makes some unrelated changes. A better candidate for a patch should be the one I attach. In the first chunk, the function being patched, ssleay_rand_add, returns void. Therefore a choice should be made between returning when failure is detected or calling abort(). Note that the current behavior when MD_init fails is to dereference a null pointer a few instructions later, so that calling abort() would not be a loss of functionality (but it would improve the safety of the code. Dereferencing a null pointer is undefined behavior and is not guaranteed to crash the program). The remaining chunks patch the function ssleay_rand_bytes, which has a convention to signaling errors through a return code, documented at: https://www.openssl.org/docs/crypto/RAND_bytes.html The patch makes the function return 0 in case of allocation failure, which seems to best match the existing documented cases: ?RAND_bytes() returns 1 on success, 0 otherwise. The error code can be obtained by ERR_get_error. RAND_pseudo_bytes() returns 1 if the bytes generated are cryptographically strong, 0 otherwise. Both functions return -1 if they are not supported by the current RAND method.? Pascal Cuoq TrustInSoft Chief Scientist -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: check_MD_Init.patch Type: application/octet-stream Size: 1736 bytes Desc: check_MD_Init.patch URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.bennett at netcommwireless.com Wed Apr 8 02:32:33 2015 From: william.bennett at netcommwireless.com (Bill Bennett) Date: Wed, 8 Apr 2015 12:32:33 +1000 Subject: [openssl-dev] TLS_PSK_WITH_AES_128_CCM_8 Message-ID: <55249341.7030209@netcommwireless.com> Hi, Are there any plans to support the ciphers from RFC6655, especially TLS_PSK_WITH_AES_128_CCM_8 in 1.0.2? This suite is required for CoAP / LWM2M (which uses DTLS). I can see that there is support for the underlying algorithms in the EVP interface. Can the ICV length be specified in s3_lib.c? What else would be needed? Thanks, Bill From steve at openssl.org Wed Apr 8 11:59:33 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 8 Apr 2015 11:59:33 +0000 Subject: [openssl-dev] Using TLSv1.2 In-Reply-To: References: Message-ID: <20150408115933.GA7515@openssl.org> On Tue, Mar 24, 2015, ???????????? ?????????????????? wrote: > I use the openssl library in the project and use client certificate > verification. When using protocol TLSv1.2 I have a problem with data > encryption, using the private key of the client certificate. This is due to > the fact that the certificate validation server selected encryption > algorithm that is not supported by the crypt used to encrypt the signature > on the client certificate (failure in method capi_rsa_sign of e_capi.c > file). > Now I have corrected the behavior as follows: > - the method ssl3_send_client_certificate after selecting a client > certificate makes cleaning pkeys [i].digest > - the method ssl_set_cert if pkeys [i] .digest not specified, specify it. > > After that I worked with an application protocol TLSv1.2 > > Is this correct or am I wrong to fix the library using openssl? There are two ways to address this. One is to fix e_capi.c to use more digest algorithms (though this wont help if the underlying CSP doesn't support them). There is a fix in RT for this but it isn't in OpenSSL itself yet. The other requires OpenSSL 1.0.2 where you can set a list of supported signature algorithms for client authentication and OpenSSL will only use those common to server and client for client authentication. For that latter solution you can use SSL_CTX_set1_client_sigalgs_list() which takes a string argument in the same format as that used for the SignatureAlgorithms command of SSL_CONF: "The value argument should be a colon separated list of signature algorithms in order of decreasing preference of the form algorithm+hash. algorithm is one of RSA, DSA or ECDSA and hash is a supported algorithm OID short name such as SHA1, SHA224, SHA256, SHA384 of SHA512. Note: algorithm and hash names are case sensitive." Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From fweimer at redhat.com Wed Apr 8 15:00:23 2015 From: fweimer at redhat.com (Florian Weimer) Date: Wed, 08 Apr 2015 17:00:23 +0200 Subject: [openssl-dev] removing compression? In-Reply-To: References: Message-ID: <55254287.3030206@redhat.com> On 04/03/2015 09:53 PM, Salz, Rich wrote: > If this will cause problems for you, please post on the list, ideally within the next week. PostgreSQL uses OpenSSL compression by default, and it is a deliberate feature (there is no application-layer compression support). -- Florian Weimer / Red Hat Product Security From rt at openssl.org Wed Apr 8 15:19:59 2015 From: rt at openssl.org (Laetitia Baudoin via RT) Date: Wed, 8 Apr 2015 17:19:59 +0200 Subject: [openssl-dev] [openssl.org #3787] [PATCH] Update the return value documentation for various EVP_* functions to match the code. In-Reply-To: References: Message-ID: Update the documented return values for the EVP_DigestVerifyInit, EVP_DigestVerifyUpdate, EVP_CIPHER_param_to_asn1 and EVP_CIPHER_asn1_to_param so they match the code. Justification: EVP_CIPHER_param_to_asn1: returns -1 on failure and 1 or the size of the IV on success. https://github.com/openssl/openssl/blob/master/crypto/evp/evp_lib.c#L64 EVP_CIPHER_asn1_to_param: returns -1 on failure or 1 or the size of the IV on success (checked also with the RC2 ASN.1 parameter parsing). https://github.com/openssl/openssl/blob/master/crypto/evp/evp_lib.c#L81 EVP_DigestVerifyInit only returns 0 on failure or 1 on success: https://github.com/openssl/openssl/blob/master/crypto/evp/m_sigver.c#L116 EVP_DigestVerifyUpdate is #defined to EVP_DigestUpdate that is already documented to return 1 for success or 0 for failure Typedef location https://github.com/openssl/openssl/blob/master/include/openssl/evp.h#L589 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fix-the-EVP_DigestVerifyInit-EVP_DigestVerifyUpdate-.patch Type: text/x-patch Size: 1699 bytes Desc: not available URL: From rt at openssl.org Wed Apr 8 15:20:33 2015 From: rt at openssl.org (Oleg Khovayko via RT) Date: Wed, 8 Apr 2015 17:20:33 +0200 Subject: [openssl-dev] [openssl.org #3788] Bug: Certificate expiration date error for 9000+ days In-Reply-To: <55252B92.5060705@gmail.com> References: <55252B92.5060705@gmail.com> Message-ID: Hi, I am using FreeBSD 8.2, 32bits i386, OpenSSL package: openssl-1.0.1_18 SSL and crypto library During certificate generation, I found the bug: If request CA-lifespan too long, then expiration date drops into far past, and CA-certificate is invalid. Moreover, this is no any error message print, everything works, and this certicicate signs another client certificates. But, when I rtied login with these client certs, I received error: ssl_error_expired_cert_alert - Mozilla, Seamonkey ssl_error_bad_cert_alert - Chrome I assume, problem in the signed int overflow. See bug example following: If request 10000 days, then expiration date written in 1906! $ openssl req -new -newkey rsa:512 -nodes -keyout emc_ca.key -x509 -days 10000 \ -subj '/O=EmerCoin/OU=EMCSSL/CN=EmerCoin World Wide Web Public Key Infrastructure/emailAddress=team at emercoin.com/UID=EMC' \ -out emc_ca.crt $ openssl x509 -noout -text -in emc_ca.crt Certificate: Data: Version: 3 (0x2) Serial Number: c6:8e:ab:87:46:5d:8e:6d Signature Algorithm: sha1WithRSAEncryption Issuer: O=EmerCoin, OU=EMCSSL, CN=EmerCoin World Wide Web Public Key Infrastructure/emailAddress=team at emercoin.com/UID=EMC Validity Not Before: Apr 8 13:13:06 2015 GMT Not After : Jul 19 06:44:50 1906 GMT Subject: O=EmerCoin, OU=EMCSSL, CN=EmerCoin World Wide Web Public Key Infrastructure/emailAddress=team at emercoin.com/UID=EMC Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (512 bit) Modulus (512 bit): 00:e7:16:06:11:e2:d6:cd:ec:49:a9:93:95:19:cf: b1:fb:b5:d5:08:5c:3d:01:4a:cc:a2:20:8b:b9:0f: d2:74:ce:14:c7:a3:eb:81:80:07:aa:8b:e4:db:8b: 42:6d:cc:e6:ae:4d:3d:39:83:f7:8f:1e:93:f3:ca: 0b:3f:71:9d:11 Exponent: 65537 (0x10001) X509v3 extensions: X509v3 Subject Key Identifier: 26:12:7D:02:A3:2D:3A:39:96:84:FE:F3:26:62:04:9D:26:43:E5:5E X509v3 Authority Key Identifier: keyid:26:12:7D:02:A3:2D:3A:39:96:84:FE:F3:26:62:04:9D:26:43:E5:5E DirName:/O=EmerCoin/OU=EMCSSL/CN=EmerCoin World Wide Web Public Key Infrastructure/emailAddress=team at emercoin.com/UID=EMC serial:C6:8E:AB:87:46:5D:8E:6D X509v3 Basic Constraints: CA:TRUE Signature Algorithm: sha1WithRSAEncryption 54:0b:c2:62:76:6c:1d:a7:c8:15:b7:52:60:ee:a4:20:67:19: 47:f3:c1:ff:03:0c:9f:fa:fe:6d:b7:c6:1f:46:94:b5:38:5d: 67:93:02:d7:53:1b:f4:04:ba:56:ce:67:42:32:9c:ad:98:f1: 0c:6a:dc:01:ba:c2:ba:0b:01:e5 From rt at openssl.org Wed Apr 8 19:32:54 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 8 Apr 2015 21:32:54 +0200 Subject: [openssl-dev] [openssl.org #3658] Memory leak in dtls1_send_server_certificate dtls1_buffer_message In-Reply-To: References: Message-ID: Off list discussions have identified that this issue was due to user code incorrectly re-calling DTLSv1_listen after it has already successfully returned. Therefore closing this issue. Matt From jaosorior at gmail.com Thu Apr 9 12:36:05 2015 From: jaosorior at gmail.com (Juan Antonio Osorio) Date: Thu, 9 Apr 2015 15:36:05 +0300 Subject: [openssl-dev] OID with length zero related bug Message-ID: Hi, I've recently encountered that OpenSSL is sending some unexpected errors when reading X.509 certificate requests, if the key is not specified, or the CSR is not signed. Now, this seems to happen because it now will specify a length=0 in the ASN.1 structure since the OID is not set (since the key is not specified). And I think this behaviour was introduced in this commit: 2e430277578d3dd586cd005682a54a59d6158146 So, when using asn1parse to read such a CSR, the section that would contain the key has BAD OBJECT, and will throw an error such as 'invalid object encoding' from 'c2i_ASN1_OBJECT' when the certificate is read or loaded. It used to be the case that it would return an OID 0.0 with length=1, but, like I said, this is not the case anymore. I'm using OpenSSL 1.0.2a. I reproduced this error while testing some code using pyOpenSSL. and here's how I reproduced it: http://pastebin.com/Ky1e8Gz0 the asn1parse dump of the CSR that causes the error looks like this: http://pastebin.com/2EvuaLsk While, in OpenSSL 1.0.1f, (the version where I tested this problem doesn't happen), it would look like this: http://pastebin.com/0vzu2zzx Now, I'm not sure how to actually report this bug, since I'm not sure if it's a bug related to the way the CSRs are being interpreted, or a bug related to how the ASN.1 structure is being written. Any insights? BR -- Juan Antonio Osorio R. e-mail: jaosorior at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From koraboros at gmail.com Thu Apr 9 12:51:24 2015 From: koraboros at gmail.com (=?UTF-8?Q?Pawe=C5=82_Ka=C5=BAmierczak?=) Date: Thu, 9 Apr 2015 14:51:24 +0200 Subject: [openssl-dev] EC based certificates not supported in CMS - why? Message-ID: Hi, currently openssl in CMS supports only RSA based certificates but EC based certificates are supported in openssl TLS... so I assume that there is already a code that can sing/verify and perform key agreement (ECKA-EG ECKA-DH) using eliptic curves. Can someone please tell me if this will be a lot of work to use that code in CMS in a way that CMS could work with EC based certificates? Backgroud: My company needs to support BSI requirements (more info can be found here chapter 8 https://www.bsi.bund.de/SharedDocs/Downloads/DE/BSI/Publikationen/TechnischeRichtlinien/TR03116/BSI-TR-03116-3.html ) and EC certificate is a must. We are now at the point where a decision will be made if we will implement everything by ourselves (which I would like to avoid) or we improve some existing open source crypto lib to support BSI requirements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Thu Apr 9 13:18:11 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 9 Apr 2015 13:18:11 +0000 Subject: [openssl-dev] OID with length zero related bug In-Reply-To: References: Message-ID: <20150409131811.GA30497@openssl.org> On Thu, Apr 09, 2015, Juan Antonio Osorio wrote: > Hi, > > I've recently encountered that OpenSSL is sending some unexpected errors > when reading X.509 certificate requests, if the key is not specified, or > the CSR is not signed. > Well if a key is not specified ot the CSR isn't signed then it isn't a valid CSR and OpenSSl should reject it. Previous versions included a bogus OID when generating such a CSR which meant it could be parsed (but it was still invalid). The encoder should really reject this and refuse to encode it but applications might not expect an error from the encoder. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Thu Apr 9 13:20:03 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 9 Apr 2015 13:20:03 +0000 Subject: [openssl-dev] EC based certificates not supported in CMS - why? In-Reply-To: References: Message-ID: <20150409132003.GB30497@openssl.org> On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote: > Hi, > > currently openssl in CMS supports only RSA based certificates but EC based > certificates are supported in openssl TLS... so I assume that there is > already a code that can sing/verify and perform key agreement (ECKA-EG > ECKA-DH) using eliptic curves. > > Can someone please tell me if this will be a lot of work to use that code > in CMS in a way that CMS could work with EC based certificates? > OpenSSL 1.0.0 and later should support ECDSA in CMS. The use of ECDH is quite rare: most implementations just use RSA key exchange. OpenSSL 1.0.2 does support ECDH though. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From erwann.abalea at opentrust.com Thu Apr 9 13:40:07 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Thu, 09 Apr 2015 15:40:07 +0200 Subject: [openssl-dev] OID with length zero related bug In-Reply-To: References: Message-ID: <55268137.4020201@opentrust.com> This is a corner case, but an interesting one. An empty OBJECT IDENTIFIER has no meaning, since it can't identify anything. Therefore, one shouldn't be able to allocate such a thing, even less encode it. The CSR is of course invalid, but the previous one was also invalid; OID 0.0 does not identify a signature algorithm (it's the OID { itu-t recommendation }). The decoding step of the "0600" hex sequence correctly produces a "BAD OBJECT", since it's an invalid encoding of an OID. So having an error when decoding such a CSR is a correct behaviour and should be expected. -- Erwann ABALEA Le 09/04/2015 14:36, Juan Antonio Osorio a ?crit : > Hi, > > I've recently encountered that OpenSSL is sending some unexpected > errors when reading X.509 certificate requests, if the key is not > specified, or the CSR is not signed. > > Now, this seems to happen because it now will specify a length=0 in > the ASN.1 structure since the OID is not set (since the key is not > specified). And I think this behaviour was introduced in this commit: > 2e430277578d3dd586cd005682a54a59d6158146 > > So, when using asn1parse to read such a CSR, the section that would > contain the key has BAD OBJECT, and will throw an error such as > 'invalid object encoding' from 'c2i_ASN1_OBJECT' when the certificate > is read or loaded. It used to be the case that it would return an OID > 0.0 with length=1, but, like I said, this is not the case anymore. > > I'm using OpenSSL 1.0.2a. > > I reproduced this error while testing some code using pyOpenSSL. and > here's how I reproduced it: http://pastebin.com/Ky1e8Gz0 > > the asn1parse dump of the CSR that causes the error looks like this: > http://pastebin.com/2EvuaLsk > > While, in OpenSSL 1.0.1f, (the version where I tested this problem > doesn't happen), it would look like this: > http://pastebin.com/0vzu2zzx > > Now, I'm not sure how to actually report this bug, since I'm not sure > if it's a bug related to the way the CSRs are being interpreted, or a > bug related to how the ASN.1 structure is being written. Any insights? > > BR > -- > Juan Antonio Osorio R. > e-mail: jaosorior at gmail.com > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From koraboros at gmail.com Thu Apr 9 13:56:02 2015 From: koraboros at gmail.com (=?UTF-8?Q?Pawe=C5=82_Ka=C5=BAmierczak?=) Date: Thu, 9 Apr 2015 15:56:02 +0200 Subject: [openssl-dev] EC based certificates not supported in CMS - why? In-Reply-To: <20150409132003.GB30497@openssl.org> References: <20150409132003.GB30497@openssl.org> Message-ID: I am affraid EC certs do not work in CMS openSSL 1.0.2. I just wrote a simple test procedure: void cmsTest() { //this RSA works //auto certFileBio = BIO_new_file("c:\\a\\simplersa_noPem.cer", "rb"); //auto prvKeyFileBio = BIO_new_file("c:\\a\\simplersa_pkey.openssl", "rb"); //this EC not auto certFileBio = BIO_new_file("c:\\a\\advancedbr256r1_noPem.cer", "rb"); auto prvKeyFileBio = BIO_new_file("c:\\a\\advancedbr256r1_pkey.pkcs8", "rb"); auto evpPkey = d2i_PrivateKey_bio(prvKeyFileBio, 0); auto cert = d2i_X509_bio(certFileBio, 0); stack_st_X509* certStack = sk_X509_new_null(); sk_X509_push(certStack, cert); X509_STORE* store = X509_STORE_new(); X509_STORE_add_cert(store, cert); //sign auto inFileBio = BIO_new_file("c:\\tmp\\0_inContent.txt", "rb"); CMS_ContentInfo *cms = CMS_sign(cert, evpPkey, 0, inFileBio, 0); auto cmsOutFileBio = BIO_new_file("c:\\tmp\\1_signedCms.txt", "wb"); auto res = PEM_write_bio_CMS_stream(cmsOutFileBio, cms, 0, 0); BIO_free(inFileBio); BIO_free(cmsOutFileBio); //encrypt inFileBio = BIO_new_file("c:\\tmp\\1_signedCms.txt", "rb"); cms = CMS_encrypt(certStack, inFileBio, EVP_aes_128_cbc(), 0); auto ecnryptedCmsOutFileBio = BIO_new_file("c:\\tmp\\2_encryptedSignedCmsOut.txt", "wb"); res = PEM_write_bio_CMS_stream(ecnryptedCmsOutFileBio, cms, 0, 0); BIO_free(inFileBio); BIO_free(ecnryptedCmsOutFileBio); //decrypt inFileBio = BIO_new_file("c:\\tmp\\2_encryptedSignedCmsOut.txt", "rb"); cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); auto decryptedCmsOutFileBio = BIO_new_file("c:\\tmp\\3_decryptedSignedCmsOut.txt", "wb"); res = CMS_decrypt(cms, evpPkey, cert, 0, decryptedCmsOutFileBio, 0); // ERROR HERE ************************************************************** BIO_free(decryptedCmsOutFileBio); BIO_free(inFileBio); //verify/read content CMS inFileBio = BIO_new_file("c:\\tmp\\3_decryptedSignedCmsOut.txt", "rb"); cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); auto decodedCmsOutFileBio = BIO_new_file("c:\\tmp\\4_inContext.txt", "wb"); res = CMS_verify(cms, certStack, store, 0, decodedCmsOutFileBio, 0); auto signers = CMS_get0_signers(cms); BIO_free(inFileBio); BIO_free(decodedCmsOutFileBio); //deinit EVP_PKEY_free(evpPkey); sk_X509_free(certStack); X509_STORE_free(store); BIO_free(certFileBio); BIO_free(prvKeyFileBio); } and it works perfectly if RSA certificate is used but It fails during decrypt if I use the brainpool based certificates. The error occurs in cms_env.c, cms_env_asn1_ctrl function int cms_env_asn1_ctrl(CMS_RecipientInfo *ri, int cmd) { EVP_PKEY *pkey; int i; if (ri->type == CMS_RECIPINFO_TRANS) pkey = ri->d.ktri->pkey; else if (ri->type == CMS_RECIPINFO_AGREE) { EVP_PKEY_CTX *pctx = ri->d.kari->pctx; if (!pctx) return 0; pkey = EVP_PKEY_CTX_get0_pkey(pctx); if (!pkey) return 0; } else return 0; if (!pkey->ameth || !pkey->ameth->pkey_ctrl) return 1; i = pkey->ameth->pkey_ctrl(pkey, ASN1_PKEY_CTRL_CMS_ENVELOPE, cmd, ri); // this returns 0 ********************* if (i == -2) { CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_NOT_SUPPORTED_FOR_THIS_KEY_TYPE); return 0; } if (i <= 0) { CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE); return 0; } return 1; } the i = pkey->ameth->pkey_ctrl call returns 0 and error CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE is set. 2015-04-09 15:20 GMT+02:00 Dr. Stephen Henson : > On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote: > > > Hi, > > > > currently openssl in CMS supports only RSA based certificates but EC > based > > certificates are supported in openssl TLS... so I assume that there is > > already a code that can sing/verify and perform key agreement (ECKA-EG > > ECKA-DH) using eliptic curves. > > > > Can someone please tell me if this will be a lot of work to use that code > > in CMS in a way that CMS could work with EC based certificates? > > > > OpenSSL 1.0.0 and later should support ECDSA in CMS. The use of ECDH is > quite > rare: most implementations just use RSA key exchange. OpenSSL 1.0.2 does > support ECDH though. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From koraboros at gmail.com Thu Apr 9 14:23:59 2015 From: koraboros at gmail.com (=?UTF-8?Q?Pawe=C5=82_Ka=C5=BAmierczak?=) Date: Thu, 9 Apr 2015 16:23:59 +0200 Subject: [openssl-dev] EC based certificates not supported in CMS - why? In-Reply-To: <20150409132003.GB30497@openssl.org> References: <20150409132003.GB30497@openssl.org> Message-ID: Hi, please ignore my previous email I debugged it a bit deeper and it turned out that in case of EC certificates the ecdh_cms_set_shared_info() function could not find "id-aes128-wrap" algo and I solved this by uncommenting following lines: OpenSSL_add_all_algorithms(void); OpenSSL_add_all_ciphers(void); OpenSSL_add_all_digests(void); that for some inexplicable reason ware commented by some very nasty creatue. 2015-04-09 15:20 GMT+02:00 Dr. Stephen Henson : > On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote: > > > Hi, > > > > currently openssl in CMS supports only RSA based certificates but EC > based > > certificates are supported in openssl TLS... so I assume that there is > > already a code that can sing/verify and perform key agreement (ECKA-EG > > ECKA-DH) using eliptic curves. > > > > Can someone please tell me if this will be a lot of work to use that code > > in CMS in a way that CMS could work with EC based certificates? > > > > OpenSSL 1.0.0 and later should support ECDSA in CMS. The use of ECDH is > quite > rare: most implementations just use RSA key exchange. OpenSSL 1.0.2 does > support ECDH though. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Thu Apr 9 16:39:27 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 9 Apr 2015 16:39:27 +0000 Subject: [openssl-dev] EC based certificates not supported in CMS - why? In-Reply-To: References: <20150409132003.GB30497@openssl.org> Message-ID: <20150409163927.GA1167@openssl.org> On Thu, Apr 09, 2015, Pawe?? Ka??mierczak wrote: > I am affraid EC certs do not work in CMS openSSL 1.0.2. I just wrote a > simple test procedure: > > void cmsTest() > { > //this RSA works > //auto certFileBio = BIO_new_file("c:\\a\\simplersa_noPem.cer", "rb"); > //auto prvKeyFileBio = BIO_new_file("c:\\a\\simplersa_pkey.openssl", > "rb"); > > //this EC not > auto certFileBio = BIO_new_file("c:\\a\\advancedbr256r1_noPem.cer", "rb"); > auto prvKeyFileBio = BIO_new_file("c:\\a\\advancedbr256r1_pkey.pkcs8", > "rb"); > > auto evpPkey = d2i_PrivateKey_bio(prvKeyFileBio, 0); > auto cert = d2i_X509_bio(certFileBio, 0); > stack_st_X509* certStack = sk_X509_new_null(); > sk_X509_push(certStack, cert); > X509_STORE* store = X509_STORE_new(); > X509_STORE_add_cert(store, cert); > > //sign > auto inFileBio = BIO_new_file("c:\\tmp\\0_inContent.txt", "rb"); > CMS_ContentInfo *cms = CMS_sign(cert, evpPkey, 0, inFileBio, 0); > auto cmsOutFileBio = BIO_new_file("c:\\tmp\\1_signedCms.txt", "wb"); > auto res = PEM_write_bio_CMS_stream(cmsOutFileBio, cms, 0, 0); > BIO_free(inFileBio); > BIO_free(cmsOutFileBio); > > //encrypt > inFileBio = BIO_new_file("c:\\tmp\\1_signedCms.txt", "rb"); > cms = CMS_encrypt(certStack, inFileBio, EVP_aes_128_cbc(), 0); > auto ecnryptedCmsOutFileBio = > BIO_new_file("c:\\tmp\\2_encryptedSignedCmsOut.txt", "wb"); > res = PEM_write_bio_CMS_stream(ecnryptedCmsOutFileBio, cms, 0, 0); > BIO_free(inFileBio); > BIO_free(ecnryptedCmsOutFileBio); > > //decrypt > inFileBio = BIO_new_file("c:\\tmp\\2_encryptedSignedCmsOut.txt", "rb"); > cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); > auto decryptedCmsOutFileBio = > BIO_new_file("c:\\tmp\\3_decryptedSignedCmsOut.txt", "wb"); > res = CMS_decrypt(cms, evpPkey, cert, 0, decryptedCmsOutFileBio, 0); // > ERROR HERE ************************************************************** > BIO_free(decryptedCmsOutFileBio); > BIO_free(inFileBio); > > //verify/read content CMS > inFileBio = BIO_new_file("c:\\tmp\\3_decryptedSignedCmsOut.txt", "rb"); > cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); > auto decodedCmsOutFileBio = BIO_new_file("c:\\tmp\\4_inContext.txt", > "wb"); > res = CMS_verify(cms, certStack, store, 0, decodedCmsOutFileBio, 0); > auto signers = CMS_get0_signers(cms); > BIO_free(inFileBio); > BIO_free(decodedCmsOutFileBio); > > //deinit > EVP_PKEY_free(evpPkey); > sk_X509_free(certStack); > X509_STORE_free(store); > BIO_free(certFileBio); > BIO_free(prvKeyFileBio); > } > > and it works perfectly if RSA certificate is used but It fails during > decrypt if I use the brainpool based certificates. > The error occurs in cms_env.c, cms_env_asn1_ctrl function > > int cms_env_asn1_ctrl(CMS_RecipientInfo *ri, int cmd) > { > EVP_PKEY *pkey; > int i; > if (ri->type == CMS_RECIPINFO_TRANS) > pkey = ri->d.ktri->pkey; > else if (ri->type == CMS_RECIPINFO_AGREE) { > EVP_PKEY_CTX *pctx = ri->d.kari->pctx; > if (!pctx) > return 0; > pkey = EVP_PKEY_CTX_get0_pkey(pctx); > if (!pkey) > return 0; > } else > return 0; > if (!pkey->ameth || !pkey->ameth->pkey_ctrl) > return 1; > i = pkey->ameth->pkey_ctrl(pkey, ASN1_PKEY_CTRL_CMS_ENVELOPE, cmd, ri); > // this returns 0 ********************* > if (i == -2) { > CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, > CMS_R_NOT_SUPPORTED_FOR_THIS_KEY_TYPE); > return 0; > } > if (i <= 0) { > CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE); > return 0; > } > return 1; > } > > the i = pkey->ameth->pkey_ctrl call returns 0 and error > CMSerr(CMS_F_CMS_ENV_ASN1_CTRL, CMS_R_CTRL_FAILURE is set. > The standard OpenSSL CMS tests in 1.0.2 include an ECDH test but using P-256. Does the cms utility do the same? Hmm... that might be something related to the use of brainPool: I'll check. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From director at openca.org Thu Apr 9 17:30:43 2015 From: director at openca.org (Massimiliano Pala) Date: Thu, 09 Apr 2015 13:30:43 -0400 Subject: [openssl-dev] PKCS7_verify() behavior - possible bug ? Message-ID: <5526B743.4080304@openca.org> Hi all, I was looking at the behavior of PKCS7_verify(). It seems that, if the flags are set to 0, then the function will assume that the "smime_sign" purpose is to be used when verifying the certificate, however, if the PKCS7_NOCHAIN is actually used, it seems that the purpose is not checked. From the code (crypto/pkcs7/pk7_smime.c - line ~320 - function PKCS7_verify() ): if (!(flags & PKCS7_NOVERIFY)) for (k = 0; k < sk_X509_num(signers); k++) { signer = sk_X509_value (signers, k); if (!(flags & PKCS7_NOCHAIN)) { if(!X509_STORE_CTX_init(&cert_ctx, store, signer, p7->d.sign->cert)) { PKCS7err(PKCS7_F_PKCS7_VERIFY,ERR_R_X509_LIB); sk_X509_free(signers); return 0; } X509_STORE_CTX_set_default(&cert_ctx, "smime_sign"); } else if(!X509_STORE_CTX_init (&cert_ctx, store, signer, NULL)) { PKCS7err(PKCS7_F_PKCS7_VERIFY,ERR_R_X509_LIB); sk_X509_free(signers); return 0; } if (!(flags & PKCS7_NOCRL)) X509_STORE_CTX_set0_crls(&cert_ctx, p7->d.sign->crl); i = X509_verify_cert(&cert_ctx); if (i <= 0) j = X509_STORE_CTX_get_error(&cert_ctx); X509_STORE_CTX_cleanup(&cert_ctx); if (i <= 0) { PKCS7err(PKCS7_F_PKCS7_VERIFY,PKCS7_R_CERTIFICATE_VERIFY_ERROR); ERR_add_error_data(2, "Verify error:", X509_verify_cert_error_string(j)); sk_X509_free(signers); return 0; } /* Check for revocation status here */ } Is this the desired behavior or if this is an error ? In other words, shouldn't the "smime_sign" purpose be checked in both cases ? I am asking because I am trying to understand if this behavior is going to be fixed / changed in the future or not (i.e., can we rely on the fact that by using the PKCS7_NOCHAIN flag the "smime_sign" purpose will not be checked) ?. Thanks, Max -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Apr 9 17:51:26 2015 From: rt at openssl.org (Jonas Peterson via RT) Date: Thu, 9 Apr 2015 19:51:26 +0200 Subject: [openssl-dev] [openssl.org #3789] CMS: Segmentation fault when using subject key identifier and EC In-Reply-To: References: Message-ID: Hi, OpenSSL segfaults when trying to create an encrypted CMS data envelope using subject key identifier and EC. Have tested this in version 1.0.2a and latest 1.1.0 release as of today (2015-04-09) with the same result. Example: $ openssl version OpenSSL 1.0.2a 19 Mar 2015 $ openssl ecparam -name prime192v1 -genkey -out ec.key $ openssl req -x509 -new -key ec.key -out ec.crt You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]: State or Province Name (full name) [Some-State]: Locality Name (eg, city) []: Organization Name (eg, company) [Internet Widgits Pty Ltd]: Organizational Unit Name (eg, section) []: Common Name (e.g. server FQDN or YOUR name) []: Email Address []: $ echo "Text to encrypt" > text.txt $ openssl cms -encrypt -keyid -in text.txt -outform DER -recip ec.crt -out out.dat Segmentation fault: 11 If I remove the 'keyid' switch it will work as expected. Best regards, Jonas Peterson From rt at openssl.org Thu Apr 9 17:51:40 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Thu, 9 Apr 2015 19:51:40 +0200 Subject: [openssl-dev] [openssl.org #3790] [PATCH] The wrong ifdef is used to gaurd usage of PSK code In-Reply-To: References: Message-ID: In the commit "Rewrite ssl_asn1.c using new ASN.1 code." (cc5b6a0) the wrong ifdef is used to gaurd usage of PSK code. --- Kurt Cancemi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-The-wrong-ifdef-is-used-to-gaurd-usage-of-PSK-code.patch Type: text/x-patch Size: 686 bytes Desc: not available URL: From rt at openssl.org Fri Apr 10 10:29:22 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 12:29:22 +0200 Subject: [openssl-dev] [openssl.org #3791] Problems configuring for OSX 10.8.5 (x86_64) In-Reply-To: References: Message-ID: This issue has kind of been with the project for so long its just kind of accepted.... But its 2015 and all Apple hardware is x86_64. Its been that way for quite a few years. Also, there's really no reason to (1) default to darwin-i386 and (2) not recognize darwin-x86_64. I suggest that darwin-x86_64 become the default, and configure to recognize darwin-x86_64. ********** $ ./config darwin-x86_64 Operating system: i686-apple-darwinDarwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure darwin64-x86_64-cc' *manually*. You have about 5 seconds to press Ctrl-C to abort. Configuring for darwin-i386-cc target already defined - darwin-i386-cc (offending arg: darwin-x86_64) riemann::openssl-git$ ./config darwin-x86_64-cc Operating system: i686-apple-darwinDarwin Kernel Version 12.6.0: Wed Mar 18 16:23:48 PDT 2015; root:xnu-2050.48.19~1/RELEASE_X86_64 WARNING! If you wish to build 64-bit library, then you have to invoke './Configure darwin64-x86_64-cc' *manually*. You have about 5 seconds to press Ctrl-C to abort. Configuring for darwin-i386-cc target already defined - darwin-i386-cc (offending arg: darwin-x86_64-cc) From rt at openssl.org Fri Apr 10 10:29:33 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 12:29:33 +0200 Subject: [openssl-dev] [openssl.org #3792] OpenSSL debug build lacks -Og In-Reply-To: References: Message-ID: This is for OpenSSL 1.0.2. -Og was added to GCC to allow one to use optimizations that don't disturb a debug session. As I understand it, it acts like like -O1 (to perform some basic analysis) without losing symbol information (i.e., "optimized out" under the debugger). See https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#Optimize-Options. -g3 includes the maximum debug information, including symbolic defines. The debug build configuration setting for GCC uses -O0 and it lacks -g3: "gcc" => { cc => "gcc", cflags => "", debug_cflags => "-O0 -g", release_cflags => "-O3", thread_cflag => "(unknown)", bn_ops => "BN_LLONG", }, For debug builds, perhaps it would be a good idea to use -g3, and -Og when available from GCC. From rt at openssl.org Fri Apr 10 10:29:49 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 12:29:49 +0200 Subject: [openssl-dev] [openssl.org #3793] rec_layer_s3.c and `if (&s->rlayer.read_ahead && !SSL_IS_DTLS(s))` In-Reply-To: References: Message-ID: Working from openssl-git. This could indicate something else was intended. ********** /usr/local/bin/clang -I../crypto -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o record/rec_layer_s3.o record/rec_layer_s3.c record/rec_layer_s3.c:383:20: warning: address of 's->rlayer.read_ahead' will always evaluate to 'true' [-Wpointer-bool-conversion] if (&s->rlayer.read_ahead && !SSL_IS_DTLS(s)) ~~~~~~~~~~^~~~~~~~~~ ~~ From rt at openssl.org Fri Apr 10 10:30:08 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 12:30:08 +0200 Subject: [openssl-dev] [openssl.org #3794] Missing symbols for padlock_aes_block during link in Master In-Reply-To: References: Message-ID: I'm trying to run OpenSSL Master through Clang's sanitizers. Below is from 99-clang-sanitizer.conf (this is my fumbling). $ make making all in crypto... /opt/local/bin/perl5 ../util/mkbuildinf.pl "/usr/local/bin/clang -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN" "darwin-sanitize-x86_64" >buildinf.h /usr/local/bin/clang -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN -c -o cryptlib.o cryptlib.c ... ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -arch x86_64}"; LDCMD="${LDCMD:-/usr/local/bin/clang}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} ) Undefined symbols for architecture x86_64: "_padlock_aes_block", referenced from: _padlock_ofb_cipher in libcrypto.a(e_padlock.o) _padlock_cfb_cipher in libcrypto.a(e_padlock.o) "_padlock_capability", referenced from: _padlock_available in libcrypto.a(e_padlock.o) "_padlock_cbc_encrypt", referenced from: _padlock_cbc_cipher in libcrypto.a(e_padlock.o) "_padlock_cfb_encrypt", referenced from: _padlock_cfb_cipher in libcrypto.a(e_padlock.o) "_padlock_ctr32_encrypt", referenced from: _padlock_ctr32_encrypt_glue in libcrypto.a(e_padlock.o) "_padlock_ecb_encrypt", referenced from: _padlock_ecb_cipher in libcrypto.a(e_padlock.o) "_padlock_key_bswap", referenced from: _padlock_aes_init_key in libcrypto.a(e_padlock.o) "_padlock_ofb_encrypt", referenced from: _padlock_ofb_cipher in libcrypto.a(e_padlock.o) "_padlock_reload_key", referenced from: _padlock_aes_init_key in libcrypto.a(e_padlock.o) _padlock_ofb_cipher in libcrypto.a(e_padlock.o) _padlock_cfb_cipher in libcrypto.a(e_padlock.o) "_padlock_xstore", referenced from: _padlock_rand_bytes in libcrypto.a(e_padlock.o) "_rc4_md5_enc", referenced from: _rc4_hmac_md5_cipher in libcrypto.a(e_rc4_hmac_md5.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[2]: *** [link_app.] Error 1 make[1]: *** [openssl] Error 2 make: *** [build_apps] Error 1 ********** $ ./Configure darwin-sanitize-x86_64 Configuring for darwin-sanitize-x86_64 no-deprecated [default] OPENSSL_NO_DEPRECATED (skip dir) no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=0 CC =/usr/local/bin/clang CFLAG =-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN EX_LIBS =-arch x86_64 CPUID_OBJ =mem_clr.o BN_ASM =bn_asm.o EC_ASM = DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes_core.o aes_cbc.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4_enc.o rc4_skey.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM = SHA1_OBJ_ASM = RMD160_OBJ_ASM= CMLL_ENC =camellia.o cmll_misc.o cmll_cbc.o MODES_OBJ = ENGINES_OBJ = PROCESSOR = RANLIB =/usr/bin/ranlib ARFLAGS = PERL =/opt/local/bin/perl5 SIXTY_FOUR_BIT_LONG mode DES_UNROLL used DES_INT used RC4_CHUNK is unsigned long Configured for darwin-sanitize-x86_64. ********** ## Personal configuration targets ## ## If you edit this file, run this command before committing ## make -f Makefile.org TABLE ## This file is interpolated by the Configure script. %targets = ( "darwin-sanitize-x86_64" => { sys_id => "MACOSX", # inherit_from => [ asm("x86_64_asm") ], cc => "clang", cflags => "-g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN", lflags => "-arch x86_64", bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL", thread_cflag => "-D_REENTRANT", perlasm_scheme => "osx64", dso_scheme => "dlfcn", }, "darwin-sanitize-i386" => { sys_id => "MACOSX", # inherit_from => [ asm("x86_asm") ], cc => "clang", cflags => "-g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch i386 -DL_ENDIAN", lflags => "-arch i386", bn_ops => "BN_LLONG RC4_INT RC4_CHUNK DES_UNROLL BF_PTR", thread_cflag => "-D_REENTRANT", perlasm_scheme => "osx32", dso_scheme => "dlfcn", }, ); ********** $ grep -R padlock_aes_block * engines/asm/e_padlock-x86.pl:&function_begin_B("padlock_aes_block"); engines/asm/e_padlock-x86.pl:&function_end_B("padlock_aes_block"); engines/asm/e_padlock-x86_64.pl:.globl padlock_aes_block engines/asm/e_padlock-x86_64.pl:.type padlock_aes_block,\@function,3 engines/asm/e_padlock-x86_64.pl:padlock_aes_block: engines/asm/e_padlock-x86_64.pl:.size padlock_aes_block,.-padlock_aes_block engines/e_padlock.c:void padlock_aes_block(void *out, const void *inp, engines/e_padlock.c: padlock_aes_block(ivp, ivp, cdata); engines/e_padlock.c: padlock_aes_block(ivp, ivp, cdata); engines/e_padlock.c: padlock_aes_block(ivp, ivp, cdata); Binary file engines/e_padlock.o matches Binary file libcrypto.a matches From rt at openssl.org Fri Apr 10 10:30:23 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 12:30:23 +0200 Subject: [openssl-dev] [openssl.org #3795] OS X is using LD_LIBRARY_PATH, and not DYLD_LIBRARY_PATH in Master In-Reply-To: References: Message-ID: I'm working with Master on OS X. I tried to add a build configuration of Clang and its sanitizers. I think I got the Darwin and OS X specific stuff included in the CONF file (see below). During link, it appears LD_LIBRARY_PATH is used rather than DYLD_LIBRARY_PATH. On OS X, DYLD_LIBRARY_PATH should be used. See https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html. ********** make[2]: Nothing to be done for `all'. making all in apps... rm -f openssl shlib_target=; if [ -n "" ]; then \ shlib_target=""; \ fi; \ LIBRARIES="-L.. -lssl -L.. -lcrypto" ; \ make -f ../Makefile.shared -e \ APPNAME=openssl OBJECTS="openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o" \ LIBDEPS=" $LIBRARIES -arch x86_64" \ link_app.${shlib_target} ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -arch x86_64}"; LDCMD="${LDCMD:-/usr/local/bin/clang}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} ) ... ********** ## Personal configuration targets ## ## If you edit this file, run this command before committing ## make -f Makefile.org TABLE ## This file is interpolated by the Configure script. %targets = ( "darwin-sanitize-x86_64" => { sys_id => "MACOSX", # inherit_from => [ asm("x86_64_asm") ], cc => "clang", cflags => "-g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch x86_64 -DL_ENDIAN", lflags => "-arch x86_64", bn_ops => "SIXTY_FOUR_BIT_LONG RC4_CHUNK DES_INT DES_UNROLL", thread_cflag => "-D_REENTRANT", perlasm_scheme => "osx64", dso_scheme => "dlfcn", }, "darwin-sanitize-i386" => { sys_id => "MACOSX", # inherit_from => [ asm("x86_asm") ], cc => "clang", cflags => "-g3 -O1 -Wall -fsanitize=undefined -fsanitize=address -arch i386 -DL_ENDIAN", lflags => "-arch i386", bn_ops => "BN_LLONG RC4_INT RC4_CHUNK DES_UNROLL BF_PTR", thread_cflag => "-D_REENTRANT", perlasm_scheme => "osx32", dso_scheme => "dlfcn", }, ); From rt at openssl.org Fri Apr 10 18:28:43 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Fri, 10 Apr 2015 20:28:43 +0200 Subject: [openssl-dev] [openssl.org #3792] AutoReply: OpenSSL debug build lacks -Og In-Reply-To: References: Message-ID: According to Jonathon Wakely on the GCC mailing list, you can use the following to see what optimizations are enabled with -Og: {gcc|g++} -Q -Og --help=optimizers See "What optimizations are included in -Og?", https://gcc.gnu.org/ml/gcc-help/2015-04/msg00064.html. (Its interesting the question was asked on GCC mailing list on the same day the suggestion to use -Og was made. Fate is with us). From rainer.jung at kippdata.de Sat Apr 11 07:54:29 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Sat, 11 Apr 2015 09:54:29 +0200 Subject: [openssl-dev] [openssl-commits] [openssl] master update In-Reply-To: <1428683327.275920.27393.nullmailer@dev.openssl.org> References: <1428683327.275920.27393.nullmailer@dev.openssl.org> Message-ID: <5528D335.1040209@kippdata.de> Am 10.04.2015 um 18:28 schrieb Viktor Dukhovni: > The branch master has been updated > via 34b0a927ab5c9232bcf864d524a9bf2558411700 (commit) > from e71cecd551f1d8beca20681184d94f7000a5e333 (commit) > > > - Log ----------------------------------------------------------------- > commit 34b0a927ab5c9232bcf864d524a9bf2558411700 > Author: Viktor Dukhovni > Date: Fri Apr 10 12:25:30 2015 -0400 > > Polish shell script to avoid needless complexity. > > No need for here documents, just use "yes" or No need for "|| exit 1" clauses, just use "set -e". > > Reviewed-by: Rich Salz > Reviewed-by: Richard Levitte > > ----------------------------------------------------------------------- > > Summary of changes: > test/testca | 32 +++++++++----------------------- > 1 file changed, 9 insertions(+), 23 deletions(-) > > diff --git a/test/testca b/test/testca > index d4d0159..4bcb1fd 100644 > --- a/test/testca > +++ b/test/testca > @@ -1,5 +1,7 @@ > #!/bin/sh So this is a /bin/sh script, not necessarily bash or ksh, and thus ... > @@ -9,35 +11,19 @@ else > fi > export PATH > > -SSLEAY_CONFIG="-config CAss.cnf" > -export SSLEAY_CONFIG > - > -OPENSSL="`pwd`/../util/opensslwrap.sh" > -export OPENSSL > +export SSLEAY_CONFIG="-config CAss.cnf" > +export OPENSSL="`pwd`/../util/opensslwrap.sh" ... > -SSLEAY_CONFIG="-config Uss.cnf" > -export SSLEAY_CONFIG > -$PERL ../apps/CA.pl -newreq || exit 1 > +export SSLEAY_CONFIG="-config Uss.cnf" > +$PERL ../apps/CA.pl -newreq > > SSLEAY_CONFIG="-config ../apps/openssl.cnf" > -export SSLEAY_CONFIG > - Combining X=Y export X into export X=Y does not work for all plain Shells. E.g. /bin/sh on Solaris is a Bourne Shell, which does not support this shortcut: $ export X=Y X=Y: is not an identifier Regards, Rainer From rt at openssl.org Sat Apr 11 11:44:15 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 11 Apr 2015 13:44:15 +0200 Subject: [openssl-dev] [openssl.org #3788] Bug: Certificate expiration date error for 9000+ days In-Reply-To: <55252B92.5060705@gmail.com> References: <55252B92.5060705@gmail.com> Message-ID: On Wed Apr 08 17:20:33 2015, khovayko at gmail.com wrote: > Hi, > > I am using FreeBSD 8.2, 32bits i386, OpenSSL package: > openssl-1.0.1_18 SSL and crypto library > > During certificate generation, I found the bug: > If request CA-lifespan too long, then expiration date drops into far > past, and > CA-certificate is invalid. > > Moreover, this is no any error message print, everything works, and > this > certicicate signs another client certificates. > But, when I rtied login with these client certs, I received error: > ssl_error_expired_cert_alert - Mozilla, Seamonkey > ssl_error_bad_cert_alert - Chrome > > I assume, problem in the signed int overflow. > > See bug example following: > > If request 10000 days, then expiration date written in 1906! > That's strange. Could you somehow be using OpenSSL 0.9.8 to generate that certificate? That's a known bug on older versions and 32 bits but 1.0.1 includes its own date routines. I just tried this with a 32 bit build and the latest 1.0.1 branch and get: Validity Not Before: Apr 11 11:41:26 2015 GMT Not After : Aug 27 11:41:26 2042 GMT Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From fedor at indutny.com Sat Apr 11 12:21:13 2015 From: fedor at indutny.com (Fedor Indutny) Date: Sat, 11 Apr 2015 14:21:13 +0200 Subject: [openssl-dev] [PATCH] evp: fix memory corruption on absent payload Message-ID: Hello! aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD payload, but fail to operate if it wasn't supplied. In fact, in case of absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the memory will be corrupted (which sometimes leads to the crash). NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this in 1.0.2, so this commit could be considered to be a partial back-port of that one. Attached is the suggested patch. Thank you, Fedor. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0 kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1 Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv pl3+vgsqfHkGs0I+W6Hy =GkP4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-evp-fix-memory-corruption-on-absent-payload.patch Type: application/octet-stream Size: 1393 bytes Desc: not available URL: From rt at openssl.org Sat Apr 11 13:06:01 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sat, 11 Apr 2015 15:06:01 +0200 Subject: [openssl-dev] [openssl.org #3790] [PATCH] The wrong ifdef is used to gaurd usage of PSK code In-Reply-To: References: Message-ID: Fixed now, 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 Apr 11 15:36:48 2015 From: rt at openssl.org (Hanno Boeck via RT) Date: Sat, 11 Apr 2015 17:36:48 +0200 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: <20150411140931.1ac670cf@pc1.fritz.box> References: <20150411140931.1ac670cf@pc1.fritz.box> Message-ID: The docs for the verify command here https://www.openssl.org/docs/apps/verify.html list a parameter -crlfile. However this parameter doesn't exist in that spelling. It is called -CRLfile (uppercase CRL) and the parameter checking is case sensitive. So the doc and the webpage as it is right now is wrong. See attached patch to fix. Please apply. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-fix-doc-verify-crlfile.diff Type: text/x-patch Size: 583 bytes Desc: not available URL: -------------- 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 Apr 11 15:37:02 2015 From: rt at openssl.org (Fedor Indutny via RT) Date: Sat, 11 Apr 2015 17:37:02 +0200 Subject: [openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload In-Reply-To: References: Message-ID: Hello! aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD payload, but fail to operate if it wasn't supplied. In fact, in case of absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the memory will be corrupted (which sometimes leads to the crash). NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this in 1.0.2, so this commit could be considered to be a partial back-port of that one. Attached is the suggested patch. Thank you, Fedor. -------------- next part -------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0 kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1 Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv pl3+vgsqfHkGs0I+W6Hy =GkP4 -----END PGP SIGNATURE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-evp-fix-memory-corruption-on-absent-payload.patch Type: application/octet-stream Size: 1393 bytes Desc: not available URL: From rt at openssl.org Sat Apr 11 16:39:34 2015 From: rt at openssl.org (Oleg Khovayko via RT) Date: Sat, 11 Apr 2015 18:39:34 +0200 Subject: [openssl-dev] [openssl.org #3788] Bug: Certificate expiration date error for 9000+ days In-Reply-To: <55294E2C.1070307@gmail.com> References: <55252B92.5060705@gmail.com> <55294E2C.1070307@gmail.com> Message-ID: Yes, you right! When I build custom OpenSSL for upgrade, it installs package into /usr/local/bin, not /usr/bin. In the /usr/bin/ runs old 0.9.8. I fixed error by: cd /usr/bin mv openssl openssl-orig-0.9.8 ln -s /usr/local/bin/openssl . Thanks for suggestion, and sorry for disturbing! Please, close this ticket. Maybe, good idea write warning for BSD users. Thanks, Oleg Stephen Henson via RT wrote: > On Wed Apr 08 17:20:33 2015, khovayko at gmail.com wrote: >> Hi, >> >> I am using FreeBSD 8.2, 32bits i386, OpenSSL package: >> openssl-1.0.1_18 SSL and crypto library >> >> During certificate generation, I found the bug: >> If request CA-lifespan too long, then expiration date drops into far >> past, and >> CA-certificate is invalid. >> >> Moreover, this is no any error message print, everything works, and >> this >> certicicate signs another client certificates. >> But, when I rtied login with these client certs, I received error: >> ssl_error_expired_cert_alert - Mozilla, Seamonkey >> ssl_error_bad_cert_alert - Chrome >> >> I assume, problem in the signed int overflow. >> >> See bug example following: >> >> If request 10000 days, then expiration date written in 1906! >> > That's strange. Could you somehow be using OpenSSL 0.9.8 to generate that > certificate? That's a known bug on older versions and 32 bits but 1.0.1 > includes its own date routines. I just tried this with a 32 bit build and the > latest 1.0.1 branch and get: > > Validity > Not Before: Apr 11 11:41:26 2015 GMT > Not After : Aug 27 11:41:26 2042 GMT > > 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 Apr 11 16:45:51 2015 From: rt at openssl.org (Oleg Khovayko via RT) Date: Sat, 11 Apr 2015 18:45:51 +0200 Subject: [openssl-dev] [openssl.org #3788] Bug: Certificate expiration date error for 9000+ days In-Reply-To: <55294FA3.4050303@gmail.com> References: <55252B92.5060705@gmail.com> <55294FA3.4050303@gmail.com> Message-ID: Yes, you right! When I build custom OpenSSL for upgrade, it installs package into /usr/local/bin, not /usr/bin. In the /usr/bin/ runs old 0.9.8. I fixed error by: cd /usr/bin mv openssl openssl-orig-0.9.8 ln -s /usr/local/bin/openssl . Thanks for suggestion, and sorry for disturbing! Please, close this ticket. Maybe, good idea write warning for FreeBSD users. Thanks, Oleg PS: Also, just for your information: We created PKI for OpenSSH public keys, based on cryptocurrency blockchain. See details here: http://emercoin.com/EmerCoin_and_OpenSSH If you found it useful and have any questions/suggestions, you're welcome. Stephen Henson via RT wrote: On Wed Apr 08 17:20:33 2015, khovayko at gmail.com wrote: Hi, I am using FreeBSD 8.2, 32bits i386, OpenSSL package: openssl-1.0.1_18 SSL and crypto library During certificate generation, I found the bug: If request CA-lifespan too long, then expiration date drops into far past, and CA-certificate is invalid. Moreover, this is no any error message print, everything works, and this certicicate signs another client certificates. But, when I rtied login with these client certs, I received error: ssl_error_expired_cert_alert - Mozilla, Seamonkey ssl_error_bad_cert_alert - Chrome I assume, problem in the signed int overflow. See bug example following: If request 10000 days, then expiration date written in 1906! That's strange. Could you somehow be using OpenSSL 0.9.8 to generate that certificate? That's a known bug on older versions and 32 bits but 1.0.1 includes its own date routines. I just tried this with a 32 bit build and the latest 1.0.1 branch and get: Validity Not Before: Apr 11 11:41:26 2015 GMT Not After : Aug 27 11:41:26 2042 GMT Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From fedor at indutny.com Sat Apr 11 19:06:00 2015 From: fedor at indutny.com (Fedor Indutny) Date: Sat, 11 Apr 2015 21:06:00 +0200 Subject: [openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload In-Reply-To: References: Message-ID: Special credit to: Etienne Stalmans (SP) for reporting the segfault in a first place! On Sat, Apr 11, 2015 at 5:37 PM, Fedor Indutny via RT wrote: > Hello! > > aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD > payload, but fail to operate if it wasn't supplied. In fact, in case of > absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the > memory will be corrupted (which sometimes leads to the crash). > > NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this > in 1.0.2, so this commit could be considered to be a partial back-port > of that one. > > Attached is the suggested patch. > > Thank you, > Fedor. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a > PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N > z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0 > kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL > Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD > fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1 > Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS > HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c > GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX > P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb > kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv > pl3+vgsqfHkGs0I+W6Hy > =GkP4 > -----END PGP SIGNATURE----- > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Apr 11 19:06:52 2015 From: rt at openssl.org (Fedor Indutny via RT) Date: Sat, 11 Apr 2015 21:06:52 +0200 Subject: [openssl-dev] [openssl.org #3797] [PATCH] evp: fix memory corruption on absent payload In-Reply-To: References: Message-ID: Special credit to: Etienne Stalmans (SP) for reporting the segfault in a first place! On Sat, Apr 11, 2015 at 5:37 PM, Fedor Indutny via RT wrote: > Hello! > > aes-128-cbc-hmac-sha1, aes-256-cbc-hmac-sha1 ciphers expect the AEAD > payload, but fail to operate if it wasn't supplied. In fact, in case of > absent payload - `plen` is going to be `NO_PAYLOAD_LENGTH` and the > memory will be corrupted (which sometimes leads to the crash). > > NOTE: 41cf2d2518f8b7f31287984ea9f13bc9d55205dc implicitly fixes this > in 1.0.2, so this commit could be considered to be a partial back-port > of that one. > > Attached is the suggested patch. > > Thank you, > Fedor. > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > > iQIcBAABAgAGBQJVKRE0AAoJENcGPM4Zt+iQKKwP/jyRhiNNMy7YVrvHTA/bF02a > PatvQGulRJvOPw0IzB8YydAsJbrBnYrVx1eniBv+5vjcA/9Tbc3yo0drIZR+um9N > z0ky4lDmQnIW5JHMhWkw55kEqpnV16rw5AeMfg4aNhFm/5m0tNHyb5Ft9Epu9hh0 > kLV7RGKKmdPP/3FUKtQNictKUAcESZaIJeDeB24XKTOzAuSdPEunfST0tQG6qjtL > Chj2XrtFDJb+eonjWQmq2RZb67q2qituTOsuqv+e26mgulocnDanrRXetUiTyhDD > fjBNXBSUHME/xmfD5ffJR/eSnzY/Xzg7E14n4S4ctIPpfZ/3ked86wCj+PC1RGT1 > Xt8lIhWwBzxDGn0161vMpFK59zWdFYBR+V6X0ubCO44F0ZfnExWAtxlr2/YkJyCS > HYMgJEZEyIp4qt9ubJ3gOFn7r5Dzo+Dc/hi2xmEneISiYvnu5ugjh4cQU/SQxy8c > GYI1KDbvhz0K/Z/qs/ByaSeYlcE5ZVanbvb8YyqtIAsRklaVzfapssMBMcWUTYcX > P6lt9sAmC7/wNdXvTMCUZoLS1Gz5HX5rmfdquT82kRWI5VYfN5qwWWwz1nN3VNcb > kyBf9NX1FJ/7tzQmYPDGNgif09vwPVD0x3q5gA5WYnrP/JZL6JYQpT9gHH7lz7Lv > pl3+vgsqfHkGs0I+W6Hy > =GkP4 > -----END PGP SIGNATURE----- > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > From rt at openssl.org Sun Apr 12 12:55:27 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Sun, 12 Apr 2015 14:55:27 +0200 Subject: [openssl-dev] [openssl.org #3788] Bug: Certificate expiration date error for 9000+ days In-Reply-To: <55252B92.5060705@gmail.com> References: <55252B92.5060705@gmail.com> Message-ID: OK thanks for the update, ticket resolved. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rt at openssl.org Sun Apr 12 13:00:50 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 12 Apr 2015 15:00:50 +0200 Subject: [openssl-dev] [openssl.org #3798] null check in x509_lu.c:cleanup In-Reply-To: References: Message-ID: around line 218 add the if check: static void cleanup(X509_OBJECT *a) { + if (!a) + return; . From rt at openssl.org Sun Apr 12 13:01:11 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 12 Apr 2015 15:01:11 +0200 Subject: [openssl-dev] [openssl.org #3799] add null to check X509_STORE_CTX_free In-Reply-To: References: Message-ID: Around line 2226 add the NULL check. void X509_STORE_CTX_free(X509_STORE_CTX *ctx) { + if (!ctx) + return; From rsalz at akamai.com Mon Apr 13 00:05:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Apr 2015 00:05:22 +0000 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: References: <20150411140931.1ac670cf@pc1.fritz.box> Message-ID: <1dc2110effad4c3397f381f5518b07d6@usma1ex-dag1mb2.msg.corp.akamai.com> I'm thinking of make the flags to the openssl apps be case-insensitive. Thoughts? Thanks for the patch. From uri at ll.mit.edu Mon Apr 13 00:31:57 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 13 Apr 2015 00:31:57 +0000 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: <1dc2110effad4c3397f381f5518b07d6@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC2712BAAB@LLE2K10-MBX01.mitll.ad.local> Good idea, IMHO. -- Regards, Uri Blumenthal Voice: (781) 981-1638 Cyber Systems and Technology Fax: (781) 981-0186 MIT Lincoln Laboratory Cell: (339) 223-5363 244 Wood Street, Lexington, MA 02420-9185 Web: http://www.ll.mit.edu/CST/ MIT LL Root CA: ----- Original Message ----- From: Salz, Rich [mailto:rsalz at akamai.com] Sent: Sunday, April 12, 2015 08:05 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option I'm thinking of make the flags to the openssl apps be case-insensitive. Thoughts? Thanks for the patch. _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Mon Apr 13 08:28:29 2015 From: rt at openssl.org (Hanno Boeck via RT) Date: Mon, 13 Apr 2015 10:28:29 +0200 Subject: [openssl-dev] [openssl.org #3800] malformed asn1 definition causes segfault in openssl asn1parse In-Reply-To: <20150412173933.1588d205@pc1.fritz.box> References: <20150412173933.1588d205@pc1.fritz.box> Message-ID: Attached file will crash the asn1 definitions parser. To test: openssl asn1parse -genconf segfault.asn I tried to create a stack trace with gdb to see what's going on and it is several megabytes in size and contains lines like: #24353 0x00007ffff78665be in asn1_multi (cnf=0x7fffffffd410, section=, utype=16) at asn1_gen.c:456 #24354 ASN1_generate_v3 (str=, cnf=cnf at entry=0x7fffffffd410) at asn1_gen.c:165 #24355 0x00007ffff78665be in asn1_multi (cnf=0x7fffffffd410, section=, utype=16) at asn1_gen.c:456 Looks to me like some endless recursion loop is happening which causes a stack overflow. Address sanitizer will sometimes report a "Bus error" and sometimes a stack overflow (depending on combination of CFLAGS and compiler): ==15366==ERROR: AddressSanitizer: stack-overflow on address 0x7fff71055ff8 (pc 0x000000477982 bp 0x000000000030 sp 0x7fff71056000 T0) o #0 0x477981 in __sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback>::AllocateBatch(__sanitizer::AllocatorStats*, __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback> >*, unsigned long) (/data/openssl/openssl-1.0.2a-clang-asan-ubsan/apps/openssl+0x477981) #1 0x47780e in __sanitizer::SizeClassAllocatorLocalCache<__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback> >::Refill(__sanitizer::SizeClassAllocator64<105553116266496ul, 4398046511104ul, 0ul, __sanitizer::SizeClassMap<17ul, 128ul, 16ul>, __asan::AsanMapUnmapCallback>*, unsigned long) (/data/openssl/openssl-1.0.2a-clang-asan-ubsan/apps/openssl+0x47780e) As it is unlikely that asn1 definitions are attacker-controlled I don't assume this has any security impact. Found with the help of american fuzzy lop. -------------- next part -------------- A non-text attachment was scrubbed... Name: segfault.asn Type: application/octet-stream Size: 83 bytes Desc: not available URL: From rt at openssl.org Mon Apr 13 08:29:03 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 13 Apr 2015 10:29:03 +0200 Subject: [openssl-dev] [openssl.org #3801] need NULL check in CMAC_CTX_free In-Reply-To: References: Message-ID: need to add these lines around 115 in cma.c void CMAC_CTX_free(CMAC_CTX *ctx) { + if (!ctx) + return; CMAC_CTX_cleanup(ctx); OPENSSL_free(ctx); } . From hanno at hboeck.de Mon Apr 13 09:55:48 2015 From: hanno at hboeck.de (Hanno =?UTF-8?B?QsO2Y2s=?=) Date: Mon, 13 Apr 2015 11:55:48 +0200 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: <1dc2110effad4c3397f381f5518b07d6@usma1ex-dag1mb2.msg.corp.akamai.com> References: <20150411140931.1ac670cf@pc1.fritz.box> <1dc2110effad4c3397f381f5518b07d6@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150413115548.107c87dd@pc1.fritz.box> Hi, On Mon, 13 Apr 2015 00:05:22 +0000 "Salz, Rich" wrote: > I'm thinking of make the flags to the openssl apps be > case-insensitive. Thoughts? Not sure this is such a good idea. I'm usually a friend of keeping stuff "more strict" to avoid confusions. Also changing this now could cause an obvious backwards problem: People using newer openssl versions may write docs which rely on the case insensitivity and people using old versions may wonder why these don't work for them. > Thanks for the patch. Independent of the case sensitivity (which likely won't be backported anyway), patch should be noncontroversial to apply right away, right? -- 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 Mon Apr 13 11:28:58 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 13 Apr 2015 11:28:58 +0000 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: <20150413115548.107c87dd@pc1.fritz.box> References: <20150411140931.1ac670cf@pc1.fritz.box> <1dc2110effad4c3397f381f5518b07d6@usma1ex-dag1mb2.msg.corp.akamai.com> <20150413115548.107c87dd@pc1.fritz.box> Message-ID: > Independent of the case sensitivity (which likely won't be backported > anyway), patch should be noncontroversial to apply right away, right? For some definition of 'right away' :) yes. From koraboros at gmail.com Mon Apr 13 12:56:02 2015 From: koraboros at gmail.com (=?UTF-8?Q?Pawe=C5=82_Ka=C5=BAmierczak?=) Date: Mon, 13 Apr 2015 14:56:02 +0200 Subject: [openssl-dev] CMS: is there a support for authenticated encryption (aes-gcm, aes-cbc-cmac etc.) in CMS? Message-ID: Hello, is there a support for aes-gcm in openSSL CMS implementaion? Following code works when EVP_aes_128_cbc is used as CMS_encrypt param but fails with EVP_aes_128_gcm. Am I missing something (like setting the gcm header/tag) or authenticated encryption is not supported in CMS? void cmsTest() { OPENSSL_init(); SSL_library_init(); SSL_load_error_strings(); OpenSSL_add_all_algorithms(); OpenSSL_add_all_ciphers(); OpenSSL_add_all_digests(); auto certFileBio = BIO_new_file("c:\\a\\advancedbr256r1_noPem.cer", "rb"); auto prvKeyFileBio = BIO_new_file("c:\\a\\advancedbr256r1_pkey.pkcs8", "rb"); auto evpPkey = d2i_PrivateKey_bio(prvKeyFileBio, 0); auto cert = d2i_X509_bio(certFileBio, 0); stack_st_X509* certStack = sk_X509_new_null(); sk_X509_push(certStack, cert); X509_STORE* store = X509_STORE_new(); X509_STORE_add_cert(store, cert); //sign auto inFileBio = BIO_new_file("c:\\tmp2\\0_inContent.txt", "rb"); CMS_ContentInfo *cms = CMS_sign(cert, evpPkey, 0, inFileBio, 0); auto cmsOutFileBio = BIO_new_file("c:\\tmp2\\1_signedCms.txt", "wb"); auto res = PEM_write_bio_CMS(cmsOutFileBio, cms); BIO_free(inFileBio); BIO_free(cmsOutFileBio); //encrypt inFileBio = BIO_new_file("c:\\tmp2\\1_signedCms.txt", "rb"); //cms = CMS_encrypt(certStack, inFileBio, EVP_aes_128_cbc(), 0); this would work********************** cms = CMS_encrypt(certStack, inFileBio, EVP_aes_128_gcm(), 0); auto ecnryptedCmsOutFileBio = BIO_new_file("c:\\tmp2\\2_encryptedSignedCmsOut.txt", "wb"); res = PEM_write_bio_CMS(ecnryptedCmsOutFileBio, cms); BIO_free(inFileBio); BIO_free(ecnryptedCmsOutFileBio); //decrypt inFileBio = BIO_new_file("c:\\tmp2\\2_encryptedSignedCmsOut.txt", "rb"); cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); auto decryptedCmsOutFileBio = BIO_new_file("c:\\tmp2\\3_decryptedSignedCmsOut.txt", "wb"); res = CMS_decrypt(cms, evpPkey, cert, 0, decryptedCmsOutFileBio, 0); BIO_free(decryptedCmsOutFileBio); BIO_free(inFileBio); //verify/read content CMS inFileBio = BIO_new_file("c:\\tmp2\\3_decryptedSignedCmsOut.txt", "rb"); cms = PEM_read_bio_CMS(inFileBio, 0, 0, 0); auto decodedCmsOutFileBio = BIO_new_file("c:\\tmp2\\4_inContext.txt", "wb"); res = CMS_verify(cms, certStack, store, 0, decodedCmsOutFileBio, 0); auto signers = CMS_get0_signers(cms); BIO_free(inFileBio); BIO_free(decodedCmsOutFileBio); //deinit EVP_PKEY_free(evpPkey); sk_X509_free(certStack); X509_STORE_free(store); BIO_free(certFileBio); BIO_free(prvKeyFileBio); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Mon Apr 13 17:37:29 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 13 Apr 2015 17:37:29 +0000 Subject: [openssl-dev] CMS: is there a support for authenticated encryption (aes-gcm, aes-cbc-cmac etc.) in CMS? In-Reply-To: References: Message-ID: <20150413173728.GA11921@openssl.org> On Mon, Apr 13, 2015, Pawe?? Ka??mierczak wrote: > Hello, > > is there a support for aes-gcm in openSSL CMS implementaion? > Following code works when EVP_aes_128_cbc is used as CMS_encrypt param but > fails with EVP_aes_128_gcm. Am I missing something (like setting the gcm > header/tag) or authenticated encryption is not supported in CMS? > No it's not currently supported and it would require support for a new content type so it's not trivial to add either. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From andrejs.igumenovs at gmail.com Mon Apr 13 18:20:35 2015 From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs) Date: Mon, 13 Apr 2015 21:20:35 +0300 Subject: [openssl-dev] Hello, OpenSSL! Message-ID: <0EFE9F0E-37EC-4B0E-A636-D06BCC81F71A@gmail.com> Dear DevTeam, I am willing to contribute to The OpenSSL Project. How and where do I start? Here is my LinkedIn page: https://ee.linkedin.com/pub/andrejs-igumenovs/53/642/8b6 Thank you, Andrejs. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Apr 13 18:32:05 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 13 Apr 2015 19:32:05 +0100 Subject: [openssl-dev] Hello, OpenSSL! In-Reply-To: <0EFE9F0E-37EC-4B0E-A636-D06BCC81F71A@gmail.com> References: <0EFE9F0E-37EC-4B0E-A636-D06BCC81F71A@gmail.com> Message-ID: <552C0BA5.5010901@openssl.org> On 13/04/15 19:20, Andrejs Igumenovs wrote: > Dear DevTeam, > > I am willing to contribute to The OpenSSL Project. > How and where do I start? Here is a good place: https://wiki.openssl.org/index.php/Main_Page#Feedback_and_Contributions Matt From rt at openssl.org Mon Apr 13 19:39:50 2015 From: rt at openssl.org (Alok Menghrajani via RT) Date: Mon, 13 Apr 2015 21:39:50 +0200 Subject: [openssl-dev] [openssl.org #3802] [PATCH] Fixes some typos in doc/ In-Reply-To: References: Message-ID: Hi, I hope you'll see value in my patches which fix typos in the docs. Alok -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Fixes-some-typos-in-doc-apps.patch Type: application/octet-stream Size: 19302 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Fixes-some-typos-in-doc-ssl.patch Type: application/octet-stream Size: 6009 bytes Desc: not available URL: From rt at openssl.org Mon Apr 13 20:40:09 2015 From: rt at openssl.org (Alok Menghrajani via RT) Date: Mon, 13 Apr 2015 22:40:09 +0200 Subject: [openssl-dev] [openssl.org #3802] [PATCH] Fixes some typos in doc/ In-Reply-To: References: Message-ID: Two more. For 0004-Corrects-port-names-in-documentation-for-BIO_set_con.patch, it is probably worth checking that my deletion is correct. On Mon, Apr 13, 2015 at 12:39 PM, Alok Menghrajani via RT wrote: > Hi, > > I hope you'll see value in my patches which fix typos in the docs. > > Alok > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Fixes-typos-in-doc-crypto.patch Type: application/octet-stream Size: 37289 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-Corrects-port-names-in-documentation-for-BIO_set_con.patch Type: application/octet-stream Size: 1163 bytes Desc: not available URL: From rt at openssl.org Tue Apr 14 12:27:21 2015 From: rt at openssl.org (Yuval El-Hanany via RT) Date: Tue, 14 Apr 2015 14:27:21 +0200 Subject: [openssl-dev] [openssl.org #3803] s_server with ECDHE fails In-Reply-To: References: Message-ID: Hi, s_server fails to load ECDH params. It might work with some compilers/platforms. The fix is in s_server.c : 1000 (1.0.1m) Original code: #ifndef OPENSSL_NO_ECDH int no_ecdhe; #endif Fix #ifndef OPENSSL_NO_ECDH int no_ecdhe = 0; #endif Thanks, Yuval. From rt at openssl.org Tue Apr 14 13:01:12 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 14 Apr 2015 15:01:12 +0200 Subject: [openssl-dev] [openssl.org #3803] s_server with ECDHE fails In-Reply-To: References: Message-ID: Hi Yuval This is a known issue that has already been fixed in git and will be in the next release. Regards Matt From a.yousar at informatik.hu-berlin.de Tue Apr 14 18:44:49 2015 From: a.yousar at informatik.hu-berlin.de (Annie) Date: Tue, 14 Apr 2015 20:44:49 +0200 Subject: [openssl-dev] [1.0.1m] strange behavior of make stacks Message-ID: <552D6021.3020004@informatik.hu-berlin.de> Dear all, I discovered a very strange behavior after the 1.0.1l to 1.0.1m change. The "make stacks" aka the Perl script util/mkstack.pl was broken. But the script itself wasn't changed, you may see that e.g. looking for tab chars, surviving therein. The reason is the change in the comment structuring (!) in crypto/stack/safestack.h. I was faced with this problem working on an implementation for the (stack of) qcStatements, a v3 extension according to RFC 3739. Some explanations: The script util/mkstacks.pl looks for a line beginning with regex ^/\* This block of defines is updated by util/mkstack.pl, please do not touch! \*/ But this line doesn't appear anymore in crypto/stack/safestack.h. It is now transformed into / * * This block of defines is updated by util/mkstack.pl, please do not touch! */ despite the warning "do not touch". The attached patch solves the issue. Beside of this crypto/stack/safestack.h lost also the following line at the very end: /* End of util/mkstack.pl block, you may now edit :-) */ which is also expected by the util/mkstack.pl script. I'm not fully aware of the consequences so I propose to give this line back to safestack. It is also integrated in the patch. Regards, /Ann. -------------- next part -------------- --- openssl-1.0.1m/util/mkstack.pl 2015-03-19 14:37:10.000000000 +0100 +++ openssl-1.0.1m.patch/util/mkstack.pl 2015-04-14 11:52:06.765625000 +0200 @@ -60,8 +60,8 @@ $old_stackfile .= $_; - if (m|^/\* This block of defines is updated by util/mkstack.pl, please do not touch! \*/|) { + if (m|^ \* This block of defines is updated by util/mkstack.pl, please do not touch!|) { $inside_block = 1; } - if (m|^/\* End of util/mkstack.pl block, you may now edit :-\) \*/|) { + if (m|^ \* End of util/mkstack.pl block, you may now edit :-\)|) { $inside_block = 0; } elsif ($inside_block == 0) { @@ -69,5 +69,5 @@ } next if($inside_block != 1); - $new_stackfile .= "/* This block of defines is updated by util/mkstack.pl, please do not touch! */"; + $new_stackfile .= " * This block of defines is updated by util/mkstack.pl, please do not touch!\n */"; foreach $type_thing (sort @stacklst) { @@ -175,5 +175,5 @@ } - $new_stackfile .= "/* End of util/mkstack.pl block, you may now edit :-) */\n"; + $new_stackfile .= "/*\n * End of util/mkstack.pl block, you may now edit :-)\n"; $inside_block = 2; } --- openssl-1.0.1m/crypto/stack/safestack.h 2015-03-19 14:38:23.000000000 +0100 +++ openssl-1.0.1m.patch/crypto/stack/safestack.h 2015-04-14 11:52:56.468750000 +0200 @@ -2531,4 +2531,8 @@ LHM_lh_stats_bio(SSL_SESSION,lh,out) # define lh_SSL_SESSION_free(lh) LHM_lh_free(SSL_SESSION,lh) +/* + * End of util/mkstack.pl block, you may now edit :-) + */ + #ifdef __cplusplus } From rt at openssl.org Wed Apr 15 10:37:01 2015 From: rt at openssl.org (openssl-users@openssl.org via RT) Date: Wed, 15 Apr 2015 12:37:01 +0200 Subject: [openssl-dev] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work. Solaris 10 Solaris Studio 12.4 Make test log attached. 1 When building 1.0.2 using ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden openssl s_client crashes on start: -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 Segmentation Fault (core dumped) -bash-3.00$ pstack core core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 00226140 ssleay_rand_add (ffbfecbc, 1, 20, ffbfeb94, 0, 14) + 530 00227028 RAND_poll (4, ffbfeca8, ffbfecc8, ffbfecc8, 2c0630, 2c0624) + 38c 00226be0 ssleay_rand_status (c734, 0, 2b9f5c, 2c05ac, 2a0e50, 13000) + 138 00065eb4 app_RAND_load_file (ffbfefc0, 2d5218, 1, 2800, 0, 1) + 88 0004d784 s_client_main (0, c00, 0, c00, 2b4adc, 2f4380) + 5c94 0001328c do_cmd (2eb4c8, 3, ffbffa88, 2b4738, 13e64, 2b3e78) + b8 00012f08 main (4, ffbffa84, 2eb4c8, 2a0000, 2b3e78, 2b4adc) + 3a4 00012a08 _start (0, 0, 0, 0, 0, 2b3e78) + 108 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: This is against the server that is still running 1.0.1h and can be successfully connected with openssl s_client built with 1.0.1h. The 64 bit build seems to work perfectly. The 32 bit builds that we use on Windows and Linux also work perfectly. 1.0.2a build fails in the same way. gcc build fails in the same way. I have built 1.0.1m with asm and that works fine. Regards, John. -------------- next part -------------- A non-text attachment was scrubbed... Name: testlogcc.gz Type: application/x-gzip Size: 15240 bytes Desc: not available URL: From rt at openssl.org Wed Apr 15 16:41:45 2015 From: rt at openssl.org (Ravindra Daramwar via RT) Date: Wed, 15 Apr 2015 18:41:45 +0200 Subject: [openssl-dev] [openssl.org #3805] Re: Error while building FIPS capable OpenSSL In-Reply-To: References: Message-ID: Added below OpenSSL version which I am using. -Ravindra From: Ravindra Daramwar > Date: Wednesday, 15 April 2015 5:31 pm To: "openssl-bugs at openssl.org" > Cc: Dhananjay Dodke >, Shahid Munshi > Subject: Error while building FIPS capable OpenSSL Hi, I am trying to build OpenSSL which uses FIPS module. I could build the FIPS module successfully but not OpenSSL. I followed below steps: 1. ./Configure darwin64-x86_64-cc shared fips --with-fipslibdir=/DLPMacSource/depot/tools/mac/openssl_fips/2.0/x86_64/lib/ --with-fipsdir=/DLPMacSource/depot/tools/mac/openssl_fips/2.0/x86_64/ 2. Make Target osx : 10.9.5 Xcode : 5.0.2 OpenSSL version: 1.0.2/1.0.2a ?make" step is giving an error as below rsaz-x86_64.s:1701:2: error: invalid instruction mnemonic 'adoxq' adoxq %rdi,%r15 ^~~~~ rsaz-x86_64.s:1702:2: error: invalid instruction mnemonic 'adcxq' adcxq %rdi,%r15 ^~~~~ make[2]: *** [rsaz-x86_64.o] Error 1 make[1]: *** [subdirs] Error 1 make: *** [build_crypto] Error 1 Please let me which is this issue. Is it because of Xcode compiler, target os or anything else. Thanks. -Ravindra From felix+openssl at cacert.org Wed Apr 15 16:57:44 2015 From: felix+openssl at cacert.org (=?UTF-8?B?RmVsaXggRMO2cnJl?=) Date: Wed, 15 Apr 2015 18:57:44 +0200 Subject: [openssl-dev] Patch for CRL-Times in "openssl ca" Message-ID: <552E9888.5010805@cacert.org> Hi, I'd like to specify the start and end times for the CRLs generated with "openssl ca". I prepared a patch and created a Github Pull-Request (https://github.com/openssl/openssl/pull/258). Is there anything else, I can do to help that this change is incorporated into the official openssl source code? Kind regards, Felix From rsalz at akamai.com Wed Apr 15 17:08:20 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 15 Apr 2015 17:08:20 +0000 Subject: [openssl-dev] Patch for CRL-Times in "openssl ca" In-Reply-To: <552E9888.5010805@cacert.org> References: <552E9888.5010805@cacert.org> Message-ID: <25f25e5aff854828b7e1610480e4c3ca@usma1ex-dag1mb2.msg.corp.akamai.com> > I'd like to specify the start and end times for the CRLs generated with > "openssl ca". I prepared a patch and created a Github Pull-Request > (https://github.com/openssl/openssl/pull/258). Is there anything else, I can > do to help that this change is incorporated into the official openssl source > code? Nope, it's good. We're working our way through a huge code-review of the apps code right now. Once that hits master, then I'll integrate your patch (and various other pending ones). From matt at openssl.org Thu Apr 16 07:59:44 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 16 Apr 2015 08:59:44 +0100 Subject: [openssl-dev] Patch for CRL-Times in "openssl ca" In-Reply-To: <552E9888.5010805@cacert.org> References: <552E9888.5010805@cacert.org> Message-ID: <552F6BF0.1070302@openssl.org> On 15/04/15 17:57, Felix D?rre wrote: > Hi, > > I'd like to specify the start and end times for the CRLs generated with > "openssl ca". I prepared a patch and created a Github Pull-Request > (https://github.com/openssl/openssl/pull/258). Is there anything else, I > can do to help that this change is incorporated into the official > openssl source code? > You should create an RT ticket (send email to rt at openssl.org) with a link to the pull request. Matt From rt at openssl.org Thu Apr 16 13:54:32 2015 From: rt at openssl.org (Michal.Puczynski@teleste.com via RT) Date: Thu, 16 Apr 2015 15:54:32 +0200 Subject: [openssl-dev] [openssl.org #3806] change request - cleanup thread ERR state In-Reply-To: References: Message-ID: Dear OpenSSL developers, I have noticed OpenSSL functions allocate structures for error storage per thread. It might be a good idea to add cleanup of those at thread termination. Suggested patch (1.0.1m) cryptlib.c:762 case DLL_THREAD_DETACH: ERR_remove_thread_state(NULL); break; Regards, Michal Puczy?ski. *----------------- Michal Puczynski Teleste Video Networks Sp. z o.o. e-mail : michal.puczynski at teleste.com phone : +48(71)3736029, +48(71)7947831 mobile : +48 606823410 skype : callto://michal.puczynski address: PL 54-440 Wroclaw ul. Rogowska 117b From rt at openssl.org Thu Apr 16 15:09:30 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 16 Apr 2015 17:09:30 +0200 Subject: [openssl-dev] [openssl.org #3800] malformed asn1 definition causes segfault in openssl asn1parse In-Reply-To: <20150412173933.1588d205@pc1.fritz.box> References: <20150412173933.1588d205@pc1.fritz.box> Message-ID: Fixed now, thanks for the report. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From gmane.bl4 at gishpuppy.com Thu Apr 16 17:45:44 2015 From: gmane.bl4 at gishpuppy.com (Guy) Date: Thu, 16 Apr 2015 12:45:44 -0500 Subject: [openssl-dev] s_client, s_server "-verify_host" Message-ID: verify_host should be verify_hostname? $ openssl version OpenSSL 1.0.2a-fips 19 Mar 2015 $ openssl s_client -showcerts -verify_host HOST -connect HOST:PORT unknown option -verify_host usage: s_client args -host host - use -connect instead -port port - use -connect instead -connect host:port - who to connect to (default is localhost:4433) -verify_host host - check peer certificate matches "host" [...] $ grep -nC3 verify_host apps\apps.c 2320- at_time = (time_t)timestamp; 2321- } 2322- (*pargs)++; 2323: } else if (strcmp(arg, "-verify_hostname") == 0) { 2324- if (!argn) 2325- *badarg = 1; 2326- hostname = argn; $ --- diff U3 a/apps/s_client.c b/apps/s_client.c --- a/apps/s_client.c +++ b/apps/s_client.c @@ -308,7 +308,7 @@ " -connect host:port - who to connect to (default is %s:%s)\n", SSL_HOST_NAME, PORT_STR); BIO_printf(bio_err, - " -verify_host host - check peer certificate matches \"host\"\n"); + " -verify_hostname host - check peer certificate matches \"host\"\n"); BIO_printf(bio_err, " -verify_email email - check peer certificate matches \"email\"\n"); BIO_printf(bio_err, diff U3 a/apps/s_server.c b/apps/s_server.c --- a/apps/s_server.c +++ b/apps/s_server.c @@ -480,7 +480,7 @@ BIO_printf(bio_err, " -accept arg - port to accept on (default is %d)\n", PORT); BIO_printf(bio_err, - " -verify_host host - check peer certificate matches \"host\"\n"); + " -verify_hostname host - check peer certificate matches \"host\"\n"); BIO_printf(bio_err, " -verify_email email - check peer certificate matches \"email\"\n"); BIO_printf(bio_err, --- From rt at openssl.org Thu Apr 16 18:01:39 2015 From: rt at openssl.org (=?UTF-8?B?RmVsaXggRMO2cnJl?= via RT) Date: Thu, 16 Apr 2015 20:01:39 +0200 Subject: [openssl-dev] [openssl.org #3807] Patch for CRL-Times in "openssl ca" In-Reply-To: <552FEDD9.5070803@cacert.org> References: <552FEDD9.5070803@cacert.org> Message-ID: I prepared a patch that adds this command line options and created a Github Pull-Request (https://github.com/openssl/openssl/pull/258) From rt at openssl.org Fri Apr 17 10:24:10 2015 From: rt at openssl.org (Olivier SZIKA via RT) Date: Fri, 17 Apr 2015 12:24:10 +0200 Subject: [openssl-dev] [openssl.org #3808] BUG: corrupted ssl session id In-Reply-To: <796405036.28778360.1429265697846.JavaMail.zimbra@stormshield.eu> References: <1771678525.28767891.1429265377682.JavaMail.zimbra@stormshield.eu> <796405036.28778360.1429265697846.JavaMail.zimbra@stormshield.eu> Message-ID: Hi all, I use openssl library in a daemon (as ssl client), and there are a lot of crashes around ssl session management. A crash happens when ssl sessions are flushed via SSL_CTX_flush_sessions(), because they could have bad session id. > openssl version on FreeBSD OpenSSL 1.0.1m 19 Mar 2015 The client cache is enable with: SSL_CTX_set_session_cache_mode(ctx, SSL_SESS_CACHE_CLIENT) Moreover, I also use: SSL_CTX_sess_set_new_cb(ctx, new_ssl_session_cb); SSL_CTX_sess_set_remove_cb(ctx, remove_ssl_session_cb); So, when server requests new session ticket (SSL3_ST_CR_SESSION_TICKET_[AB]), the session can have more references than once. But in function ssl3_get_new_session_ticket(), session_id is changed without checks on session->references. If session_id is changed then cache access is wrong! To solve this problem, I used a new ssl session, created with i2d/d2i (and release one reference from old ssl session). What do you think? Olivier -- Olivier Szika R&D System Engineer Stormshield - Stormshield Network Security -------------- next part -------------- A non-text attachment was scrubbed... Name: patch-ssl-session Type: text/x-patch Size: 1630 bytes Desc: not available URL: From rt at openssl.org Fri Apr 17 14:00:50 2015 From: rt at openssl.org (John Unsworth via RT) Date: Fri, 17 Apr 2015 16:00:50 +0200 Subject: [openssl-dev] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: References: Message-ID: If I build using just ./Configure solaris-sparcv9-cc Everything works fine. However ./Configure solaris-sparcv9-cc -xcode=pic32 Causes the problem. John. From rt at openssl.org Fri Apr 17 20:09:15 2015 From: rt at openssl.org (Daniel Etzold via RT) Date: Fri, 17 Apr 2015 22:09:15 +0200 Subject: [openssl-dev] [openssl.org #3809] [enhancement request] add critical to basicContraints in openssl.cnf In-Reply-To: References: Message-ID: The configuration file openssl.cnf in the repository in path app/ has the following entry for a ?typical CA?: # This is what PKIX recommends but some broken software chokes on critical # extensions. #basicConstraints = critical,CA:true # So we do this instead. basicConstraints = CA:true These settings date back to year 1999. [1, 2] As I understand RFC 5280 correctly conforming CAs must mark the basicContraints extension as critical if the public key is used to validate digital signatures on certificates. Since this is the ?typical? case (and the configuration is for a ?typical CA?) I would like to suggest to change the default behaviour and set the basicConstraints extension to critical by default. I think the right way is not to ?fix? the configuration file so that it works with broken software. Instead the default settings should be as close as possible to the RFC. Sources: RFC 5280: ?Conforming CAs MUST include this extension in all CA certificates that contain public keys used to validate digital signatures on certificates and MUST mark the extension as critical in such certificates.? [1] https://github.com/openssl/openssl/commit/257e206da6b42181b0dc8976792164c4d9cff89b#diff-8ce6aaad88b10ed2b3b4592fd5c8e03a [2] https://github.com/openssl/openssl/commit/b2347661cef9447600a77b33575639a1bce6725c From rt at openssl.org Fri Apr 17 20:09:22 2015 From: rt at openssl.org (Gueron, Shay via RT) Date: Fri, 17 Apr 2015 22:09:22 +0200 Subject: [openssl-dev] [openssl.org #3810] [PATCH] Improved P256 ECC performance by means of a dedicated function for modular inversion modulo the P256 group order In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939BD3C4B@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939BD3C4B@hasmsx107.ger.corp.intel.com> Message-ID: Hello all, This patch is a contribution to OpenSSL. It concerns the P256 ECC implementation. The patch improves upon our previous submission, by providing a dedicated function to perform modular inversion modulo the P256 group order. Results: The performance improvements, for single threaded applications, compared to the current (development) version of OpenSSL are as follows. (measured by "openssl speed" utility) On Architecture Codename Haswell: ECDSA sign: 1.28X ECDSA verify: 1.10X On Architecture Broadwell: ECDSA sign: 1.42X ECDSA verify: 1.18X We license the whole submission under BSD license. Developers and authors: *************************************************************************** Shay Gueron (1, 2), and Vlad Krasnov (3) (1) University of Haifa, Israel (2) Intel Corporation, Israel Development Center, Haifa, Israel (3) CloudFlare, Inc. *************************************************************************** --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: nistz256_inv_ord.patch Type: application/octet-stream Size: 37978 bytes Desc: not available URL: From dominyktiller at gmail.com Sat Apr 18 13:16:14 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Sat, 18 Apr 2015 14:16:14 +0100 Subject: [openssl-dev] OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) Message-ID: <5532591E.6000600@gmail.com> Apologies that this is kinda badly written. Detailed bug reports aren't my forte. Feel free to ping back questions if detail isn't clear/useful/etc. OS X 10.10.3?s release changed some certs in the Keychain. There?s a full list of changes here: https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a This has caused some chaos with OpenSSL and LibreSSL, in things built against them, using a .pem generated from OS X?s Keychains. The biggest, most popular affected sites are the whole range of Google domains. Google cross-sign their GeoTrust root with an old Equifax root (Equifax Secure Certificate Authority) because a lot of the older clients don?t have the GeoTrust root on their system and would just error out. Have emailed with Adam Langley on the cert errors and essentially Google aren?t going to be able to stop that cross-signing any time soon. According to Adam most SSL clients should go through the cert chain of the domain and hit the GeoTrust cert and verify at that point, if the GeoTrust root exists in a .pem file OpenSSL can find and use, which does exist when generating a PEM from the system Keychains. It?s not supposed to carry on to the Equifax root, but it is, and this is causing breakage on OS X 10.10.3 onwards. This problem only exists in OpenSSL and LibreSSL as far as testing goes. It isn?t reproducible with Apple?s Security Framework, or GnuTLS. Interestingly, Apple have done something to their shipped OpenSSL 0.9.8x to fix the problem - If I build OpenSSL 0.9.8x from source and use it, failure, but if I use the one Apple installs the connection verifies and succeeds. Here?s hoping they?ve punted whatever those changes were upstream to you. This is the error you get: ================================================== ?2015-04-10 16:58:58? https://google.com/ Resolving google.com? 216.58.210.46, 2a00:1450:4009:800::200e Connecting to google.com|216.58.210.46|:443? connected. ERROR: cannot verify google.com?s certificate, issued by ?CN=Google Internet Authority G2,O=Google Inc,C=US?: Unable to locally verify the issuer?s authority. To connect to google.com insecurely, use `?no-check-certificate?. ================================================== How to reproduce: * Install OpenSSL on OS X 10.10.3 or above. I have it installed to /usr/local/opt/openssl - With the sysconfdir in /usr/local/etc. * Generate a PEM file from OS X?s Security Keychain: * security find-certificate -a -p /Library/Keychains/System.keychain >> sys.pem * security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain >> sysroot.pem * cat sys.pem >> sysroot.pem * mv sysroot.pem /usr/local/etc/openssl * Download and install cURL: * Pass ??with-ssl=/path/to/openssl/dir? and ?--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem? to configure. * Run ?/path/to/your/installed/curl -I https://google.com? It reproduces with wget, mutt, various other tools. If you put the Equifax certificate back, and then rehash, you can make the connection. But the Equifax cert is old, and weak, and Apple aren?t likely to return it to the Keychain. So this problem connecting to Google will persist until the reason for not stopping at and verifying on the GeoTrust root are narrowed down and hopefully fixed. Mozilla are also pressing ahead with removing that Equifax root from their certs, so it?s not a simple case of working around it by switching PEM. -- Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From dominyktiller at gmail.com Sat Apr 18 13:30:30 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Sat, 18 Apr 2015 14:30:30 +0100 Subject: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) In-Reply-To: <5532591E.6000600@gmail.com> References: <5532591E.6000600@gmail.com> Message-ID: <55325C76.9070104@gmail.com> Apologies. Either I'm an idiot or autocorrect is feeling amusing today. I meant https://gist.github.com/DomT4/f86618bdfe2f27c8d66a rather than https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. -------- Forwarded Message -------- Subject: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) Date: Sat, 18 Apr 2015 14:16:14 +0100 From: Dominyk Tiller To: openssl-dev at openssl.org Apologies that this is kinda badly written. Detailed bug reports aren't my forte. Feel free to ping back questions if detail isn't clear/useful/etc. OS X 10.10.3?s release changed some certs in the Keychain. There?s a full list of changes here: https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a This has caused some chaos with OpenSSL and LibreSSL, in things built against them, using a .pem generated from OS X?s Keychains. The biggest, most popular affected sites are the whole range of Google domains. Google cross-sign their GeoTrust root with an old Equifax root (Equifax Secure Certificate Authority) because a lot of the older clients don?t have the GeoTrust root on their system and would just error out. Have emailed with Adam Langley on the cert errors and essentially Google aren?t going to be able to stop that cross-signing any time soon. According to Adam most SSL clients should go through the cert chain of the domain and hit the GeoTrust cert and verify at that point, if the GeoTrust root exists in a .pem file OpenSSL can find and use, which does exist when generating a PEM from the system Keychains. It?s not supposed to carry on to the Equifax root, but it is, and this is causing breakage on OS X 10.10.3 onwards. This problem only exists in OpenSSL and LibreSSL as far as testing goes. It isn?t reproducible with Apple?s Security Framework, or GnuTLS. Interestingly, Apple have done something to their shipped OpenSSL 0.9.8x to fix the problem - If I build OpenSSL 0.9.8x from source and use it, failure, but if I use the one Apple installs the connection verifies and succeeds. Here?s hoping they?ve punted whatever those changes were upstream to you. This is the error you get: ================================================== ?2015-04-10 16:58:58? https://google.com/ Resolving google.com? 216.58.210.46, 2a00:1450:4009:800::200e Connecting to google.com|216.58.210.46|:443? connected. ERROR: cannot verify google.com?s certificate, issued by ?CN=Google Internet Authority G2,O=Google Inc,C=US?: Unable to locally verify the issuer?s authority. To connect to google.com insecurely, use `?no-check-certificate?. ================================================== How to reproduce: * Install OpenSSL on OS X 10.10.3 or above. I have it installed to /usr/local/opt/openssl - With the sysconfdir in /usr/local/etc. * Generate a PEM file from OS X?s Security Keychain: * security find-certificate -a -p /Library/Keychains/System.keychain >> sys.pem * security find-certificate -a -p /System/Library/Keychains/SystemRootCertificates.keychain >> sysroot.pem * cat sys.pem >> sysroot.pem * mv sysroot.pem /usr/local/etc/openssl * Download and install cURL: * Pass ??with-ssl=/path/to/openssl/dir? and ?--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem? to configure. * Run ?/path/to/your/installed/curl -I https://google.com? It reproduces with wget, mutt, various other tools. If you put the Equifax certificate back, and then rehash, you can make the connection. But the Equifax cert is old, and weak, and Apple aren?t likely to return it to the Keychain. So this problem connecting to Google will persist until the reason for not stopping at and verifying on the GeoTrust root are narrowed down and hopefully fixed. Mozilla are also pressing ahead with removing that Equifax root from their certs, so it?s not a simple case of working around it by switching PEM. -- Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: OpenPGP digital signature URL: From rt at openssl.org Sat Apr 18 14:02:47 2015 From: rt at openssl.org (Jeremy Huddleston Sequoia via RT) Date: Sat, 18 Apr 2015 16:02:47 +0200 Subject: [openssl-dev] [openssl.org #3811] [BUG REPORT] - Missing register name in aes-x86_64.s In-Reply-To: <2416E52E-9F03-488A-AC99-5B56B7BE03E0@macports.org> References: <2416E52E-9F03-488A-AC99-5B56B7BE03E0@macports.org> Message-ID: The suggested fix for #3759: [PATCH] crypto: use bigint in x86-64 perl addresses some issues but not all issues with the generation of the asm from the perl scripts. Using the provided patch, one still fails with: /usr/bin/perl asm/aes-x86_64.pl macosx > aes-x86_64.s /opt/local/bin/gcc-apple-4.2 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o aes-x86_64.o aes-x86_64.s aes-x86_64.s:1383:missing or invalid immediate expression `' taken as 0 aes-x86_64.s:1383:suffix or operands invalid for `mov' aes-x86_64.s:1544:missing or invalid immediate expression `' taken as 0 aes-x86_64.s:1544:suffix or operands invalid for `mov' L$cbc_do_ecopy: movq %r15,%rsi leaq 80(%rsp),%rdi leaq 80(%rsp),%r15 movl $,%ecx # Line 1383 .long 0x90A548F3 movl %eax,(%rdi) --- .p2align 2 L$cbc_fast_cleanup: cmpl $0,80+240(%rsp) leaq 80(%rsp),%rdi je L$cbc_exit movl $,%ecx # Line 1544 xorq %rax,%rax .long 0x90AB48F3 jmp L$cbc_exit From rt at openssl.org Sat Apr 18 16:05:49 2015 From: rt at openssl.org (Hanno Boeck via RT) Date: Sat, 18 Apr 2015 18:05:49 +0200 Subject: [openssl-dev] [openssl.org #3812] asn1parse -genconf may cause access to uninitialized variable In-Reply-To: <20150418160602.421c223c@pc1.fritz.box> References: <20150418160602.421c223c@pc1.fritz.box> Message-ID: When calling asn1parse -genconf with a nonexistent file this will cause an access to an uninitialized variable. Test: valgrind -q openssl asn1parse -genconf nonexistingfile The reason is this code in asn1pars.c: conferr: if (errline > 0) BIO_printf(bio, "Error on line %ld of config file '%s'\n", errline, genconf); else BIO_printf(bio, "Error loading config file '%s'\n", genconf); It assumes that if errline wasn't set it's zero. While on most systems it's true that uninitialized variables are zero, this is not something that should be relied upon. Pre-initializing the variable with zero fixes this. See patch (for current git code) and valgrind output attached. Please apply. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-fix-asn1parse-uninitialized-variable.diff Type: text/x-patch Size: 353 bytes Desc: not available URL: -------------- next part -------------- WARNING: can't open config file: /usr/local/ssl/openssl.cnf ==30382== Conditional jump or move depends on uninitialised value(s) ==30382== at 0x4073C5: do_generate (asn1pars.c:439) ==30382== by 0x4073C5: asn1parse_main (asn1pars.c:273) ==30382== by 0x405320: do_cmd (openssl.c:470) ==30382== by 0x404FEA: main (openssl.c:366) ==30382== ==30382== Conditional jump or move depends on uninitialised value(s) ==30382== at 0x528598: fmtint (b_print.c:479) ==30382== by 0x52A157: _dopr (b_print.c:374) ==30382== by 0x52A157: BIO_vprintf (b_print.c:774) ==30382== by 0x52AE63: BIO_printf (b_print.c:754) ==30382== by 0x4073DC: do_generate (asn1pars.c:440) ==30382== by 0x4073DC: asn1parse_main (asn1pars.c:273) ==30382== by 0x405320: do_cmd (openssl.c:470) ==30382== by 0x404FEA: main (openssl.c:366) ==30382== ==30382== Use of uninitialised value of size 8 ==30382== at 0x52860C: fmtint (b_print.c:496) ==30382== by 0x52A157: _dopr (b_print.c:374) ==30382== by 0x52A157: BIO_vprintf (b_print.c:774) ==30382== by 0x52AE63: BIO_printf (b_print.c:754) ==30382== by 0x4073DC: do_generate (asn1pars.c:440) ==30382== by 0x4073DC: asn1parse_main (asn1pars.c:273) ==30382== by 0x405320: do_cmd (openssl.c:470) ==30382== by 0x404FEA: main (openssl.c:366) ==30382== ==30382== Conditional jump or move depends on uninitialised value(s) ==30382== at 0x528622: fmtint (b_print.c:499) ==30382== by 0x52A157: _dopr (b_print.c:374) ==30382== by 0x52A157: BIO_vprintf (b_print.c:774) ==30382== by 0x52AE63: BIO_printf (b_print.c:754) ==30382== by 0x4073DC: do_generate (asn1pars.c:440) ==30382== by 0x4073DC: asn1parse_main (asn1pars.c:273) ==30382== by 0x405320: do_cmd (openssl.c:470) ==30382== by 0x404FEA: main (openssl.c:366) ==30382== Error on line 69349704 of config file 'nonexistentfile' 67417424:error:02001002:system library:fopen:No such file or directory:bss_file.c:168:fopen('nonexistentfile','rb') 67417424:error:2006D080:BIO routines:BIO_new_file:no such file:bss_file.c:171: 67417424:error:0E078072:configuration file routines:DEF_LOAD:no such file:conf_def.c:195: From rich at kde.org Sun Apr 19 20:57:47 2015 From: rich at kde.org (Richard Moore) Date: Sun, 19 Apr 2015 21:57:47 +0100 Subject: [openssl-dev] Missing API features Message-ID: Hi All, Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a string to obtain this information seems daft. We're missing API for: key exchange, authentication method, encryption algorithm, MAC and the export flag. It's also worth noting that SSL_CIPHER_get_version and SSL_CIPHER_description should probably be returning const char * not char *. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Mon Apr 20 10:16:19 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 20 Apr 2015 13:16:19 +0300 Subject: [openssl-dev] Error building openssl on SUSE Message-ID: Hello openssl-dev, I got a problem building openssl 1.0.2a on SUSE. Platform: >uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler: > gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl= http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) Error message: gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D OPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_AS M -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s ghash-x86_64.s: Assembler messages: ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1' ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0' ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3' ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1' ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0' ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3' ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0' Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 20 14:33:55 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 14:33:55 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: Message-ID: >Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only >SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a string to obtain this information seems daft. We're >missing API for: key exchange, authentication method, encryption algorithm, MAC and the export flag. (Man, outlook makes it hard to NOT top-post. Sigh.) Since all of those are implied by the cipher spec, could we just have an API to return the two-byte cipher identifier? (That would break if TLS 1.3 moves to "a la carte" selection, but I doubt that will happen.) Export is gone :) And what's the MAC if using an AEAD cipher like AES-GCM? > It's also worth noting that SSL_CIPHER_get_version and SSL_CIPHER_description should probably be returning const char * not char *. Yes, is that a bug to backport or just fix in master, you think? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From waywardgeek at google.com Mon Apr 20 15:36:36 2015 From: waywardgeek at google.com (Bill Cox) Date: Mon, 20 Apr 2015 08:36:36 -0700 Subject: [openssl-dev] Enhance Extended Master Secret to conform to new MUST requirements in spec Message-ID: Hi. I'm looking into extended master secret (EMS) support in OpenSSL. It works on my machine correctly, except for session resumption. From the latest EMS spec: "If a server receives a ClientHello for an abbreviated handshake offering to resume a previous session, it behaves as follows. o If the original session did not use an extended master secret but the new ClientHello does contain the "extended_master_secret" extension, the server MUST NOT perform the abbreviated handshake. Instead, it SHOULD continue with a full handshake to negotiate a new session." The threat here is that in a Triple Handshake attack, the attacker A down-grades both initial connections to client C and server S to not support EMS. In the second step, the session resumption step, he re-enables EMS on both connections, causing the handshake logs to agree, which allows the third connection (the renegotiation step) to complete with EMS enabled for any client accepting a server cert change. At this point C accepts the connection to A as actually a connection to S, thwarting TLS authentication. Emilia suggested that I develop a patch for this by forking master on github and submitting a pull request. If I understand correctly, you guys prefer an email like this before starting work on patches. Is that right? There is also a bit of related behavior that I would also like to fix. As described in the spec: "If a client receives a ServerHello that accepts an abbreviated handshake, it behaves as follows. o If the original session did not use an extended master secret but the new ServerHello does contain the "extended_master_secret" extension, the client MUST abort the handshake." In this case, the client has detected a bug in the server's EMS implementation, and if the client continues, it is subject to the full TH downgrade attack as above. Thanks, Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Apr 20 15:39:07 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 20 Apr 2015 15:39:07 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: Message-ID: <20150420153907.GF25758@mournblade.imrryr.org> On Mon, Apr 20, 2015 at 02:33:55PM +0000, Salz, Rich wrote: > > It's also worth noting that SSL_CIPHER_get_version and SSL_CIPHER_description should probably be returning const char * not char *. > > Yes, is that a bug to backport or just fix in master, you think? Constification often requires source changes in applications, so I think backporting is out. -- Viktor. From rt at openssl.org Mon Apr 20 17:00:52 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 20 Apr 2015 19:00:52 +0200 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: References: Message-ID: Hello openssl-dev, I got a problem building openssl 1.0.2a on SUSE. Platform: >uname -a Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 x86_64 x86_64 x86_64 GNU/Linux Compiler: > gcc -v Using built-in specs. Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl= http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.3 --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) Error message: gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D OPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_AS M -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s ghash-x86_64.s: Assembler messages: ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1' ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0' ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3' ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq $17,%xmm2,%xmm0,%xmm1' ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq $0,%xmm2,%xmm0,%xmm0' ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm3,%xmm3' ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq $0,%xmm6,%xmm14,%xmm0' Thank you! -- SY, Dmitry Belyavsky -- SY, Dmitry Belyavsky From rt at openssl.org Mon Apr 20 17:01:03 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Mon, 20 Apr 2015 19:01:03 +0200 Subject: [openssl-dev] [openssl.org #3814] make dclean breaks build and tests In-Reply-To: References: Message-ID: It appears `make dclean` still whacks a bunch of test files in Master. It looks like at east 39 files are deleted: $ git status | grep delete | wc -l 39 ***** If the test/ directory is deleted, then that means its not possible to test the library after a build. You might as well delete all the source files and package what remains :) It would probably be a better strategy to have `make dcean` put the sources in a pristine state without deleting the test/ directory. This way, those building the library can do so without extraneous cruft from the development process. And they can test the library after building. ***** $ make clean && make dclean ... $ git status On branch master Your branch is up-to-date with 'origin/master'. Changes not staged for commit: (use "git add/rm ..." to update what will be committed) (use "git checkout -- ..." to discard changes in working directory) modified: apps/Makefile modified: crypto/Makefile modified: crypto/aes/Makefile modified: crypto/asn1/Makefile modified: crypto/bf/Makefile modified: crypto/bio/Makefile modified: crypto/bn/Makefile modified: crypto/buffer/Makefile modified: crypto/camellia/Makefile modified: crypto/cast/Makefile modified: crypto/cmac/Makefile modified: crypto/cms/Makefile modified: crypto/comp/Makefile modified: crypto/conf/Makefile modified: crypto/des/Makefile modified: crypto/dh/Makefile modified: crypto/dsa/Makefile modified: crypto/dso/Makefile modified: crypto/ec/Makefile modified: crypto/ecdh/Makefile modified: crypto/ecdsa/Makefile modified: crypto/engine/Makefile modified: crypto/err/Makefile modified: crypto/evp/Makefile modified: crypto/hmac/Makefile modified: crypto/idea/Makefile modified: crypto/krb5/Makefile modified: crypto/lhash/Makefile modified: crypto/md4/Makefile modified: crypto/md5/Makefile modified: crypto/mdc2/Makefile modified: crypto/modes/Makefile modified: crypto/objects/Makefile modified: crypto/ocsp/Makefile modified: crypto/pem/Makefile modified: crypto/pkcs12/Makefile modified: crypto/pkcs7/Makefile modified: crypto/pqueue/Makefile modified: crypto/rand/Makefile modified: crypto/rc2/Makefile modified: crypto/rc4/Makefile modified: crypto/ripemd/Makefile modified: crypto/rsa/Makefile modified: crypto/seed/Makefile modified: crypto/sha/Makefile modified: crypto/srp/Makefile modified: crypto/stack/Makefile modified: crypto/ts/Makefile modified: crypto/txt_db/Makefile modified: crypto/ui/Makefile modified: crypto/whrlpool/Makefile modified: crypto/x509/Makefile modified: crypto/x509v3/Makefile modified: engines/Makefile modified: engines/ccgost/Makefile modified: ssl/Makefile modified: test/Makefile deleted: test/bftest.c deleted: test/bntest.c deleted: test/casttest.c deleted: test/constant_time_test.c deleted: test/destest.c deleted: test/dhtest.c deleted: test/dsatest.c deleted: test/ecdhtest.c deleted: test/ecdsatest.c deleted: test/ectest.c deleted: test/enginetest.c deleted: test/evp_extra_test.c deleted: test/evp_test.c deleted: test/evptests.txt deleted: test/exptest.c deleted: test/gost2814789test.c deleted: test/heartbeat_test.c deleted: test/hmactest.c deleted: test/ideatest.c deleted: test/igetest.c deleted: test/jpaketest.c deleted: test/md2test.c deleted: test/md4test.c deleted: test/md5test.c deleted: test/mdc2test.c deleted: test/p5_crpt2_test.c deleted: test/randtest.c deleted: test/rc2test.c deleted: test/rc4test.c deleted: test/rc5test.c deleted: test/rmdtest.c deleted: test/rsa_test.c deleted: test/sha1test.c deleted: test/sha256t.c deleted: test/sha512t.c deleted: test/ssltest.c deleted: test/testutil.c deleted: test/v3nametest.c deleted: test/wp_test.c From richmoore44 at gmail.com Mon Apr 20 20:21:43 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 20 Apr 2015 21:21:43 +0100 Subject: [openssl-dev] Missing API features In-Reply-To: References: Message-ID: On 20 April 2015 at 15:33, Salz, Rich wrote: > >Continuing with the problems of making structs opaque, currently the API > for querying the information about ciphers is quite weak. Only > >SSL_CIPHER_description provides access to data such as the key exchange > method, and parsing a string to obtain this information seems daft. We're > >missing API for: key exchange, authentication method, encryption > algorithm, MAC and the export flag. > > (Man, outlook makes it hard to NOT top-post. Sigh.) > > Since all of those are implied by the cipher spec, could we just have an > API to return the two-byte cipher identifier? (That would break if TLS 1.3 > moves to "a la carte" selection, but I doubt that will happen.) Export is > gone :) And what's the MAC if using an AEAD cipher like AES-GCM? > > Just returning the cipher id would mean every app needs to replicate the table that openssl already has, and keep it updated. Doesn't seem like a good plan to me. According to the current code in openssl the 'MAC' when using AES-GCM is AEAD - not ideal perhaps, but what we've got. > > It's also worth noting that SSL_CIPHER_get_version and > SSL_CIPHER_description should probably be returning const char * not char *. > > Yes, is that a bug to backport or just fix in master, you think? > Changing the return type here should be binary compatible on any sane platform, but it might cause source incompatibilities. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Apr 20 20:25:08 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 20:25:08 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: Message-ID: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> What is the information you're looking for? "kx=X25519" or kx="2KRSA" or ... ? I picked those because sometimes there's a keysize, and other times it's implicit, for example. The internal table is going to need restructuring. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Richard Moore [mailto:richmoore44 at gmail.com] Sent: Monday, April 20, 2015 4:22 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Missing API features On 20 April 2015 at 15:33, Salz, Rich > wrote: >Continuing with the problems of making structs opaque, currently the API for querying the information about ciphers is quite weak. Only >SSL_CIPHER_description provides access to data such as the key exchange method, and parsing a string to obtain this information seems daft. We're >missing API for: key exchange, authentication method, encryption algorithm, MAC and the export flag. (Man, outlook makes it hard to NOT top-post. Sigh.) Since all of those are implied by the cipher spec, could we just have an API to return the two-byte cipher identifier? (That would break if TLS 1.3 moves to "a la carte" selection, but I doubt that will happen.) Export is gone :) And what's the MAC if using an AEAD cipher like AES-GCM? Just returning the cipher id would mean every app needs to replicate the table that openssl already has, and keep it updated. Doesn't seem like a good plan to me. According to the current code in openssl the 'MAC' when using AES-GCM is AEAD - not ideal perhaps, but what we've got. > It's also worth noting that SSL_CIPHER_get_version and SSL_CIPHER_description should probably be returning const char * not char *. Yes, is that a bug to backport or just fix in master, you think? Changing the return type here should be binary compatible on any sane platform, but it might cause source incompatibilities. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From richmoore44 at gmail.com Mon Apr 20 20:34:20 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Mon, 20 Apr 2015 21:34:20 +0100 Subject: [openssl-dev] Missing API features In-Reply-To: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: On 20 April 2015 at 21:25, Salz, Rich wrote: > What is the information you're looking for? "kx=X25519" or kx="2KRSA" > or ... ? I picked those because sometimes there's a keysize, and other > times it's implicit, for example. The internal table is going to need > restructuring. > In the case of Qt both of those would work - the API we provide looks like this: http://doc.qt.io/qt-5/qsslcipher.html The basic idea is to provide the information to people using the API so that they can use it when describing the cipher to users. To be honest, I'm not sure how much of this users will actually understand in practice, but that's a different problem. Cheers Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Apr 20 22:17:36 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Apr 2015 23:17:36 +0100 Subject: [openssl-dev] Missing API features In-Reply-To: References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <55357B00.9020601@openssl.org> On 20/04/15 21:34, Richard Moore wrote: > > > On 20 April 2015 at 21:25, Salz, Rich > wrote: > > What is the information you?re looking for? ?kx=X25519? or > kx=?2KRSA? or ? ? I picked those because sometimes there?s a > keysize, and other times it?s implicit, for example. The internal > table is going to need restructuring. > > > In the case of Qt both of those would work - the API we provide looks > like this: http://doc.qt.io/qt-5/qsslcipher.html > The basic idea is to provide the information to people using the API so > that they can use it when describing the cipher to users. To be honest, > I'm not sure how much of this users will actually understand in > practice, but that's a different problem. Could we get this added to the wiki so we don't forget about it? Matt From matt at openssl.org Mon Apr 20 22:52:23 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 20 Apr 2015 23:52:23 +0100 Subject: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) In-Reply-To: <55325C76.9070104@gmail.com> References: <5532591E.6000600@gmail.com> <55325C76.9070104@gmail.com> Message-ID: <55358327.1080809@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 18/04/15 14:30, Dominyk Tiller wrote: > Apologies. Either I'm an idiot or autocorrect is feeling amusing > today. I meant https://gist.github.com/DomT4/f86618bdfe2f27c8d66a > rather than https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. > > Sent from OS X. If you wish to communicate more securely my PGP > Public Key is 0x872524db9d74326c. > > > -------- Forwarded Message -------- Subject: OpenSSL fails to > connect to Google on OS X 10.10.3 (Bug Report) Date: Sat, 18 Apr > 2015 14:16:14 +0100 From: Dominyk Tiller > To: openssl-dev at openssl.org > > Apologies that this is kinda badly written. Detailed bug reports > aren't my forte. Feel free to ping back questions if detail isn't > clear/useful/etc. > > OS X 10.10.3?s release changed some certs in the Keychain. There?s > a full list of changes here: > https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a > > This has caused some chaos with OpenSSL and LibreSSL, in things > built against them, using a .pem generated from OS X?s Keychains. > The biggest, most popular affected sites are the whole range of > Google domains. > > Google cross-sign their GeoTrust root with an old Equifax root > (Equifax Secure Certificate Authority) because a lot of the older > clients don?t have the GeoTrust root on their system and would just > error out. Have emailed with Adam Langley on the cert errors and > essentially Google aren?t going to be able to stop that > cross-signing any time soon. > > According to Adam most SSL clients should go through the cert chain > of the domain and hit the GeoTrust cert and verify at that point, > if the GeoTrust root exists in a .pem file OpenSSL can find and > use, which does exist when generating a PEM from the system > Keychains. It?s not supposed to carry on to the Equifax root, but > it is, and this is causing breakage on OS X 10.10.3 onwards. Hi Dominyk This is a known issue. It has been fixed in git master for a while. Technically speaking this is not a bug at all. OpenSSL's verification algorithm is working exactly as designed. For that reason a decision was taken not to backport this to existing releases (which only receives bug fixes). However, due to the real problems that this is causing for users, we have changed our mind on this and we have now backported this to 1.0.2. It's in git now and will become available as part of 1.0.2b. Discussions are ongoing with regards to 1.0.1. Regards Matt > > This problem only exists in OpenSSL and LibreSSL as far as testing > goes. It isn?t reproducible with Apple?s Security Framework, or > GnuTLS. > > Interestingly, Apple have done something to their shipped OpenSSL > 0.9.8x to fix the problem - If I build OpenSSL 0.9.8x from source > and use it, failure, but if I use the one Apple installs the > connection verifies and succeeds. Here?s hoping they?ve punted > whatever those changes were upstream to you. > > This is the error you get: > > ================================================== ?2015-04-10 > 16:58:58? https://google.com/ Resolving google.com? 216.58.210.46, > 2a00:1450:4009:800::200e Connecting to > google.com|216.58.210.46|:443? connected. ERROR: cannot verify > google.com?s certificate, issued by ?CN=Google Internet Authority > G2,O=Google Inc,C=US?: Unable to locally verify the issuer?s > authority. To connect to google.com insecurely, use > `?no-check-certificate?. > ================================================== > > How to reproduce: > > * Install OpenSSL on OS X 10.10.3 or above. I have it installed to > /usr/local/opt/openssl - With the sysconfdir in /usr/local/etc. > > * Generate a PEM file from OS X?s Security Keychain: * security > find-certificate -a -p /Library/Keychains/System.keychain >> > sys.pem * security find-certificate -a -p > /System/Library/Keychains/SystemRootCertificates.keychain >> > sysroot.pem * cat sys.pem >> sysroot.pem * mv sysroot.pem > /usr/local/etc/openssl > > * Download and install cURL: * Pass > ??with-ssl=/path/to/openssl/dir? and > ?--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem? to > configure. > > * Run ?/path/to/your/installed/curl -I https://google.com? > > It reproduces with wget, mutt, various other tools. If you put the > Equifax certificate back, and then rehash, you can make the > connection. But the Equifax cert is old, and weak, and Apple aren?t > likely to return it to the Keychain. So this problem connecting to > Google will persist until the reason for not stopping at and > verifying on the GeoTrust root are narrowed down and hopefully > fixed. > > Mozilla are also pressing ahead with removing that Equifax root > from their certs, so it?s not a simple case of working around it by > switching PEM. > > > > _______________________________________________ openssl-dev mailing > list To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVNYMnAAoJENnE0m0OYESRLkQIAIKPnmVymZbwEd+iWszlrLrc Vcjx6Yy8R/xoFsgo8yuFEXwpFdWBcowiHYdKXgDqx5Du9f5io2VlqE/ghKqCVpe5 yHrlL29bU16G6RlpSoBqKZB+mL+8IbTzoYMUYE14pIBPuhwhbpR+aORAdeO/qxuI IZ0Py9PQYEATboEMA0WtFmumw6AWFpAMPnr+lUhhTKF5yXyb98vk82KyTd2Hv9MY 3KS/k3x6hblXSLlOlyNNEyCuLBzqXGqfANxbuoXf+RQufFSaD8Mbmo2ZDmMJHuT9 kkSxcYTUd0InE9R02StyV8OdZpijvyxisAZgDumGJJXzsp56lBjijW4Z20ju4gA= =zvru -----END PGP SIGNATURE----- From rt at openssl.org Tue Apr 21 07:00:30 2015 From: rt at openssl.org (Palak Agarwal via RT) Date: Tue, 21 Apr 2015 09:00:30 +0200 Subject: [openssl-dev] [openssl.org #3815] Issue with X509_NAME_hash in 0.9.8zb In-Reply-To: <1084634388.1090583.1429589210899.JavaMail.yahoo@mail.yahoo.com> References: <1084634388.1090583.1429589210899.JavaMail.yahoo@mail.yahoo.com> Message-ID: Hi, The return value of X509_NAME_hash() has changed from 0.9.8zb onwards. I have written a sample program to verify the value return of X509_NAME_hash(). I linked the same program with four different version of crypto library. The output is as below: ===================================================================== (Linux)(snapper53-64)progs{85} ./X509_NAME_hash_test.t 9C361DAC (Linux)(snapper53-64)progs{86} ./X509_NAME_hash_test.y 9C361DAC (Linux)(snapper53-64)progs{87} ./X509_NAME_hash_test.zb 01B7949D (Linux)(snapper53-64)progs{88} ./X509_NAME_hash_test.zc 01B7949D ===================================================================== The extension in the binary name is the version of the openSSL. Below is the sample program: ? 1 #include ? 2 #include ? 3 #include ? 4 #include "openssl/asn1.h" ? 5 #include "openssl/objects.h" ? 6 #include "openssl/x509.h" ? 7 #include "openssl/x509v3.h" ? 8 ? 9 int add_entry_to_X509_NAME( X509_NAME* name, ?10???????????????????????????? const char* id, ?11???????????????????????????? const char* value) ?12 { ?13???????? int ret = X509_NAME_add_entry_by_txt( name, ?14??????????????????????????????????????????? id, /*(char *) id,*/ ?15??????????????????????????????????????????? MBSTRING_UTF8, ?16??????????????????????????????????????????? (const unsigned char*)value, ?17??????????????????????????????????????????? -1, /*strlen(value),*/ ?18??????????????????????????????????????????? -1, ?19??????????????????????????????????????????? 0 ); ?20 ?21???????? if (ret != 1) ?22???????? { ?23???????????? printf("Unable to add %s - %s to X509Name (ret = %d)\n", id, value, ret) ; ?24???????????? return -1; ?25???????? } ?26 ?27???????? return 0 ; ?28 } ?29 ?30 ?31 int main () ?32 { ?33???????? unsigned long file_hash ; ?34???????? X509_NAME *name; ?35???????? int i; ?36 ?37???????? name = X509_NAME_new(); ?38???????? if (!name) ?39???????????? printf("Unable to alloc mem for X509_Name") ; ?40 ?41???????? add_entry_to_X509_NAME(name, "commonName", "test_agent"); ?42???????? add_entry_to_X509_NAME(name, "organizationalUnitName", "test_domain at example.com"); ?43???????? add_entry_to_X509_NAME(name, "organizationName", "ex");?44 ?45???????? file_hash = X509_NAME_hash ((X509_NAME *) name) ; ?46 ?47???????? printf ("%08X \n", (unsigned int) file_hash); ?48 ?49???????? return 0; ?50 } Could you please confirm if this is an openssl bug? Thanks & Regards,Palak From rt at openssl.org Tue Apr 21 07:00:50 2015 From: rt at openssl.org (Hanno Boeck via RT) Date: Tue, 21 Apr 2015 09:00:50 +0200 Subject: [openssl-dev] [openssl.org #3816] Call of memcmp with null pointers in obj_cmp() In-Reply-To: <20150419181719.38c214d9@pc1.fritz.box> References: <20150419181719.38c214d9@pc1.fritz.box> Message-ID: The function obj_cmp() (file crypto/objects/obj_dat.c) can in some situations call memcmp() with a null pointer and a zero length. This is invalid behaviour. When compiling openssl with undefined behaviour sanitizer (add -fsanitize=undefined to compile flags) this can be seen. One example that triggers this behaviour is the pkcs7 command (but there are others, e.g. I've seen it with the timestamp function): apps/openssl pkcs7 -in test/testp7.pem What happens is that obj_cmp takes objects of the type ASN1_OBJECT and passes their ->data pointer to memcmp. Zero-sized ASN1_OBJECT structures can have a null pointer as data. Attached patch will check for zero-sized objects and won't call memcmp on them. -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-fix-obj_cmp-memcmp-nullptr.diff Type: text/x-patch Size: 417 bytes Desc: not available URL: From steve at openssl.org Tue Apr 21 11:50:59 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 21 Apr 2015 11:50:59 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150421115058.GA20127@openssl.org> On Mon, Apr 20, 2015, Richard Moore wrote: > On 20 April 2015 at 21:25, Salz, Rich wrote: > > > What is the information you're looking for? "kx=X25519" or kx="2KRSA" > > or ... ? I picked those because sometimes there's a keysize, and other > > times it's implicit, for example. The internal table is going to need > > restructuring. > > > > In the case of Qt both of those would work - the API we provide looks like > this: http://doc.qt.io/qt-5/qsslcipher.html > The basic idea is to provide the information to people using the API so > that they can use it when describing the cipher to users. To be honest, I'm > not sure how much of this users will actually understand in practice, but > that's a different problem. > I think what would be useful here would be an API that can determine appropriate characterictics of an SSL_CIPHER. For example a NID corresponding to the key exchange algorithm, signer, cipher and MAC. We have to find this stuff out internally but there is no exposed API to do this. Enough for an application to write its own version of SSL_CIPHER_description for example. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From richmoore44 at gmail.com Tue Apr 21 12:02:29 2015 From: richmoore44 at gmail.com (Richard Moore) Date: Tue, 21 Apr 2015 13:02:29 +0100 Subject: [openssl-dev] Missing API features In-Reply-To: <20150421115058.GA20127@openssl.org> References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> <20150421115058.GA20127@openssl.org> Message-ID: On 21 April 2015 at 12:50, Dr. Stephen Henson wrote: > I think what would be useful here would be an API that can determine > appropriate characterictics of an SSL_CIPHER. For example a NID > corresponding to the key exchange algorithm, signer, cipher and MAC. We > have > to find this stuff out internally but there is no exposed API to do this. > > Enough for an application to write its own version of > SSL_CIPHER_description > for example. > Yes, that would be ideal. Rich. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dominyktiller at gmail.com Tue Apr 21 14:43:58 2015 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Tue, 21 Apr 2015 15:43:58 +0100 Subject: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) In-Reply-To: <55358327.1080809@openssl.org> References: <5532591E.6000600@gmail.com> <55325C76.9070104@gmail.com> <55358327.1080809@openssl.org> Message-ID: <5536622E.5050001@gmail.com> Hi Matt, Thanks for the reply on this, and for backporting the fix to 1.0.2! Having it available to 1.0.1 would be great too, but appreciate the OpenSSL team isn't huge. Is there any timetable on the 1.0.2b release? It seems pulling the following three commits into the 1.0.2a branch and patching: 47daa155a31b0a54ce09ad2ed4d55fad74096dab dfd3322d72a2d49f597b86dab6f37a8cf0f26dbf 6281abc79623419eae6a64768c478272d5d3a426 Does the job. Verification against Google domains with an OS X 10.10.3+ Keychain-generated PEM works great. Usually pretty reluctant to cherry-pick patches on security tools but given the trouble this is causing, am I safe to do so in this situation? Thanks, Dominyk Sent from OS X. If you wish to communicate more securely my PGP Public Key is 0x872524db9d74326c. On 20/04/2015 23:52, Matt Caswell wrote: > > > On 18/04/15 14:30, Dominyk Tiller wrote: >> Apologies. Either I'm an idiot or autocorrect is feeling amusing >> today. I meant https://gist.github.com/DomT4/f86618bdfe2f27c8d66a >> rather than https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. > >> Sent from OS X. If you wish to communicate more securely my PGP >> Public Key is 0x872524db9d74326c. > > >> -------- Forwarded Message -------- Subject: OpenSSL fails to >> connect to Google on OS X 10.10.3 (Bug Report) Date: Sat, 18 Apr >> 2015 14:16:14 +0100 From: Dominyk Tiller >> To: openssl-dev at openssl.org > >> Apologies that this is kinda badly written. Detailed bug reports >> aren't my forte. Feel free to ping back questions if detail isn't >> clear/useful/etc. > >> OS X 10.10.3?s release changed some certs in the Keychain. There?s >> a full list of changes here: >> https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a > >> This has caused some chaos with OpenSSL and LibreSSL, in things >> built against them, using a .pem generated from OS X?s Keychains. >> The biggest, most popular affected sites are the whole range of >> Google domains. > >> Google cross-sign their GeoTrust root with an old Equifax root >> (Equifax Secure Certificate Authority) because a lot of the older >> clients don?t have the GeoTrust root on their system and would just >> error out. Have emailed with Adam Langley on the cert errors and >> essentially Google aren?t going to be able to stop that >> cross-signing any time soon. > >> According to Adam most SSL clients should go through the cert chain >> of the domain and hit the GeoTrust cert and verify at that point, >> if the GeoTrust root exists in a .pem file OpenSSL can find and >> use, which does exist when generating a PEM from the system >> Keychains. It?s not supposed to carry on to the Equifax root, but >> it is, and this is causing breakage on OS X 10.10.3 onwards. > > Hi Dominyk > > This is a known issue. It has been fixed in git master for a while. > Technically speaking this is not a bug at all. OpenSSL's verification > algorithm is working exactly as designed. For that reason a decision > was taken not to backport this to existing releases (which only > receives bug fixes). However, due to the real problems that this is > causing for users, we have changed our mind on this and we have now > backported this to 1.0.2. It's in git now and will become available as > part of 1.0.2b. Discussions are ongoing with regards to 1.0.1. > > Regards > > Matt > > > > >> This problem only exists in OpenSSL and LibreSSL as far as testing >> goes. It isn?t reproducible with Apple?s Security Framework, or >> GnuTLS. > >> Interestingly, Apple have done something to their shipped OpenSSL >> 0.9.8x to fix the problem - If I build OpenSSL 0.9.8x from source >> and use it, failure, but if I use the one Apple installs the >> connection verifies and succeeds. Here?s hoping they?ve punted >> whatever those changes were upstream to you. > >> This is the error you get: > >> ================================================== ?2015-04-10 >> 16:58:58? https://google.com/ Resolving google.com? 216.58.210.46, >> 2a00:1450:4009:800::200e Connecting to >> google.com|216.58.210.46|:443? connected. ERROR: cannot verify >> google.com?s certificate, issued by ?CN=Google Internet Authority >> G2,O=Google Inc,C=US?: Unable to locally verify the issuer?s >> authority. To connect to google.com insecurely, use >> `?no-check-certificate?. >> ================================================== > >> How to reproduce: > >> * Install OpenSSL on OS X 10.10.3 or above. I have it installed to >> /usr/local/opt/openssl - With the sysconfdir in /usr/local/etc. > >> * Generate a PEM file from OS X?s Security Keychain: * security >> find-certificate -a -p /Library/Keychains/System.keychain >> >> sys.pem * security find-certificate -a -p >> /System/Library/Keychains/SystemRootCertificates.keychain >> >> sysroot.pem * cat sys.pem >> sysroot.pem * mv sysroot.pem >> /usr/local/etc/openssl > >> * Download and install cURL: * Pass >> ??with-ssl=/path/to/openssl/dir? and >> ?--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem? to >> configure. > >> * Run ?/path/to/your/installed/curl -I https://google.com? > >> It reproduces with wget, mutt, various other tools. If you put the >> Equifax certificate back, and then rehash, you can make the >> connection. But the Equifax cert is old, and weak, and Apple aren?t >> likely to return it to the Keychain. So this problem connecting to >> Google will persist until the reason for not stopping at and >> verifying on the GeoTrust root are narrowed down and hopefully >> fixed. > >> Mozilla are also pressing ahead with removing that Equifax root >> from their certs, so it?s not a simple case of working around it by >> switching PEM. > > > >> _______________________________________________ openssl-dev mailing >> list To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-dev > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/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 rsalz at akamai.com Mon Apr 20 20:38:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 20 Apr 2015 20:38:06 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > To be honest, I'm not sure how much of this users will actually understand in practice, but that's a different problem. Agree, which is why the current method may just be good enough... From matt at openssl.org Tue Apr 21 15:24:08 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 21 Apr 2015 16:24:08 +0100 Subject: [openssl-dev] Fwd: OpenSSL fails to connect to Google on OS X 10.10.3 (Bug Report) In-Reply-To: <5536622E.5050001@gmail.com> References: <5532591E.6000600@gmail.com> <55325C76.9070104@gmail.com> <55358327.1080809@openssl.org> <5536622E.5050001@gmail.com> Message-ID: <55366B98.2010804@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 21/04/15 15:43, Dominyk Tiller wrote: > Hi Matt, > > Thanks for the reply on this, and for backporting the fix to > 1.0.2! Having it available to 1.0.1 would be great too, but > appreciate the OpenSSL team isn't huge. > > Is there any timetable on the 1.0.2b release? It seems pulling the > following three commits into the 1.0.2a branch and patching: No, unfortunately not. The releases are normally driven by what security issues come along which we can't predict. > > 47daa155a31b0a54ce09ad2ed4d55fad74096dab You don't need this one. I'm about to revert it. > dfd3322d72a2d49f597b86dab6f37a8cf0f26dbf You only need this one if you want to be able to control whether the new verify algorithm is used or not via the newly defined X509_V_FLAG_NO_ALT_CHAINS flag. By default it will be used. > 6281abc79623419eae6a64768c478272d5d3a426 This is the important one. > > Does the job. Verification against Google domains with an OS X > 10.10.3+ Keychain-generated PEM works great. Usually pretty > reluctant to cherry-pick patches on security tools but given the > trouble this is causing, am I safe to do so in this situation? I can't foresee any problems with doing that. Obviously though we only support official releases. Matt > > Thanks, > > Dominyk > > Sent from OS X. If you wish to communicate more securely my PGP > Public Key is 0x872524db9d74326c. > > On 20/04/2015 23:52, Matt Caswell wrote: >> >> >> On 18/04/15 14:30, Dominyk Tiller wrote: >>> Apologies. Either I'm an idiot or autocorrect is feeling >>> amusing today. I meant >>> https://gist.github.com/DomT4/f86618bdfe2f27c8d66a rather than >>> https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a. >> >>> Sent from OS X. If you wish to communicate more securely my >>> PGP Public Key is 0x872524db9d74326c. >> >> >>> -------- Forwarded Message -------- Subject: OpenSSL fails to >>> connect to Google on OS X 10.10.3 (Bug Report) Date: Sat, 18 >>> Apr 2015 14:16:14 +0100 From: Dominyk Tiller >>> To: openssl-dev at openssl.org >> >>> Apologies that this is kinda badly written. Detailed bug >>> reports aren't my forte. Feel free to ping back questions if >>> detail isn't clear/useful/etc. >> >>> OS X 10.10.3?s release changed some certs in the Keychain. >>> There?s a full list of changes here: >>> https://gist.github.cok/DomT4/f86618bdfe2f27c8d66a >> >>> This has caused some chaos with OpenSSL and LibreSSL, in >>> things built against them, using a .pem generated from OS X?s >>> Keychains. The biggest, most popular affected sites are the >>> whole range of Google domains. >> >>> Google cross-sign their GeoTrust root with an old Equifax root >>> (Equifax Secure Certificate Authority) because a lot of the >>> older clients don?t have the GeoTrust root on their system and >>> would just error out. Have emailed with Adam Langley on the >>> cert errors and essentially Google aren?t going to be able to >>> stop that cross-signing any time soon. >> >>> According to Adam most SSL clients should go through the cert >>> chain of the domain and hit the GeoTrust cert and verify at >>> that point, if the GeoTrust root exists in a .pem file OpenSSL >>> can find and use, which does exist when generating a PEM from >>> the system Keychains. It?s not supposed to carry on to the >>> Equifax root, but it is, and this is causing breakage on OS X >>> 10.10.3 onwards. >> >> Hi Dominyk >> >> This is a known issue. It has been fixed in git master for a >> while. Technically speaking this is not a bug at all. OpenSSL's >> verification algorithm is working exactly as designed. For that >> reason a decision was taken not to backport this to existing >> releases (which only receives bug fixes). However, due to the >> real problems that this is causing for users, we have changed our >> mind on this and we have now backported this to 1.0.2. It's in >> git now and will become available as part of 1.0.2b. Discussions >> are ongoing with regards to 1.0.1. >> >> Regards >> >> Matt >> >> >> >> >>> This problem only exists in OpenSSL and LibreSSL as far as >>> testing goes. It isn?t reproducible with Apple?s Security >>> Framework, or GnuTLS. >> >>> Interestingly, Apple have done something to their shipped >>> OpenSSL 0.9.8x to fix the problem - If I build OpenSSL 0.9.8x >>> from source and use it, failure, but if I use the one Apple >>> installs the connection verifies and succeeds. Here?s hoping >>> they?ve punted whatever those changes were upstream to you. >> >>> This is the error you get: >> >>> ================================================== ?2015-04-10 >>> 16:58:58? https://google.com/ Resolving google.com? >>> 216.58.210.46, 2a00:1450:4009:800::200e Connecting to >>> google.com|216.58.210.46|:443? connected. ERROR: cannot verify >>> google.com?s certificate, issued by ?CN=Google Internet >>> Authority G2,O=Google Inc,C=US?: Unable to locally verify the >>> issuer?s authority. To connect to google.com insecurely, use >>> `?no-check-certificate?. >>> ================================================== >> >>> How to reproduce: >> >>> * Install OpenSSL on OS X 10.10.3 or above. I have it installed >>> to /usr/local/opt/openssl - With the sysconfdir in >>> /usr/local/etc. >> >>> * Generate a PEM file from OS X?s Security Keychain: * >>> security find-certificate -a -p >>> /Library/Keychains/System.keychain >> sys.pem * security >>> find-certificate -a -p >>> /System/Library/Keychains/SystemRootCertificates.keychain >> >>> sysroot.pem * cat sys.pem >> sysroot.pem * mv sysroot.pem >>> /usr/local/etc/openssl >> >>> * Download and install cURL: * Pass >>> ??with-ssl=/path/to/openssl/dir? and >>> ?--with-ca-bundle=/path/to/sysconfdir/openssl/sysroot.pem? to >>> configure. >> >>> * Run ?/path/to/your/installed/curl -I https://google.com? >> >>> It reproduces with wget, mutt, various other tools. If you put >>> the Equifax certificate back, and then rehash, you can make >>> the connection. But the Equifax cert is old, and weak, and >>> Apple aren?t likely to return it to the Keychain. So this >>> problem connecting to Google will persist until the reason for >>> not stopping at and verifying on the GeoTrust root are narrowed >>> down and hopefully fixed. >> >>> Mozilla are also pressing ahead with removing that Equifax >>> root from their certs, so it?s not a simple case of working >>> around it by switching PEM. >> >> >> >>> _______________________________________________ openssl-dev >>> mailing list To unsubscribe: >>> https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> _______________________________________________ openssl-dev >> mailing list To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > > > _______________________________________________ openssl-dev mailing > list To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-dev > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJVNmuYAAoJENnE0m0OYESRwAcH/1XrZzo+SKPrLMQ8DvfZI1w5 +Y8IzNn38TVwTmD0SoJWdwCrIu0x1SQkQQ3aVspkscBzUDHM9Rs0xPQYuKqXPhNW re+1iLjvYh99yAy1lMEVVIlML6Q8V23QZ0YarBa41sZ0z3JfOknWVart1Cpzbbzq XsG9dOcP8mBlED/P/KPMY7P4FbTB8jL57y9d+JiKzUvjWJufQAryEeCq8/vKGz6e /2eK+QsEPLrxQRFu7J6PhnobRIw15FOKujavzZmkmaijc/6Q+6VcBkrRth9DSzNe XCbuD0A2ekCccz33l9I5xPE+6xce+5D9HTkWoFGQDxXUFbsIoOAqewx7AIx4nJA= =u2ow -----END PGP SIGNATURE----- From emilia at openssl.org Tue Apr 21 17:46:24 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 21 Apr 2015 19:46:24 +0200 Subject: [openssl-dev] s3_clnt.c changes regarding external pre-shared secret seem to break EAP-FAST In-Reply-To: References: <55084BE001E705C20039061F_0_80099@p057> <574588A4-7350-4DDE-920F-ED0D38500A51@gmail.com> Message-ID: On Wed, Apr 1, 2015 at 10:53 PM, Brian Smith wrote: > Emilia K?sper wrote: > > On Fri, Mar 27, 2015 at 10:40 PM, Brian Smith > wrote: > >> If OpenSSL's client code were changed to always use an empty session > >> ID when attempting resumption using a session ticket, then the > >> EAP-FAST case wouldn't be different from the general session ticket > >> resumption case. I think that this is a cleaner approach. > > > > 1) The way EAP-FAST diverges from 5246 and 5077 is indeed quite > > unfortunate. The lookahead is messy, and hard to get right - I don't want > > another "early CCS" due to lack of determinism in the state machine. > Setting > > the session ID is much cleaner. So, I'd rather put in a workaround that > is > > specific to EAP-FAST and doesn't affect regular handshakes. > > The added complexity of having a special case for EAP-FAST seems worse > to me. After all, it's not OK to have EAP-FAST be non-secure, and so > it is important to have the no-session-ID case be correct regardless. > This has now been fixed in commit 6e3d015363ed09c4eff5c02ad41153387ffdf5af and cherry-picked to stable branches. I certainly hope it's correct! I've done my best to make it so. Cheers, Emilia > > 2) Removing the session ID upon resumption would be a big change in > > behaviour that I don't think would qualify for a stable branch anyway > unless > > there was a security or regression issue behind it. > > Fair enough. I have no idea what the compatibility problems might > arise. If I have some time, I might try to change one of the web > browsers to do this, to see what happens. If I do, I'll report back. > > Cheers, > Brian > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From darovskikh.andrei at gmail.com Wed Apr 22 08:55:21 2015 From: darovskikh.andrei at gmail.com (=?UTF-8?B?0JDQvdC00YDQtdC5INCU0LDRgNC+0LLRgdC60LjRhQ==?=) Date: Wed, 22 Apr 2015 11:55:21 +0300 Subject: [openssl-dev] [PATCH] for capi_load_ssl_client_cert Message-ID: Hello. capi_load_ssl_client_cert function does not select the certificates that have a chain of issuers if the server transmits only the root certificate of the issuer. Attached patch fixes this error. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: e_capi.c.patch Type: application/octet-stream Size: 6997 bytes Desc: not available URL: From steve at openssl.org Wed Apr 22 14:06:56 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 22 Apr 2015 14:06:56 +0000 Subject: [openssl-dev] Missing API features In-Reply-To: References: <1c5ed9e9379a4de184323fa82252e76a@usma1ex-dag1mb2.msg.corp.akamai.com> <20150421115058.GA20127@openssl.org> Message-ID: <20150422140656.GA17577@openssl.org> On Tue, Apr 21, 2015, Richard Moore wrote: > On 21 April 2015 at 12:50, Dr. Stephen Henson wrote: > > > I think what would be useful here would be an API that can determine > > appropriate characterictics of an SSL_CIPHER. For example a NID > > corresponding to the key exchange algorithm, signer, cipher and MAC. We > > have > > to find this stuff out internally but there is no exposed API to do this. > > > > Enough for an application to write its own version of > > SSL_CIPHER_description > > for example. > > > > Yes, that would be ideal. > I've just added a couple of SSL_CIPHER utility functions to the master branch which handle the cipher and MAC. More to follow. 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 Apr 22 16:33:41 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 22 Apr 2015 18:33:41 +0200 Subject: [openssl-dev] [openssl.org #3786] [PATCH] Check return value of CRYPTO_malloc In-Reply-To: References: Message-ID: Patch applied. Many thanks. Matt From balajimarisetti at gmail.com Thu Apr 23 13:00:22 2015 From: balajimarisetti at gmail.com (balaji marisetti) Date: Thu, 23 Apr 2015 18:30:22 +0530 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: References: <1427720548359.36445@caviumnetworks.com> Message-ID: Hi, Can someone comment on this patch request. I just to know if there was anything wrong (or requirement not met) for this patch to be accepted. Thanks, Balaji M On 30 March 2015 at 23:24, Marisetti, Balaji via RT wrote: > This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. > > > Thanks, > > Balaji M > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- :-)balaji From rt at openssl.org Thu Apr 23 13:01:19 2015 From: rt at openssl.org (balaji marisetti via RT) Date: Thu, 23 Apr 2015 15:01:19 +0200 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: References: <1427720548359.36445@caviumnetworks.com> Message-ID: Hi, Can someone comment on this patch request. I just to know if there was anything wrong (or requirement not met) for this patch to be accepted. Thanks, Balaji M On 30 March 2015 at 23:24, Marisetti, Balaji via RT wrote: > This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. > > > Thanks, > > Balaji M > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- :-)balaji From rsalz at akamai.com Thu Apr 23 13:21:30 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Apr 2015 13:21:30 +0000 Subject: [openssl-dev] Anyone still using Netscape SPKI SPKAC? Message-ID: <543cef2af99b42869b0458497bcf574f@usma1ex-dag1mb2.msg.corp.akamai.com> Is anyone still using the Netscape SPKAC or SPKI structures? I want to remove them from the next release (i.e., master) -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Apr 23 16:59:58 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 23 Apr 2015 16:59:58 +0000 Subject: [openssl-dev] Anyone still using Netscape SPKI SPKAC? In-Reply-To: <543cef2af99b42869b0458497bcf574f@usma1ex-dag1mb2.msg.corp.akamai.com> References: <543cef2af99b42869b0458497bcf574f@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: > Is anyone still using the Netscape SPKAC or SPKI structures? I want to remove them from the next release (i.e., master) Steve Henson pointed out that they are used in HTML5 keygen. I'll have to look to see if they're the same types. From rt at openssl.org Thu Apr 23 17:51:06 2015 From: rt at openssl.org (Dima Tisnek via RT) Date: Thu, 23 Apr 2015 19:51:06 +0200 Subject: [openssl-dev] [openssl.org #3817] bug report, command line SRP In-Reply-To: References: Message-ID: Commands to reproduce touch srp.db openssl srp -srpvfile srp.db -add fuser # password "pass" openssl s_server -srpvfile srp.db -nocert -cipher SRP -www # another term, 5 times openssl s_client -connect localhost:4433 -srpuser fuser -srppass stdin # input "pass" I get this in server output, one accept per client run: Using default temp DH parameters ACCEPT User fuser doesn't exist ACCEPT User @?j doesn't exist ACCEPT User fuser doesn't exist ACCEPT User @?j doesn't exist ACCEPT User fuser doesn't exist ACCEPT Somehow, every other time, SRP user is printed as rubbish. Seems like a bug somewhere, hopefully only in the command line tool. Trying same sequence again, I often get "User doesn't exist" instead, that is username is apparently empty. From rt at openssl.org Thu Apr 23 17:51:49 2015 From: rt at openssl.org (Florian Pritz via RT) Date: Thu, 23 Apr 2015 19:51:49 +0200 Subject: [openssl-dev] [openssl.org #3818] [BUG] dovecot imap-login segfault when running nmap -sV In-Reply-To: <5538B641.1010606@xinu.at> References: <5538B641.1010606@xinu.at> Message-ID: Hi, The only reply I've got on the dovecot list so far believe this to be an openssl issue so I'm sending this to you guys. I've noticed that nmap crashes imap-login of my dovecot (also pop3-login) and narrowed it down to `nmap -sV -p 993 $host`. I've noticed that if I remove "ssl_protocols = !SSLv2 !SSLv3" from my config or enable SSLv3 rather than disabling it the segfault disappears. I'm running on Arch Linux with dovecot 2.2.16-1 and openssl 1.0.2.a-1. I've also attached a network capture. I hope this is enough information to reproduce the issue. If necessary I can recompile dovecot with debug symbols for a better backtrace. Thanks, Florian dovecot.conf https://paste.xinu.at/PUsJ/ syslog: > Apr 21 10:52:16 karif dovecot[7849]: imap-login: Disconnected (no auth attempts in 6 secs): user=<>, rip=81.217.47.122, lip=78.46.56.141, TLS handshaking: SSL_accept() failed: error:1407609C:SSL routines:SSL23_GET_CLIENT_HELLO:http request > Apr 21 10:52:16 karif dovecot[7849]: imap-login: Fatal: master: service(imap-login): child 7879 killed with signal 11 (core not dumped - add -D parameter to service imap-login { executable } [last ip=81.217.47.122] > Apr 21 10:52:16 karif kernel: imap-login[7879] segfault at f0 ip 00007fb2b8b1360b sp 00007fff926ffd50 error 4 in libssl.so.1.0.0[7fb2b8af3000+6f000] backtrace: > #0 0x00007f120100260b in ssl3_get_client_hello () from /usr/lib/libssl.so.1.0.0 > #1 0x00007f120100738f in ssl3_accept () from /usr/lib/libssl.so.1.0.0 > #2 0x00007f1201012b36 in ssl3_write_bytes () from /usr/lib/libssl.so.1.0.0 > #3 0x00007f1201906200 in ?? () from /usr/lib/dovecot/libdovecot-login.so.0 > #4 0x00007f12019062d8 in ?? () from /usr/lib/dovecot/libdovecot-login.so.0 > #5 0x00007f1201905f72 in ssl_proxy_destroy () from /usr/lib/dovecot/libdovecot-login.so.0 > #6 0x00007f12019060e4 in ?? () from /usr/lib/dovecot/libdovecot-login.so.0 > #7 0x00007f1201906671 in ?? () from /usr/lib/dovecot/libdovecot-login.so.0 > #8 0x00007f1201902efa in ?? () from /usr/lib/dovecot/libdovecot-login.so.0 > #9 0x00007f120162d503 in ?? () from /usr/lib/dovecot/libdovecot.so.0 > #10 0x00007f120168d62c in io_loop_call_io () from /usr/lib/dovecot/libdovecot.so.0 > #11 0x00007f120168e665 in io_loop_handler_run_internal () from /usr/lib/dovecot/libdovecot.so.0 > #12 0x00007f120168d699 in io_loop_handler_run () from /usr/lib/dovecot/libdovecot.so.0 > #13 0x00007f120168d718 in io_loop_run () from /usr/lib/dovecot/libdovecot.so.0 > #14 0x00007f120162cb23 in master_service_run () from /usr/lib/dovecot/libdovecot.so.0 > #15 0x00007f1201903788 in login_binary_run () from /usr/lib/dovecot/libdovecot-login.so.0 > #16 0x00007f120127d800 in __libc_start_main () from /usr/lib/libc.so.6 > #17 0x0000000000402909 in _start () nmap output: >> nmap -sV --packet-trace -p 993 karif > > Starting Nmap 6.47 ( http://nmap.org ) at 2015-04-21 10:52 CEST > CONN (0.0426s) TCP localhost > 78.46.56.141:80 => Operation now in progress > CONN (0.0427s) TCP localhost > 78.46.56.141:443 => Operation now in progress > NSOCK INFO [0.0650s] nsi_new2(): nsi_new (IOD #1) > NSOCK INFO [0.0650s] nsock_connect_udp(): UDP connection requested to 192.168.4.1:53 (IOD #1) EID 8 > NSOCK INFO [0.0650s] nsock_read(): Read request from IOD #1 [192.168.4.1:53] (timeout: -1ms) EID 18 > NSOCK INFO [0.0650s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [192.168.4.1:53] > NSOCK INFO [0.0650s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 27 [192.168.4.1:53] > NSOCK INFO [0.0650s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 18 [192.168.4.1:53] (79 bytes): .............141.56.46.78.in-addr.arpa..................karif.server-speed.net. > NSOCK INFO [0.0650s] nsock_read(): Read request from IOD #1 [192.168.4.1:53] (timeout: -1ms) EID 34 > NSOCK INFO [0.0650s] nsi_delete(): nsi_delete (IOD #1) > NSOCK INFO [0.0650s] msevent_cancel(): msevent_cancel on event #34 (type READ) > CONN (0.0656s) TCP localhost > 78.46.56.141:993 => Operation now in progress > NSOCK INFO [0.1320s] nsi_new2(): nsi_new (IOD #1) > NSOCK INFO [0.1330s] nsock_connect_tcp(): TCP connection requested to 78.46.56.141:993 (IOD #1) EID 8 > NSOCK INFO [0.1550s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 8 [78.46.56.141:993] > Service scan sending probe NULL to 78.46.56.141:993 (tcp) > NSOCK INFO [0.1550s] nsock_read(): Read request from IOD #1 [78.46.56.141:993] (timeout: 6000ms) EID 18 > NSOCK INFO [6.1610s] nsock_trace_handler_callback(): Callback: READ TIMEOUT for EID 18 [78.46.56.141:993] > Service scan sending probe GetRequest to 78.46.56.141:993 (tcp) > NSOCK INFO [6.1610s] nsock_read(): Read request from IOD #1 [78.46.56.141:993] (timeout: 5000ms) EID 34 > NSOCK INFO [6.1610s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 27 [78.46.56.141:993] > NSOCK INFO [6.1840s] nsock_trace_handler_callback(): Callback: READ ERROR [Connection reset by peer (104)] for EID 34 [78.46.56.141:993] > NSOCK INFO [6.1840s] nsi_delete(): nsi_delete (IOD #1) > NSOCK INFO [6.1840s] nsi_new2(): nsi_new (IOD #2) > NSOCK INFO [6.1840s] nsock_connect_tcp(): TCP connection requested to 78.46.56.141:993 (IOD #2) EID 40 > NSOCK INFO [6.2050s] nsock_trace_handler_callback(): Callback: CONNECT SUCCESS for EID 40 [78.46.56.141:993] > Service scan sending probe SSLSessionReq to 78.46.56.141:993 (tcp) > NSOCK INFO [6.2060s] nsock_read(): Read request from IOD #2 [78.46.56.141:993] (timeout: 5000ms) EID 58 > NSOCK INFO [6.2060s] nsock_trace_handler_callback(): Callback: WRITE SUCCESS for EID 51 [78.46.56.141:993] > NSOCK INFO [6.2280s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 58 [78.46.56.141:993] (7 bytes): ......( > Service scan match (Probe SSLSessionReq matched with SSLSessionReq line 10443): 78.46.56.141:993 is ssl. Version: |TLSv1||| > NSOCK INFO [6.2280s] nsi_delete(): nsi_delete (IOD #2) > NSOCK INFO [6.2280s] nsi_new2(): nsi_new (IOD #3) > NSOCK INFO [6.2280s] nsock_connect_ssl(): SSL connection requested to 78.46.56.141:993/tcp (IOD #3) EID 65 > NSOCK INFO [6.3370s] nsock_trace_handler_callback(): Callback: SSL-CONNECT SUCCESS for EID 65 [78.46.56.141:993] > Service scan sending probe NULL to 78.46.56.141:993 (tcp) > NSOCK INFO [6.3370s] nsock_read(): Read request from IOD #3 [78.46.56.141:993] (timeout: 6000ms) EID 74 > NSOCK INFO [6.3960s] nsock_trace_handler_callback(): Callback: READ SUCCESS for EID 74 [78.46.56.141:993] (114 bytes) > Service scan match (Probe NULL matched with NULL line 1312): 78.46.56.141:993 is SSL/imap. Version: |Dovecot imapd||| > NSOCK INFO [6.3960s] nsi_delete(): nsi_delete (IOD #3) > Nmap scan report for karif (78.46.56.141) > Host is up (0.023s latency). > rDNS record for 78.46.56.141: karif.server-speed.net > PORT STATE SERVICE VERSION > 993/tcp open ssl/imap Dovecot imapd > > Service detection performed. Please report any incorrect results at http://nmap.org/submit/ . > Nmap done: 1 IP address (1 host up) scanned in 6.40 seconds -------------- next part -------------- A non-text attachment was scrubbed... Name: imap-login-crash.pcapng.gz Type: application/gzip Size: 7625 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rt at openssl.org Thu Apr 23 19:25:45 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 23 Apr 2015 21:25:45 +0200 Subject: [openssl-dev] [openssl.org #3818] [BUG] dovecot imap-login segfault when running nmap -sV In-Reply-To: <5538B641.1010606@xinu.at> References: <5538B641.1010606@xinu.at> Message-ID: On Thu Apr 23 19:51:49 2015, bluewind at xinu.at wrote: > Hi, > > The only reply I've got on the dovecot list so far believe this to be > an > openssl issue so I'm sending this to you guys. > > I've noticed that nmap crashes imap-login of my dovecot (also > pop3-login) and narrowed it down to `nmap -sV -p 993 $host`. I've > noticed that if I remove "ssl_protocols = !SSLv2 !SSLv3" from my > config > or enable SSLv3 rather than disabling it the segfault disappears. Thank you for your detailed description of the issue. I suspect I know what the problem is. If I'm correct then its actually OpenSSL being less than forgiving of a dovecot bug. In your capture you can see nmap sending an SSLv3 ClientHello message to OpenSSL, and then OpenSSL responding with a handshake failure alert (as it should do because you have disabled SSLv3). At this point OpenSSL will return to dovecot with a fatal error code. The SSL object for the connection should have no further attempts made to continue to read from it or write to it. If dovecot does so then it is likely to have bad consequences. My suspicion is that dovecot has ignored the returned error and attempted to continue with the connection. If I'm right then this is a dovecot bug to fix. Having said that OpenSSL should probably be more forgiving of this error condition. Please see attached patch for 1.0.2a. If this resolves the issue, then it confirms my suspicions. The patch simply ensures that any subsequent attempt to use the SSL object will immediately return with an error. Let me know how you get on. Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: retry-cert-fix.patch Type: text/x-patch Size: 1523 bytes Desc: not available URL: From brian at briansmith.org Thu Apr 23 21:07:01 2015 From: brian at briansmith.org (Brian Smith) Date: Thu, 23 Apr 2015 11:07:01 -1000 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness Message-ID: Hi, I have some questions regarding this implementation. https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c 1. In ecp_nistz256_points_mul, we have this code: if ((BN_num_bits(scalar) > 256) { ... if (!BN_nnmod(tmp_scalar, scalar, &group->order, ctx)) {...} scalar = tmp_scalar; } I think it would be useful to add a comment about why this is OK in terms of the constant-time-correctness of the code, because it isn't obvious. 2. Later in the same function, we have this code: bn_correct_top(r->X); bn_correct_top(r->Y); bn_correct_top(r->Z); Again, it isn't clear why it is OK to call bn_correct_top given that bn_correct_top isn't a constant-time function. I think either this code should be changed so that it is constant time, or a comment should be added explaining why it doesn't need to be. 3. When doing the initial adaptation of the code to get it working inside of BoringSSL, I had to make this change: bn_correct_top(r->X); bn_correct_top(r->Y); bn_correct_top(r->Z); + r->Z_is_one = is_one(p.p.Z); (Alternatively, maybe one can change BoringSSL's implementation of EC_POINT_is_at_infinity to ignore r->Z_is_one like OpenSSL's implementation does.) Looking at the OpenSSL code, I can see that Z_is_one is only used for optimization purposes in the "simple" ECC implementation. Even ignoring BoringSSL being different, I found it confusing that sometimes Z_is_one *must* be set correctly and other times it *must* be ignored. Perhaps it is worth renaming this member to "simple_Z_is_one" and/or documenting more clearly when it is maintained and when it can and cannot be used. Alternatively, I noticed that BN_is_one is not a very expensive function, and probably can be made even less expensive, so the optimization of using the Z_is_one flag instead of just calling BN_is_one may not be worthwhile. Perhaps it would be better to remove it completely? 4. There seems to be quite a bit of missing error checking in this code. For example, the return values of calls to bn_wexpand are not checked in multiple functions. Further, a lot of the error checking in the probably-never-used ecp_nistz256_mult_precompute function is missing, e.g. calls to EC_POINT_new, EC_POINT_copy, and ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be combed for missing error checks. 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new context will be created with BN_CTX_new but BN_CTX_free is not called anywhere in the file. All that aside, this code is very fast, and it is awesome that it got adapted to non-X64 platforms already! Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at briansmith.org Thu Apr 23 21:24:57 2015 From: brian at briansmith.org (Brian Smith) Date: Thu, 23 Apr 2015 11:24:57 -1000 Subject: [openssl-dev] ec_wNAF_precompute_mult sometimes calls BN_CTX_end without BN_CTX_start Message-ID: See https://boringssl.googlesource.com/boringssl/+/d6405beb2c75564edbbb7f4203252aa5edee2359 It seems OpenSSL has the same bug, although the code is slightly different, and my fix for BoringSSL should be easy to adapt for OpenSSL. It may be worth trying to find the same pattern elsewhere in the OpenSSL code. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Fri Apr 24 13:00:42 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 24 Apr 2015 15:00:42 +0200 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness In-Reply-To: References: Message-ID: Thanks for the report! Let me clarify a few points, and then I'll fix it. On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith wrote: > Hi, > > I have some questions regarding this implementation. > > > https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c > > 1. In ecp_nistz256_points_mul, we have this code: > > if ((BN_num_bits(scalar) > 256) { > ... > if (!BN_nnmod(tmp_scalar, scalar, &group->order, ctx)) {...} > scalar = tmp_scalar; > } > > I think it would be useful to add a comment about why this is OK in terms > of the constant-time-correctness of the code, because it isn't obvious. > > Yes, this needs a comment. Basically we treat overlong scalars as malformed, and don't guarantee constant-timeness for them. (It'd be too hard.) In the ecp_nistp***.c modules, this is commented. > 2. Later in the same function, we have this code: > > bn_correct_top(r->X); > bn_correct_top(r->Y); > bn_correct_top(r->Z); > > Again, it isn't clear why it is OK to call bn_correct_top given that > bn_correct_top isn't a constant-time function. I think either this code > should be changed so that it is constant time, or a comment should be added > explaining why it doesn't need to be. > I think that's fine and just needs a comment. It happens in the end and basically strips leading zero-words from the (presumably public) output. The ecp_nistp***.c code just calls EC_POINT_set_Jprojective_coordinates_GFp() at this point. > > 3. When doing the initial adaptation of the code to get it working inside > of BoringSSL, I had to make this change: > > bn_correct_top(r->X); > bn_correct_top(r->Y); > bn_correct_top(r->Z); > + r->Z_is_one = is_one(p.p.Z); > > (Alternatively, maybe one can change BoringSSL's implementation > of EC_POINT_is_at_infinity to ignore r->Z_is_one like OpenSSL's > implementation does.) > Yep, that's a bug because r->Z_is_one may remain incorrectly set. I don't know why BoringSSL does that extra check in EC_POINT_is_at_infinity, though; it precedes their public git history. I'll check with the authors. I agree with you that this appears an optimization flag, so what should always be guaranteed is that point->Z_is_one => BN_is_one(point->Z). But !point->Z_is_one => inconclusive. > > Looking at the OpenSSL code, I can see that Z_is_one is only used for > optimization purposes in the "simple" ECC implementation. Even ignoring > BoringSSL being different, I found it confusing that sometimes Z_is_one > *must* be set correctly and other times it *must* be ignored. Perhaps it is > worth renaming this member to "simple_Z_is_one" and/or documenting more > clearly when it is maintained and when it can and cannot be used. > > Alternatively, I noticed that BN_is_one is not a very expensive function, > and probably can be made even less expensive, so the optimization of using > the Z_is_one flag instead of just calling BN_is_one may not be worthwhile. > Perhaps it would be better to remove it completely? > Quite likely! This'll go on a TODO list somewhere... > > 4. There seems to be quite a bit of missing error checking in this code. > For example, the return values of calls to bn_wexpand are not checked in > multiple functions. Further, a lot of the error checking in the > probably-never-used ecp_nistz256_mult_precompute function is missing, e.g. > calls to EC_POINT_new, EC_POINT_copy, and > ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be > combed for missing error checks. > > 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new > context will be created with BN_CTX_new but BN_CTX_free is not called > anywhere in the file. > Yep, these need fixing. Cheers, Emilia > All that aside, this code is very fast, and it is awesome that it got > adapted to non-X64 platforms already! > > Cheers, > Brian > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From emilia at openssl.org Fri Apr 24 13:15:59 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 24 Apr 2015 15:15:59 +0200 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness In-Reply-To: References: Message-ID: On Fri, Apr 24, 2015 at 3:00 PM, Emilia K?sper wrote: > Thanks for the report! Let me clarify a few points, and then I'll fix it. > > On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith > wrote: > >> Hi, >> >> I have some questions regarding this implementation. >> >> >> https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c >> >> 1. In ecp_nistz256_points_mul, we have this code: >> >> if ((BN_num_bits(scalar) > 256) { >> ... >> if (!BN_nnmod(tmp_scalar, scalar, &group->order, ctx)) {...} >> scalar = tmp_scalar; >> } >> >> I think it would be useful to add a comment about why this is OK in terms >> of the constant-time-correctness of the code, because it isn't obvious. >> >> > Yes, this needs a comment. Basically we treat overlong scalars as > malformed, and don't guarantee constant-timeness for them. (It'd be too > hard.) In the ecp_nistp***.c modules, this is commented. > > > >> 2. Later in the same function, we have this code: >> >> bn_correct_top(r->X); >> bn_correct_top(r->Y); >> bn_correct_top(r->Z); >> >> Again, it isn't clear why it is OK to call bn_correct_top given that >> bn_correct_top isn't a constant-time function. I think either this code >> should be changed so that it is constant time, or a comment should be added >> explaining why it doesn't need to be. >> > > I think that's fine and just needs a comment. It happens in the end and > basically strips leading zero-words from the (presumably public) output. > The ecp_nistp***.c code just calls > EC_POINT_set_Jprojective_coordinates_GFp() at this point. > > >> >> 3. When doing the initial adaptation of the code to get it working inside >> of BoringSSL, I had to make this change: >> >> bn_correct_top(r->X); >> bn_correct_top(r->Y); >> bn_correct_top(r->Z); >> + r->Z_is_one = is_one(p.p.Z); >> >> (Alternatively, maybe one can change BoringSSL's implementation >> of EC_POINT_is_at_infinity to ignore r->Z_is_one like OpenSSL's >> implementation does.) >> > > Yep, that's a bug because r->Z_is_one may remain incorrectly set. > > I don't know why BoringSSL does that extra check in > EC_POINT_is_at_infinity, though; it precedes their public git history. I'll > check with the authors. > I agree with you that this appears an optimization flag, so what should > always be guaranteed is that point->Z_is_one => BN_is_one(point->Z). But > !point->Z_is_one => inconclusive. > Oh, I think it's just an optimization on their end. > > > >> >> Looking at the OpenSSL code, I can see that Z_is_one is only used for >> optimization purposes in the "simple" ECC implementation. Even ignoring >> BoringSSL being different, I found it confusing that sometimes Z_is_one >> *must* be set correctly and other times it *must* be ignored. Perhaps it is >> worth renaming this member to "simple_Z_is_one" and/or documenting more >> clearly when it is maintained and when it can and cannot be used. >> >> Alternatively, I noticed that BN_is_one is not a very expensive function, >> and probably can be made even less expensive, so the optimization of using >> the Z_is_one flag instead of just calling BN_is_one may not be worthwhile. >> Perhaps it would be better to remove it completely? >> > > Quite likely! This'll go on a TODO list somewhere... > > >> >> 4. There seems to be quite a bit of missing error checking in this code. >> For example, the return values of calls to bn_wexpand are not checked in >> multiple functions. Further, a lot of the error checking in the >> probably-never-used ecp_nistz256_mult_precompute function is missing, e.g. >> calls to EC_POINT_new, EC_POINT_copy, and >> ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be >> combed for missing error checks. >> >> 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new >> context will be created with BN_CTX_new but BN_CTX_free is not called >> anywhere in the file. >> > > Yep, these need fixing. > > Cheers, > Emilia > > >> All that aside, this code is very fast, and it is awesome that it got >> adapted to non-X64 platforms already! >> >> Cheers, >> Brian >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Apr 24 15:14:44 2015 From: rt at openssl.org (Borut Podlipnik via RT) Date: Fri, 24 Apr 2015 17:14:44 +0200 Subject: [openssl-dev] [openssl.org #3819] make openssl-1.0.2a failed on Solaris 10 i86pc In-Reply-To: References: Message-ID: Dear developers, I am not able to build openssl-1.02.a on Solaris 10: # uname -a SunOS corona 5.10 Generic_150401-23 i86pc i386 i86pc Solaris # ./Configure solaris-x86-gcc --openssldir=/usr/local/openssl-1.0.2a shared ? Configured for solaris-x86-gcc. # make making all in crypto... make[1]: Entering directory `/export/home/borut/admin/openssl/openssl-1.0.2a/crypto' /bin/perl ../util/mkbuildinf.pl "gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM" "solaris-x86-gcc" >buildinf.h gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o cryptlib.o cryptlib.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o mem.o mem.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o mem_dbg.o mem_dbg.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o cversion.o cversion.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o ex_data.o ex_data.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o cpt_err.o cpt_err.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o ebcdic.o ebcdic.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o uid.o uid.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o o_time.o o_time.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o o_str.o o_str.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o o_dir.o o_dir.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o o_fips.o o_fips.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o o_init.o o_init.c gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o fips_ers.o fips_ers.c /bin/perl x86cpuid.pl elf -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM > x86cpuid.s gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o x86cpuid.o x86cpuid.s Assembler: x86cpuid.s "x86cpuid.s", line 158 : Illegal subtraction in ... "OPENSSL_ia32cap_P - .L009PIC_me_up" make[1]: *** [x86cpuid.o] Error 1 make[1]: Leaving directory `/export/home/borut/admin/openssl/openssl-1.0.2a/crypto' make: *** [build_crypto] Error 1 # Any idea how to fix this? Best regards, Borut Podlipnik -- ++++++++++++++++++++++++++++++++++++ Borut Podlipnik Max Planck Institute for Solar System Research Justus-von-Liebig-Weg 3 37077 G?ttingen Phone:+49 551 384 979 227 Email: podlipnik at mps.mpg.de ++++++++++++++++++++++++++++++++++++ From emilia at openssl.org Fri Apr 24 15:54:01 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Fri, 24 Apr 2015 17:54:01 +0200 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness In-Reply-To: References: Message-ID: commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2). commit 53dd4ddf71 fixes 5 and some of 4. Still ploughing my way through the rest of error checking. Cheers, Emilia On Fri, Apr 24, 2015 at 3:15 PM, Emilia K?sper wrote: > > > On Fri, Apr 24, 2015 at 3:00 PM, Emilia K?sper wrote: > >> Thanks for the report! Let me clarify a few points, and then I'll fix it. >> >> On Thu, Apr 23, 2015 at 11:07 PM, Brian Smith >> wrote: >> >>> Hi, >>> >>> I have some questions regarding this implementation. >>> >>> >>> https://github.com/openssl/openssl/blob/e0e920b1a063f14f36418f8795c96f2c649400e1/crypto/ec/ecp_nistz256.c >>> >>> 1. In ecp_nistz256_points_mul, we have this code: >>> >>> if ((BN_num_bits(scalar) > 256) { >>> ... >>> if (!BN_nnmod(tmp_scalar, scalar, &group->order, ctx)) {...} >>> scalar = tmp_scalar; >>> } >>> >>> I think it would be useful to add a comment about why this is OK in >>> terms of the constant-time-correctness of the code, because it isn't >>> obvious. >>> >>> >> Yes, this needs a comment. Basically we treat overlong scalars as >> malformed, and don't guarantee constant-timeness for them. (It'd be too >> hard.) In the ecp_nistp***.c modules, this is commented. >> >> >> >>> 2. Later in the same function, we have this code: >>> >>> bn_correct_top(r->X); >>> bn_correct_top(r->Y); >>> bn_correct_top(r->Z); >>> >>> Again, it isn't clear why it is OK to call bn_correct_top given that >>> bn_correct_top isn't a constant-time function. I think either this code >>> should be changed so that it is constant time, or a comment should be added >>> explaining why it doesn't need to be. >>> >> >> I think that's fine and just needs a comment. It happens in the end and >> basically strips leading zero-words from the (presumably public) output. >> The ecp_nistp***.c code just calls >> EC_POINT_set_Jprojective_coordinates_GFp() at this point. >> >> >>> >>> 3. When doing the initial adaptation of the code to get it working >>> inside of BoringSSL, I had to make this change: >>> >>> bn_correct_top(r->X); >>> bn_correct_top(r->Y); >>> bn_correct_top(r->Z); >>> + r->Z_is_one = is_one(p.p.Z); >>> >>> (Alternatively, maybe one can change BoringSSL's implementation >>> of EC_POINT_is_at_infinity to ignore r->Z_is_one like OpenSSL's >>> implementation does.) >>> >> >> Yep, that's a bug because r->Z_is_one may remain incorrectly set. >> >> I don't know why BoringSSL does that extra check in >> EC_POINT_is_at_infinity, though; it precedes their public git history. I'll >> check with the authors. >> I agree with you that this appears an optimization flag, so what should >> always be guaranteed is that point->Z_is_one => BN_is_one(point->Z). But >> !point->Z_is_one => inconclusive. >> > > Oh, I think it's just an optimization on their end. > > >> >> >> >>> >>> Looking at the OpenSSL code, I can see that Z_is_one is only used for >>> optimization purposes in the "simple" ECC implementation. Even ignoring >>> BoringSSL being different, I found it confusing that sometimes Z_is_one >>> *must* be set correctly and other times it *must* be ignored. Perhaps it is >>> worth renaming this member to "simple_Z_is_one" and/or documenting more >>> clearly when it is maintained and when it can and cannot be used. >>> >>> Alternatively, I noticed that BN_is_one is not a very expensive >>> function, and probably can be made even less expensive, so the optimization >>> of using the Z_is_one flag instead of just calling BN_is_one may not be >>> worthwhile. Perhaps it would be better to remove it completely? >>> >> >> Quite likely! This'll go on a TODO list somewhere... >> >> >>> >>> 4. There seems to be quite a bit of missing error checking in this code. >>> For example, the return values of calls to bn_wexpand are not checked in >>> multiple functions. Further, a lot of the error checking in the >>> probably-never-used ecp_nistz256_mult_precompute function is missing, e.g. >>> calls to EC_POINT_new, EC_POINT_copy, and >>> ec_GFp_simple_{add,dbl,make_affine}. I think this whole file needs to be >>> combed for missing error checks. >>> >>> 5. In ecp_nistz256_mult_precompute, if the ctx parameter is null, a new >>> context will be created with BN_CTX_new but BN_CTX_free is not called >>> anywhere in the file. >>> >> >> Yep, these need fixing. >> >> Cheers, >> Emilia >> >> >>> All that aside, this code is very fast, and it is awesome that it got >>> adapted to non-X64 platforms already! >>> >>> Cheers, >>> Brian >>> >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Apr 24 16:39:33 2015 From: rt at openssl.org (Florian Pritz via RT) Date: Fri, 24 Apr 2015 18:39:33 +0200 Subject: [openssl-dev] [openssl.org #3818] [BUG] dovecot imap-login segfault when running nmap -sV In-Reply-To: <553A71A7.8090409@xinu.at> References: <5538B641.1010606@xinu.at> <553A71A7.8090409@xinu.at> Message-ID: On 23.04.2015 21:25, Matt Caswell via RT wrote: > If I'm right then this is a dovecot bug to fix. Having said that OpenSSL should > probably be more forgiving of this error condition. Please see attached patch > for 1.0.2a. If this resolves the issue, then it confirms my suspicions. The > patch simply ensures that any subsequent attempt to use the SSL object will > immediately return with an error. Hi, I've applied the patch and verified that the bug is now indeed gone. I'll forward that information to dovecot upstream. Thank you for the quick diagnosis. Florian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 801 bytes Desc: not available URL: From rt at openssl.org Sat Apr 25 09:13:04 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Sat, 25 Apr 2015 11:13:04 +0200 Subject: [openssl-dev] [openssl.org #3820] [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow In-Reply-To: References: Message-ID: Hello, Summary: currently function LIBEAY32!OPENSSL_isservice() calls USER32!GetDesktopWindow() to determine if the code is running as a service or not. That function call is not necessary. Attached patch has the details. Additional data: 1) Operating systems affected: all version of Windows. 2) OpenSSL versions affected: all versions running on Windows, starting Apr 7 2005. Thank you, Gunnar Kudrjavets -------------- next part -------------- >From 7693250e03ea284c2fb3a565cd3cbceeb2512943 Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Thu, 23 Apr 2015 13:22:49 -0700 Subject: [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow Currently function LIBEAY32!OPENSSL_isservice() calls GetDesktopWindow() to determine if the code is running as a service or not. There are a couple of issues with that: 1) That function call is not necessary and given that its result is ignored then it can be removed from the code. 2) It introduces an unnecessary dependency on whatever binary happens to host GetDesktopWindow() in some API Set on a particular version of Windows. Testing performed: 1) Clean compilation for debug-VC-WIN32 and VC-WIN32. 2) Good test results (nmake -f ms\ntdll.mak test) for debug-VC-WIN32 and VC-WIN32. 3) Stepped through relevant changes using WinDBG in cases when code was both running as part of the service and not. Verified that the existing behavior is maintained. The following OS-s were tested: Windows 8.1 Enterprise, Windows Server 2012 R2 Datacenter, and Windows XP Version 2002 (SP 3 aka 5.1.2600). The test cases consisted of: *) Running a console application and verifying that OPENSSL_isservice() returns 0 as expected. *) Running a service containing code from OPENSSL_isservice() and verifying that the function returns 1 as expected. The code to call GetDesktopWindow() was originally introduced as part of 9f2027e56d9e82dc89f079ed285d5571cbee5592. --- crypto/cryptlib.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/crypto/cryptlib.c b/crypto/cryptlib.c index ce07b84..be4cdb0 100644 --- a/crypto/cryptlib.c +++ b/crypto/cryptlib.c @@ -288,8 +288,6 @@ int OPENSSL_isservice(void) if (_OPENSSL_isservice.p != (void *)-1) return (*_OPENSSL_isservice.f) (); - (void)GetDesktopWindow(); /* return value is ignored */ - h = GetProcessWindowStation(); if (h == NULL) return -1; -- 1.9.5.msysgit.1 From rt at openssl.org Sat Apr 25 09:13:20 2015 From: rt at openssl.org (Jason.Kubicki@wellsfargo.com via RT) Date: Sat, 25 Apr 2015 11:13:20 +0200 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help 0.9.8 on windows - OpenSSL verify error. In-Reply-To: References: Message-ID: When I try to verify a SHA-2 certificate that chains up to a SHA-1 root I get error 20 at depth 0. If I leave the SHA-1 root off of the CAfile I get past depth 0. Verizon support was able to replicate this issue as well. We are trying to use OpenSSL verify to check our intermediate issuing CA (WellsSecure CA 01 G2) against the chain with the SHA-1 Baltimore Root at the top of the hierarchy. With the Baltimore root our chain looks like this: SHA-1 Baltimore root --> SHA-2 WellsSecure Public Root --> SHA-2 WellsSecure CA 01 G2 --> SHA-2 End-Entities With version 0.9.8 of OpenSSL we are seeing the following error: OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo/OU=WellsSecure Certification Authorities/CN=WellsSecure Certification Authority 01 G2 error 20 at 0 depth lookup:unable to get local issuer certificate I believe this error indicates that OpenSSL is unable to determine the issuer of our issuing intermediate CA. We only get this error when we try to verify the chain up to the SHA-1 Baltimore Root. It works in newer versions of OpenSSL and it works with our SHA-2 self-signed root and the cross-certificate from the SHA-2 Verizon Global root as seen below. With version 1.0.1 and 1.0.2 of OpenSSL we do not see the error. OpenSSL> version OpenSSL 1.0.1l 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL> version OpenSSL 1.0.2 22 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We do not see this issue in OpenSSL 0.9.8 if we validate the intermediate issuing CA against the existing Verizon Global root cross cert chain. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Verizon_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We also do not see the issue when we validate the intermediate issuing CA against our WellsSecure Public Root self-signed certificate. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\WellsSecure_Public_Root_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL 0.9.8 does not appear to support the -partial_chain command so we cannot test the intermediate issuing CA against just the cross-certificate as issued by the SHA-1 Baltimore root without error but the error is expected. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile "C:\test\WSPRCA CC from Baltimore.cer" C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certification Authority 01 G2 error 2 at 1 depth lookup:unable to get issuer certificate I believe this error means that OpenSSL was able to find the issuer of our issuing intermediate CA, which it could not do when the Baltimore root is present, and tie it to the cross-certificate issued by the Baltimore root. The reason this error is happening is that my CAfile for this test did not contain the Baltimore self-signed root. There appears to be some sort of issue that is causing OpenSSL 0.9.8 to be unable to validate our chain when the SHA-1 Baltimore self signed root is at the top of the chain. Have you encountered this error before with a mixed hierarchy or are you able to shed any light on what may be causing this issue? I am attaching PEM encoded versions of the files for your own testing and validation. Jason Kubicki, CISSP Information Security Analyst Cryptographic Services - Enterprise Key Management & Public Key Infrastructure | Wells Fargo -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIFCTCCA/GgAwIBAgIKYQyP4AAAAAAAAjANBgkqhkiG9w0BAQsFADCBjTELMAkG A1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJlMRwwGgYD VQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1NlY3VyZSBQ dWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAeFw0xMjEw MDEyMDQwMDVaFw0yMjEwMDEyMDUwMDVaMIGHMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLV2VsbHMgRmFyZ28xLjAsBgNVBAsTJVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXRpZXMxMjAwBgNVBAMTKVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1idl7QU1OQVGPn51Pb62YWCvWOVOWPm1zs4OKIMSq+zR5EiVs0ve7lLo5VP+ WV3c/Er6yOxXXV01ocnN9N6hmOWhVn5KyDATGNCM5nHMHHdQQbfCAzFVycW1TO9H rjw74B1P+4jjy+B0nMRie3XSGACXEb11bDuummHCLYEM+6VanCOx41eRSd8VDcEK cP6NUkS4tujEwZojiujP0h7t/Jf3rtey7ORWGkq/rj9AH7Lo23Gr6bxeu3o3Auzv UejLKfUjh4cA2eZWgDMiGIRW4f9V7ZY9P+jwevl2D619qGPlYMsRBfcZ36xJs03C pWRFZxjHWJ9+u/nb4knLxy8jHwIDAQABo4IBbTCCAWkwDgYDVR0PAQH/BAQDAgGG MB0GA1UdDgQWBBRZmgHl58Pm8yV48VrZqOnxcpSOMDBMBgNVHSAERTBDMEEGC2CG SAGG+3uDdAAAMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cud2VsbHNmYXJnby5j b20vcmVwb3NpdG9yeTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCHJ JdNq/qQS/+bdV1fPjz5yhAjNMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwu cGtpLndlbGxzZmFyZ28uY29tL3dzcHJjYTAxRzIuY3JsMHYGCCsGAQUFBwEBBGow aDA4BggrBgEFBQcwAoYsaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20vd3Nw cmNhMDFHMi5jcnQwLAYIKwYBBQUHMAGGIGh0dHA6Ly92YWxpZGF0b3Iud2VsbHNm YXJnby5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAd4xIa2AexQNSrmBK7RX5cFrh0 tFPydFSlXRo12TOvC0BexgvATrfuN6GPGemgt3nI/iTmNW+N4iw1phVnySyAr23Z nI8Hj73zy8Imyf42dfBIDN7dJFWKAU+sZRpFpuH358v0kBbbeZXQRLt/W4Ax0RJ9 TLbqIa3DiQ7tqo6LUvt7+yXH310YCu3722QGFXFfJmGmjmo5R+dL1vc5OQpNwpWo tfvKwpKHBXOCFqtzXU+X+IMbeSo6fajs5Qaqq1StCmzwCEYHiRQU8hyzUghcaMHF NDfxncSsdp2lgzAioW4ly0Qc8xzQlkUlSSHKv103SDDLJUVFPB4t82yCyDlK -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIQXCwtpvvXVopPgEL9qP3rJjANBgkqhkiG9w0BAQsFADCB jTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJl MRwwGgYDVQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1Nl Y3VyZSBQdWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAe Fw0xMjA4MDkxNjM2NDVaFw0zMDEyMjYxNjQ2MzNaMIGNMQswCQYDVQQGEwJVUzEg MB4GA1UEChMXV2VsbHMgRmFyZ28gV2VsbHNTZWN1cmUxHDAaBgNVBAsTE1dlbGxz IEZhcmdvIEJhbmsgTkExPjA8BgNVBAMTNVdlbGxzU2VjdXJlIFB1YmxpYyBSb290 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwyWEb3XDCHkxFHAv0geLGyu5Ao0guOzJ+S4atX73DJUc x9qNric9AxqppOpwiThrd45xOhlAjKmzFPwB7Fti2IpnvXT2eFdJ53SATQrXDLM3 RntUn1xBYvIuDifZT4hcuBUa2VvZMJ3Aqag2tdeULyptO19o6yN3Vs4IP/6Y3nuX 8diTmRFCCYUGWwdb9Pkkk9Z6vc//AT6P0/8cvVI7MREroqyvwJHslOf0VAmMB2gN icZ1ub42Zm0jmiZDjbX/gikaU/X3IIJQJBX8t1JGdUdpAwtL1QPvsTx+Hjxk0i2B o2j0VFrXtkFn4u6TTgcoAyVfvFhqGhGHg1+EZd3TFQIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUIckl02r+pBL/5t1X V8+PPnKECM0wDQYJKoZIhvcNAQELBQADggEBAArE2ntHUGAvYnFg+yWyyCGyui4a YxW+/SR6HI7lr2AZD29yHWLwh8GuPufUesF30mluNZ46GSWZWMrGtvViK4UJAgnf EwvFUo8rEjug+o9EqIormGCHwgbAzNsaXjGi+L5oKbdB64E96EOY1zOH7zUWidaL mWbECjNWzFmuPMeLwAEVkhy7pNyfmvgEdRnquBkSInGX8OAmrWDERyEsQfwWI+sE HC0F6n7eE4QtaItigOdnwzGafqicKT/xQIFJJ0dP8tb4lqjhlqo3Q+j7oore26FH 4K1RoQNutEB2TJM7IbQRx+lKSWDwXResA3FLrQjVeGjNZxomzljPjzjRG2c= -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEZ MBcGA1UECgwQVmVyaXpvbiBCdXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAd BgNVBAMMFlZlcml6b24gR2xvYmFsIFJvb3QgQ0EwHhcNMDkwNzMwMTQyNzA0WhcN MzQwNzMwMTQyNzA0WjBcMQswCQYDVQQGEwJVUzEZMBcGA1UECgwQVmVyaXpvbiBC dXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAdBgNVBAMMFlZlcml6b24gR2xv YmFsIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKAAxw Hb/rNIbDmUU1Hn9D96tvJC3NGcIQu7DKKVupIKurcizE4gI5bYK4xRHq+PuznmL4 Mx6wH8nj9jfbBMg7Y0824oWkJR3HaR8EvWhFE5YHH5RQ9T7FJ1SewElXRI4HY9Sm ru0imcxNlmkEE252iZ90FpT5HVS9ornSgwEiDE1EgKr+NYknJaeGicbVGpLjj8WV oBRymuhWxQJVHJf5IC7Q9TwTGVr24fkLA4Jpp4y31m+cVj6d6CoJYG1L5vuLmRT3 NE9lWYCNuVfIojUh2IhxVl3uglctJpAYn5qcnI/v1MVjp1R9R5GHfRoSqBsYb6lv sSe65AR0zjcef2bFAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRMOBG4mABbWitwPqp45NVnZ2enfjANBgkqhkiG9w0B AQsFAAOCAQEAAV+gsQYB9HnXZRhgPs95oLrCI08j34eWX4EOOBUuXMgCaCkg/Ivu pYoYgWRcmDV+OTCCpIKKULW6w+ha1qie4sMX29vE67AKIA3pnuP/YFRH8Tud1Cg8 oq6j+6qLgiIqNYeQuBxZR5DVnS76SeNlqDbrx+QcaNyzMWyrTs4kgBXIEFkQEXJN epyYnMT8YeCzsp1OoMbCWasY1qJVRewpqiU31k5KPQtAweST5PzNkQv45qvMs3bE Yr8Z7Ya2ecMpVFS8mX1GV8+mz/RUKpoDZUcBoUIqyyVHbnxeAEuR2fkbEAZw+UIV pl+q10Ae/clInZeB6lxowqDniaFTTb/H4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgICBFAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx GTAXBgNVBAoMEFZlcml6b24gQnVzaW5lc3MxETAPBgNVBAsMCE9tbmlSb290MR8w HQYDVQQDDBZWZXJpem9uIEdsb2JhbCBSb290IENBMB4XDTEzMDEzMDE3MzQwNFoX DTIzMDEzMDE3MzI1OVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggEAMIH9MBIGA1UdEwEB/wQIMAYBAf8CAQEw UwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5BggrBgEFBQcCARYtaHR0cDovL2N5 YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkuY2ZtMA4GA1UdDwEB/wQE AwIB5jAfBgNVHSMEGDAWgBRMOBG4mABbWitwPqp45NVnZ2enfjBCBgNVHR8EOzA5 MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1c3QuY29tL0NSTC9PbW5pcm9v dDIwMzQuY3JsMB0GA1UdDgQWBBQhySXTav6kEv/m3VdXz48+coQIzTANBgkqhkiG 9w0BAQsFAAOCAQEAJMU82S8OjWhmtDAVv4Ii+PpMQibfZtVqZ70kHVf+pYHpJ/YI e6ncRd7uKWYdU+0MaJ8SSZytnFQa2M4T/Dsp5bFpsMyDvp/LpyP9idEtVNwCTzfN uhTTTa7K8RA6oB1s8zG3r37zgSYZ3g+A7iXnUwwGo+NjH3YfggOmv4If668dABlI 2dEQjOkH4hl0a2RU1ytmoCCOj4fvXFa+YEWQG3Liy38b1N+UdqlYC+GFP+rlHGTF /WkJiKReAyq9xy74ipom7jaS73IzS7TEK1n5GGz7Dt+Bz2PGT06M0oGFsG4j1WbA JIKp29kbvaFrVVAhTZaq4+mMkL2gm//boC+qrg== -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- From chenyt at cs.sjtu.edu.cn Sat Apr 25 17:52:15 2015 From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=) Date: Sat, 25 Apr 2015 10:52:15 -0700 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. In-Reply-To: References: Message-ID: <5600F25AA8F94001A03DFBD37F35B91A@sjtu.edu.cn> Are the AKID(s) of the target certificates same as SKID(s) of the issuers? As what I have observed and reported, OpenSSL cannot tackle such kind of problems. Yuting -----Original Message----- From: Jason.Kubicki at wellsfargo.com via RT Sent: Saturday, April 25, 2015 2:13 AM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. When I try to verify a SHA-2 certificate that chains up to a SHA-1 root I get error 20 at depth 0. If I leave the SHA-1 root off of the CAfile I get past depth 0. Verizon support was able to replicate this issue as well. We are trying to use OpenSSL verify to check our intermediate issuing CA (WellsSecure CA 01 G2) against the chain with the SHA-1 Baltimore Root at the top of the hierarchy. With the Baltimore root our chain looks like this: SHA-1 Baltimore root --> SHA-2 WellsSecure Public Root --> SHA-2 WellsSecure CA 01 G2 --> SHA-2 End-Entities With version 0.9.8 of OpenSSL we are seeing the following error: OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo/OU=WellsSecure Certification Authorities/CN=WellsSecure Certification Authority 01 G2 error 20 at 0 depth lookup:unable to get local issuer certificate I believe this error indicates that OpenSSL is unable to determine the issuer of our issuing intermediate CA. We only get this error when we try to verify the chain up to the SHA-1 Baltimore Root. It works in newer versions of OpenSSL and it works with our SHA-2 self-signed root and the cross-certificate from the SHA-2 Verizon Global root as seen below. With version 1.0.1 and 1.0.2 of OpenSSL we do not see the error. OpenSSL> version OpenSSL 1.0.1l 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL> version OpenSSL 1.0.2 22 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We do not see this issue in OpenSSL 0.9.8 if we validate the intermediate issuing CA against the existing Verizon Global root cross cert chain. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Verizon_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We also do not see the issue when we validate the intermediate issuing CA against our WellsSecure Public Root self-signed certificate. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\WellsSecure_Public_Root_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL 0.9.8 does not appear to support the -partial_chain command so we cannot test the intermediate issuing CA against just the cross-certificate as issued by the SHA-1 Baltimore root without error but the error is expected. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile "C:\test\WSPRCA CC from Baltimore.cer" C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certification Authority 01 G2 error 2 at 1 depth lookup:unable to get issuer certificate I believe this error means that OpenSSL was able to find the issuer of our issuing intermediate CA, which it could not do when the Baltimore root is present, and tie it to the cross-certificate issued by the Baltimore root. The reason this error is happening is that my CAfile for this test did not contain the Baltimore self-signed root. There appears to be some sort of issue that is causing OpenSSL 0.9.8 to be unable to validate our chain when the SHA-1 Baltimore self signed root is at the top of the chain. Have you encountered this error before with a mixed hierarchy or are you able to shed any light on what may be causing this issue? I am attaching PEM encoded versions of the files for your own testing and validation. Jason Kubicki, CISSP Information Security Analyst Cryptographic Services - Enterprise Key Management & Public Key Infrastructure | Wells Fargo -----BEGIN CERTIFICATE----- MIIFCTCCA/GgAwIBAgIKYQyP4AAAAAAAAjANBgkqhkiG9w0BAQsFADCBjTELMAkG A1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJlMRwwGgYD VQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1NlY3VyZSBQ dWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAeFw0xMjEw MDEyMDQwMDVaFw0yMjEwMDEyMDUwMDVaMIGHMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLV2VsbHMgRmFyZ28xLjAsBgNVBAsTJVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXRpZXMxMjAwBgNVBAMTKVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1idl7QU1OQVGPn51Pb62YWCvWOVOWPm1zs4OKIMSq+zR5EiVs0ve7lLo5VP+ WV3c/Er6yOxXXV01ocnN9N6hmOWhVn5KyDATGNCM5nHMHHdQQbfCAzFVycW1TO9H rjw74B1P+4jjy+B0nMRie3XSGACXEb11bDuummHCLYEM+6VanCOx41eRSd8VDcEK cP6NUkS4tujEwZojiujP0h7t/Jf3rtey7ORWGkq/rj9AH7Lo23Gr6bxeu3o3Auzv UejLKfUjh4cA2eZWgDMiGIRW4f9V7ZY9P+jwevl2D619qGPlYMsRBfcZ36xJs03C pWRFZxjHWJ9+u/nb4knLxy8jHwIDAQABo4IBbTCCAWkwDgYDVR0PAQH/BAQDAgGG MB0GA1UdDgQWBBRZmgHl58Pm8yV48VrZqOnxcpSOMDBMBgNVHSAERTBDMEEGC2CG SAGG+3uDdAAAMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cud2VsbHNmYXJnby5j b20vcmVwb3NpdG9yeTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCHJ JdNq/qQS/+bdV1fPjz5yhAjNMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwu cGtpLndlbGxzZmFyZ28uY29tL3dzcHJjYTAxRzIuY3JsMHYGCCsGAQUFBwEBBGow aDA4BggrBgEFBQcwAoYsaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20vd3Nw cmNhMDFHMi5jcnQwLAYIKwYBBQUHMAGGIGh0dHA6Ly92YWxpZGF0b3Iud2VsbHNm YXJnby5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAd4xIa2AexQNSrmBK7RX5cFrh0 tFPydFSlXRo12TOvC0BexgvATrfuN6GPGemgt3nI/iTmNW+N4iw1phVnySyAr23Z nI8Hj73zy8Imyf42dfBIDN7dJFWKAU+sZRpFpuH358v0kBbbeZXQRLt/W4Ax0RJ9 TLbqIa3DiQ7tqo6LUvt7+yXH310YCu3722QGFXFfJmGmjmo5R+dL1vc5OQpNwpWo tfvKwpKHBXOCFqtzXU+X+IMbeSo6fajs5Qaqq1StCmzwCEYHiRQU8hyzUghcaMHF NDfxncSsdp2lgzAioW4ly0Qc8xzQlkUlSSHKv103SDDLJUVFPB4t82yCyDlK -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIQXCwtpvvXVopPgEL9qP3rJjANBgkqhkiG9w0BAQsFADCB jTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJl MRwwGgYDVQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1Nl Y3VyZSBQdWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAe Fw0xMjA4MDkxNjM2NDVaFw0zMDEyMjYxNjQ2MzNaMIGNMQswCQYDVQQGEwJVUzEg MB4GA1UEChMXV2VsbHMgRmFyZ28gV2VsbHNTZWN1cmUxHDAaBgNVBAsTE1dlbGxz IEZhcmdvIEJhbmsgTkExPjA8BgNVBAMTNVdlbGxzU2VjdXJlIFB1YmxpYyBSb290 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwyWEb3XDCHkxFHAv0geLGyu5Ao0guOzJ+S4atX73DJUc x9qNric9AxqppOpwiThrd45xOhlAjKmzFPwB7Fti2IpnvXT2eFdJ53SATQrXDLM3 RntUn1xBYvIuDifZT4hcuBUa2VvZMJ3Aqag2tdeULyptO19o6yN3Vs4IP/6Y3nuX 8diTmRFCCYUGWwdb9Pkkk9Z6vc//AT6P0/8cvVI7MREroqyvwJHslOf0VAmMB2gN icZ1ub42Zm0jmiZDjbX/gikaU/X3IIJQJBX8t1JGdUdpAwtL1QPvsTx+Hjxk0i2B o2j0VFrXtkFn4u6TTgcoAyVfvFhqGhGHg1+EZd3TFQIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUIckl02r+pBL/5t1X V8+PPnKECM0wDQYJKoZIhvcNAQELBQADggEBAArE2ntHUGAvYnFg+yWyyCGyui4a YxW+/SR6HI7lr2AZD29yHWLwh8GuPufUesF30mluNZ46GSWZWMrGtvViK4UJAgnf EwvFUo8rEjug+o9EqIormGCHwgbAzNsaXjGi+L5oKbdB64E96EOY1zOH7zUWidaL mWbECjNWzFmuPMeLwAEVkhy7pNyfmvgEdRnquBkSInGX8OAmrWDERyEsQfwWI+sE HC0F6n7eE4QtaItigOdnwzGafqicKT/xQIFJJ0dP8tb4lqjhlqo3Q+j7oore26FH 4K1RoQNutEB2TJM7IbQRx+lKSWDwXResA3FLrQjVeGjNZxomzljPjzjRG2c= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEZ MBcGA1UECgwQVmVyaXpvbiBCdXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAd BgNVBAMMFlZlcml6b24gR2xvYmFsIFJvb3QgQ0EwHhcNMDkwNzMwMTQyNzA0WhcN MzQwNzMwMTQyNzA0WjBcMQswCQYDVQQGEwJVUzEZMBcGA1UECgwQVmVyaXpvbiBC dXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAdBgNVBAMMFlZlcml6b24gR2xv YmFsIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKAAxw Hb/rNIbDmUU1Hn9D96tvJC3NGcIQu7DKKVupIKurcizE4gI5bYK4xRHq+PuznmL4 Mx6wH8nj9jfbBMg7Y0824oWkJR3HaR8EvWhFE5YHH5RQ9T7FJ1SewElXRI4HY9Sm ru0imcxNlmkEE252iZ90FpT5HVS9ornSgwEiDE1EgKr+NYknJaeGicbVGpLjj8WV oBRymuhWxQJVHJf5IC7Q9TwTGVr24fkLA4Jpp4y31m+cVj6d6CoJYG1L5vuLmRT3 NE9lWYCNuVfIojUh2IhxVl3uglctJpAYn5qcnI/v1MVjp1R9R5GHfRoSqBsYb6lv sSe65AR0zjcef2bFAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRMOBG4mABbWitwPqp45NVnZ2enfjANBgkqhkiG9w0B AQsFAAOCAQEAAV+gsQYB9HnXZRhgPs95oLrCI08j34eWX4EOOBUuXMgCaCkg/Ivu pYoYgWRcmDV+OTCCpIKKULW6w+ha1qie4sMX29vE67AKIA3pnuP/YFRH8Tud1Cg8 oq6j+6qLgiIqNYeQuBxZR5DVnS76SeNlqDbrx+QcaNyzMWyrTs4kgBXIEFkQEXJN epyYnMT8YeCzsp1OoMbCWasY1qJVRewpqiU31k5KPQtAweST5PzNkQv45qvMs3bE Yr8Z7Ya2ecMpVFS8mX1GV8+mz/RUKpoDZUcBoUIqyyVHbnxeAEuR2fkbEAZw+UIV pl+q10Ae/clInZeB6lxowqDniaFTTb/H4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgICBFAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx GTAXBgNVBAoMEFZlcml6b24gQnVzaW5lc3MxETAPBgNVBAsMCE9tbmlSb290MR8w HQYDVQQDDBZWZXJpem9uIEdsb2JhbCBSb290IENBMB4XDTEzMDEzMDE3MzQwNFoX DTIzMDEzMDE3MzI1OVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggEAMIH9MBIGA1UdEwEB/wQIMAYBAf8CAQEw UwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5BggrBgEFBQcCARYtaHR0cDovL2N5 YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkuY2ZtMA4GA1UdDwEB/wQE AwIB5jAfBgNVHSMEGDAWgBRMOBG4mABbWitwPqp45NVnZ2enfjBCBgNVHR8EOzA5 MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1c3QuY29tL0NSTC9PbW5pcm9v dDIwMzQuY3JsMB0GA1UdDgQWBBQhySXTav6kEv/m3VdXz48+coQIzTANBgkqhkiG 9w0BAQsFAAOCAQEAJMU82S8OjWhmtDAVv4Ii+PpMQibfZtVqZ70kHVf+pYHpJ/YI e6ncRd7uKWYdU+0MaJ8SSZytnFQa2M4T/Dsp5bFpsMyDvp/LpyP9idEtVNwCTzfN uhTTTa7K8RA6oB1s8zG3r37zgSYZ3g+A7iXnUwwGo+NjH3YfggOmv4If668dABlI 2dEQjOkH4hl0a2RU1ytmoCCOj4fvXFa+YEWQG3Liy38b1N+UdqlYC+GFP+rlHGTF /WkJiKReAyq9xy74ipom7jaS73IzS7TEK1n5GGz7Dt+Bz2PGT06M0oGFsG4j1WbA JIKp29kbvaFrVVAhTZaq4+mMkL2gm//boC+qrg== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sat Apr 25 17:59:19 2015 From: rt at openssl.org (=?UTF-8?B?6ZmI6Zuo5Lqt?= via RT) Date: Sat, 25 Apr 2015 19:59:19 +0200 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. In-Reply-To: <5600F25AA8F94001A03DFBD37F35B91A@sjtu.edu.cn> References: <5600F25AA8F94001A03DFBD37F35B91A@sjtu.edu.cn> Message-ID: Are the AKID(s) of the target certificates same as SKID(s) of the issuers? As what I have observed and reported, OpenSSL cannot tackle such kind of problems. Yuting -----Original Message----- From: Jason.Kubicki at wellsfargo.com via RT Sent: Saturday, April 25, 2015 2:13 AM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. When I try to verify a SHA-2 certificate that chains up to a SHA-1 root I get error 20 at depth 0. If I leave the SHA-1 root off of the CAfile I get past depth 0. Verizon support was able to replicate this issue as well. We are trying to use OpenSSL verify to check our intermediate issuing CA (WellsSecure CA 01 G2) against the chain with the SHA-1 Baltimore Root at the top of the hierarchy. With the Baltimore root our chain looks like this: SHA-1 Baltimore root --> SHA-2 WellsSecure Public Root --> SHA-2 WellsSecure CA 01 G2 --> SHA-2 End-Entities With version 0.9.8 of OpenSSL we are seeing the following error: OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo/OU=WellsSecure Certification Authorities/CN=WellsSecure Certification Authority 01 G2 error 20 at 0 depth lookup:unable to get local issuer certificate I believe this error indicates that OpenSSL is unable to determine the issuer of our issuing intermediate CA. We only get this error when we try to verify the chain up to the SHA-1 Baltimore Root. It works in newer versions of OpenSSL and it works with our SHA-2 self-signed root and the cross-certificate from the SHA-2 Verizon Global root as seen below. With version 1.0.1 and 1.0.2 of OpenSSL we do not see the error. OpenSSL> version OpenSSL 1.0.1l 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL> version OpenSSL 1.0.2 22 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We do not see this issue in OpenSSL 0.9.8 if we validate the intermediate issuing CA against the existing Verizon Global root cross cert chain. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Verizon_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We also do not see the issue when we validate the intermediate issuing CA against our WellsSecure Public Root self-signed certificate. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\WellsSecure_Public_Root_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL 0.9.8 does not appear to support the -partial_chain command so we cannot test the intermediate issuing CA against just the cross-certificate as issued by the SHA-1 Baltimore root without error but the error is expected. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile "C:\test\WSPRCA CC from Baltimore.cer" C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certification Authority 01 G2 error 2 at 1 depth lookup:unable to get issuer certificate I believe this error means that OpenSSL was able to find the issuer of our issuing intermediate CA, which it could not do when the Baltimore root is present, and tie it to the cross-certificate issued by the Baltimore root. The reason this error is happening is that my CAfile for this test did not contain the Baltimore self-signed root. There appears to be some sort of issue that is causing OpenSSL 0.9.8 to be unable to validate our chain when the SHA-1 Baltimore self signed root is at the top of the chain. Have you encountered this error before with a mixed hierarchy or are you able to shed any light on what may be causing this issue? I am attaching PEM encoded versions of the files for your own testing and validation. Jason Kubicki, CISSP Information Security Analyst Cryptographic Services - Enterprise Key Management & Public Key Infrastructure | Wells Fargo -----BEGIN CERTIFICATE----- MIIFCTCCA/GgAwIBAgIKYQyP4AAAAAAAAjANBgkqhkiG9w0BAQsFADCBjTELMAkG A1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJlMRwwGgYD VQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1NlY3VyZSBQ dWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAeFw0xMjEw MDEyMDQwMDVaFw0yMjEwMDEyMDUwMDVaMIGHMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLV2VsbHMgRmFyZ28xLjAsBgNVBAsTJVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXRpZXMxMjAwBgNVBAMTKVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1idl7QU1OQVGPn51Pb62YWCvWOVOWPm1zs4OKIMSq+zR5EiVs0ve7lLo5VP+ WV3c/Er6yOxXXV01ocnN9N6hmOWhVn5KyDATGNCM5nHMHHdQQbfCAzFVycW1TO9H rjw74B1P+4jjy+B0nMRie3XSGACXEb11bDuummHCLYEM+6VanCOx41eRSd8VDcEK cP6NUkS4tujEwZojiujP0h7t/Jf3rtey7ORWGkq/rj9AH7Lo23Gr6bxeu3o3Auzv UejLKfUjh4cA2eZWgDMiGIRW4f9V7ZY9P+jwevl2D619qGPlYMsRBfcZ36xJs03C pWRFZxjHWJ9+u/nb4knLxy8jHwIDAQABo4IBbTCCAWkwDgYDVR0PAQH/BAQDAgGG MB0GA1UdDgQWBBRZmgHl58Pm8yV48VrZqOnxcpSOMDBMBgNVHSAERTBDMEEGC2CG SAGG+3uDdAAAMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cud2VsbHNmYXJnby5j b20vcmVwb3NpdG9yeTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCHJ JdNq/qQS/+bdV1fPjz5yhAjNMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwu cGtpLndlbGxzZmFyZ28uY29tL3dzcHJjYTAxRzIuY3JsMHYGCCsGAQUFBwEBBGow aDA4BggrBgEFBQcwAoYsaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20vd3Nw cmNhMDFHMi5jcnQwLAYIKwYBBQUHMAGGIGh0dHA6Ly92YWxpZGF0b3Iud2VsbHNm YXJnby5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAd4xIa2AexQNSrmBK7RX5cFrh0 tFPydFSlXRo12TOvC0BexgvATrfuN6GPGemgt3nI/iTmNW+N4iw1phVnySyAr23Z nI8Hj73zy8Imyf42dfBIDN7dJFWKAU+sZRpFpuH358v0kBbbeZXQRLt/W4Ax0RJ9 TLbqIa3DiQ7tqo6LUvt7+yXH310YCu3722QGFXFfJmGmjmo5R+dL1vc5OQpNwpWo tfvKwpKHBXOCFqtzXU+X+IMbeSo6fajs5Qaqq1StCmzwCEYHiRQU8hyzUghcaMHF NDfxncSsdp2lgzAioW4ly0Qc8xzQlkUlSSHKv103SDDLJUVFPB4t82yCyDlK -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIQXCwtpvvXVopPgEL9qP3rJjANBgkqhkiG9w0BAQsFADCB jTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJl MRwwGgYDVQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1Nl Y3VyZSBQdWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAe Fw0xMjA4MDkxNjM2NDVaFw0zMDEyMjYxNjQ2MzNaMIGNMQswCQYDVQQGEwJVUzEg MB4GA1UEChMXV2VsbHMgRmFyZ28gV2VsbHNTZWN1cmUxHDAaBgNVBAsTE1dlbGxz IEZhcmdvIEJhbmsgTkExPjA8BgNVBAMTNVdlbGxzU2VjdXJlIFB1YmxpYyBSb290 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwyWEb3XDCHkxFHAv0geLGyu5Ao0guOzJ+S4atX73DJUc x9qNric9AxqppOpwiThrd45xOhlAjKmzFPwB7Fti2IpnvXT2eFdJ53SATQrXDLM3 RntUn1xBYvIuDifZT4hcuBUa2VvZMJ3Aqag2tdeULyptO19o6yN3Vs4IP/6Y3nuX 8diTmRFCCYUGWwdb9Pkkk9Z6vc//AT6P0/8cvVI7MREroqyvwJHslOf0VAmMB2gN icZ1ub42Zm0jmiZDjbX/gikaU/X3IIJQJBX8t1JGdUdpAwtL1QPvsTx+Hjxk0i2B o2j0VFrXtkFn4u6TTgcoAyVfvFhqGhGHg1+EZd3TFQIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUIckl02r+pBL/5t1X V8+PPnKECM0wDQYJKoZIhvcNAQELBQADggEBAArE2ntHUGAvYnFg+yWyyCGyui4a YxW+/SR6HI7lr2AZD29yHWLwh8GuPufUesF30mluNZ46GSWZWMrGtvViK4UJAgnf EwvFUo8rEjug+o9EqIormGCHwgbAzNsaXjGi+L5oKbdB64E96EOY1zOH7zUWidaL mWbECjNWzFmuPMeLwAEVkhy7pNyfmvgEdRnquBkSInGX8OAmrWDERyEsQfwWI+sE HC0F6n7eE4QtaItigOdnwzGafqicKT/xQIFJJ0dP8tb4lqjhlqo3Q+j7oore26FH 4K1RoQNutEB2TJM7IbQRx+lKSWDwXResA3FLrQjVeGjNZxomzljPjzjRG2c= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEZ MBcGA1UECgwQVmVyaXpvbiBCdXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAd BgNVBAMMFlZlcml6b24gR2xvYmFsIFJvb3QgQ0EwHhcNMDkwNzMwMTQyNzA0WhcN MzQwNzMwMTQyNzA0WjBcMQswCQYDVQQGEwJVUzEZMBcGA1UECgwQVmVyaXpvbiBC dXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAdBgNVBAMMFlZlcml6b24gR2xv YmFsIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKAAxw Hb/rNIbDmUU1Hn9D96tvJC3NGcIQu7DKKVupIKurcizE4gI5bYK4xRHq+PuznmL4 Mx6wH8nj9jfbBMg7Y0824oWkJR3HaR8EvWhFE5YHH5RQ9T7FJ1SewElXRI4HY9Sm ru0imcxNlmkEE252iZ90FpT5HVS9ornSgwEiDE1EgKr+NYknJaeGicbVGpLjj8WV oBRymuhWxQJVHJf5IC7Q9TwTGVr24fkLA4Jpp4y31m+cVj6d6CoJYG1L5vuLmRT3 NE9lWYCNuVfIojUh2IhxVl3uglctJpAYn5qcnI/v1MVjp1R9R5GHfRoSqBsYb6lv sSe65AR0zjcef2bFAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRMOBG4mABbWitwPqp45NVnZ2enfjANBgkqhkiG9w0B AQsFAAOCAQEAAV+gsQYB9HnXZRhgPs95oLrCI08j34eWX4EOOBUuXMgCaCkg/Ivu pYoYgWRcmDV+OTCCpIKKULW6w+ha1qie4sMX29vE67AKIA3pnuP/YFRH8Tud1Cg8 oq6j+6qLgiIqNYeQuBxZR5DVnS76SeNlqDbrx+QcaNyzMWyrTs4kgBXIEFkQEXJN epyYnMT8YeCzsp1OoMbCWasY1qJVRewpqiU31k5KPQtAweST5PzNkQv45qvMs3bE Yr8Z7Ya2ecMpVFS8mX1GV8+mz/RUKpoDZUcBoUIqyyVHbnxeAEuR2fkbEAZw+UIV pl+q10Ae/clInZeB6lxowqDniaFTTb/H4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgICBFAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx GTAXBgNVBAoMEFZlcml6b24gQnVzaW5lc3MxETAPBgNVBAsMCE9tbmlSb290MR8w HQYDVQQDDBZWZXJpem9uIEdsb2JhbCBSb290IENBMB4XDTEzMDEzMDE3MzQwNFoX DTIzMDEzMDE3MzI1OVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggEAMIH9MBIGA1UdEwEB/wQIMAYBAf8CAQEw UwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5BggrBgEFBQcCARYtaHR0cDovL2N5 YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkuY2ZtMA4GA1UdDwEB/wQE AwIB5jAfBgNVHSMEGDAWgBRMOBG4mABbWitwPqp45NVnZ2enfjBCBgNVHR8EOzA5 MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1c3QuY29tL0NSTC9PbW5pcm9v dDIwMzQuY3JsMB0GA1UdDgQWBBQhySXTav6kEv/m3VdXz48+coQIzTANBgkqhkiG 9w0BAQsFAAOCAQEAJMU82S8OjWhmtDAVv4Ii+PpMQibfZtVqZ70kHVf+pYHpJ/YI e6ncRd7uKWYdU+0MaJ8SSZytnFQa2M4T/Dsp5bFpsMyDvp/LpyP9idEtVNwCTzfN uhTTTa7K8RA6oB1s8zG3r37zgSYZ3g+A7iXnUwwGo+NjH3YfggOmv4If668dABlI 2dEQjOkH4hl0a2RU1ytmoCCOj4fvXFa+YEWQG3Liy38b1N+UdqlYC+GFP+rlHGTF /WkJiKReAyq9xy74ipom7jaS73IzS7TEK1n5GGz7Dt+Bz2PGT06M0oGFsG4j1WbA JIKp29kbvaFrVVAhTZaq4+mMkL2gm//boC+qrg== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From chenyt at cs.sjtu.edu.cn Sat Apr 25 18:32:34 2015 From: chenyt at cs.sjtu.edu.cn (=?UTF-8?B?6ZmI6Zuo5Lqt?=) Date: Sat, 25 Apr 2015 11:32:34 -0700 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. In-Reply-To: References: Message-ID: <1327BDB0DB7D48A8B7CDF698DCC38C8D@sjtu.edu.cn> Quickly check the contents, and in CAfile_Baltimore_root, the value of Basic Constraints: CA: TRUE, pathlen: 1 That can be one reason. Yuting Chen -----Original Message----- From: Jason.Kubicki at wellsfargo.com via RT Sent: Saturday, April 25, 2015 2:13 AM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. When I try to verify a SHA-2 certificate that chains up to a SHA-1 root I get error 20 at depth 0. If I leave the SHA-1 root off of the CAfile I get past depth 0. Verizon support was able to replicate this issue as well. We are trying to use OpenSSL verify to check our intermediate issuing CA (WellsSecure CA 01 G2) against the chain with the SHA-1 Baltimore Root at the top of the hierarchy. With the Baltimore root our chain looks like this: SHA-1 Baltimore root --> SHA-2 WellsSecure Public Root --> SHA-2 WellsSecure CA 01 G2 --> SHA-2 End-Entities With version 0.9.8 of OpenSSL we are seeing the following error: OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo/OU=WellsSecure Certification Authorities/CN=WellsSecure Certification Authority 01 G2 error 20 at 0 depth lookup:unable to get local issuer certificate I believe this error indicates that OpenSSL is unable to determine the issuer of our issuing intermediate CA. We only get this error when we try to verify the chain up to the SHA-1 Baltimore Root. It works in newer versions of OpenSSL and it works with our SHA-2 self-signed root and the cross-certificate from the SHA-2 Verizon Global root as seen below. With version 1.0.1 and 1.0.2 of OpenSSL we do not see the error. OpenSSL> version OpenSSL 1.0.1l 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL> version OpenSSL 1.0.2 22 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We do not see this issue in OpenSSL 0.9.8 if we validate the intermediate issuing CA against the existing Verizon Global root cross cert chain. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Verizon_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We also do not see the issue when we validate the intermediate issuing CA against our WellsSecure Public Root self-signed certificate. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\WellsSecure_Public_Root_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL 0.9.8 does not appear to support the -partial_chain command so we cannot test the intermediate issuing CA against just the cross-certificate as issued by the SHA-1 Baltimore root without error but the error is expected. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile "C:\test\WSPRCA CC from Baltimore.cer" C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certification Authority 01 G2 error 2 at 1 depth lookup:unable to get issuer certificate I believe this error means that OpenSSL was able to find the issuer of our issuing intermediate CA, which it could not do when the Baltimore root is present, and tie it to the cross-certificate issued by the Baltimore root. The reason this error is happening is that my CAfile for this test did not contain the Baltimore self-signed root. There appears to be some sort of issue that is causing OpenSSL 0.9.8 to be unable to validate our chain when the SHA-1 Baltimore self signed root is at the top of the chain. Have you encountered this error before with a mixed hierarchy or are you able to shed any light on what may be causing this issue? I am attaching PEM encoded versions of the files for your own testing and validation. Jason Kubicki, CISSP Information Security Analyst Cryptographic Services - Enterprise Key Management & Public Key Infrastructure | Wells Fargo -----BEGIN CERTIFICATE----- MIIFCTCCA/GgAwIBAgIKYQyP4AAAAAAAAjANBgkqhkiG9w0BAQsFADCBjTELMAkG A1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJlMRwwGgYD VQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1NlY3VyZSBQ dWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAeFw0xMjEw MDEyMDQwMDVaFw0yMjEwMDEyMDUwMDVaMIGHMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLV2VsbHMgRmFyZ28xLjAsBgNVBAsTJVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXRpZXMxMjAwBgNVBAMTKVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1idl7QU1OQVGPn51Pb62YWCvWOVOWPm1zs4OKIMSq+zR5EiVs0ve7lLo5VP+ WV3c/Er6yOxXXV01ocnN9N6hmOWhVn5KyDATGNCM5nHMHHdQQbfCAzFVycW1TO9H rjw74B1P+4jjy+B0nMRie3XSGACXEb11bDuummHCLYEM+6VanCOx41eRSd8VDcEK cP6NUkS4tujEwZojiujP0h7t/Jf3rtey7ORWGkq/rj9AH7Lo23Gr6bxeu3o3Auzv UejLKfUjh4cA2eZWgDMiGIRW4f9V7ZY9P+jwevl2D619qGPlYMsRBfcZ36xJs03C pWRFZxjHWJ9+u/nb4knLxy8jHwIDAQABo4IBbTCCAWkwDgYDVR0PAQH/BAQDAgGG MB0GA1UdDgQWBBRZmgHl58Pm8yV48VrZqOnxcpSOMDBMBgNVHSAERTBDMEEGC2CG SAGG+3uDdAAAMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cud2VsbHNmYXJnby5j b20vcmVwb3NpdG9yeTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCHJ JdNq/qQS/+bdV1fPjz5yhAjNMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwu cGtpLndlbGxzZmFyZ28uY29tL3dzcHJjYTAxRzIuY3JsMHYGCCsGAQUFBwEBBGow aDA4BggrBgEFBQcwAoYsaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20vd3Nw cmNhMDFHMi5jcnQwLAYIKwYBBQUHMAGGIGh0dHA6Ly92YWxpZGF0b3Iud2VsbHNm YXJnby5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAd4xIa2AexQNSrmBK7RX5cFrh0 tFPydFSlXRo12TOvC0BexgvATrfuN6GPGemgt3nI/iTmNW+N4iw1phVnySyAr23Z nI8Hj73zy8Imyf42dfBIDN7dJFWKAU+sZRpFpuH358v0kBbbeZXQRLt/W4Ax0RJ9 TLbqIa3DiQ7tqo6LUvt7+yXH310YCu3722QGFXFfJmGmjmo5R+dL1vc5OQpNwpWo tfvKwpKHBXOCFqtzXU+X+IMbeSo6fajs5Qaqq1StCmzwCEYHiRQU8hyzUghcaMHF NDfxncSsdp2lgzAioW4ly0Qc8xzQlkUlSSHKv103SDDLJUVFPB4t82yCyDlK -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIQXCwtpvvXVopPgEL9qP3rJjANBgkqhkiG9w0BAQsFADCB jTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJl MRwwGgYDVQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1Nl Y3VyZSBQdWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAe Fw0xMjA4MDkxNjM2NDVaFw0zMDEyMjYxNjQ2MzNaMIGNMQswCQYDVQQGEwJVUzEg MB4GA1UEChMXV2VsbHMgRmFyZ28gV2VsbHNTZWN1cmUxHDAaBgNVBAsTE1dlbGxz IEZhcmdvIEJhbmsgTkExPjA8BgNVBAMTNVdlbGxzU2VjdXJlIFB1YmxpYyBSb290 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwyWEb3XDCHkxFHAv0geLGyu5Ao0guOzJ+S4atX73DJUc x9qNric9AxqppOpwiThrd45xOhlAjKmzFPwB7Fti2IpnvXT2eFdJ53SATQrXDLM3 RntUn1xBYvIuDifZT4hcuBUa2VvZMJ3Aqag2tdeULyptO19o6yN3Vs4IP/6Y3nuX 8diTmRFCCYUGWwdb9Pkkk9Z6vc//AT6P0/8cvVI7MREroqyvwJHslOf0VAmMB2gN icZ1ub42Zm0jmiZDjbX/gikaU/X3IIJQJBX8t1JGdUdpAwtL1QPvsTx+Hjxk0i2B o2j0VFrXtkFn4u6TTgcoAyVfvFhqGhGHg1+EZd3TFQIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUIckl02r+pBL/5t1X V8+PPnKECM0wDQYJKoZIhvcNAQELBQADggEBAArE2ntHUGAvYnFg+yWyyCGyui4a YxW+/SR6HI7lr2AZD29yHWLwh8GuPufUesF30mluNZ46GSWZWMrGtvViK4UJAgnf EwvFUo8rEjug+o9EqIormGCHwgbAzNsaXjGi+L5oKbdB64E96EOY1zOH7zUWidaL mWbECjNWzFmuPMeLwAEVkhy7pNyfmvgEdRnquBkSInGX8OAmrWDERyEsQfwWI+sE HC0F6n7eE4QtaItigOdnwzGafqicKT/xQIFJJ0dP8tb4lqjhlqo3Q+j7oore26FH 4K1RoQNutEB2TJM7IbQRx+lKSWDwXResA3FLrQjVeGjNZxomzljPjzjRG2c= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEZ MBcGA1UECgwQVmVyaXpvbiBCdXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAd BgNVBAMMFlZlcml6b24gR2xvYmFsIFJvb3QgQ0EwHhcNMDkwNzMwMTQyNzA0WhcN MzQwNzMwMTQyNzA0WjBcMQswCQYDVQQGEwJVUzEZMBcGA1UECgwQVmVyaXpvbiBC dXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAdBgNVBAMMFlZlcml6b24gR2xv YmFsIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKAAxw Hb/rNIbDmUU1Hn9D96tvJC3NGcIQu7DKKVupIKurcizE4gI5bYK4xRHq+PuznmL4 Mx6wH8nj9jfbBMg7Y0824oWkJR3HaR8EvWhFE5YHH5RQ9T7FJ1SewElXRI4HY9Sm ru0imcxNlmkEE252iZ90FpT5HVS9ornSgwEiDE1EgKr+NYknJaeGicbVGpLjj8WV oBRymuhWxQJVHJf5IC7Q9TwTGVr24fkLA4Jpp4y31m+cVj6d6CoJYG1L5vuLmRT3 NE9lWYCNuVfIojUh2IhxVl3uglctJpAYn5qcnI/v1MVjp1R9R5GHfRoSqBsYb6lv sSe65AR0zjcef2bFAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRMOBG4mABbWitwPqp45NVnZ2enfjANBgkqhkiG9w0B AQsFAAOCAQEAAV+gsQYB9HnXZRhgPs95oLrCI08j34eWX4EOOBUuXMgCaCkg/Ivu pYoYgWRcmDV+OTCCpIKKULW6w+ha1qie4sMX29vE67AKIA3pnuP/YFRH8Tud1Cg8 oq6j+6qLgiIqNYeQuBxZR5DVnS76SeNlqDbrx+QcaNyzMWyrTs4kgBXIEFkQEXJN epyYnMT8YeCzsp1OoMbCWasY1qJVRewpqiU31k5KPQtAweST5PzNkQv45qvMs3bE Yr8Z7Ya2ecMpVFS8mX1GV8+mz/RUKpoDZUcBoUIqyyVHbnxeAEuR2fkbEAZw+UIV pl+q10Ae/clInZeB6lxowqDniaFTTb/H4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgICBFAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx GTAXBgNVBAoMEFZlcml6b24gQnVzaW5lc3MxETAPBgNVBAsMCE9tbmlSb290MR8w HQYDVQQDDBZWZXJpem9uIEdsb2JhbCBSb290IENBMB4XDTEzMDEzMDE3MzQwNFoX DTIzMDEzMDE3MzI1OVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggEAMIH9MBIGA1UdEwEB/wQIMAYBAf8CAQEw UwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5BggrBgEFBQcCARYtaHR0cDovL2N5 YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkuY2ZtMA4GA1UdDwEB/wQE AwIB5jAfBgNVHSMEGDAWgBRMOBG4mABbWitwPqp45NVnZ2enfjBCBgNVHR8EOzA5 MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1c3QuY29tL0NSTC9PbW5pcm9v dDIwMzQuY3JsMB0GA1UdDgQWBBQhySXTav6kEv/m3VdXz48+coQIzTANBgkqhkiG 9w0BAQsFAAOCAQEAJMU82S8OjWhmtDAVv4Ii+PpMQibfZtVqZ70kHVf+pYHpJ/YI e6ncRd7uKWYdU+0MaJ8SSZytnFQa2M4T/Dsp5bFpsMyDvp/LpyP9idEtVNwCTzfN uhTTTa7K8RA6oB1s8zG3r37zgSYZ3g+A7iXnUwwGo+NjH3YfggOmv4If668dABlI 2dEQjOkH4hl0a2RU1ytmoCCOj4fvXFa+YEWQG3Liy38b1N+UdqlYC+GFP+rlHGTF /WkJiKReAyq9xy74ipom7jaS73IzS7TEK1n5GGz7Dt+Bz2PGT06M0oGFsG4j1WbA JIKp29kbvaFrVVAhTZaq4+mMkL2gm//boC+qrg== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sat Apr 25 18:34:15 2015 From: rt at openssl.org (=?UTF-8?B?6ZmI6Zuo5Lqt?= via RT) Date: Sat, 25 Apr 2015 20:34:15 +0200 Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. In-Reply-To: <1327BDB0DB7D48A8B7CDF698DCC38C8D@sjtu.edu.cn> References: <1327BDB0DB7D48A8B7CDF698DCC38C8D@sjtu.edu.cn> Message-ID: Quickly check the contents, and in CAfile_Baltimore_root, the value of Basic Constraints: CA: TRUE, pathlen: 1 That can be one reason. Yuting Chen -----Original Message----- From: Jason.Kubicki at wellsfargo.com via RT Sent: Saturday, April 25, 2015 2:13 AM Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3821] Possible bug/request for help0.9.8 on windows - OpenSSL verify error. When I try to verify a SHA-2 certificate that chains up to a SHA-1 root I get error 20 at depth 0. If I leave the SHA-1 root off of the CAfile I get past depth 0. Verizon support was able to replicate this issue as well. We are trying to use OpenSSL verify to check our intermediate issuing CA (WellsSecure CA 01 G2) against the chain with the SHA-1 Baltimore Root at the top of the hierarchy. With the Baltimore root our chain looks like this: SHA-1 Baltimore root --> SHA-2 WellsSecure Public Root --> SHA-2 WellsSecure CA 01 G2 --> SHA-2 End-Entities With version 0.9.8 of OpenSSL we are seeing the following error: OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo/OU=WellsSecure Certification Authorities/CN=WellsSecure Certification Authority 01 G2 error 20 at 0 depth lookup:unable to get local issuer certificate I believe this error indicates that OpenSSL is unable to determine the issuer of our issuing intermediate CA. We only get this error when we try to verify the chain up to the SHA-1 Baltimore Root. It works in newer versions of OpenSSL and it works with our SHA-2 self-signed root and the cross-certificate from the SHA-2 Verizon Global root as seen below. With version 1.0.1 and 1.0.2 of OpenSSL we do not see the error. OpenSSL> version OpenSSL 1.0.1l 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL> version OpenSSL 1.0.2 22 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Baltimore_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We do not see this issue in OpenSSL 0.9.8 if we validate the intermediate issuing CA against the existing Verizon Global root cross cert chain. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\CAfile_Verizon_root+WSPRCA01G2cc.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK We also do not see the issue when we validate the intermediate issuing CA against our WellsSecure Public Root self-signed certificate. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile C:\test\WellsSecure_Public_Root_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: OK OpenSSL 0.9.8 does not appear to support the -partial_chain command so we cannot test the intermediate issuing CA against just the cross-certificate as issued by the SHA-1 Baltimore root without error but the error is expected. OpenSSL> version OpenSSL 0.9.8ze 15 Jan 2015 OpenSSL> verify -CAfile "C:\test\WSPRCA CC from Baltimore.cer" C:\test\WellsSecure_CA_01_G2.cer C:\test\WellsSecure_CA_01_G2.cer: /C=US/O=Wells Fargo WellsSecure/OU=Wells Fargo Bank NA/CN=WellsSecure Public Root Certification Authority 01 G2 error 2 at 1 depth lookup:unable to get issuer certificate I believe this error means that OpenSSL was able to find the issuer of our issuing intermediate CA, which it could not do when the Baltimore root is present, and tie it to the cross-certificate issued by the Baltimore root. The reason this error is happening is that my CAfile for this test did not contain the Baltimore self-signed root. There appears to be some sort of issue that is causing OpenSSL 0.9.8 to be unable to validate our chain when the SHA-1 Baltimore self signed root is at the top of the chain. Have you encountered this error before with a mixed hierarchy or are you able to shed any light on what may be causing this issue? I am attaching PEM encoded versions of the files for your own testing and validation. Jason Kubicki, CISSP Information Security Analyst Cryptographic Services - Enterprise Key Management & Public Key Infrastructure | Wells Fargo -----BEGIN CERTIFICATE----- MIIFCTCCA/GgAwIBAgIKYQyP4AAAAAAAAjANBgkqhkiG9w0BAQsFADCBjTELMAkG A1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJlMRwwGgYD VQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1NlY3VyZSBQ dWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAeFw0xMjEw MDEyMDQwMDVaFw0yMjEwMDEyMDUwMDVaMIGHMQswCQYDVQQGEwJVUzEUMBIGA1UE ChMLV2VsbHMgRmFyZ28xLjAsBgNVBAsTJVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXRpZXMxMjAwBgNVBAMTKVdlbGxzU2VjdXJlIENlcnRpZmljYXRp b24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKC AQEA1idl7QU1OQVGPn51Pb62YWCvWOVOWPm1zs4OKIMSq+zR5EiVs0ve7lLo5VP+ WV3c/Er6yOxXXV01ocnN9N6hmOWhVn5KyDATGNCM5nHMHHdQQbfCAzFVycW1TO9H rjw74B1P+4jjy+B0nMRie3XSGACXEb11bDuummHCLYEM+6VanCOx41eRSd8VDcEK cP6NUkS4tujEwZojiujP0h7t/Jf3rtey7ORWGkq/rj9AH7Lo23Gr6bxeu3o3Auzv UejLKfUjh4cA2eZWgDMiGIRW4f9V7ZY9P+jwevl2D619qGPlYMsRBfcZ36xJs03C pWRFZxjHWJ9+u/nb4knLxy8jHwIDAQABo4IBbTCCAWkwDgYDVR0PAQH/BAQDAgGG MB0GA1UdDgQWBBRZmgHl58Pm8yV48VrZqOnxcpSOMDBMBgNVHSAERTBDMEEGC2CG SAGG+3uDdAAAMDIwMAYIKwYBBQUHAgEWJGh0dHA6Ly93d3cud2VsbHNmYXJnby5j b20vcmVwb3NpdG9yeTASBgNVHRMBAf8ECDAGAQH/AgEAMB8GA1UdIwQYMBaAFCHJ JdNq/qQS/+bdV1fPjz5yhAjNMD0GA1UdHwQ2MDQwMqAwoC6GLGh0dHA6Ly9jcmwu cGtpLndlbGxzZmFyZ28uY29tL3dzcHJjYTAxRzIuY3JsMHYGCCsGAQUFBwEBBGow aDA4BggrBgEFBQcwAoYsaHR0cDovL2NybC5wa2kud2VsbHNmYXJnby5jb20vd3Nw cmNhMDFHMi5jcnQwLAYIKwYBBQUHMAGGIGh0dHA6Ly92YWxpZGF0b3Iud2VsbHNm YXJnby5jb20vMA0GCSqGSIb3DQEBCwUAA4IBAQAd4xIa2AexQNSrmBK7RX5cFrh0 tFPydFSlXRo12TOvC0BexgvATrfuN6GPGemgt3nI/iTmNW+N4iw1phVnySyAr23Z nI8Hj73zy8Imyf42dfBIDN7dJFWKAU+sZRpFpuH358v0kBbbeZXQRLt/W4Ax0RJ9 TLbqIa3DiQ7tqo6LUvt7+yXH310YCu3722QGFXFfJmGmjmo5R+dL1vc5OQpNwpWo tfvKwpKHBXOCFqtzXU+X+IMbeSo6fajs5Qaqq1StCmzwCEYHiRQU8hyzUghcaMHF NDfxncSsdp2lgzAioW4ly0Qc8xzQlkUlSSHKv103SDDLJUVFPB4t82yCyDlK -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIID6DCCAtCgAwIBAgIQXCwtpvvXVopPgEL9qP3rJjANBgkqhkiG9w0BAQsFADCB jTELMAkGA1UEBhMCVVMxIDAeBgNVBAoTF1dlbGxzIEZhcmdvIFdlbGxzU2VjdXJl MRwwGgYDVQQLExNXZWxscyBGYXJnbyBCYW5rIE5BMT4wPAYDVQQDEzVXZWxsc1Nl Y3VyZSBQdWJsaWMgUm9vdCBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAwMSBHMjAe Fw0xMjA4MDkxNjM2NDVaFw0zMDEyMjYxNjQ2MzNaMIGNMQswCQYDVQQGEwJVUzEg MB4GA1UEChMXV2VsbHMgRmFyZ28gV2VsbHNTZWN1cmUxHDAaBgNVBAsTE1dlbGxz IEZhcmdvIEJhbmsgTkExPjA8BgNVBAMTNVdlbGxzU2VjdXJlIFB1YmxpYyBSb290 IENlcnRpZmljYXRpb24gQXV0aG9yaXR5IDAxIEcyMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAwyWEb3XDCHkxFHAv0geLGyu5Ao0guOzJ+S4atX73DJUc x9qNric9AxqppOpwiThrd45xOhlAjKmzFPwB7Fti2IpnvXT2eFdJ53SATQrXDLM3 RntUn1xBYvIuDifZT4hcuBUa2VvZMJ3Aqag2tdeULyptO19o6yN3Vs4IP/6Y3nuX 8diTmRFCCYUGWwdb9Pkkk9Z6vc//AT6P0/8cvVI7MREroqyvwJHslOf0VAmMB2gN icZ1ub42Zm0jmiZDjbX/gikaU/X3IIJQJBX8t1JGdUdpAwtL1QPvsTx+Hjxk0i2B o2j0VFrXtkFn4u6TTgcoAyVfvFhqGhGHg1+EZd3TFQIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAYYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUIckl02r+pBL/5t1X V8+PPnKECM0wDQYJKoZIhvcNAQELBQADggEBAArE2ntHUGAvYnFg+yWyyCGyui4a YxW+/SR6HI7lr2AZD29yHWLwh8GuPufUesF30mluNZ46GSWZWMrGtvViK4UJAgnf EwvFUo8rEjug+o9EqIormGCHwgbAzNsaXjGi+L5oKbdB64E96EOY1zOH7zUWidaL mWbECjNWzFmuPMeLwAEVkhy7pNyfmvgEdRnquBkSInGX8OAmrWDERyEsQfwWI+sE HC0F6n7eE4QtaItigOdnwzGafqicKT/xQIFJJ0dP8tb4lqjhlqo3Q+j7oore26FH 4K1RoQNutEB2TJM7IbQRx+lKSWDwXResA3FLrQjVeGjNZxomzljPjzjRG2c= -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgIBATANBgkqhkiG9w0BAQsFADBcMQswCQYDVQQGEwJVUzEZ MBcGA1UECgwQVmVyaXpvbiBCdXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAd BgNVBAMMFlZlcml6b24gR2xvYmFsIFJvb3QgQ0EwHhcNMDkwNzMwMTQyNzA0WhcN MzQwNzMwMTQyNzA0WjBcMQswCQYDVQQGEwJVUzEZMBcGA1UECgwQVmVyaXpvbiBC dXNpbmVzczERMA8GA1UECwwIT21uaVJvb3QxHzAdBgNVBAMMFlZlcml6b24gR2xv YmFsIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKAAxw Hb/rNIbDmUU1Hn9D96tvJC3NGcIQu7DKKVupIKurcizE4gI5bYK4xRHq+PuznmL4 Mx6wH8nj9jfbBMg7Y0824oWkJR3HaR8EvWhFE5YHH5RQ9T7FJ1SewElXRI4HY9Sm ru0imcxNlmkEE252iZ90FpT5HVS9ornSgwEiDE1EgKr+NYknJaeGicbVGpLjj8WV oBRymuhWxQJVHJf5IC7Q9TwTGVr24fkLA4Jpp4y31m+cVj6d6CoJYG1L5vuLmRT3 NE9lWYCNuVfIojUh2IhxVl3uglctJpAYn5qcnI/v1MVjp1R9R5GHfRoSqBsYb6lv sSe65AR0zjcef2bFAgMBAAGjQjBAMA8GA1UdEwEB/wQFMAMBAf8wDgYDVR0PAQH/ BAQDAgEGMB0GA1UdDgQWBBRMOBG4mABbWitwPqp45NVnZ2enfjANBgkqhkiG9w0B AQsFAAOCAQEAAV+gsQYB9HnXZRhgPs95oLrCI08j34eWX4EOOBUuXMgCaCkg/Ivu pYoYgWRcmDV+OTCCpIKKULW6w+ha1qie4sMX29vE67AKIA3pnuP/YFRH8Tud1Cg8 oq6j+6qLgiIqNYeQuBxZR5DVnS76SeNlqDbrx+QcaNyzMWyrTs4kgBXIEFkQEXJN epyYnMT8YeCzsp1OoMbCWasY1qJVRewpqiU31k5KPQtAweST5PzNkQv45qvMs3bE Yr8Z7Ya2ecMpVFS8mX1GV8+mz/RUKpoDZUcBoUIqyyVHbnxeAEuR2fkbEAZw+UIV pl+q10Ae/clInZeB6lxowqDniaFTTb/H4w== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIEaDCCA1CgAwIBAgICBFAwDQYJKoZIhvcNAQELBQAwXDELMAkGA1UEBhMCVVMx GTAXBgNVBAoMEFZlcml6b24gQnVzaW5lc3MxETAPBgNVBAsMCE9tbmlSb290MR8w HQYDVQQDDBZWZXJpem9uIEdsb2JhbCBSb290IENBMB4XDTEzMDEzMDE3MzQwNFoX DTIzMDEzMDE3MzI1OVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggEAMIH9MBIGA1UdEwEB/wQIMAYBAf8CAQEw UwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5BggrBgEFBQcCARYtaHR0cDovL2N5 YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9zaXRvcnkuY2ZtMA4GA1UdDwEB/wQE AwIB5jAfBgNVHSMEGDAWgBRMOBG4mABbWitwPqp45NVnZ2enfjBCBgNVHR8EOzA5 MDegNaAzhjFodHRwOi8vY2RwMS5wdWJsaWMtdHJ1c3QuY29tL0NSTC9PbW5pcm9v dDIwMzQuY3JsMB0GA1UdDgQWBBQhySXTav6kEv/m3VdXz48+coQIzTANBgkqhkiG 9w0BAQsFAAOCAQEAJMU82S8OjWhmtDAVv4Ii+PpMQibfZtVqZ70kHVf+pYHpJ/YI e6ncRd7uKWYdU+0MaJ8SSZytnFQa2M4T/Dsp5bFpsMyDvp/LpyP9idEtVNwCTzfN uhTTTa7K8RA6oB1s8zG3r37zgSYZ3g+A7iXnUwwGo+NjH3YfggOmv4If668dABlI 2dEQjOkH4hl0a2RU1ytmoCCOj4fvXFa+YEWQG3Liy38b1N+UdqlYC+GFP+rlHGTF /WkJiKReAyq9xy74ipom7jaS73IzS7TEK1n5GGz7Dt+Bz2PGT06M0oGFsG4j1WbA JIKp29kbvaFrVVAhTZaq4+mMkL2gm//boC+qrg== -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIDdzCCAl+gAwIBAgIEAgAAuTANBgkqhkiG9w0BAQUFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTAwMDUxMjE4NDYwMFoX DTI1MDUxMjIzNTkwMFowWjELMAkGA1UEBhMCSUUxEjAQBgNVBAoTCUJhbHRpbW9y ZTETMBEGA1UECxMKQ3liZXJUcnVzdDEiMCAGA1UEAxMZQmFsdGltb3JlIEN5YmVy VHJ1c3QgUm9vdDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKMEuyKr mD1X6CZymrV51Cni4eiVgLGw41uOKymaZN+hXe2wCQVt2yguzmKiYv60iNoS6zjr IZ3AQSsBUnuId9Mcj8e6uYi1agnnc+gRQKfRzMpijS3ljwumUNKoUMMo6vWrJYeK mpYcqWe4PwzV9/lSEy/CG9VwcPCPwBLKBsua4dnKM3p31vjsufFoREJIE9LAwqSu XmD+tqYF/LTdB1kC1FkYmGP1pWPgkAx9XbIGevOF6uvUA65ehD5f/xXtabz5OTZy dc93Uk3zyZAsuT3lySNTPx8kmCFcB5kpvcY67Oduhjprl3RjM71oGDHweI12v/ye jl0qhqdNkNwnGjkCAwEAAaNFMEMwHQYDVR0OBBYEFOWdWTCCR1jMrPoIVDaGezq1 BE3wMBIGA1UdEwEB/wQIMAYBAf8CAQMwDgYDVR0PAQH/BAQDAgEGMA0GCSqGSIb3 DQEBBQUAA4IBAQCFDF2O5G9RaEIFoN27TyclhAO992T9Ldcw46QQF+vaKSm2eT92 9hkTI7gQCvlYpNRhcL0EYWoSihfVCr3FvDB81ukMJY2GQE/szKN+OMY3EU/t3Wgx jkzSswF07r51XgdIGn9w/xZchMB5hbgF/X++ZRGjD8ACtPhSNzkE1akxehi/oCr0 Epn3o0WC4zxe9Z2etciefC7IpJ5OCBRLbf1wbWsaY71k5h+3zvDyny67G7fyUIhz ksLi4xaNmjICq44Y3ekQEe5+NauQrz4wlHrQMz2nZQ/1/I6eYs9HRCwBXbsdtTLS R9I4LtD+gdwyah617jzV/OeBHRnDJELqYzmp -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- -----BEGIN CERTIFICATE----- MIIE1jCCA76gAwIBAgIEByfDtDANBgkqhkiG9w0BAQsFADBaMQswCQYDVQQGEwJJ RTESMBAGA1UEChMJQmFsdGltb3JlMRMwEQYDVQQLEwpDeWJlclRydXN0MSIwIAYD VQQDExlCYWx0aW1vcmUgQ3liZXJUcnVzdCBSb290MB4XDTE1MDIyNjE2NDkwMFoX DTI1MDIyNjE2NDc0MVowgY0xCzAJBgNVBAYTAlVTMSAwHgYDVQQKDBdXZWxscyBG YXJnbyBXZWxsc1NlY3VyZTEcMBoGA1UECwwTV2VsbHMgRmFyZ28gQmFuayBOQTE+ MDwGA1UEAww1V2VsbHNTZWN1cmUgUHVibGljIFJvb3QgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgMDEgRzIwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDD JYRvdcMIeTEUcC/SB4sbK7kCjSC47Mn5Lhq1fvcMlRzH2o2uJz0DGqmk6nCJOGt3 jnE6GUCMqbMU/AHsW2LYime9dPZ4V0nndIBNCtcMszdGe1SfXEFi8i4OJ9lPiFy4 FRrZW9kwncCpqDa115QvKm07X2jrI3dWzgg//pjee5fx2JOZEUIJhQZbB1v0+SST 1nq9z/8BPo/T/xy9UjsxESuirK/AkeyU5/RUCYwHaA2JxnW5vjZmbSOaJkONtf+C KRpT9fcgglAkFfy3UkZ1R2kDC0vVA++xPH4ePGTSLYGjaPRUWte2QWfi7pNOBygD JV+8WGoaEYeDX4Rl3dMVAgMBAAGjggFuMIIBajASBgNVHRMBAf8ECDAGAQH/AgEB MEIGCCsGAQUFBwEBBDYwNDAyBggrBgEFBQcwAYYmaHR0cDovL29jc3Aub21uaXJv b3QuY29tL2JhbHRpbW9yZXJvb3QwUwYDVR0gBEwwSjBIBgkrBgEEAbE+AQAwOzA5 BggrBgEFBQcCARYtaHR0cDovL2N5YmVydHJ1c3Qub21uaXJvb3QuY29tL3JlcG9z aXRvcnkuY2ZtMA4GA1UdDwEB/wQEAwIBpjAnBgNVHSUEIDAeBggrBgEFBQcDAQYI KwYBBQUHAwIGCCsGAQUFBwMEMB8GA1UdIwQYMBaAFOWdWTCCR1jMrPoIVDaGezq1 BE3wMEIGA1UdHwQ7MDkwN6A1oDOGMWh0dHA6Ly9jZHAxLnB1YmxpYy10cnVzdC5j b20vQ1JML09tbmlyb290MjAyNS5jcmwwHQYDVR0OBBYEFCHJJdNq/qQS/+bdV1fP jz5yhAjNMA0GCSqGSIb3DQEBCwUAA4IBAQBwHz2aeGaaqE55Akqi2zy2hii8sgwR 3owuF3SeBxpfnwKQqVVZG8vv57ekGdrQ1mlyCSqW330WNFZDMUekOv0VNmcDvxHa trUqzMQsKaS1YACjZg/fyK2KUjpx8Y/t0WnDVAGjpux/mU2xtH2RWGkVGx60DHI7 /VWxYjnDLtQMGVzM9eG6x0C+IMAeOSGmDxS6xdb51xb/fDRZ7WOJkVdIl1qdBqkY ok+37vLK4wupqmR9lpDlsWeZcp/3/gG/hRhw6auwwFpFe4eZB9CmNkT0a6bKhXCd oyCUQybEkik+S33SXxtf6ktzlHXiKormx0d1/6mcp9UzzHbAhNCYhjtZ -----END CERTIFICATE----- _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Sun Apr 26 12:09:17 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 26 Apr 2015 14:09:17 +0200 Subject: [openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly In-Reply-To: References: Message-ID: This discussion relates to 1.0.2a. But I know its applies to other versions from all the changes I've had to make to Makefile.org. I'm not sure if this me using Configure incorrectly, or a bug in Configure. I suspect its the later. Below, I used both --prefix and --openssldir in an attempt to set them. If there is difficulty in determining what should be done, then perhaps there should be a --rpath Configure option. As a matter of fact, I tried to add an --rpath option to Configure. The LDFLAGS are not being honored in the build system. Sigh.... ***** ./Configure linux-x86_64 shared no-ssl2 no-ssl3 no-comp --openssldir=/usr/local/ssl --prefix=/usr/local/ssl make depend make ldd ./apps/openssl linux-vdso.so.1 => (0x00007ffc555f8000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007fa0e8174000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007fa0e7d99000) ... ldd ./apps/openssl linux-vdso.so.1 => (0x00007ffef14c8000) libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 (0x00007ff03065b000) libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 (0x00007ff030280000) ... ***** $ grep -i rpath * CHANGES: *) Add full support for -rpath/-R, both in shared libraries and CHANGES: uses the RPATH feature, and is available through the special CHANGES: configuration target "alpha-cc-rpath", which will never be selected ... Makefile: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.bak: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.org: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ Makefile.shared:DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)" Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -rpath $(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -R $(LIBRPATH)"; \ Makefile.shared: @LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,+s,+cdp,../:,+cdp,./:,+b,$(LIBRPATH)"; \ Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,-brtl,-blibpath:$(LIBRPATH):$${LIBPATH:-/usr/lib:/lib}"; \ Makefile.shared:symlink.cygwin symlink.alpha-osf1 symlink.tru64 symlink.tru64-rpath symlink.beos: Makefile.shared:link_o.tru64-shared-rpath: link_o.tru64-rpath Makefile.shared:link_a.tru64-shared-rpath: link_a.tru64-rpath Makefile.shared:link_app.tru64-shared-rpath: link_app.tru64-rpath Makefile.shared:symlink.tru64-shared-rpath: symlink.tru64-rpath ... -------------- next part -------------- 13c13 < my $usage="Usage: Configure [no- ...] [enable- ...] [experimental- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]\n"; --- > my $usage="Usage: Configure [no- ...] [enable- ...] [experimental- ...] [-Dxxx] [-lxxx] [-Lxxx] [-fxxx] [-Kxxx] [no-hw-xxx|no-hw] [[no-]threads] [[no-]shared] [[no-]zlib|zlib-dynamic] [no-asm] [no-dso] [no-krb5] [sctp] [386] [--prefix=DIR] [--rpath=DIR] [--openssldir=OPENSSLDIR] [--with-xxx[=vvv]] [--test-sanity] os/compiler[:flags]\n"; 20a21,23 > # --rpath prefix for the OpenSSL library directories. Use by libssl and > # and openssl. There is no default directory. You must opt-in > # for the behavior. 702a706 > my $requested_rpath=""; 927a932,935 > elsif (/^--rpath=(.*)$/) > { > $requested_rpath=$1; > } 1499a1508,1511 > if ($requested_rpath ne "") > { > $shared_ldflag.=" -Wl,-rpath,\$(requested_rpath)"; > } 1753a1766 > 1755a1769 > print "RPATH =$requested_rpath\n" if($requested_rpath ne ""); 2058c2072 < VALUE "LegalCopyright", "Copyright ? 1998-2005 The OpenSSL Project. Copyright ? 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved.\\0" --- > VALUE "LegalCopyright", "Copyright \A9 1998-2005 The OpenSSL Project. Copyright \A9 1995-1998 Eric A. Young, Tim J. Hudson. All rights reserved.\\0" From rt at openssl.org Sun Apr 26 12:21:42 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sun, 26 Apr 2015 14:21:42 +0200 Subject: [openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly In-Reply-To: <20150426122112.GA22528@roeckx.be> References: <20150426122112.GA22528@roeckx.be> Message-ID: On Sun, Apr 26, 2015 at 02:09:17PM +0200, noloader at gmail.com via RT wrote: > This discussion relates to 1.0.2a. But I know its applies to other > versions from all the changes I've had to make to Makefile.org. > > I'm not sure if this me using Configure incorrectly, or a bug in > Configure. I suspect its the later. > > Below, I used both --prefix and --openssldir in an attempt to set them. > > If there is difficulty in determining what should be done, then > perhaps there should be a --rpath Configure option. I'm not sure why you have a need for an rpath in the first place. > ./Configure linux-x86_64 shared no-ssl2 no-ssl3 no-comp > --openssldir=/usr/local/ssl --prefix=/usr/local/ssl > make depend > make > ldd ./apps/openssl > linux-vdso.so.1 => (0x00007ffc555f8000) > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x00007fa0e8174000) > libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (0x00007fa0e7d99000) > ... What did you expect this to return? Even if you had an rpath, but no files are in /usr/local/ssl/ it would still search in /lib/x86_64-linux-gnu/. Kurt From deengert at gmail.com Sun Apr 26 12:50:48 2015 From: deengert at gmail.com (Douglas E Engert) Date: Sun, 26 Apr 2015 07:50:48 -0500 Subject: [openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly In-Reply-To: References: Message-ID: <553CDF28.70104@gmail.com> On 4/26/2015 7:09 AM, noloader at gmail.com via RT wrote: > This discussion relates to 1.0.2a. But I know its applies to other > versions from all the changes I've had to make to Makefile.org. > > I'm not sure if this me using Configure incorrectly, or a bug in > Configure. I suspect its the later. > > Below, I used both --prefix and --openssldir in an attempt to set them. > > If there is difficulty in determining what should be done, then > perhaps there should be a --rpath Configure option. > > As a matter of fact, I tried to add an --rpath option to Configure. > The LDFLAGS are not being honored in the build system. Sigh.... > > ***** > > ./Configure linux-x86_64 shared no-ssl2 no-ssl3 no-comp > --openssldir=/usr/local/ssl --prefix=/usr/local/ssl > make depend > make does this show the RPATH and NEEDED libs: readelf -d Did you do an install? If you need to test before install, you can set/export LD_LIBRARY_PATH to the directory eith the libs. > ldd ./apps/openssl > linux-vdso.so.1 => (0x00007ffc555f8000) > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x00007fa0e8174000) > libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (0x00007fa0e7d99000) > ... > ldd ./apps/openssl > linux-vdso.so.1 => (0x00007ffef14c8000) > libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 > (0x00007ff03065b000) > libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 > (0x00007ff030280000) > ... > > ***** > > $ grep -i rpath * > CHANGES: *) Add full support for -rpath/-R, both in shared libraries and > CHANGES: uses the RPATH feature, and is available through the special > CHANGES: configuration target "alpha-cc-rpath", which will never be selected > ... > Makefile: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ > Makefile.bak: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ > Makefile.org: SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' \ > Makefile.shared:DO_GNU_APP=LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)" > Makefile.shared: LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBPATH)"; \ > Makefile.shared: LDFLAGS="$(CFLAGS) -rpath $(LIBRPATH)"; \ > Makefile.shared: LDFLAGS="$(CFLAGS) -R $(LIBRPATH)"; \ > Makefile.shared: @LDFLAGS="$(CFLAGS) -Wl,-rpath,$(LIBRPATH)"; \ > Makefile.shared: LDFLAGS="$(CFLAGS) > -Wl,+s,+cdp,../:,+cdp,./:,+b,$(LIBRPATH)"; \ > Makefile.shared: LDFLAGS="$(CFLAGS) > -Wl,-brtl,-blibpath:$(LIBRPATH):$${LIBPATH:-/usr/lib:/lib}"; \ > Makefile.shared:symlink.cygwin symlink.alpha-osf1 symlink.tru64 > symlink.tru64-rpath symlink.beos: > Makefile.shared:link_o.tru64-shared-rpath: link_o.tru64-rpath > Makefile.shared:link_a.tru64-shared-rpath: link_a.tru64-rpath > Makefile.shared:link_app.tru64-shared-rpath: link_app.tru64-rpath > Makefile.shared:symlink.tru64-shared-rpath: symlink.tru64-rpath > ... > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- Douglas E. Engert From rt at openssl.org Sun Apr 26 17:02:42 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 26 Apr 2015 19:02:42 +0200 Subject: [openssl-dev] [openssl.org #3822] BUG: Configure does not set RPATH correctly In-Reply-To: References: <20150426122112.GA22528@roeckx.be> Message-ID: On Sun, Apr 26, 2015 at 8:21 AM, Kurt Roeckx via RT wrote: > On Sun, Apr 26, 2015 at 02:09:17PM +0200, noloader at gmail.com via RT wrote: >> This discussion relates to 1.0.2a. But I know its applies to other >> versions from all the changes I've had to make to Makefile.org. >> >> I'm not sure if this me using Configure incorrectly, or a bug in >> Configure. I suspect its the later. >> >> Below, I used both --prefix and --openssldir in an attempt to set them. >> >> If there is difficulty in determining what should be done, then >> perhaps there should be a --rpath Configure option. > > I'm not sure why you have a need for an rpath in the first place. In this case, no. But I will need it when I install in /opt. >> ./Configure linux-x86_64 shared no-ssl2 no-ssl3 no-comp >> --openssldir=/usr/local/ssl --prefix=/usr/local/ssl >> make depend >> make >> ldd ./apps/openssl >> linux-vdso.so.1 => (0x00007ffc555f8000) >> libssl.so.1.0.0 => /lib/x86_64-linux-gnu/libssl.so.1.0.0 >> (0x00007fa0e8174000) >> libcrypto.so.1.0.0 => /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 >> (0x00007fa0e7d99000) >> ... > > What did you expect this to return? Even if you had an rpath, > but no files are in /usr/local/ssl/ it would still search in > /lib/x86_64-linux-gnu/. 1.0.2.a is installed in /usr/local/ssl. I was being kind of lazy by building in my home directory trying to pickup the libraries that were already installed. But I also tried /usr/local/ssl/lib with no joy either. From brian at briansmith.org Sun Apr 26 20:37:42 2015 From: brian at briansmith.org (Brian Smith) Date: Sun, 26 Apr 2015 10:37:42 -1000 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness In-Reply-To: References: Message-ID: On Fri, Apr 24, 2015 at 5:54 AM, Emilia K?sper wrote: > commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2). > commit 53dd4ddf71 fixes 5 and some of 4. > > Still ploughing my way through the rest of error checking. > > Great. I want to call your attention to one particularly non-obvious failure to handle errors correctly: static void ecp_nistz256_windowed_mul([...], P256_POINT *r, [...]) { [...] if ((num * 16 + 6) > OPENSSL_MALLOC_MAX_NELEMS(P256_POINT) || (table_storage = OPENSSL_malloc((num * 16 + 5) * sizeof(P256_POINT) + 64)) == NULL || (p_str = OPENSSL_malloc(num * 33 * sizeof(unsigned char))) == NULL || (scalars = OPENSSL_malloc(num * sizeof(BIGNUM *))) == NULL) { ECerr(EC_F_ECP_NISTZ256_WINDOWED_MUL, ERR_R_MALLOC_FAILURE); goto err; } [...] err: [...] } ecp_nistz256_windowed_mul checks for errors, but it doesn't report the fact that an error occurred to the caller, because it has return type |void|. And, the caller doesn't check that ecp_nistz256_windowed_mul failed; it can't because of the void return type. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From anuradhag.30 at gmail.com Mon Apr 27 06:47:53 2015 From: anuradhag.30 at gmail.com (Annuradha Gupta) Date: Mon, 27 Apr 2015 12:17:53 +0530 Subject: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit Message-ID: Hi I wanted to understand FIPS 140-2 support, on Mac 32/64 and iOS 32/64. Which version of OpenSSL will have the required support for these platforms. -- Best Regards, Anuradha -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Apr 27 11:36:43 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 27 Apr 2015 07:36:43 -0400 Subject: [openssl-dev] FIPS support for Mac 64 bit and iOS 64 bit In-Reply-To: References: Message-ID: <553E1F4B.7090403@openssl.com> On 04/27/2015 02:47 AM, Annuradha Gupta wrote: > Hi > > I wanted to understand FIPS 140-2 support, on Mac 32/64 and iOS 32/64. > Which version of OpenSSL will have the required support for these platforms. Mac support is unknown (not in process and no prospective sponsors). 64bit iOS is pending, held up by the "hostage" issue[*]. All the hands-on testing is done and we're in the wait-on-the-bureaucracy phase. My best guess at this point is another two or three months. That revision will probably be called 2.0.10, but it won't be a revision of the #1747 validation. Instead it will be the first revision of the pending new "salvage edition" validation[**]. It will be the same tarball as if we were allowed to update the #1747 validation directly, though. -Steve M. [*] http://openssl.com/fips/hostage.html [**] http://openssl.com/fips/ransom.html -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From John.Zabel at ultra-dne.com Mon Apr 27 19:03:22 2015 From: John.Zabel at ultra-dne.com (John Zabel) Date: Mon, 27 Apr 2015 15:03:22 -0400 Subject: [openssl-dev] OpenSSL support for 186-4 Message-ID: <052C40F1B2C3AF4A82C79CA7822A17A70F0CCA0A03@dne14.dne.local> Can anyone tell me what versions of OpenSSL and the FIPS object module are needed to support 186-4? I have seen a few vague discussions on the subject but no definitive answer. Thanks This e-mail from Ultra Electronics and any attachments to it are confidential to the intended recipient and may also be privileged. If you have received it in error please notify the sender and delete it from your system. If you are not the intended recipient you must not copy it or use it for any purpose nor disclose or distribute its contents to any other person. All communications may be subject to interception or monitoring for operational and/or security purposes. Please rely on your own virus checking as the sender cannot accept any liability for any damage arising from any bug or virus infection. Recipient shall control the disclosure & access of technical data, information, and other items received under this e-mail in accordance with U.S. export control laws & regulations, including but not limited to the ITAR. No technical data, information or other items provided by Ultra Electronics - DNE Technologies, Inc. in connection with this email shall be provided to any foreign persons or to a foreign entity, including without limitation, a foreign subsidiary of recipient without the express written authorization of Ultra Electronics - DNE Technologies, Inc.; dissemination to non-U.S. persons whether in the United States or abroad requires an export license or other authorization -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Apr 28 07:44:45 2015 From: rt at openssl.org (Dima Tisnek via RT) Date: Tue, 28 Apr 2015 09:44:45 +0200 Subject: [openssl-dev] [openssl.org #3226] In-Reply-To: References: Message-ID: A patch was posted a year ago, but it's not merged in. It looks like typically errors are not checked after calls like EVP_DigestInit_ex(), is it considered unlikely, or is error always buffered in context? +nosy From rt at openssl.org Tue Apr 28 07:53:11 2015 From: rt at openssl.org (Dima Tisnek via RT) Date: Tue, 28 Apr 2015 09:53:11 +0200 Subject: [openssl-dev] [openssl.org #2883] In-Reply-To: References: Message-ID: It looks like proposed patch to srp_lib.c is obsolete, there's `return 0` there now. proposed patch to tasn_new.c is obsolete too, `if (!it)` is checked at the top of the function. I think it's time to close this ticket. +nosy From emilia at openssl.org Tue Apr 28 10:54:58 2015 From: emilia at openssl.org (=?UTF-8?Q?Emilia_K=C3=A4sper?=) Date: Tue, 28 Apr 2015 12:54:58 +0200 Subject: [openssl-dev] ecp_nistz256 correctness/constant-timedness In-Reply-To: References: Message-ID: On Sun, Apr 26, 2015 at 10:37 PM, Brian Smith wrote: > On Fri, Apr 24, 2015 at 5:54 AM, Emilia K?sper wrote: > >> commit c028254b12 fixes 1., 2. and 3. (also applied to 1.0.2). >> commit 53dd4ddf71 fixes 5 and some of 4. >> >> Still ploughing my way through the rest of error checking. >> >> > > Great. > > I want to call your attention to one particularly non-obvious failure to > handle errors correctly: > > static void ecp_nistz256_windowed_mul([...], P256_POINT *r, [...]) > { > [...] > > if ((num * 16 + 6) > OPENSSL_MALLOC_MAX_NELEMS(P256_POINT) > || (table_storage = > OPENSSL_malloc((num * 16 + 5) * sizeof(P256_POINT) + 64)) == > NULL > || (p_str = > OPENSSL_malloc(num * 33 * sizeof(unsigned char))) == NULL > || (scalars = OPENSSL_malloc(num * sizeof(BIGNUM *))) == NULL) { > ECerr(EC_F_ECP_NISTZ256_WINDOWED_MUL, ERR_R_MALLOC_FAILURE); > goto err; > } > > [...] > > err: > [...] > } > > ecp_nistz256_windowed_mul checks for errors, but it doesn't report the > fact that an error occurred to the caller, because it has return type > |void|. And, the caller doesn't check that ecp_nistz256_windowed_mul > failed; it can't because of the void return type. > Thanks again, I would have missed that! I hope I got it all now. Scroll past commit 5956b110e3 (master) or 07977739f0 (1.0.2) for all the changes. Cheers, Emilia > Cheers, > Brian > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at briansmith.org Tue Apr 28 12:19:22 2015 From: brian at briansmith.org (Brian Smith) Date: Tue, 28 Apr 2015 02:19:22 -1000 Subject: [openssl-dev] Concerns regarding bn_wexpand/bn_expand2/bn_expand_internal Message-ID: Although bn_wexpand is a private function within the crypto/bn module, it is exposed to other modules through bn_int.h. It is used from outside crypto/bn quite frequently. bn_wexpand is implemented in terms of a function called bn_expand2: /* * This is an internal function that should not be used in applications. It * ensures that 'b' has enough room for a 'words' word number and initialises * any unused part of b->d with leading zeros. It is mostly used by the * various BIGNUM routines. If there is an error, NULL is returned. If not, * 'b' is returned. */ BIGNUM *bn_expand2(BIGNUM *b, int words) { bn_check_top(b); if (words > b->dmax) { BN_ULONG *a = bn_expand_internal(b, words); if (!a) return NULL; if (b->d) OPENSSL_free(b->d); b->d = a; b->dmax = words; } bn_check_top(b); return b; } My understanding of "any unused part of b->d" would be something like |memset(b->d + b->top, 0, words - b->top)|. But, does bn_expand2 actually zeroize anything? In bn_expand_internal, we see: [...] #ifdef PURIFY /* * Valgrind complains in BN_consttime_swap because we process the whole * array even if it's not initialised yet. This doesn't matter in that * function - what's important is constant time operation (we're not * actually going to use the data) */ memset(a, 0, sizeof(BN_ULONG) * words); #endif It seems like when PURIFY is not set, then bn_expand2 is not meeting its contract. I wrote a test like so: BIGNUM b; BN_init(&b); bn_wexpand(&b, 1000); I then iterated through all the words of b to verified that all 1000 words were zero, but in fact they were not. That is concerning. Here's the RT for this changeset: https://rt.openssl.org/Ticket/Display.html?id=3415&user=guest&pass=guest Quote: "This seems to be the most pragmatic way forward, although it does have the disadvantage that this will mask any other future problems in the bn library due to incorrect unlitialised reads of this data." I think that masking such problems is too big a disadvantage to be allowed, in general, because it effectively disables uninitialized memory checking for BIGNUM, which is one of the most important things to have uninitialized memory checking for. But, if such a workaround is really needed for BN_consttime_swap, then I think that workaround should be put into BN_consttime_swap instead of into this lower-level function. Even more preferably, the fix would appear in the caller of BN_consttime_swap. Cheers, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From 7.paragc at gmail.com Tue Apr 28 19:56:01 2015 From: 7.paragc at gmail.com (Parag Chinchole) Date: Tue, 28 Apr 2015 14:56:01 -0500 Subject: [openssl-dev] out-of-bounds read in BN_mod_exp_mont_consttime Message-ID: <60FF2D54-A2C7-488A-8A05-C6D08CDDD999@gmail.com> Hi, BoringSSL reported an out-of-bounds read in BN_mod_exp_mont_consttime and appear to have patched it: https://boringssl-review.googlesource.com/#/c/1393/ How serious is this issue? Are there any plans for OpenSSL to use a similar fix too? Cheers Parag -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue Apr 28 22:34:12 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 29 Apr 2015 00:34:12 +0200 Subject: [openssl-dev] [openssl.org #2561] Re: Memory leak with SSL built-in compressions In-Reply-To: References: Message-ID: Is there any progress on this? Its been about 5 years, and folks are still having trouble with it. For example: * http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl. * http://openssl.6102.n7.nabble.com/Preferred-way-to-free-ssl-comp-methods-td48573.html * http://openssl.6102.n7.nabble.com/Small-memory-leak-on-multithreaded-server-td54921.html I know some others disagree, but that's really just bike shedding (http://bikeshed.com/).If one person feels its OK to leak memory, then that's fine. But everyone else should not be made to suffer the other's consequences. From rt at openssl.org Wed Apr 29 05:09:58 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Wed, 29 Apr 2015 07:09:58 +0200 Subject: [openssl-dev] [openssl.org #3823] [PATCH] Improve the robustness of event logging In-Reply-To: References: Message-ID: Hello, Summary: handle possible failures when writing a message to the event log. In debug builds, send data to the debugger as a last resort. Additional data: 1) Operating systems affected: all versions of Windows. 2) OpenSSL versions affected: all versions running on Windows. Thank you, Gunnar Kudrjavets -------------- next part -------------- >From b96aad8654354c4c859c72d780f56e671b6b0c4c Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Mon, 27 Apr 2015 11:14:45 -0700 Subject: [PATCH] Improve the robustness of event logging There are a couple of minor fixes here: 1) Handle the case when RegisterEventSource() fails (which it may for various reasons) and do the work of logging the event only if it succeeds. 2) Handle the case when ReportEvent() fails and do our best in debug builds to at least attempt somehow indicate that something has gone wrong. The typical situation would be someone running tools like DbMon, DBWin32, DebugView or just having the debugger attached. The intent is to make sure that at least some data will be captured so that we can save hours and days of debugging time. 3) Minor fix to change the MessageBox() flag to MB_ICONERROR. Though the value of MB_ICONERROR is the same value as MB_ICONSTOP, the intent is better conveyed by using MB_ICONERROR. Testing performed: 1) Clean compilation for debug-VC-WIN32 and VC-WIN32. 2) Good test results (nmake -f ms\ntdll.mak test) for debug-VC-WIN32 and VC-WIN32. 3) Stepped through relevant changes using WinDBG and exercised the impacted code paths. --- crypto/cryptlib.c | 26 +++++++++++++++++++++----- 1 file changed, 21 insertions(+), 5 deletions(-) diff --git a/crypto/cryptlib.c b/crypto/cryptlib.c index be4cdb0..617c105 100644 --- a/crypto/cryptlib.c +++ b/crypto/cryptlib.c @@ -413,13 +413,29 @@ void OPENSSL_showfatal(const char *fmta, ...) # if defined(_WIN32_WINNT) && _WIN32_WINNT>=0x0333 /* this -------------v--- guards NT-specific calls */ if (check_winnt() && OPENSSL_isservice() > 0) { - HANDLE h = RegisterEventSource(0, _T("OPENSSL")); - const TCHAR *pmsg = buf; - ReportEvent(h, EVENTLOG_ERROR_TYPE, 0, 0, 0, 1, 0, &pmsg, 0); - DeregisterEventSource(h); + HANDLE hEventLog = RegisterEventSource(NULL, _T("OpenSSL")); + + if (hEventLog != NULL) { + const TCHAR *pmsg = buf; + + if (!ReportEvent(hEventLog, EVENTLOG_ERROR_TYPE, 0, 0, NULL, + 1, 0, &pmsg, NULL)) { +#if defined(DEBUG) + /* + * We are in a situation where we tried to report a critical + * error and this failed for some reason. As a last resort, + * in debug builds, send output to the debugger or any other + * tool like DebugView which can monitor the output. + */ + OutputDebugString(pmsg); +#endif + } + + (void)DeregisterEventSource(hEventLog); + } } else # endif - MessageBox(NULL, buf, _T("OpenSSL: FATAL"), MB_OK | MB_ICONSTOP); + MessageBox(NULL, buf, _T("OpenSSL: FATAL"), MB_OK | MB_ICONERROR); } #else void OPENSSL_showfatal(const char *fmta, ...) -- 1.9.5.msysgit.1 From rt at openssl.org Wed Apr 29 05:10:29 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 29 Apr 2015 07:10:29 +0200 Subject: [openssl-dev] [openssl.org #3824] FEATURE: Please provide a function to unintialize the library In-Reply-To: References: Message-ID: This question crops up on occasion: How do you shutdown the OpenSSL library. See, for example: * "How to properly uninitialize OpenSSL", http://stackoverflow.com/questions/29845527/how-to-properly-uninitialize-openssl. * "Order of Cleanup to avoid memory leaks?", http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784 If you look at an answer like questions and answers http://comments.gmane.org/gmane.comp.encryption.openssl.user/50784, its non-trivial to get right. There were at least ***8*** cleanup calls, and 1 was still missed. In addition, there are some things that cannot be cleaned up because they are not accessible outside the library. For example: * ssl_comp_methods * https://rt.openssl.org/Ticket/Display.html?id=2561&user=guest&pass=guest * http://rt.openssl.org/Ticket/Display.html?id=2439&user=guest&pass=guest * https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=584968. Please provide a function to unintialize the library. I imagine it would be similar to SSL_library_init(). But rather than having it create things, it would cleanup things. From zoli at polarhome.com Wed Apr 29 07:49:55 2015 From: zoli at polarhome.com (Zoltan Arpadffy) Date: Wed, 29 Apr 2015 09:49:55 +0200 Subject: [openssl-dev] Getting Access Violation while testing "test sslv3 with client authentication" In-Reply-To: References: Message-ID: <20150429094955.40296ovnyuw6bmlf@www.polarhome.com> Hi, I am sorry for the late reply, but I was very busy nowadays with other issues. Were there any errors during the build? On polarhome's IA64 (running as SYSTEM user) is not possible to reproduce the error: SYSTEM at ia64$ <.test>tests.com test_ssl %DCL-W-NOCOMD, no command on line - reenter with alphabetic first character SYSTEM at ia64$ @<.test>tests.com test_ssl @@@ TESTS.COM ---> TEST_SSL test SSL protocol %SEARCH-I-NOMATCHES, no strings matched test sslv2 Available compression methods: NONE SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with server authentication Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with client authentication Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with both client and server authentication Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 Available compression methods: NONE SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with server authentication Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with client authentication Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with both client and server authentication Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 Available compression methods: NONE TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with server authentication Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with client authentication Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with both client and server authentication Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 via BIO pair Available compression methods: NONE SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with server authentication via BIO pair Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with client authentication via BIO pair Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2 with both client and server authentication via BIO pair Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv2, cipher SSLv2 IDEA-CBC-MD5, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 via BIO pair Available compression methods: NONE SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with server authentication via BIO pair Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with client authentication via BIO pair Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv3 with both client and server authentication via BIO pair Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 SSLv3, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 via BIO pair Available compression methods: NONE TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 w/o DHE via BIO pair Available compression methods: NONE TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with 1024 bit DHE via BIO pair Available compression methods: NONE DONE via BIO pair: TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with server authentication Available compression methods: NONE server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with client authentication via BIO pair Available compression methods: NONE client authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test sslv2/sslv3 with both client and server authentication via BIO pair Available compression methods: NONE client authentication server authentication depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 depth=1 /C=AU/O=Dodgy Brothers/CN=Dodgy CA depth=0 /C=AU/O=Dodgy Brothers/CN=Brother 1/CN=Brother 2 TLSv1.2, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-GCM-SHA384, 2048 bit RSA 1 handshakes of 256 bytes done test tls1 with 1024bit anonymous DH, multiple handshakes Available compression methods: NONE DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ADH-AES256-SHA 10 handshakes of 256 bytes done Approximate total server time: 0.08 s Approximate total client time: 0.25 s test tls1 with 1024bit RSA, no DHE, multiple handshakes Available compression methods: NONE DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA 10 handshakes of 256 bytes done Approximate total server time: 0.31 s Approximate total client time: 0.10 s test tls1 with 1024bit RSA, 1024bit DHE, multiple handshakes Available compression methods: NONE DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA DONE via BIO pair: TLSv1, cipher TLSv1/SSLv3 ECDHE-RSA-AES256-SHA, 2048 bit RSA 10 handshakes of 256 bytes done Approximate total server time: 0.33 s Approximate total client time: 0.10 s OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: VMS IA64 V8.4 options: bn(64,64) rc4(ptr,int) des(ptr,risc1,16,long) idea(int) blowfish(idx) compiler: /POINTER_SIZE=32 OPENSSLDIR: N/A Regards, Z Quoting jitu Singh : > Hi, > > I have build SSL 1.0.2 on OpenVMS IA64 8.4 but while running tests.com i am > getting some > access violation issue for SSTEST.EXE. > > I have raised a ticket in http://www.polarhome.com/horde/whups/ticket/?id=61 > with ID #61. > But didn't get any response. > PFA for details. > > Can anybody please help ? > > Thanks and Regards, > Jitu > --- WebMail, polarhome.com From rt at openssl.org Wed Apr 29 11:35:14 2015 From: rt at openssl.org (=?UTF-8?B?SmFuIEthbHXFvmE=?= via RT) Date: Wed, 29 Apr 2015 13:35:14 +0200 Subject: [openssl-dev] [openssl.org #3825] [PATCH] Add X509_STORE_clear_cache to clear CRL/cert cache In-Reply-To: <554089C7.9030500@redhat.com> References: <554089C7.9030500@redhat.com> Message-ID: Hi, when long-running process, such as httpd, uses OpenSSL and loads new CRLs or certificates over the time, they are all staying in the X509_STORE's cache. It could be really nice to have a way how to clear the cache to free the CRls/certificates from the memory. Attached patch against master does that by introducing new X509_STORE_clear_cache. Few things about the patch to point out: 1. It increases the refcount of X509_OBJECT returned by by_dir.c:get_cert_by_subject. This is needed to ensure that X509_OBJECT won't be freed when cache is cleared by another thread during get_cert_by_subject execution. This change breaks the ABI because the get_cert_by_subject semantic changed, but I haven't found another way how to do that. 2. Other refcount changes should be safe and again ensures that X509_OBJECT is not freed by another thread while used. 3. The patch changes semantic of X509_STORE.cache variable, but this variable has not been used for anything before (It is just set to 1 during initialization and never used again), so this should be safe too. In the future, it would be nice to call X509_STORE_clear_cache automatically when caching is disabled, but so far I haven't found good place where to do such call. Regards, Jan Kaluza -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-master-x509-clear.patch Type: text/x-diff Size: 6345 bytes Desc: not available URL: From berryfarm at sent.com Wed Apr 29 16:32:35 2015 From: berryfarm at sent.com (berryfarm at sent.com) Date: Wed, 29 Apr 2015 09:32:35 -0700 Subject: [openssl-dev] `make depend`, advised by ./config, fails to find stddef.h in system/compiler path. old bug (#3566) says don't bother with `make depend`? true, or another bug? Message-ID: <1430325155.3538377.260246521.59721AB6@webmail.messagingengine.com> Hi all. As prep to eventually building an Openssl instance with support for a specific hardware engine on linux/64, I'm first building a basic instance. I start with source ~/.bashrc cd /usr/local/src/openssl/openssl-1.0.2a make clean unset CFLAGS CPPFLAGS CXXFLAGS unset SHARED_LDFLAGS LDFLAGS LIBDEPS unset ZLIB_INCLUDE C_INCLUDE_PATH ./config --openssldir=/usr/local/BUILDTEST --libdir=lib64 \ threads shared enable-ec_nistp_64_gcc_128 no-idea no-ssl2 no-rc5 no-mdc2 This returns ... Since you've disabled or enabled at least one algorithm, you need to do the following before building: make depend Configured for linux-x86_64. So I exec make depend And that generates a *lot* of this noise about cannot find include file "stddef.h" making depend in crypto... make[1]: Entering directory '/usr/local/src/openssl/openssl-1.0.2a/crypto' makedepend: warning: cryptlib.c (reading /usr/include/stdlib.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: /usr/include/time.h includes /usr/include/bits/types.h more than once! Already have /usr/include/bits/types.h makedepend: warning: cryptlib.c (reading /usr/include/sys/types.h, line 146): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/alloca.h, line 24): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/string.h, line 32): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h makedepend: warning: cryptlib.c (reading /usr/include/unistd.h, line 226): cannot find include file "stddef.h" not in ./stddef.h not in ../stddef.h not in ../include/stddef.h not in /usr/include/stddef.h ... On my system locate stddef.h /usr/include/linux/stddef.h /usr/lib64/gcc/x86_64-suse-linux/4.8/include/stddef.h /usr/lib64/gcc/x86_64-suse-linux/5/include/stddef.h and gcc's cpp search path is cpp -v Using built-in specs. COLLECT_GCC=cpp Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada,go --enable-checking=release --with-gxx-include-dir=/usr/include/c++/5 --enable-ssp --disable-libssp --disable-libvtv --enable-libmpx --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --with-default-libstdcxx-abi=c++98 --enable-version-specific-runtime-libs --enable-linker-build-id --enable-linux-futex --program-suffix=-5 --without-system-libunwind --enable-multilib --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux Thread model: posix gcc version 5.1.1 (SUSE Linux) COLLECT_GCC_OPTIONS='-E' '-v' '-mtune=generic' '-march=x86-64' /usr/lib64/gcc/x86_64-suse-linux/5/cc1 -E -quiet -v - -mtune=generic -march=x86-64 #include "..." search starts here: #include <...> search starts here: >>> /usr/lib64/gcc/x86_64-suse-linux/5/include /usr/local/include /usr/lib64/gcc/x86_64-suse-linux/5/include-fixed /usr/lib64/gcc/x86_64-suse-linux/5/../../../../x86_64-suse-linux/include /usr/include End of search list. Not that it's authoritative, but Wikipedia suggests (https://en.wikipedia.org/wiki/Makedepend) that 'makedepend' has "become superseded by the dependency generation facilities of various compilers, and is now used primarily as a worst-case fallback, e.g. by depcomp and GNU Automake" Also at this bug for an older version of openssl Dr. Stephen Henson had said "#3566: make depend failes" https://rt.openssl.org/Ticket/Display.html?id=3566#txn-49052 openssl-1.0.1j Obviously this needs fixing but as a workaround: if you're building from scratch (or after "make clean") it should compile fine with without doing "make depend". (1) Is the problem with my build because this bug hasn't been fixed yet in 1.0.2a? (2) Is `makedepend` the problem, and should something else be used? (3) Is that advice to not exec "make depend" correct, even though the output of the configure step says specifically to exec it? Thanks, Barry From rt at openssl.org Thu Apr 30 08:09:59 2015 From: rt at openssl.org (John Foley via RT) Date: Thu, 30 Apr 2015 10:09:59 +0200 Subject: [openssl-dev] [openssl.org #3826] Contribution/Patch In-Reply-To: <554111CE.9000600@cisco.com> References: <554111CE.9000600@cisco.com> Message-ID: This may be considered a bug. When doing a FIPS build of OpenSSL 1.0.2a, some ciphers leverage the FIPS flavor of the cipher even when FIPS mode is disabled. This impacts performance since the FIPS ciphers incur additional overhead. The attached patch changes this behavior to only invoke the FIPS flavor of a cipher when FIPS mode is enabled. -------------- next part -------------- A non-text attachment was scrubbed... Name: fipscipher.patch Type: text/x-patch Size: 3003 bytes Desc: not available URL: From rt at openssl.org Thu Apr 30 11:05:19 2015 From: rt at openssl.org (daniel@poradnik-webmastera.com via RT) Date: Thu, 30 Apr 2015 13:05:19 +0200 Subject: [openssl-dev] [openssl.org #3827] Suspicious valgrind report In-Reply-To: <20150430122146.Horde.Lotz3X-92h3MLB371p-qgA1@sirzooro.prohost.pl> References: <20150430122146.Horde.Lotz3X-92h3MLB371p-qgA1@sirzooro.prohost.pl> Message-ID: Hi, I build OpenSSL 1.0.1m on Linux/RedHat with -DPURIFY option and tried to analyze my app using Valgrind. Thanks to -DPURIFY most warnings about uninitialized memory are gone, but not all. Remaining ones share common signature - uninitialized memory comes from stack allocation in aesni_cbc_encrypt(): ==8922== Conditional jump or move depends on uninitialised value(s) ==8922== [cut but cut, various places in my app] ==8922== Uninitialised value was created by a stack allocation ==8922== at 0x566D77: aesni_cbc_encrypt (in /path/myapp) I did not check if this is real bug or unpurified place. Please take a look on this and fix it. Regards, Daniel From rt at openssl.org Thu Apr 30 14:28:20 2015 From: rt at openssl.org (Stephen Henson via RT) Date: Thu, 30 Apr 2015 16:28:20 +0200 Subject: [openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions In-Reply-To: References: Message-ID: On Wed Apr 29 00:34:11 2015, noloader at gmail.com wrote: > Is there any progress on this? > See SSL_COMP_free_compression_methods(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From porten at froglogic.com Thu Apr 30 14:50:52 2015 From: porten at froglogic.com (Harri Porten) Date: Thu, 30 Apr 2015 16:50:52 +0200 (CEST) Subject: [openssl-dev] Test coverage report + small patch Message-ID: Hi! In case you are interested in seeing the condition/decision source code coverage as achieved through the OpenSSL test suite: http://www.opencoverage.net/projects/openssl/index_html/sources.html We now regularly generate the reports from the tip of the master branch. In the hope that it'll be useful for those touching and wanting to know how well it is tested. Condition/decision coverage uncovers test combinations normally hidden in line or statement coverage. Hence the much lower result of 29.6%. A long way to go still :} Please let us know if you notice that we should extend the build or test configuration to enable or run more components of the code. Some of the dead code findings may be harmless. Still, changes like the attached one for b_sock.c will fix cases like http://www.opencoverage.net/projects/openssl/index_html/source_565.html#line688 and make the code more understandable at the same time. Maybe it's even an unwanted leftover? Harri. -------------- next part -------------- A non-text attachment was scrubbed... Name: b_sock.diff Type: text/x-diff Size: 678 bytes Desc: URL: From andrejs.igumenovs at gmail.com Thu Apr 30 16:41:23 2015 From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs) Date: Thu, 30 Apr 2015 19:41:23 +0300 Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: References: Message-ID: <16221C5E-F585-47F7-ADA0-6B6E6E6052A3@gmail.com> Hi Harri, This looks helpful for those writing unit tests. It would be cool to have a similar thing for the unit test coverage. (https://wiki.openssl.org/index.php/Unit_Testing) - Andrejs > On 30.04.2015, at 17:50, Harri Porten wrote: > > Hi! > > In case you are interested in seeing the condition/decision source code coverage as achieved through the OpenSSL test suite: > > http://www.opencoverage.net/projects/openssl/index_html/sources.html > > We now regularly generate the reports from the tip of the master branch. In the hope that it'll be useful for those touching and wanting to know how well it is tested. > > Condition/decision coverage uncovers test combinations normally hidden in line or statement coverage. Hence the much lower result of 29.6%. A long way to go still :} > > Please let us know if you notice that we should extend the build or test configuration to enable or run more components of the code. > > Some of the dead code findings may be harmless. Still, changes like the attached one for b_sock.c will fix cases like > http://www.opencoverage.net/projects/openssl/index_html/source_565.html#line688 and make the code more understandable at the same time. Maybe it's even an unwanted leftover? > > Harri. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Apr 30 18:03:05 2015 From: rt at openssl.org (Stefan Titze via RT) Date: Thu, 30 Apr 2015 20:03:05 +0200 Subject: [openssl-dev] [openssl.org #3828] OpenSSL random number generator initialization causes a deadlock on Windows In-Reply-To: <04489bc58cd8440f86498a0ed624ffd1@GILDOR.baramundi.net> References: <04489bc58cd8440f86498a0ed624ffd1@GILDOR.baramundi.net> Message-ID: Hi, we discoverd a bug in the PRND initialization of OpenSSL (version 1.0.1j, but the code in the current version is identical) when executed on Windows 7 SP1. We're assuming that the problem is very likely to occur on all Windows Versions. The function RAND_poll that is used to seed the PRND walks through heap entries (rand_win.c lines 430 - 478). A deadlock can occur when another thread is implicitly creating a low fragmentation heap at the same time the OpenSSL thread traverses the heap. Details why this can happen are explained below. Here is our WinDbg session output. In this output the deadlock situation is clearly visible: Critical Sections 0:000> !locks ... CritSec +630138 at 00630138 WaiterWoken No LockCount 8 RecursionCount 1 OwningThread 600 EntryCount 0 ContentionCount 6e *** Locked CritSec +38c0138 at 038c0138 WaiterWoken No LockCount 1 RecursionCount 1 OwningThread 52c EntryCount 0 ContentionCount 2 *** Locked ... Thread Callstacks Callstack of Thread 600 # ChildEBP RetAddr Args to Child 00 03bcec98 77339e2e 00000540 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 03bcecfc 77339d12 00000000 00000000 03bceeac ntdll!RtlpWaitOnCriticalSection+0x13e 02 03bced24 7733782a 038c0138 00000000 00000000 ntdll!RtlEnterCriticalSection+0x150 03 03bced58 773bf9d6 038c0000 74fc9206 03bceeec ntdll!RtlLockHeap+0x3d 04 03bcee40 7738de9e 03bceeac 773a3dc5 00000000 ntdll!RtlpQueryExtendedHeapInformation+0xbd 05 03bcee80 773a445d 00000000 00000002 03bceeac ntdll!RtlQueryHeapInformation+0x4a 06 03bcef24 77383320 04830000 75030000 03bcefec ntdll!RtlQueryProcessHeapInformation+0x288 07 03bcefa0 750c5f33 000004ec 00000014 04830000 ntdll!RtlQueryProcessDebugInformation+0x28a 08 03bcefd0 100526b6 04830000 d7b8ddca 00000014 kernel32!Heap32Next+0x4d 09 03bcf4e4 1004e3c4 00000000 00004000 03826c00 lib!RAND_poll+0x586 0a 03bcf538 1004e7a3 03826d08 00000010 00000001 lib!ssleay_rand_bytes+0xd4 0b 03bcf54c 1005a4f5 03826d08 00000010 006e5001 lib!ssleay_rand_pseudo_bytes+0x13 0c 03bcf568 1012445f 101b2ba8 d7b8d822 006e50a8 lib!SSL_CTX_new+0x2a5 ... Callstack of Thread 52c # ChildEBP RetAddr Args to Child 00 0338f3f8 77339e2e 00000454 00000000 00000000 ntdll!NtWaitForSingleObject+0x15 01 0338f45c 77339d12 00000000 00000000 00630000 ntdll!RtlpWaitOnCriticalSection+0x13e 02 0338f484 77339f93 00630138 74788926 00078000 ntdll!RtlEnterCriticalSection+0x150 03 0338f560 77333074 000003f8 00000400 00000000 ntdll!RtlpAllocateHeap+0x159 04 0338f5e4 77338593 00630000 00800000 000003f8 ntdll!RtlAllocateHeap+0x23a 05 0338f630 77337a87 00000028 74788a86 04190048 ntdll!RtlpAllocateUserBlock+0xae 06 0338f6c0 7732e0f2 04190048 04190048 00000000 ntdll!RtlpLowFragHeapAllocFromContext+0x802 07 0338f734 77337489 00630000 00000000 00000020 ntdll!RtlAllocateHeap+0x206 08 0338f744 77333fb3 038c0000 04190048 00000000 ntdll!RtlpAllocateDebugInfo+0x28 09 0338f780 773342f4 04190048 00000000 00000000 ntdll!RtlInitializeCriticalSectionEx+0x93 0a 0338f794 7733ee0d 04190048 04190048 038c0000 ntdll!RtlInitializeCriticalSection+0x12 0b 0338f7a8 7733eddb 00000000 00000800 038c0000 ntdll!RtlpInitializeLowFragHeap+0x28 0c 0338f7b8 7733eb85 74788bb6 038c00cc 038c0000 ntdll!RtlpCreateLowFragHeap+0x28 0d 0338f7f0 7733ec2d 038c0000 038c021c 0338f8dc ntdll!RtlpActivateLowFragmentationHeap+0xc9 0e 0338f800 7733ebf9 038c0000 7478849a 72c8d09c ntdll!RtlpPerformHeapMaintenance+0x2a 0f 0338f8dc 77333074 0000008c 00000098 038c021c ntdll!RtlpAllocateHeap+0x172 10 0338f960 72c85b50 038c0000 00000008 0000008c ntdll!RtlAllocateHeap+0x23a 11 0338f99c 754459b1 024b4a54 0338faa8 00000000 nlaapi!WSM_NSPLookupServiceBegin_v2+0x5e 12 0338f9b8 7544598d 024b4a18 0338faa8 00000000 ws2_32!NSPROVIDER::NSPLookupServiceBegin+0x1b 13 0338f9d4 7544591c 024b4dd8 0338faa8 00000000 ws2_32!NSPROVIDERSTATE::LookupServiceBegin+0x1d 14 0338fa38 754457cc 024d63b8 0338faa8 00000210 ws2_32!NSQUERY::LookupServiceBegin+0x18d 15 0338fa88 7566ea34 0338faa8 00000210 0069c3a8 ws2_32!WSALookupServiceBeginW+0x7f 16 0338fafc 7566e987 00000000 0338fb24 75663577 wininet!NLA_NET_CHANGE::Initialize+0xa3 17 0338fb08 75663577 00000001 00000000 00000000 wininet!CheckForNetworkChange+0x26 18 0338fb24 756590bf 037accb8 037b86e8 00000000 wininet!CFsm_HttpSendRequest::RunSM+0x98 19 0338fb64 75659779 037b86e8 00000000 00000000 wininet!CFsm::Run+0x7a 1a 0338fb7c 75686366 037be640 75665e5d 0339528c wininet!DoFsm+0x25 1b 0338fbcc 756838ca 00cc000c 00000000 00000000 wininet!HttpWrapSendRequest+0x1ce 1c 0338fbf0 756d1b16 00cc000c 00000000 00000000 wininet!InternalHttpSendRequestA+0x1d 1d 0338fc48 101076ec 00cc000c 00000000 00000000 wininet!HttpSendRequestA+0x36 ... Conclusions Notes: - The first parameter of RtlEnterCriticalSection is the pointer to the critical section the caller wants to lock. - The first parameter of RtlAllocateHeap is the heap handle - The first parameter of RtlLockHeap is the heap handle The threads are in a deadlock situation because: - Thread 600 o Locks critical section 00630138 o Waits for critical section 038c0138 - Thread 52c o Locks critical section 038c0138 o Waits for critical section 00630138 ? Deadlock Why does the deadlock occur? - Thread 600 locks the critical section 00630138. This critical section belongs to the heap 00630000. I don't know why thread 600 keeps this critical section locked. - Thread 52c allocates memory on heap 038c0000. The heap is locked (critical section 038c0138). - Thread 600 wants to query extended heap information for the heap 038c0000 and waits because the heap is locked (critical section 038c0138). - Thread 52c: Windows decides to activate the low fragmentation feature on the heap 038c0000. - Thread 52c: Windows creates a new critical section and wants to store the critical section in the heap 00630000. - Thread 52c: Because the heap 00630000 is locked (critical section 00630138) thread 52c wait. - Now thread 52c and 600 are in a deadlock situation and the heap 038c0000 and 00630000 are locked forever which blocks other threads too. What does this mean: - It isn't a good idea to traverse heaps on Windows operating systems. How to fix the problem: Note: We've analyzed three different deadlock situations on two different machines. The callstacks for all deadlocks are nearly identical. The same problem was reported by different users too: http://openssl.6102.n7.nabble.com/Deadlock-in-RAND-poll-s-Heap32First-call-td2614.html http://rt.openssl.org/Ticket/Display.html?id=2485&user=guest&pass=guest We're changed our code in a way that we're avoiding the deadlock situation by reading some random bytes from the random number generator in a static initializer. This initializes the PRND at process start. But this workaround just lowers the probability that the deadlock occurs. Generally on Windows, heap data should not be used as a source for the random number generator initialization. Therefore we're recommending to remove the heap traversing code in RAND_poll. Mit freundlichen Gr??en Stefan Titze Entwicklung [cid:baramundi_LOGO_Mailsignatur.jpg] baramundi software AG Beim Glaspalast 1 86153 Augsburg stefan.titze at baramundi.de www.baramundi.de Fon: +49 (821) 5 67 08 - 575 Fax: +49 (821) 5 67 08 - 19 Vorstand: Dipl.-Ing. (FH) Uwe Beikirch | Marcus Eiglsperger Aufsichtsratsvorsitzender: Rainer Liebich Sitz und Registergericht: Augsburg, HRB-Nr. 2064 | USt-IdNr. DE 210294111 [cid:14-Fujitsu_DeskView.jpg] -------------- next part -------------- A non-text attachment was scrubbed... Name: baramundi_LOGO_Mailsignatur.jpg Type: image/jpeg Size: 10149 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 14-Fujitsu_DeskView.jpg Type: image/jpeg Size: 31763 bytes Desc: not available URL: