From jeremy.farrell at oracle.com Tue Nov 1 04:29:50 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Tue, 1 Nov 2016 04:29:50 +0000 Subject: [openssl-users] libraries after the build for WIn platform In-Reply-To: References: Message-ID: I think this depends on what version of OpenSSL you're using and whether you're using static or dynamic libraries, none of which you mention. There were changes in library names in recent releases. Try reviewing the various NOTES, INSTALL, and README files for whichever version of OpenSSL you are working with. Note also that there are substantial API changes between major releases of OpenSSL; if the thing you are building expects particular names for the static or import library files, that suggests it probably expects a particular API version (not the newest one if it's expecting those names). If you use whatever version of OpenSSL the other library is expecting, it should have files with the expected names. Regards, jjf On 31/10/2016 11:41, Ernst Maurer wrote: > hi > > I'm not using openssl daily , just need to build and link it with > another library. > that lib requires libeay32.lib and ssleay32.lib. > Are these ones from OpenSSL distribution? > I've tried two options: > 1. download a few pre-built versions of the binaries > 2. build own binaries from latest git > > both cases don't contain these lib (and dll) files. > please assist > > Rgds, > Ernst -- J. J. Farrell Not speaking for Oracle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernst.maurer at gmail.com Tue Nov 1 09:25:00 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 01 Nov 2016 09:25:00 +0000 Subject: [openssl-users] libraries after the build for WIn platform In-Reply-To: References: Message-ID: Thank you for the reply, I've tried to build dynamic version (import lib + dll) so I see the libs like: openssl.lib libcrypto.lib capi.lib and some other ones, so do you mean that libeay32 and ssleay32 some depricated version ? and recommend me to go throu the git history for a looking for? (of course, I built from the head of git.) P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca) Rgds, Ernst On Tue, Nov 1, 2016 at 7:30 AM Jeremy Farrell wrote: I think this depends on what version of OpenSSL you're using and whether you're using static or dynamic libraries, none of which you mention. There were changes in library names in recent releases. Try reviewing the various NOTES, INSTALL, and README files for whichever version of OpenSSL you are working with. Note also that there are substantial API changes between major releases of OpenSSL; if the thing you are building expects particular names for the static or import library files, that suggests it probably expects a particular API version (not the newest one if it's expecting those names). If you use whatever version of OpenSSL the other library is expecting, it should have files with the expected names. Regards, jjf On 31/10/2016 11:41, Ernst Maurer wrote: hi I'm not using openssl daily , just need to build and link it with another library. that lib requires libeay32.lib and ssleay32.lib. Are these ones from OpenSSL distribution? I've tried two options: 1. download a few pre-built versions of the binaries 2. build own binaries from latest git both cases don't contain these lib (and dll) files. please assist Rgds, Ernst -- J. J. Farrell Not speaking for Oracle. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.grasman at gmail.com Tue Nov 1 09:46:51 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Tue, 1 Nov 2016 10:46:51 +0100 Subject: [openssl-users] libraries after the build for WIn platform In-Reply-To: References: Message-ID: Hi Ernst, On Tue, Nov 1, 2016 at 10:25 AM, Ernst Maurer wrote: > Thank you for the reply, > I've tried to build dynamic version (import lib + dll) so I see the libs > like: > openssl.lib > libcrypto.lib > capi.lib > and some other ones, > > so do you mean that libeay32 and ssleay32 some depricated version ? and > recommend me to go throu the git history for a looking for? (of course, I > built from the head of git.) > > P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca) There are two generations of OpenSSL in flight at the moment: - 1.0.2, the 'old' one. Libs are named libeay32.* and ssleay32.* - 1.1.0, the 'new' one. Libs are named libcrypto*.* and libssl*.* 1.1.0 was released quite recently, so there's a good chance existing clients are more compatible with 1.0.2. We're building 1.0.2 from released source packages so I'm not sure about the details, but if you have a git clone there should be a tag or branch you could check out. - Kim From jeremy.farrell at oracle.com Tue Nov 1 09:48:19 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Tue, 1 Nov 2016 09:48:19 +0000 Subject: [openssl-users] libraries after the build for WIn platform In-Reply-To: References: Message-ID: I'd recommend using the official releases rather than the work-in-progress code at the head of git. Whoever looks after the library which needs OpenSSL should be able to tell you what version it needs, but from those names it's the 1.0.2 branch or earlier. 1.0.2 will be supported until the end of 2019, and its latest release is 1.0.2j. It's available from the downloads page at https://www.openssl.org/source/ and there may be built binary distributions available elsewhere. Regards, jjf On 01/11/2016 09:25, Ernst Maurer wrote: > Thank you for the reply, > I've tried to build dynamic version (import lib + dll) so I see the > libs like: > openssl.lib > libcrypto.lib > capi.lib > and some other ones, > > so do you mean that libeay32 and ssleay32 some depricated version ? > and recommend me to go throu the git history for a looking for? (of > course, I built from the head of git.) > > P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca) > > Rgds, > Ernst > > On Tue, Nov 1, 2016 at 7:30 AM Jeremy Farrell > > wrote: > > I think this depends on what version of OpenSSL you're using and > whether you're using static or dynamic libraries, none of which > you mention. There were changes in library names in recent > releases. Try reviewing the various NOTES, INSTALL, and README > files for whichever version of OpenSSL you are working with. > > Note also that there are substantial API changes between major > releases of OpenSSL; if the thing you are building expects > particular names for the static or import library files, that > suggests it probably expects a particular API version (not the > newest one if it's expecting those names). If you use whatever > version of OpenSSL the other library is expecting, it should have > files with the expected names. > > Regards, > jjf > > On 31/10/2016 11:41, Ernst Maurer wrote: >> hi >> >> I'm not using openssl daily , just need to build and link it with >> another library. >> that lib requires libeay32.lib and ssleay32.lib. >> Are these ones from OpenSSL distribution? >> I've tried two options: >> 1. download a few pre-built versions of the binaries >> 2. build own binaries from latest git >> >> both cases don't contain these lib (and dll) files. >> please assist >> >> Rgds, >> Ernst > -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ernst.maurer at gmail.com Tue Nov 1 09:49:29 2016 From: ernst.maurer at gmail.com (Ernst Maurer) Date: Tue, 01 Nov 2016 09:49:29 +0000 Subject: [openssl-users] libraries after the build for WIn platform In-Reply-To: References: Message-ID: Thank you! That is clear. ??, 01 ??? 2016 ?., 12:47 Kim Gr?sman : > Hi Ernst, > > On Tue, Nov 1, 2016 at 10:25 AM, Ernst Maurer > wrote: > > Thank you for the reply, > > I've tried to build dynamic version (import lib + dll) so I see the libs > > like: > > openssl.lib > > libcrypto.lib > > capi.lib > > and some other ones, > > > > so do you mean that libeay32 and ssleay32 some depricated version ? and > > recommend me to go throu the git history for a looking for? (of course, I > > built from the head of git.) > > > > P.S. I need this for the linking with Microsoft REST SDK (aka Casablanca) > > There are two generations of OpenSSL in flight at the moment: > > - 1.0.2, the 'old' one. Libs are named libeay32.* and ssleay32.* > - 1.1.0, the 'new' one. Libs are named libcrypto*.* and libssl*.* > > 1.1.0 was released quite recently, so there's a good chance existing > clients are more compatible with 1.0.2. > > We're building 1.0.2 from released source packages so I'm not sure > about the details, but if you have a git clone there should be a tag > or branch you could check out. > > - Kim > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Nov 1 09:54:39 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 01 Nov 2016 10:54:39 +0100 (CET) Subject: [openssl-users] [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031 In-Reply-To: <20161031142938.GA97772@doctor.nl2k.ab.ca> References: <20161031142938.GA97772@doctor.nl2k.ab.ca> Message-ID: <20161101.105439.1148965401617886766.levitte@openssl.org> I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and in both cases, that test goes through with no trouble at all. Could you tell us your exact configuration? If I recall correctly, you have your own hacked configuration, right? Cheers, Richard In message <20161031142938.GA97772 at doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 08:29:38 -0600, The Doctor said: doctor> I saw this yesterday as well doctor> doctor> ../util/shlib_wrap.sh ./heartbeat_test doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1 doctor> ** test_dtls1_not_bleeding failed ** doctor> -------- doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1 doctor> ** test_dtls1_not_bleeding_empty_payload failed ** doctor> -------- doctor> test_tls1_not_bleeding failed: expected return value 0, received -1 doctor> ** test_tls1_not_bleeding failed ** doctor> -------- doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1 doctor> ** test_tls1_not_bleeding_empty_payload failed ** doctor> -------- doctor> 4 tests failed doctor> *** Error code 1 doctor> doctor> Stop. doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test doctor> *** Error code 1 doctor> doctor> Please fix doctor> doctor> -- doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! doctor> http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism doctor> Time for the USA to hold a referendum on its republic and vote to dissolve!! doctor> -- doctor> openssl-dev mailing list doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev doctor> From Nauman.Hameed at enghouse.com Tue Nov 1 13:41:56 2016 From: Nauman.Hameed at enghouse.com (Nauman Hameed) Date: Tue, 1 Nov 2016 13:41:56 +0000 Subject: [openssl-users] Key wrapping methods for NIST 800-38F Message-ID: Hi Guys We are using OpenSLL 1.0.2j with FIPS Object Module (FOM) 2.0.10. We want to implement a key-wrapping mechanism in accordance with NIST publication 800-38F. This publication requires use of AES Key Wrap, AES Key Wrap With Padding, or Triple DEA Key Wrap. I wanted to know if we can use any of these in FIPS and/or non-FIPS mode with the OpenSSL 1.0.2j + FOM 2.0.10? If it is not possible to use these in FIPS or non-FIPS modes with above versions, which versions should be used? Please note that we are using the Microsoft Windows platform. Thanks Regards Nauman -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Tue Nov 1 14:11:09 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 1 Nov 2016 08:11:09 -0600 Subject: [openssl-users] [openssl-dev] Still seeing test failure in openssl 1.0.2 SNAPHOT 20161031 In-Reply-To: <20161101.105439.1148965401617886766.levitte@openssl.org> References: <20161031142938.GA97772@doctor.nl2k.ab.ca> <20161101.105439.1148965401617886766.levitte@openssl.org> Message-ID: <20161101141109.GD27402@doctor.nl2k.ab.ca> On Tue, Nov 01, 2016 at 10:54:39AM +0100, Richard Levitte wrote: > I just tested on two systems, Debian [unstable] and FreeBSD 8.4, and > in both cases, that test goes through with no trouble at all. > > Could you tell us your exact configuration? If I recall correctly, > you have your own hacked configuration, right? > > Cheers, > Richard Certainly, My configuration script is #!/usr/local/bin/bash CC=/usr/local/bin/clang39 ./Configure --prefix=/usr/ BSD-x86_64 enable-gmp experimental-jpake enable-rfc3779 enable-shared zlib-dynamic disable-sctp experimental-store enable-ssl-trace enable-unit-test; make depend > > In message <20161031142938.GA97772 at doctor.nl2k.ab.ca> on Mon, 31 Oct 2016 08:29:38 -0600, The Doctor said: > > doctor> I saw this yesterday as well > doctor> > doctor> ../util/shlib_wrap.sh ./heartbeat_test > doctor> test_dtls1_not_bleeding failed: expected return value 0, received -1 > doctor> ** test_dtls1_not_bleeding failed ** > doctor> -------- > doctor> test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1 > doctor> ** test_dtls1_not_bleeding_empty_payload failed ** > doctor> -------- > doctor> test_tls1_not_bleeding failed: expected return value 0, received -1 > doctor> ** test_tls1_not_bleeding failed ** > doctor> -------- > doctor> test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1 > doctor> ** test_tls1_not_bleeding_empty_payload failed ** > doctor> -------- > doctor> 4 tests failed > doctor> *** Error code 1 > doctor> > doctor> Stop. > doctor> make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161031/test > doctor> *** Error code 1 > doctor> > doctor> Please fix > doctor> > doctor> -- > doctor> Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > doctor> God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > doctor> http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > doctor> Time for the USA to hold a referendum on its republic and vote to dissolve!! > doctor> -- > doctor> openssl-dev mailing list > doctor> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > doctor> -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! From k1000.c at gmail.com Tue Nov 1 15:29:11 2016 From: k1000.c at gmail.com (Camiel C. Coppelmans) Date: Tue, 1 Nov 2016 11:29:11 -0400 Subject: [openssl-users] SSL_Write() returns error SSL_ERROR_SYSCALL with errno 11, and it wants caller to try again Message-ID: Hi, I did encounter a situation which I think could be better handled by openssl lib. In my system, when working under heavy load, sometimes while calling SSL_Write, it will return SSL_ERROR_SYSCALL, which we treated as an error and aborted the operation. Next time, when we wanted to send a new packet, passing a new buffer with a different length to the SSL_Write function, it returns the error SSL_ERROR_SSL with the following details: *140701061253440:error:1409F07F:SSL routines:ssl3_write_pending:bad write retry:s3_pkt.c:1097* Meaning that SSL_Write was actually expecting us to call it again with the same buffer and length that was used when it returned SSL_ERROR_SYSCALL. It turns out that when SSL_Write returned SSL_ERROR_SYSCALL, errno value was set to 11 (EAGAIN or EWOULDBLOCK), so I figured out that, although openssl didn't explicitly indicate us to try again, the underling socket did, therefore I started to handle this specific scenario the same way I would if SSL_Write would have returned SSL_ERROR_WANT_WRITE, and it worked. My question is: Is it ok to trust the errno in this scenario? Can I handle it that way I handled? And two: If Openssl is expecting us to retry the SSL_Write call, it should have returned SSL_ERROR_WANT_WRITE, like it does for all other scenarios. So, maybe it is something to be improved for a future release. This issue happened in the following versions: 0.9.8zb and 1.0.2e Thanks, Camiel -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 1 16:42:58 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Nov 2016 16:42:58 +0000 Subject: [openssl-users] Problems with cert authentication under Turkish locale In-Reply-To: <3a2fe67c-c3a1-4133-3bcd-47946a5c87ca@snafu.de> References: <3a2fe67c-c3a1-4133-3bcd-47946a5c87ca@snafu.de> Message-ID: <20161101164258.GH26244@mournblade.imrryr.org> On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: [ Redirecting to openssl-users. ] > We have problems authenticating a a CERT while LC_CTYPE is set to > tr_TR.UTF-8 > > The issue is triggered in libcurl but it seems to come out of libssl. It > seems to be I see nothing in the OpenSSL X.509 stack that would be sensitive to this locale. In particular, with OpenSSL >= 1.0.2 doing the hostname check, both: LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com and LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com return success. OpenSSL 1.0.1 and earlier do not do hostname checks, that's left to the application. With 1.0.1 the chain alone verifies just fine: $ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem CONNECTED(00000003) depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 verify return:1 depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3 verify return:1 depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Washington, businessCategory = Private Organization, serialNumber = 600413485, C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = mail.live.com verify return:1 --- Certificate chain 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 --- Server certificate -----BEGIN CERTIFICATE----- ... -----END CERTIFICATE----- subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 --- No client certificate CA names sent --- SSL handshake has read 5342 bytes and written 511 bytes --- New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-SHA384 Session-ID: ... Session-ID-ctx: Master-Key: ... Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1478018209 Timeout : 300 (sec) Verify return code: 0 (ok) So it seems that any problem lies with libcurl. -- Viktor. From jb-openssl at wisemo.com Tue Nov 1 17:15:01 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 1 Nov 2016 18:15:01 +0100 Subject: [openssl-users] Problems with cert authentication under Turkish locale In-Reply-To: <20161101164258.GH26244@mournblade.imrryr.org> References: <3a2fe67c-c3a1-4133-3bcd-47946a5c87ca@snafu.de> <20161101164258.GH26244@mournblade.imrryr.org> Message-ID: <5399ffc4-be60-1478-c391-bb92f91bc012@wisemo.com> On 01/11/2016 17:42, Viktor Dukhovni wrote: > On Tue, Nov 01, 2016 at 04:28:18PM +0100, Sebastian Kloska wrote: > > [ Redirecting to openssl-users. ] (I cannot see the original posts, as I am only subscribed to -users). >> We have problems authenticating a a CERT while LC_CTYPE is set to >> tr_TR.UTF-8 >> >> The issue is triggered in libcurl but it seems to come out of libssl. It >> seems to be Note that the Turkish UNICODE locales have the unusual property that the uppercase/lowercase routines do not match ASCII "I" to ASCII "i", to cater to the distinguishing between "dotted" and "dotless" letter I in Turkish natural language. It is the only known locales to case map an ASCII character differently than the basic ASCII algorithm presumed by the standard for Internet host names. So something, in either OpenSSL or curl (or a combination) may (on the OPs system) be using a locale-sensitive function to compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind of locale-neutral function should be used to avoid the special handling that the Unicode standard specifies for the letter "I" in Turkish. > I see nothing in the OpenSSL X.509 stack that would be sensitive > to this locale. In particular, with OpenSSL >= 1.0.2 doing the > hostname check, both: > > LANG=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com > > and > > LC_CTYPE=tr_TR.UTF-8 /Volumes/gitvol/viktor/ssl/OpenSSL_1_0_2/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem -verify_hostname www.hotmail.com > > return success. OpenSSL 1.0.1 and earlier do not do hostname > checks, that's left to the application. With 1.0.1 the chain alone > verifies just fine: > > $ LC_CTYPE=tr_TR.UTF-8 /.../OpenSSL_1_0_1/bin/openssl s_client -connect www.hotmail.com:443 -CAfile /tmp/bundle.pem > CONNECTED(00000003) > depth=2 C = US, O = "VeriSign, Inc.", OU = VeriSign Trust Network, OU = "(c) 2006 VeriSign, Inc. - For authorized use only", CN = VeriSign Class 3 Public Primary Certification Authority - G5 > verify return:1 > depth=1 C = US, O = Symantec Corporation, OU = Symantec Trust Network, CN = Symantec Class 3 EV SSL CA - G3 > verify return:1 > depth=0 1.3.6.1.4.1.311.60.2.1.3 = US, 1.3.6.1.4.1.311.60.2.1.2 = Washington, businessCategory = Private Organization, serialNumber = 600413485, C = US, postalCode = 98052, ST = Washington, L = Redmond, street = 1 Microsoft Way, O = Microsoft Corporation, OU = Outlook Kahuna BAY-A Jun2015, CN = mail.live.com > verify return:1 > --- > Certificate chain > 0 s:/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com > i:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 > 1 s:/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 > i:/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=(c) 2006 VeriSign, Inc. - For authorized use only/CN=VeriSign Class 3 Public Primary Certification Authority - G5 > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=/1.3.6.1.4.1.311.60.2.1.3=US/1.3.6.1.4.1.311.60.2.1.2=Washington/businessCategory=Private Organization/serialNumber=600413485/C=US/postalCode=98052/ST=Washington/L=Redmond/street=1 Microsoft Way/O=Microsoft Corporation/OU=Outlook Kahuna BAY-A Jun2015/CN=mail.live.com > issuer=/C=US/O=Symantec Corporation/OU=Symantec Trust Network/CN=Symantec Class 3 EV SSL CA - G3 > --- > No client certificate CA names sent > --- > SSL handshake has read 5342 bytes and written 511 bytes > --- > New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA384 > Server public key is 2048 bit > Secure Renegotiation IS supported > Compression: NONE > Expansion: NONE > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES256-SHA384 > Session-ID: ... > Session-ID-ctx: > Master-Key: ... > Key-Arg : None > PSK identity: None > PSK identity hint: None > SRP username: None > Start Time: 1478018209 > Timeout : 300 (sec) > Verify return code: 0 (ok) > > So it seems that any problem lies with libcurl. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Nov 1 17:53:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 1 Nov 2016 17:53:20 +0000 Subject: [openssl-users] Problems with cert authentication under Turkish locale In-Reply-To: <5399ffc4-be60-1478-c391-bb92f91bc012@wisemo.com> References: <3a2fe67c-c3a1-4133-3bcd-47946a5c87ca@snafu.de> <20161101164258.GH26244@mournblade.imrryr.org> <5399ffc4-be60-1478-c391-bb92f91bc012@wisemo.com> Message-ID: <20161101175320.GJ26244@mournblade.imrryr.org> On Tue, Nov 01, 2016 at 06:15:01PM +0100, Jakob Bohm wrote: > >>The issue is triggered in libcurl but it seems to come out of libssl. It > >>seems to be > > Note that the Turkish UNICODE locales have the unusual property > that the uppercase/lowercase routines do not match ASCII "I" to > ASCII "i", to cater to the distinguishing between "dotted" and > "dotless" letter I in Turkish natural language. It is the only > known locales to case map an ASCII character differently than the > basic ASCII algorithm presumed by the standard for Internet host > names. Indeed, but the hostname comparison code in OpenSSL 1.0.2+ does not uses none of the locale-sensitive tolower(), toupper(), str[n]casecmp() to do name comparison: /* Compare while ASCII ignoring case. */ static int equal_nocase(const unsigned char *pattern, size_t pattern_len, const unsigned char *subject, size_t subject_len, unsigned int flags) { skip_prefix(&pattern, &pattern_len, subject_len, flags); if (pattern_len != subject_len) return 0; while (pattern_len) { unsigned char l = *pattern; unsigned char r = *subject; /* The pattern must not contain NUL characters. */ if (l == 0) return 0; if (l != r) { if ('A' <= l && l <= 'Z') l = (l - 'A') + 'a'; if ('A' <= r && r <= 'Z') r = (r - 'A') + 'a'; if (l != r) return 0; } ++pattern; ++subject; --pattern_len; } return 1; } The only use of strncasecmp() is to compare the first four characters of an A-label with with "xn--". No known locale breaks that, and there's no "xn--" in "www.hotmail.com". The inputs are required to be A-labels, so Unicode is out of scope: https://www.openssl.org/docs/man1.1.0/crypto/X509_check_host.html Per section 6.4.2 of RFC 6125, name values representing international domain names must be given in A-label form. The namelen argument must be the number of characters in the name string or zero in which case the length is calculated with strlen(name). When name starts with a dot (e.g ".example.com"), it will be matched by a certificate valid for any sub-domain of name, (see also X509_CHECK_FLAG_SINGLE_LABEL_SUBDOMAINS below). Perhaps similar language should be added to: https://www.openssl.org/docs/man1.1.0/ssl/SSL_set1_host.html SSL_set1_host() sets the expected DNS hostname to name clearing any previously specified host name or names. If name is NULL, or the empty string the list of hostnames is cleared, and name checks are not performed on the peer certificate. When a non-empty name is specified, certificate verification automatically checks the peer hostname via X509_check_host with flags as specified via SSL_set_hostflags(). Clients that enable DANE TLSA authentication via SSL_dane_enable should leave it to that function to set the primary reference identifier of the peer, and should not call SSL_set1_host(). Some users may not delve deeper and read the X509_check_host() documentation. Documentation patches welcome. > So something, in either OpenSSL or curl (or a combination) may > (on the OPs system) be using a locale-sensitive function to > compare e.g. "hotmail.com" and "HOTMAIL.COM", where some kind > of locale-neutral function should be used to avoid the special > handling that the Unicode standard specifies for the letter "I" > in Turkish. > > >I see nothing in the OpenSSL X.509 stack that would be sensitive > >to this locale. In particular, with OpenSSL >= 1.0.2 doing the > >hostname check, both: It is hard to see where OpenSSL could be going astray. It is true that on Windows OpenSSL provides an OPENSSL_str[n]casecmp() that compares by mapping to upper case. Perhaps libcurl is using that? The name constraint code might hypothetically not work right in the Turkish locale, because it uses the locale-sensitive strcasecmp(). That should be fixed, but is not pertinent to the OP's report. -- Viktor. From o.andriyanov at gmail.com Tue Nov 1 23:16:54 2016 From: o.andriyanov at gmail.com (Oleg Andriyanov) Date: Wed, 2 Nov 2016 02:16:54 +0300 Subject: [openssl-users] Is it safe to share single X509_STORE between multiple threads for verifying certificate? Message-ID: Hello, I'd like a clarify a little bit about multithreaded use of X509_verify_cert. Use case: I want connections to be accepted and served in a network thread and delegate all certificate checking to another thread (or even thread pool). CA for all certificates to be checked is stored in a single |X509_STORE|. Basically, when certificate is received from a client, I create new |X509_STORE_CTX|, initialize it with a single (say, global) |X509_STORE|, and feed a worker thread with a checking routine which calls |X509_verify_cert|. The question is, does this kind of thread-sharing of |X509_STORE| need any external locking provided by an application? Particularly, I'm worried because |X509_STORE_CTX_init| takes a non-const pointer of my |X509_STORE|. Probably, this is because this function modifies reference counters inside the store, which is thread-safe provided that locking callbacks are set during initialization of the library. There should be no other non-const access to the store, right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dlipubkey at gmail.com Wed Nov 2 02:57:19 2016 From: dlipubkey at gmail.com (David Li) Date: Tue, 1 Nov 2016 19:57:19 -0700 Subject: [openssl-users] Alert number 43 Message-ID: Hi, When I tested a remote server using s_client, it responded with: verify return:1 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:598: I found the the following URL about this: http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top My question: Does this indicate something wrong with server side certificate like the URL said? Thanks. David From noloader at gmail.com Wed Nov 2 03:07:13 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 1 Nov 2016 23:07:13 -0400 Subject: [openssl-users] Alert number 43 In-Reply-To: References: Message-ID: > When I tested a remote server using s_client, it responded with: > > verify return:1 > > 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 > alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 > > 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl > handshake failure:s3_pkt.c:598: > > > I found the the following URL about this: > > http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top > > My question: Does this indicate something wrong with server side > certificate like the URL said? Netscape Cert Type was recently removed, IIRC. OpenSSL servers [used to?] have a bug where they can't use the EC key pair they generated for use with an EC-based certificate. Also see http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves. Post the certificate. Use `openssl s_client -connect : -tls1 -servername | openssl x509 -text -noout` Jeff From ishanthakur41 at yahoo.in Wed Nov 2 13:41:09 2016 From: ishanthakur41 at yahoo.in (Ishan Thakur) Date: Wed, 2 Nov 2016 13:41:09 +0000 (UTC) Subject: [openssl-users] OpenSSL 1.0.2h generates libss.so.1.0.0 instead of libssl.so.1.0.2 In-Reply-To: <209029889.714083.1478093016087@mail.yahoo.com> References: <209029889.714083.1478093016087.ref@mail.yahoo.com> <209029889.714083.1478093016087@mail.yahoo.com> Message-ID: <255566131.718665.1478094069885@mail.yahoo.com> Hi ,??? Why Building OpenSSL 1.0.2h generates libss.so.1.0.0/libcrypto.so.1.0.0 and not libssl.so.1.0.2/libcrypto.so.1.0.2 ? Regards,Ishan -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Nov 2 13:56:32 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 2 Nov 2016 14:56:32 +0100 Subject: [openssl-users] OpenSSL 1.0.2h generates libss.so.1.0.0 instead of libssl.so.1.0.2 In-Reply-To: <255566131.718665.1478094069885@mail.yahoo.com> References: <209029889.714083.1478093016087.ref@mail.yahoo.com> <209029889.714083.1478093016087@mail.yahoo.com> <255566131.718665.1478094069885@mail.yahoo.com> Message-ID: <5d43f959-6faf-afee-268e-f339d6b25a9b@wisemo.com> On 02/11/2016 14:41, Ishan Thakur wrote: > > > > Hi , > Why Building OpenSSL 1.0.2h generates > libss.so.1.0.0/libcrypto.so.1.0.0 and not > libssl.so.1.0.2/libcrypto.so.1.0.2 ? > Regards, > Ishan > > Because the OpenSSL team claims that it is binary compatible (and thus a drop in upgrade for) OpenSSL 1.0.0 and all later 1.0.x versions previously released. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From doctor at doctor.nl2k.ab.ca Wed Nov 2 14:47:48 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 2 Nov 2016 08:47:48 -0600 Subject: [openssl-users] iStill seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases Message-ID: <20161102144748.GA13285@doctor.nl2k.ab.ca> Why is this not solved? ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value 0, received -1 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value 0, received -1 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value 0, received -1 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. Using FreeBSD 11 . -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! From dlipubkey at gmail.com Wed Nov 2 16:41:02 2016 From: dlipubkey at gmail.com (David Li) Date: Wed, 2 Nov 2016 09:41:02 -0700 Subject: [openssl-users] Alert number 43 In-Reply-To: References: Message-ID: Hi Jeff, I am not sure I can post the entire cert here. Is there any part in particular that would be useful to debug the Alert Number 43 problem? David On Tue, Nov 1, 2016 at 8:07 PM, Jeffrey Walton wrote: >> When I tested a remote server using s_client, it responded with: >> >> verify return:1 >> >> 139790582232992:error:14094413:SSL routines:SSL3_READ_BYTES:sslv3 >> alert unsupported certificate:s3_pkt.c:1259:SSL alert number 43 >> >> 139790582232992:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl >> handshake failure:s3_pkt.c:598: >> >> >> I found the the following URL about this: >> >> http://stackoverflow.com/questions/14435839/ssl-alert-43-when-doing-client-authentication-in-ssl?answertab=oldest#tab-top >> >> My question: Does this indicate something wrong with server side >> certificate like the URL said? > > Netscape Cert Type was recently removed, IIRC. > > OpenSSL servers [used to?] have a bug where they can't use the EC key > pair they generated for use with an EC-based certificate. Also see > http://wiki.openssl.org/index.php/Elliptic_Curve_Cryptography#Named_Curves. > > Post the certificate. Use `openssl s_client -connect : > -tls1 -servername | openssl x509 -text -noout` > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From talkbits at gmail.com Wed Nov 2 16:55:51 2016 From: talkbits at gmail.com (IT Guru) Date: Wed, 2 Nov 2016 11:55:51 -0500 Subject: [openssl-users] Most recent OpenSSL version supported by Windows 2003 Message-ID: Hi I am building a Windows 2003 system, which is the latest (stable) version supported on a 2003 system? Keep in mind Windows 2003 does not support TLS 1.1 or TLS 1.2. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 2 17:00:27 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 2 Nov 2016 17:00:27 +0000 Subject: [openssl-users] [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases In-Reply-To: <20161102144748.GA13285@doctor.nl2k.ab.ca> References: <20161102144748.GA13285@doctor.nl2k.ab.ca> Message-ID: <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com> > Why is this not solved? It will be solved before the next release. No further promises. From doctor at doctor.nl2k.ab.ca Wed Nov 2 17:04:46 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 2 Nov 2016 11:04:46 -0600 Subject: [openssl-users] [openssl-dev] iStill seeing heartbeat prolem in openssl 1.0.2 STABLE Daily releases In-Reply-To: <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20161102144748.GA13285@doctor.nl2k.ab.ca> <5c6b04015a5545409935d3a5a44fb19d@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20161102170446.GB4023@doctor.nl2k.ab.ca> On Wed, Nov 02, 2016 at 05:00:27PM +0000, Salz, Rich wrote: > > > Why is this not solved? > > It will be solved before the next release. No further promises. I will report back tomorrow. Still It is a good thing to gripe if you see an issue. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Time for the USA to hold a referendum on its republic and vote to dissolve!! From jb-openssl at wisemo.com Wed Nov 2 17:07:16 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 2 Nov 2016 18:07:16 +0100 Subject: [openssl-users] Most recent OpenSSL version supported by Windows 2003 In-Reply-To: References: Message-ID: On 02/11/2016 17:55, IT Guru wrote: > Hi I am building a Windows 2003 system, which is the latest (stable) > version supported on a 2003 system? Keep in mind Windows 2003 does not > support TLS 1.1 or TLS 1.2. > I recently did a successful compile and test of version 1.0.2j (the latest version with the classic API) on an XP i386 system. Since XP i386 is NT 5.01 and Server 2003 is NT 5.02 I guess the current 1.0.2j release should work (including TLS 1.1 and TLS 1.2 code, since OpenSSL doesn't need Windows own crypto except as a way to initialize the random number generator). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From richard.stanek at rockwellcollins.com Wed Nov 2 22:23:34 2016 From: richard.stanek at rockwellcollins.com (Richard Stanek) Date: Wed, 2 Nov 2016 17:23:34 -0500 Subject: [openssl-users] C++ : Extracting CRL from a PKCS12 Message-ID: My original requirements were to extract the user certificate, the private key, and the CAs. For that I was using the call to PKCS12_parse(...). This satisfied the original requirements. Very easy to find, understand, and use. The new requirements that I have are that I also need to extract a CRL from that PKCS12. I see that there is a CRLBag defined in the IETF RFC 7292 PKCS12 Standard (https://tools.ietf.org/html/rfc7292), so I know a CRL could exist inside a PKCS12. I can't seem to find any API or C++ examples that extract a CRL from a PKSC12. Is there an API, example code, or advice on how to extract a CRL from a PKCS12? Thank you for your time, Rick From veredz72 at gmail.com Thu Nov 3 05:06:20 2016 From: veredz72 at gmail.com (Zvi Vered) Date: Thu, 3 Nov 2016 07:06:20 +0200 Subject: [openssl-users] openssl-1.1.0b : Getting keys from TPM Message-ID: <5A5D364E552E43F791DD320DA928607C@DESKTOPIMSMU5Q> Hello, I want to use openssl in order to send\receive encrypted messages to a server. My Target has TPM. Can you please explain how to configure the openssl library to take public+private keys from TPM ? Should I use a specific TPM library ? Thank you, Z.V From akshar.kanak1 at gmail.com Thu Nov 3 06:26:16 2016 From: akshar.kanak1 at gmail.com (Akshar Kanak) Date: Thu, 3 Nov 2016 11:56:16 +0530 Subject: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM) Message-ID: Dear team as per the documnet http://csrc.nist.gov/groups/STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 150 , Its mentioned The implementation of the nonce_explicit management logic inside the module shall ensure that when the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key (e.g., a 64-bit counter starting from 0 and increasing, when it reaches the maximum value of 2 64 -1), *either party (the client or the server) that encounters this condition triggers a handshake to establish a new encryption key ? see Sections 7.4.1.1 and 7.4.1.2 in RFC 5246*. is this being handled by openssl ? in the source code of openssl i am not able find out the exact location where this renegotiation is initiated when the counter over flows ? Thanks in advance Thanks and regards Akshar -------------- next part -------------- An HTML attachment was scrubbed... URL: From sreeees at gmail.com Thu Nov 3 11:30:51 2016 From: sreeees at gmail.com (Sreekanth Sukumaran) Date: Thu, 3 Nov 2016 17:00:51 +0530 Subject: [openssl-users] OpenSSL 1.0.1 branch : setting Diffie Hellman Elliptic curve name via SSL_set_tmp_ecdh and EC_KEY_new_by_curve_name Message-ID: Hi All, In our project, we are currently supporting two branches of OpenSSL (1.0.1 and 1.0.2) Recently we had a requirement to enable elliptic curve Diffie Hellman, we see that in OpenSSL 1.0.2 branch, we can use the below function to enable ECDH /* Set automatic curve selection for server ssl to onoff.If onoff is 1 then the highest preference curve is automatically used for ECDH temporary keys used during key exchange. */ (void)SSL_set_ecdh_auto(ssl, 1); However in OpenSSL 1.0.1 the ECDH curve name has to be explicitly set by the calling function. We researched about this and in one of the examples in OpenSSL wiki at https://wiki.openssl.org/index.php/Elliptic_Curve_Diffie_Hellman we have found that *"**NID_X9_62_prime256v1" *is used. Hence for OpenSSL 1.0.1, we have the implementation as below sECDH = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1); // secp256r1 curve - referred as prime256v1 (void)SSL_set_tmp_ecdh(ssl, sECDH); However we are wondering, whether there is any recommendation for the choice of the named elliptic curve. Is any particular recommended ? Any suggestions in this regard is much appreciated. -- Regards, Sreekanth -------------- next part -------------- An HTML attachment was scrubbed... URL: From ishanthakur41 at yahoo.in Thu Nov 3 11:29:53 2016 From: ishanthakur41 at yahoo.in (Ishan Thakur) Date: Thu, 3 Nov 2016 11:29:53 +0000 (UTC) Subject: [openssl-users] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ? References: <1501043604.654494.1478172593718.ref@mail.yahoo.com> Message-ID: <1501043604.654494.1478172593718@mail.yahoo.com> Hi , When I run "otool -L in MAC" , or "ldd in linux" machines I get the current version of OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the libraries.$ otool -L ./libssl.dylib libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) Regards, Ishan -------------- next part -------------- An HTML attachment was scrubbed... URL: From roland.peissert.ext at siemens.com Thu Nov 3 11:59:16 2016 From: roland.peissert.ext at siemens.com (Peissert, Roland (ext)) Date: Thu, 3 Nov 2016 11:59:16 +0000 Subject: [openssl-users] OpenSSL with Qt5 on Win7 Message-ID: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> Hello, I want to use OpenSSL with Qt5 on Win 7. Is there any tutorial or how do or documentation, how to install and recompile OpenSSL and Qt5 on Win7 ? 1. I download still install Win 7 with Visual Studio 2015 2. Then I install Q5 with Visual Studio AddOn for Qt 3. Next I download OpenSSL openssl-1.1.0b.tar.gz from here: http://www.openssl.org/source 4. And I install Active Perl 5. I made one folder C:\libsopenssl 6. When I compile OpenSSL with this command: perl Configure VC-WIN32 no-asm --prefix=c:\libsopenssl 7. I receive this error: [cid:image001.png at 01D2359E.43028830] Thank you in advanced. Best Regards Roland Peissert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 45571 bytes Desc: image001.png URL: From richmoore44 at gmail.com Thu Nov 3 12:41:57 2016 From: richmoore44 at gmail.com (Richard Moore) Date: Thu, 3 Nov 2016 12:41:57 +0000 Subject: [openssl-users] OpenSSL with Qt5 on Win7 In-Reply-To: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> References: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> Message-ID: On 3 November 2016 at 11:59, Peissert, Roland (ext) < roland.peissert.ext at siemens.com> wrote: > 3. Next I download OpenSSL openssl-1.1.0b.tar.gz from here: > http://www.openssl.org/source > > > > ?Qt doesn't support openssl 1.1 currently. Cheers Rich. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu Nov 3 12:53:56 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 03 Nov 2016 13:53:56 +0100 (CET) Subject: [openssl-users] [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ? In-Reply-To: <1501043604.654494.1478172593718@mail.yahoo.com> References: <1501043604.654494.1478172593718.ref@mail.yahoo.com> <1501043604.654494.1478172593718@mail.yahoo.com> Message-ID: <20161103.135356.1571694957013623952.levitte@openssl.org> Hi, I'm curious. Why exactly do you want to change the shared library version? That being said, this is not a good idea. I hope I explained why well enough in the thread with the subject "OpenSSL 1.0.2h generates libss.so.1.0.0 instead of libssl.so.1.0.2" started by you on openssl-dev. For reference, you can find my answer here: https://mta.openssl.org/pipermail/openssl-dev/2016-November/008665.html Cheers, Richard In message <1501043604.654494.1478172593718 at mail.yahoo.com> on Thu, 3 Nov 2016 11:29:53 +0000 (UTC), Ishan Thakur said: ishanthakur41> Hi , ishanthakur41> When I run "otool -L in MAC" , or "ldd in linux" machines I get the current version of OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the libraries. ishanthakur41> $ otool -L ./libssl.dylib ishanthakur41> libssl.1.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) ishanthakur41> ishanthakur41> Regards, ishanthakur41> Ishan From michel.sales at free.fr Thu Nov 3 13:02:47 2016 From: michel.sales at free.fr (Michel) Date: Thu, 3 Nov 2016 14:02:47 +0100 Subject: [openssl-users] OpenSSL with Qt5 on Win7 In-Reply-To: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> References: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> Message-ID: <002901d235d2$93de0110$bb9a0330$@sales@free.fr> Hi, As nmake is not in your current path, it looks like you didn?t launch the ?Developer Command Prompt for Visual Studio?. Regards, Michel. De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Peissert, Roland (ext) Envoy? : jeudi 3 novembre 2016 12:59 ? : openssl-users at openssl.org Objet : [openssl-users] OpenSSL with Qt5 on Win7 Hello, I want to use OpenSSL with Qt5 on Win 7. Is there any tutorial or how do or documentation, how to install and recompile OpenSSL and Qt5 on Win7 ? 1. I download still install Win 7 with Visual Studio 2015 2. Then I install Q5 with Visual Studio AddOn for Qt 3. Next I download OpenSSL openssl-1.1.0b.tar.gz from here: http://www.openssl.org/source 4. And I install Active Perl 5. I made one folder C:\libsopenssl 6. When I compile OpenSSL with this command: perl Configure VC-WIN32 no-asm ?-prefix=c:\libsopenssl 7. I receive this error: cid:image001.png at 01D2359E.43028830 Thank you in advanced. Best Regards Roland Peissert -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.png Type: image/png Size: 45571 bytes Desc: not available URL: From kim.grasman at gmail.com Thu Nov 3 13:14:35 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Thu, 3 Nov 2016 14:14:35 +0100 Subject: [openssl-users] OpenSSL with Qt5 on Win7 In-Reply-To: <581b3590.52181c0a.ca714.2dc3SMTPIN_ADDED_BROKEN@mx.google.com> References: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> <581b3590.52181c0a.ca714.2dc3SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On Thu, Nov 3, 2016 at 2:02 PM, Michel wrote: > Hi, > > > > As nmake is not in your current path, it looks like you didn?t launch the > ?Developer Command Prompt for Visual Studio?. > > > > > For posterity, I've gotten that message even when nmake is on the path. Invoking nmake afterwards works fine. - Kim -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Nov 3 13:19:43 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Nov 2016 13:19:43 +0000 Subject: [openssl-users] OpenSSL with Qt5 on Win7 In-Reply-To: References: <1C0FC67BD0448248B39BEFBBDAF7A7B10C0A833B@DEFTHW99EK5MSX.ww902.siemens.net> <581b3590.52181c0a.ca714.2dc3SMTPIN_ADDED_BROKEN@mx.google.com> Message-ID: On 03/11/16 13:14, Kim Gr?sman wrote: > On Thu, Nov 3, 2016 at 2:02 PM, Michel > wrote: > > Hi,____ > > __ __ > > As nmake is not in your current path, it looks like you didn?t > launch the ?Developer Command Prompt for Visual Studio?.____ > > __ __ > > > > For posterity, I've gotten that message even when nmake is on the path. > Invoking nmake afterwards works fine. It comes from perl not OpenSSL. I'm not sure why - some problem in the perl setup I think. Matt From kgoldman at us.ibm.com Thu Nov 3 15:21:58 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 3 Nov 2016 09:21:58 -0600 Subject: [openssl-users] openssl-1.1.0b : Getting keys from TPM In-Reply-To: <5A5D364E552E43F791DD320DA928607C@DESKTOPIMSMU5Q> References: <5A5D364E552E43F791DD320DA928607C@DESKTOPIMSMU5Q> Message-ID: A few comments: 1 - Does "take ... keys" mean read then out of the TPM. 2 - Getting a public key from the TPM is easy. Getting the private key is harder. In addition, some keys can be created so that the private part never leaves the TPM. 3 - You have to specify whether this is TPM 1.2 or TPM 2.0. Then I may be able to point you to sample code. On 11/2/2016 11:06 PM, Zvi Vered wrote: > > I want to use openssl in order to send\receive encrypted messages to a > server. > > My Target has TPM. > > Can you please explain how to configure the openssl library to take > public+private keys from TPM ? > > Should I use a specific TPM library ? > From veredz72 at gmail.com Thu Nov 3 16:02:04 2016 From: veredz72 at gmail.com (Zvi Vered) Date: Thu, 3 Nov 2016 18:02:04 +0200 Subject: [openssl-users] openssl-1.1.0b : Getting keys from TPM In-Reply-To: References: <5A5D364E552E43F791DD320DA928607C@DESKTOPIMSMU5Q> Message-ID: Hi Ken, 1. I mean: read from TPM 2. In order to create an SSL session with the server, should I need also the private key ? 3. I want to use TPM 2.0 Thank you for your help, Z.V On Thu, Nov 3, 2016 at 5:21 PM, Ken Goldman wrote: > A few comments: > > 1 - Does "take ... keys" mean read then out of the TPM. > > 2 - Getting a public key from the TPM is easy. Getting the private key is > harder. In addition, some keys can be created so that the private part > never leaves the TPM. > > 3 - You have to specify whether this is TPM 1.2 or TPM 2.0. Then I may be > able to point you to sample code. > > > On 11/2/2016 11:06 PM, Zvi Vered wrote: > >> >> I want to use openssl in order to send\receive encrypted messages to a >> server. >> >> My Target has TPM. >> >> Can you please explain how to configure the openssl library to take >> public+private keys from TPM ? >> >> Should I use a specific TPM library ? >> >> > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Thu Nov 3 12:58:40 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Thu, 3 Nov 2016 13:58:40 +0100 Subject: [openssl-users] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ? In-Reply-To: <1501043604.654494.1478172593718@mail.yahoo.com> References: <1501043604.654494.1478172593718.ref@mail.yahoo.com> <1501043604.654494.1478172593718@mail.yahoo.com> Message-ID: <72165154-343d-d3db-396a-8168b7361c44@fedict.be> Hi Ishan, On 03-11-16 12:29, Ishan Thakur wrote: > Hi , > > When I run "otool -L in MAC" , or "ldd in linux" machines I get the _current version_ of OpenSSL as 1.0.0 but I have built OpenSSL v1.0.2h , how to change this "current version" in the libraries. > > $ otool -L ./libssl.dylib > libssl.1.0.0.dylib (compatibility version 1.0.0, _current version 1.0.0_) You should NOT confuse the shared library version with the version of the software package. The two are not related (except when the developers misunderstand how library versioning works), and trying to keep the two in sync is bound to make things break. For more information, see , ?3.3. -- Wouter Verhelst From akshar.kanak1 at gmail.com Fri Nov 4 04:33:21 2016 From: akshar.kanak1 at gmail.com (Akshar Kanak) Date: Fri, 4 Nov 2016 10:03:21 +0530 Subject: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM) Message-ID: Dear team as per the documnet http://csrc.nist.gov/groups/ STM/cmvp/documents/fips140-2/FIPS1402IG.pdf page 150 , Its mentioned The implementation of the nonce_explicit management logic inside the module shall ensure that when the nonce_explicit part of the IV exhausts the maximum number of possible values for a given session key (e.g., a 64-bit counter starting from 0 and increasing, when it reaches the maximum value of 2 64 -1), *either party (the client or the server) that encounters this condition triggers a handshake to establish a new encryption key ? see Sections 7.4.1.1 and 7.4.1.2 in RFC 5246*. is this being handled by openssl ? in the source code of openssl i am not able find out the exact location where this renegotiation is initiated when the counter over flows ? Thanks in advance Thanks and regards Akshar -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nauman.Hameed at enghouse.com Fri Nov 4 05:14:03 2016 From: Nauman.Hameed at enghouse.com (Nauman Hameed) Date: Fri, 4 Nov 2016 05:14:03 +0000 Subject: [openssl-users] Key wrapping methods for NIST 800-38F In-Reply-To: References: Message-ID: <63bba82595954defa58b0f43102f7282@UK-MAIL-001.edge.local> Hi Guys Can anyone please provide some feedback on this? Thanks in advance. Regards Nauman From: Nauman Hameed Sent: Tuesday, November 1, 2016 6:42 PM To: 'openssl-users at openssl.org' Subject: Key wrapping methods for NIST 800-38F Hi Guys We are using OpenSLL 1.0.2j with FIPS Object Module (FOM) 2.0.10. We want to implement a key-wrapping mechanism in accordance with NIST publication 800-38F. This publication requires use of AES Key Wrap, AES Key Wrap With Padding, or Triple DEA Key Wrap. I wanted to know if we can use any of these in FIPS and/or non-FIPS mode with the OpenSSL 1.0.2j + FOM 2.0.10? If it is not possible to use these in FIPS or non-FIPS modes with above versions, which versions should be used? Please note that we are using the Microsoft Windows platform. Thanks Regards Nauman -------------- next part -------------- An HTML attachment was scrubbed... URL: From srangari at avaya.com Fri Nov 4 06:53:52 2016 From: srangari at avaya.com (Rangari, Sahil (Sahil)) Date: Fri, 4 Nov 2016 06:53:52 +0000 Subject: [openssl-users] Does the OpenSSL site has translation for error codes: Error code is: 12 Message-ID: Hi, I have been looking for a description of what certain error codes mean on the OpenSSL site, but could not found any. Earlier there used to be page for the error codes. I would like to know what exactly this error means: @20160901 11:09:17.372 #9768 [.\emspopclient.cpp at 960] EMSPOPClient::tlsconnect Server Response Network Layer Error- Error message is: X.509 certificate has invalid signature @20160901 11:09:17.372 #9768 [.\emspopclient.cpp at 960] EMSPOPClient::tlsconnect Server Response Network Layer Error code is: 12 The above is a trace from an OpenSSL client. Does it means that the certificate presented by the OpenSSL server is invalid OR The CA chain at the client is invalid OR The CRL is invalid If you do have page that list the error descriptions then it would be good. Thanks, Sahil -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Nov 4 07:05:05 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 4 Nov 2016 08:05:05 +0100 Subject: [openssl-users] Does the OpenSSL site has translation for error codes: Error code is: 12 In-Reply-To: References: Message-ID: <819a42a1-9291-03a4-9bce-42188a36e420@wisemo.com> On 04/11/2016 07:53, Rangari, Sahil (Sahil) wrote: > > Hi, > > I have been looking for a description of what certain error codes mean > on the OpenSSL site, but could not found any. > > Earlier there used to be page for the error codes. > > I would like to know what exactly this error means: > > @20160901 11:09:17.372 #9768 [.\emspopclient.cpp at 960] > > *EMSPOPClient::tlsconnect Server Response Network Layer Error- Error > message is: X.509 certificate has invalid signature* > > @20160901 11:09:17.372 #9768 [.\emspopclient.cpp at 960] > > EMSPOPClient::tlsconnect Server Response Network Layer Error code is: 12 > > The above is a trace from an OpenSSL client. > > Does it means that the certificate presented by the OpenSSL server is > invalid OR > The CA chain at the client is invalid OR > > The CRL is invalid > > If you do have page that list the error descriptions then it would be > good. > See https://www.openssl.org/docs/faq.html#PROG7 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From meissner at suse.de Fri Nov 4 08:26:00 2016 From: meissner at suse.de (Marcus Meissner) Date: Fri, 4 Nov 2016 09:26:00 +0100 Subject: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM) In-Reply-To: References: Message-ID: <20161104082600.GC28927@suse.de> On Fri, Nov 04, 2016 at 10:03:21AM +0530, Akshar Kanak wrote: > Dear team > as per the documnet http://csrc.nist.gov/groups/ > STM/cmvp/documents/fips140-2/FIPS1402IG.pdf > page 150 , Its mentioned > The implementation of the nonce_explicit management logic inside the > module shall ensure that > when the nonce_explicit part of the IV exhausts the maximum number of > possible values for a given > session key (e.g., a 64-bit counter starting from 0 and increasing, > when it reaches the maximum value > of 2 64 -1), > *either party (the client or the server) that encounters this condition > triggers a handshake to establish a new encryption key ? see Sections > 7.4.1.1 and 7.4.1.2 in RFC 5246*. > > is this being handled by openssl ? in the source code of openssl i am > not able find out the > exact location where this renegotiation is initiated when the counter > over flows ? (my understanding might be limited) I think we currently do an error if the calling frontend does not initiate renegotiation. Code is here: crypto/modes/gcm128.c CRYPTO_gcm128_encrypt_ctr32 These kind of checks avoid the 32bit counter overflow: if (mlen > ((U64(1) << 36) - 32) || (sizeof(len) == 8 && mlen < len)) return -1; The calling instance needs to re-iv with CRYPTO_gcm128_setiv. For TLS, if I understand correctly, the stack does intiailize the GCM cipher with a new IV on every TLS record and these cannot be that large. Ciao, Marcus From jb-openssl at wisemo.com Fri Nov 4 12:14:19 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 4 Nov 2016 13:14:19 +0100 Subject: [openssl-users] [FIPS compliance] ssl reneg when counter overflows(AES_GCM) In-Reply-To: <20161104082600.GC28927@suse.de> References: <20161104082600.GC28927@suse.de> Message-ID: <5746ed27-5919-572e-fbf9-69891f52398d@wisemo.com> On 04/11/2016 09:26, Marcus Meissner wrote: > On Fri, Nov 04, 2016 at 10:03:21AM +0530, Akshar Kanak wrote: >> Dear team >> as per the documnet http://csrc.nist.gov/groups/ >> STM/cmvp/documents/fips140-2/FIPS1402IG.pdf >> page 150 , Its mentioned >> The implementation of the nonce_explicit management logic inside the >> module shall ensure that >> when the nonce_explicit part of the IV exhausts the maximum number of >> possible values for a given >> session key (e.g., a 64-bit counter starting from 0 and increasing, >> when it reaches the maximum value >> of 2 64 -1), >> *either party (the client or the server) that encounters this condition >> triggers a handshake to establish a new encryption key ? see Sections >> 7.4.1.1 and 7.4.1.2 in RFC 5246*. >> >> is this being handled by openssl ? in the source code of openssl i am >> not able find out the >> exact location where this renegotiation is initiated when the counter >> over flows ? > (my understanding might be limited) > > > I think we currently do an error if the calling frontend does not initiate renegotiation. > > Code is here: > crypto/modes/gcm128.c > > CRYPTO_gcm128_encrypt_ctr32 > > These kind of checks avoid the 32bit counter overflow: > > if (mlen > ((U64(1) << 36) - 32) || (sizeof(len) == 8 && mlen < len)) > return -1; > > The calling instance needs to re-iv with CRYPTO_gcm128_setiv. > > For TLS, if I understand correctly, the stack does intiailize the GCM cipher > with a new IV on every TLS record and these cannot be that large. > > Ciao, Marcus As I understand the GCM mode, the limitation is that the same IV must not be used twice, and only a limited number of all the possible IVs may be used before changing the *key*. Setting a "new" IV for each TLS record is always needed, regardless if it comes from a simple record counter or is transmitted for each record (the TLS RFCs presumable have a fixed choice for this). But to get a new *key* before too much data has been encrypted with it (such limits exist for *all* algorithms and modes), I believe that an actual TLS renegotiation is needed, involving at least a partial handshake without closing the connection. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From kurt at roeckx.be Fri Nov 4 16:05:58 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 4 Nov 2016 17:05:58 +0100 Subject: [openssl-users] [openssl-dev] After building 1.0.2h , ldd output shows current version as 1.0.0. How to CHange this , Why is this so ? In-Reply-To: <20161103.135356.1571694957013623952.levitte@openssl.org> References: <1501043604.654494.1478172593718.ref@mail.yahoo.com> <1501043604.654494.1478172593718@mail.yahoo.com> <20161103.135356.1571694957013623952.levitte@openssl.org> Message-ID: <20161104160558.sgubm5wnmaxgmyvx@roeckx.be> On Thu, Nov 03, 2016 at 01:53:56PM +0100, Richard Levitte wrote: > Hi, > > I'm curious. Why exactly do you want to change the shared library > version? I had to change the soname in Debian (because I dropped all SSLv2 and SSLv3 symbols) and changed it to 1.0.2. Kurt From viktor_jaegerskuepper at freenet.de Fri Nov 4 16:21:00 2016 From: viktor_jaegerskuepper at freenet.de (=?UTF-8?B?VmlrdG9yIErDpGdlcnNrw7xwcGVy?=) Date: Fri, 04 Nov 2016 16:21:00 +0000 Subject: [openssl-users] X25519 not listed in ecparam -list_curves Message-ID: Hi, OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH -curves X25519 -connect google.com:443" works as expected, and I get "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the output of "openssl ecparam -list_curves" in version 1.1.0b (I use 1.1.0b-2 from Debian). Should it be listed there anyway? Regards, Viktor From graeme.perrow at sap.com Sun Nov 6 05:15:50 2016 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Sun, 6 Nov 2016 05:15:50 +0000 Subject: [openssl-users] PKI encryption failing on 32-bit Solaris Message-ID: <7ae99eeb38134f138683c9cced783bca@DEWDFE13DE14.global.corp.sap> I have a small test program (source attached) that does a very simple PKI encrypt / decrypt. This program works on Windows, Linux, and Solaris (64-bit) but fails if I run a 32-bit version on Solaris 10. Solaris 11 is fine. If I use "./config -kPIC -m32 -xarch=sparc" to build OpenSSL, I get a crash in bn_mul_mont_t4_32. I added "no-asm" and it no longer crashes but I get this error output: OSSL error 4275158204:error:0407109F:rsa routines:RSA_padding_check_PKCS1_type_2:pkcs decoding error:rsa_pk1.c:272: End OSSL error decrypt failed I also tried adding -d to the config line and then the program succeeds though is very verbose. Could this be a bug in OpenSSL, or am I configuring it incorrectly, or is there a bug in my code? Thanks for any insight Graeme Perrow -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: pkiencrypt.cpp URL: From Michal.Trojnara at stunnel.org Sun Nov 6 20:53:12 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Sun, 6 Nov 2016 21:53:12 +0100 Subject: [openssl-users] stunnel 5.37 released Message-ID: <470b3521-3d72-b2b1-cc2c-08826e48136e@stunnel.org> Dear Users, I have released version 5.37 of stunnel. Version 5.37, 2016.11.06, urgency: MEDIUM * Bugfixes - OpenSSL DLLs updated to version 1.0.2j (stops crashes). - The default SNI target (not handled by any slave service) is handled by the master service rather than rejected. - Removed thread synchronization in the FORK threading model. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: d0e3530e3effc64fdec792c71791d4937c6b8bd3b9ea4895c6bb6526dcd0d241 stunnel-5.37.tar.gz b1015afdfc536312b9e3556483c9bfeefd9e29d6f483d305459033272adcf4ad stunnel-5.37-installer.exe 4bda9b0116676fec7533b3c1e40b9d24f0722e6317c59be4831c19102f4a925c stunnel-5.37-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From ajaygargnsit at gmail.com Mon Nov 7 10:06:18 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Mon, 7 Nov 2016 02:06:18 -0800 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit Message-ID: Hi All. Following are the steps I followed : ############################################################################### a) Downloaded nasm.exe from internet, and placed it in the include-path. b) *perl Configure VC-WIN32* c) *ms\do_nasm.bat* d) *nmake -f ms\nt.mak* e) *make* *###############################################################################* Compilation runs fine for some time, but then I get hundreds of IDENTICAL errors as follows :: ############################################################################### *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keywordtmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line expecteafter operandtmp32\sha1-586.asm:3970: error: symbol `__sha1_block_data_order_avx' redefinedtmp32\sha1-586.asm:3970: error: parser: instruction expectedtmp32\sha1-586.asm:3972: error: parser: instruction expectedtmp32\sha1-586.asm:3983: error: parser: instruction expectedtmp32\sha1-586.asm:3985: error: parser: instruction expectedtmp32\sha1-586.asm:3986: error: parser: instruction expectedtmp32\sha1-586.asm:3987: warning: label alone on a line without a colon might in errorNMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\N\nasm.EXE"' : return code '0x1'Stop.* *###############################################################################* Any pointers how to solve this? I will heartfully grateful. Thanks and Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Mon Nov 7 11:42:16 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Mon, 7 Nov 2016 03:42:16 -0800 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: Oops... pardon me. The e) step was not done. The errors came right after step d) On 7 Nov 2016 3:36 p.m., "Ajay Garg" wrote: > Hi All. > > Following are the steps I followed : > > ############################################################ > ################### > a) > Downloaded nasm.exe from internet, and placed it in the include-path. > > b) > *perl Configure VC-WIN32* > > c) > > > *ms\do_nasm.bat* > d) > > > *nmake -f ms\nt.mak* > e) > *make* > > > > > > > *###############################################################################* > Compilation runs fine for some time, but then I get hundreds of IDENTICAL > errors as follows :: > > ############################################################ > ################### > > > > > > > > > > > > > > *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM > keywordtmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of > line expecteafter operandtmp32\sha1-586.asm:3970: error: symbol > `__sha1_block_data_order_avx' redefinedtmp32\sha1-586.asm:3970: error: > parser: instruction expectedtmp32\sha1-586.asm:3972: error: parser: > instruction expectedtmp32\sha1-586.asm:3983: error: parser: instruction > expectedtmp32\sha1-586.asm:3985: error: parser: instruction > expectedtmp32\sha1-586.asm:3986: error: parser: instruction > expectedtmp32\sha1-586.asm:3987: warning: label alone on a line without a > colon might in errorNMAKE : fatal error U1077: '"C:\Program Files\Microsoft > Visual Studio 14.0\VC\N\nasm.EXE"' : return code '0x1'Stop.* > > > > > *###############################################################################* > Any pointers how to solve this? > I will heartfully grateful. > > > > Thanks and Regards, > Ajay > -------------- next part -------------- An HTML attachment was scrubbed... URL: From satta at debian.org Mon Nov 7 11:42:22 2016 From: satta at debian.org (Sascha Steinbiss) Date: Mon, 7 Nov 2016 12:42:22 +0100 Subject: [openssl-users] Duplicating const X509_NAME Message-ID: <3e6478aa-fa36-f970-7d80-88a79d0ab9ca@debian.org> Hi all, I was wondering how to properly make a clone of a const X509_NAME in OpenSSL 1.1? In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id() and would like to pass it to X509_find_by_subject() which takes a X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a local copy -- which looked like the obvious approach -- but that also only takes a non-const parameter. Any ideas? With Thanks and kind regards Sascha From ishanthakur41 at yahoo.in Mon Nov 7 12:07:24 2016 From: ishanthakur41 at yahoo.in (Ishan Thakur) Date: Mon, 7 Nov 2016 12:07:24 +0000 (UTC) Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: <1831627768.1960052.1478520444500@mail.yahoo.com> Hi Ajay ,I am not exactly sure about this , but you can try these 2 things and see if it works :1. Install NASM properly , in your case its being searched at '"C:\Program Files\Microsoft Visual Studio 14.0\VC\N\nasm.EXE"'2.? If above does not works use this command :??????? perl Configure VC-WIN32 no-asm Regards,Ishan From: Ajay Garg To: openssl-users at openssl.org Sent: Monday, 7 November 2016 5:12 PM Subject: Re: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit Oops... pardon me. The e) step was not done.The errors came right after step d) On 7 Nov 2016 3:36 p.m., "Ajay Garg" wrote: Hi All. Following are the steps I followed : ############################## ############################## ################### a) Downloaded nasm.exe from internet, and placed it in the include-path. b) perl Configure VC-WIN32 c) ms\do_nasm.bat d) nmake -f ms\nt.mak e) make ############################## ############################## ################### Compilation runs fine for some time, but then I get hundreds of IDENTICAL errors as follows :: ############################## ############################## ################### tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line expecte after operand tmp32\sha1-586.asm:3970: error: symbol `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error: parser: instruction expected tmp32\sha1-586.asm:3972: error: parser: instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction expected tmp32\sha1-586.asm:3985: error: parser: instruction expected tmp32\sha1-586.asm:3986: error: parser: instruction expected tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon might ?in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop. ############################## ############################## ################### Any pointers how to solve this? I will heartfully grateful. Thanks and Regards, Ajay -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Mon Nov 7 11:13:22 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 7 Nov 2016 11:13:22 +0000 (GMT) Subject: [openssl-users] [openssl-announce] Forthcoming OpenSSL release Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL release =========================== The OpenSSL project team would like to announce the forthcoming release of OpenSSL version 1.1.0c This release will be made available on 10th November 2016 between 1200-1600 UTC and will fix several security defects. The highest security defect being fixed is classified as severity "High", and does not affect OpenSSL versions prior to 1.1.0. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJYIGF/AAoJEAEKUEB8TIy9lzYH/2M2KpYDo9dr1Nx8KobKx/jZ uzT9lI7oXujxnauQPVvTGcbX3RYswXbWXCh6c5TUXXanLQH0RQNvWJgmrdYrIzzD 22Softp4Djf67QZqjGGssrtTVeRf2q5ShgGHfbB7ShI6BEgN9QCzaelplNIyIMvH 6CixH6li5K4RkkmgaUvkWPsXGbyra2IzPzvJJCQF8rS3OZZcvCWWUC4U5qSFyzQJ KKj8C0loHimNVAYGXubuK8rZpsPzs+GQeLWI2koJLc9T3y96yumeJP9snUsN5pUi vatIay5LxXr9xKzGl79X6k75xlrJuEAxJcImvbstFAlftgMRCjyEKy4LGyBIgqA= =5j78 -----END PGP SIGNATURE----- -- openssl-announce mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-announce From jeremy.farrell at oracle.com Mon Nov 7 16:01:03 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Mon, 7 Nov 2016 16:01:03 +0000 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: What version of OpenSSL? What version of nasm (nasm -v)? People are more likely to be able to help if you provide such basic information. Regards, jjf On 07/11/2016 11:42, Ajay Garg wrote: > > Oops... pardon me. > The e) step was not done. > > The errors came right after step d) > > > On 7 Nov 2016 3:36 p.m., "Ajay Garg" > wrote: > > Hi All. > > Following are the steps I followed : > > ############################################################################### > a) > Downloaded nasm.exe from internet, and placed it in the include-path. > > b) > *perl Configure VC-WIN32* > > c) > *ms\do_nasm.bat > > * > d)* > nmake -f ms\nt.mak > > * > e)* > * > *make* > *############################################################################### > > > * > Compilation runs fine for some time, but then I get hundreds of > IDENTICAL errors as follows :: > > ############################################################################### > *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword > tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of > line expecte > after operand > tmp32\sha1-586.asm:3970: error: symbol > `__sha1_block_data_order_avx' redefined > tmp32\sha1-586.asm:3970: error: parser: instruction expected > tmp32\sha1-586.asm:3972: error: parser: instruction expected > tmp32\sha1-586.asm:3983: error: parser: instruction expected > tmp32\sha1-586.asm:3985: error: parser: instruction expected > tmp32\sha1-586.asm:3986: error: parser: instruction expected > tmp32\sha1-586.asm:3987: warning: label alone on a line without a > colon might > in error > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual > Studio 14.0\VC\ > N\nasm.EXE"' : return code '0x1' > Stop.* > *############################################################################### > > * > Any pointers how to solve this? > I will heartfully grateful. > > Thanks and Regards, > Ajay > -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Mon Nov 7 16:22:57 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Mon, 7 Nov 2016 21:52:57 +0530 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: Oops.. sorry. OpenSSL-version is 1.0.2d, and nasm-version is 2.12.02. On Mon, Nov 7, 2016 at 9:31 PM, Jeremy Farrell wrote: > What version of OpenSSL? What version of nasm (nasm -v)? People are more > likely to be able to help if you provide such basic information. > > Regards, > jjf > > On 07/11/2016 11:42, Ajay Garg wrote: > > Oops... pardon me. > The e) step was not done. > > The errors came right after step d) > > On 7 Nov 2016 3:36 p.m., "Ajay Garg" wrote: > >> Hi All. >> >> Following are the steps I followed : >> >> ############################################################ >> ################### >> a) >> Downloaded nasm.exe from internet, and placed it in the include-path. >> >> b) >> *perl Configure VC-WIN32* >> >> c) >> >> >> *ms\do_nasm.bat * >> d) >> >> >> * nmake -f ms\nt.mak * >> e) >> *make* >> >> >> >> *############################################################################### >> * >> Compilation runs fine for some time, but then I get hundreds of IDENTICAL >> errors as follows :: >> >> ############################################################ >> ################### >> >> >> >> >> >> >> >> >> >> >> >> >> >> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword >> tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line >> expecte after operand tmp32\sha1-586.asm:3970: error: symbol >> `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error: >> parser: instruction expected tmp32\sha1-586.asm:3972: error: parser: >> instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction >> expected tmp32\sha1-586.asm:3985: error: parser: instruction expected >> tmp32\sha1-586.asm:3986: error: parser: instruction expected >> tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon >> might in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft >> Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop.* >> >> >> *############################################################################### >> * >> Any pointers how to solve this? >> I will heartfully grateful. >> >> Thanks and Regards, >> Ajay >> > > -- > J. J. Farrell > Not speaking for Oracle > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Nov 7 17:11:56 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 7 Nov 2016 12:11:56 -0500 Subject: [openssl-users] How to sort cipher list by ephemeral/non-ephemeral? Message-ID: I prefer to use a cipher list like "HIGH:!aNULL:!RC4:!MD5". I prefer it because its fairly easy to parse and understand. Its also easy to teach to developers. I want the resulting ciphers sorted with the ephemeral suites at the head of the list. How does one sort the list with ephemeral suites at the top of the list? ----- If 'openssl ciphers' is stable with respect to its output, then the order is (is this @strength?): # openssl ciphers -v 'HIGH:!aNULL:!MD5:!RC4:!PSK:!SRP:!KRB5' | cut -f 1 -d ' ' ECDHE-RSA-AES256-GCM-SHA384 ECDHE-ECDSA-AES256-GCM-SHA384 ECDHE-RSA-AES256-SHA384 ECDHE-ECDSA-AES256-SHA384 ECDHE-RSA-AES256-SHA ECDHE-ECDSA-AES256-SHA DHE-DSS-AES256-GCM-SHA384 DHE-RSA-AES256-GCM-SHA384 DHE-RSA-AES256-SHA256 DHE-DSS-AES256-SHA256 DHE-RSA-AES256-SHA DHE-DSS-AES256-SHA DHE-RSA-CAMELLIA256-SHA DHE-DSS-CAMELLIA256-SHA ECDH-RSA-AES256-GCM-SHA384 ECDH-ECDSA-AES256-GCM-SHA384 ECDH-RSA-AES256-SHA384 ECDH-ECDSA-AES256-SHA384 ECDH-RSA-AES256-SHA ECDH-ECDSA-AES256-SHA AES256-GCM-SHA384 AES256-SHA256 AES256-SHA CAMELLIA256-SHA ECDHE-RSA-AES128-GCM-SHA256 ECDHE-ECDSA-AES128-GCM-SHA256 ECDHE-RSA-AES128-SHA256 ECDHE-ECDSA-AES128-SHA256 ECDHE-RSA-AES128-SHA ECDHE-ECDSA-AES128-SHA DHE-DSS-AES128-GCM-SHA256 DHE-RSA-AES128-GCM-SHA256 DHE-RSA-AES128-SHA256 DHE-DSS-AES128-SHA256 DHE-RSA-AES128-SHA DHE-DSS-AES128-SHA DHE-RSA-CAMELLIA128-SHA DHE-DSS-CAMELLIA128-SHA ECDH-RSA-AES128-GCM-SHA256 ECDH-ECDSA-AES128-GCM-SHA256 ECDH-RSA-AES128-SHA256 ECDH-ECDSA-AES128-SHA256 ECDH-RSA-AES128-SHA ECDH-ECDSA-AES128-SHA AES128-GCM-SHA256 AES128-SHA256 AES128-SHA CAMELLIA128-SHA ECDHE-RSA-DES-CBC3-SHA ECDHE-ECDSA-DES-CBC3-SHA EDH-RSA-DES-CBC3-SHA EDH-DSS-DES-CBC3-SHA ECDH-RSA-DES-CBC3-SHA ECDH-ECDSA-DES-CBC3-SHA DES-CBC3-SHA From rsalz at akamai.com Mon Nov 7 17:29:49 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 7 Nov 2016 17:29:49 +0000 Subject: [openssl-users] How to sort cipher list by ephemeral/non-ephemeral? In-Reply-To: References: Message-ID: <34a85f79d8ee40ccb89e270a1b6cd428@usma1ex-dag1mb1.msg.corp.akamai.com> You can't do it with keywords. Be explicit about what you want and put it in the order you want. That way you will not be surprised when the expansion of a keyword changes. >From your list, ECDHE first, then decide RSA/ECDSA. Then AES-GCM. Why do you care about sha384 vs 256? Do you really need camellia-only? And @STRENGTH is a hack, looking at only one factor. Here is a real-world example (this ignores some of my advice) ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:AES256-GCM-SHA384: AES256-SHA256:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256: ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256: ECDHE-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256: -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From debbie10t at gmail.com Mon Nov 7 17:32:06 2016 From: debbie10t at gmail.com (debbie10t) Date: Mon, 7 Nov 2016 17:32:06 +0000 Subject: [openssl-users] mailing list registration renewal - clarify bounce errors Message-ID: Hi, today I received an email from openssl-users-request at openssl.org Your membership in the mailing list openssl-users has been disabled due to excessive bounces .. I can find no evidence of "excessive bounces .." so I am just asking here, is this a standard clean up of the ML or have you really received excessive bounces from my email address ? Thank you. -- From rsalz at akamai.com Mon Nov 7 17:34:07 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 7 Nov 2016 17:34:07 +0000 Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: References: Message-ID: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> > I can find no evidence of "excessive bounces .." so I am just asking here, is > this a standard clean up of the ML or have you really received excessive > bounces from my email address ? The latter. We have seen some more reports of this recently, and are increasing the logging to determine the cause. Interestingly, it's all from gmail.com addresses. From hellonotelling at gmail.com Mon Nov 7 17:39:32 2016 From: hellonotelling at gmail.com (Hello Notelling) Date: Mon, 7 Nov 2016 09:39:32 -0800 Subject: [openssl-users] openssl-users Digest, Vol 24, Issue 12 In-Reply-To: References: Message-ID: Your query is being processed On 7 Nov 2016 5:34 p.m., wrote: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: Problem in compiling OpenSSL on Windows-7-32-bit (Ajay Garg) > 2. How to sort cipher list by ephemeral/non-ephemeral? > (Jeffrey Walton) > 3. Re: How to sort cipher list by ephemeral/non-ephemeral? > (Salz, Rich) > 4. mailing list registration renewal - clarify bounce errors > (debbie10t) > 5. Re: mailing list registration renewal - clarify bounce errors > (Salz, Rich) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 7 Nov 2016 21:52:57 +0530 > From: Ajay Garg > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Problem in compiling OpenSSL on > Windows-7-32-bit > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Oops.. sorry. > OpenSSL-version is 1.0.2d, and nasm-version is 2.12.02. > > > > On Mon, Nov 7, 2016 at 9:31 PM, Jeremy Farrell > wrote: > > > What version of OpenSSL? What version of nasm (nasm -v)? People are more > > likely to be able to help if you provide such basic information. > > > > Regards, > > jjf > > > > On 07/11/2016 11:42, Ajay Garg wrote: > > > > Oops... pardon me. > > The e) step was not done. > > > > The errors came right after step d) > > > > On 7 Nov 2016 3:36 p.m., "Ajay Garg" wrote: > > > >> Hi All. > >> > >> Following are the steps I followed : > >> > >> ############################################################ > >> ################### > >> a) > >> Downloaded nasm.exe from internet, and placed it in the include-path. > >> > >> b) > >> *perl Configure VC-WIN32* > >> > >> c) > >> > >> > >> *ms\do_nasm.bat * > >> d) > >> > >> > >> * nmake -f ms\nt.mak * > >> e) > >> *make* > >> > >> > >> > >> *########################################################### > #################### > >> * > >> Compilation runs fine for some time, but then I get hundreds of > IDENTICAL > >> errors as follows :: > >> > >> ############################################################ > >> ################### > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword > >> tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line > >> expecte after operand tmp32\sha1-586.asm:3970: error: symbol > >> `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error: > >> parser: instruction expected tmp32\sha1-586.asm:3972: error: parser: > >> instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction > >> expected tmp32\sha1-586.asm:3985: error: parser: instruction expected > >> tmp32\sha1-586.asm:3986: error: parser: instruction expected > >> tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon > >> might in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft > >> Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop.* > >> > >> > >> *########################################################### > #################### > >> * > >> Any pointers how to solve this? > >> I will heartfully grateful. > >> > >> Thanks and Regards, > >> Ajay > >> > > > > -- > > J. J. Farrell > > Not speaking for Oracle > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -- > Regards, > Ajay > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161107/55d53de6/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Mon, 7 Nov 2016 12:11:56 -0500 > From: Jeffrey Walton > To: OpenSSL Users > Subject: [openssl-users] How to sort cipher list by > ephemeral/non-ephemeral? > Message-ID: > gmail.com> > Content-Type: text/plain; charset=UTF-8 > > I prefer to use a cipher list like "HIGH:!aNULL:!RC4:!MD5". I prefer > it because its fairly easy to parse and understand. Its also easy to > teach to developers. > > I want the resulting ciphers sorted with the ephemeral suites at the > head of the list. > > How does one sort the list with ephemeral suites at the top of the list? > > ----- > > If 'openssl ciphers' is stable with respect to its output, then the > order is (is this @strength?): > > # openssl ciphers -v 'HIGH:!aNULL:!MD5:!RC4:!PSK:!SRP:!KRB5' | cut -f 1 > -d ' ' > ECDHE-RSA-AES256-GCM-SHA384 > ECDHE-ECDSA-AES256-GCM-SHA384 > ECDHE-RSA-AES256-SHA384 > ECDHE-ECDSA-AES256-SHA384 > ECDHE-RSA-AES256-SHA > ECDHE-ECDSA-AES256-SHA > DHE-DSS-AES256-GCM-SHA384 > DHE-RSA-AES256-GCM-SHA384 > DHE-RSA-AES256-SHA256 > DHE-DSS-AES256-SHA256 > DHE-RSA-AES256-SHA > DHE-DSS-AES256-SHA > DHE-RSA-CAMELLIA256-SHA > DHE-DSS-CAMELLIA256-SHA > ECDH-RSA-AES256-GCM-SHA384 > ECDH-ECDSA-AES256-GCM-SHA384 > ECDH-RSA-AES256-SHA384 > ECDH-ECDSA-AES256-SHA384 > ECDH-RSA-AES256-SHA > ECDH-ECDSA-AES256-SHA > AES256-GCM-SHA384 > AES256-SHA256 > AES256-SHA > CAMELLIA256-SHA > ECDHE-RSA-AES128-GCM-SHA256 > ECDHE-ECDSA-AES128-GCM-SHA256 > ECDHE-RSA-AES128-SHA256 > ECDHE-ECDSA-AES128-SHA256 > ECDHE-RSA-AES128-SHA > ECDHE-ECDSA-AES128-SHA > DHE-DSS-AES128-GCM-SHA256 > DHE-RSA-AES128-GCM-SHA256 > DHE-RSA-AES128-SHA256 > DHE-DSS-AES128-SHA256 > DHE-RSA-AES128-SHA > DHE-DSS-AES128-SHA > DHE-RSA-CAMELLIA128-SHA > DHE-DSS-CAMELLIA128-SHA > ECDH-RSA-AES128-GCM-SHA256 > ECDH-ECDSA-AES128-GCM-SHA256 > ECDH-RSA-AES128-SHA256 > ECDH-ECDSA-AES128-SHA256 > ECDH-RSA-AES128-SHA > ECDH-ECDSA-AES128-SHA > AES128-GCM-SHA256 > AES128-SHA256 > AES128-SHA > CAMELLIA128-SHA > ECDHE-RSA-DES-CBC3-SHA > ECDHE-ECDSA-DES-CBC3-SHA > EDH-RSA-DES-CBC3-SHA > EDH-DSS-DES-CBC3-SHA > ECDH-RSA-DES-CBC3-SHA > ECDH-ECDSA-DES-CBC3-SHA > DES-CBC3-SHA > > > ------------------------------ > > Message: 3 > Date: Mon, 7 Nov 2016 17:29:49 +0000 > From: "Salz, Rich" > To: "noloader at gmail.com" , > "openssl-users at openssl.org" > Subject: Re: [openssl-users] How to sort cipher list by > ephemeral/non-ephemeral? > Message-ID: > <34a85f79d8ee40ccb89e270a1b6cd428 at usma1ex-dag1mb1.msg.corp. > akamai.com> > Content-Type: text/plain; charset="Windows-1252" > > You can't do it with keywords. Be explicit about what you want and put it > in the order you want. That way you will not be surprised when the > expansion of a keyword changes. > > >From your list, ECDHE first, then decide RSA/ECDSA. Then AES-GCM. Why > do you care about sha384 vs 256? Do you really need camellia-only? > > And @STRENGTH is a hack, looking at only one factor. > > Here is a real-world example (this ignores some of my advice) > ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: > ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:AES256- > GCM-SHA384: > AES256-SHA256:DES-CBC3-SHA:ECDHE-RSA-AES128-GCM-SHA256: > ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-SHA256: > ECDHE-ECDSA-AES128-SHA256:AES128-GCM-SHA256:AES128-SHA256: > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz at jabber.at Twitter: RichSalz > > > ------------------------------ > > Message: 4 > Date: Mon, 7 Nov 2016 17:32:06 +0000 > From: debbie10t > To: openssl-users at openssl.org > Subject: [openssl-users] mailing list registration renewal - clarify > bounce errors > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi, > > today I received an email from openssl-users-request at openssl.org > > > Your membership in the mailing list openssl-users has been disabled > due to excessive bounces .. > > > I can find no evidence of "excessive bounces .." so I am just asking > here, is this a standard clean up of the ML or have you really received > excessive bounces from my email address ? > > Thank you. > -- > > > ------------------------------ > > Message: 5 > Date: Mon, 7 Nov 2016 17:34:07 +0000 > From: "Salz, Rich" > To: "openssl-users at openssl.org" > Subject: Re: [openssl-users] mailing list registration renewal - > clarify bounce errors > Message-ID: > <2cf7b93033d64c05bc455d9249f36c2b at usma1ex-dag1mb1.msg.corp. > akamai.com> > Content-Type: text/plain; charset="Windows-1252" > > > I can find no evidence of "excessive bounces .." so I am just asking > here, is > > this a standard clean up of the ML or have you really received excessive > > bounces from my email address ? > > The latter. > > We have seen some more reports of this recently, and are increasing the > logging to determine the cause. Interestingly, it's all from gmail.com > addresses. > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 24, Issue 12 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From debbie10t at gmail.com Mon Nov 7 17:40:46 2016 From: debbie10t at gmail.com (debbie10t) Date: Mon, 7 Nov 2016 17:40:46 +0000 Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 07/11/16 17:34, Salz, Rich wrote: >> I can find no evidence of "excessive bounces .." so I am just asking here, is >> this a standard clean up of the ML or have you really received excessive >> bounces from my email address ? > > The latter. > > We have seen some more reports of this recently, and are increasing the logging to determine the cause. Interestingly, it's all from gmail.com addresses. > Well, that is very interesting ! Would it be possible to forward me a copy of the headers showing a bounce from my account? Perhaps I can help solve the problem. From secaficionado at gmail.com Mon Nov 7 18:27:53 2016 From: secaficionado at gmail.com (Sec_Aficiondado) Date: Mon, 7 Nov 2016 13:27:53 -0500 Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: References: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Hi all, Same here. I got the message but I see no evidence of issues in this email account. I changed my password just in case anyway. Thanks! Sent from my mobile > On Nov 7, 2016, at 12:40 PM, debbie10t wrote: > > > > On 07/11/16 17:34, Salz, Rich wrote: >>> I can find no evidence of "excessive bounces .." so I am just asking here, is >>> this a standard clean up of the ML or have you really received excessive >>> bounces from my email address ? >> >> The latter. >> >> We have seen some more reports of this recently, and are increasing the logging to determine the cause. Interestingly, it's all from gmail.com addresses. >> > > Well, that is very interesting ! Would it be possible to forward me > a copy of the headers showing a bounce from my account? Perhaps I can > help solve the problem. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From beldmit at gmail.com Mon Nov 7 18:50:13 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 7 Nov 2016 21:50:13 +0300 Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Hello Rich, On Mon, Nov 7, 2016 at 8:34 PM, Salz, Rich wrote: > > I can find no evidence of "excessive bounces .." so I am just asking > here, is > > this a standard clean up of the ML or have you really received excessive > > bounces from my email address ? > > The latter. > > We have seen some more reports of this recently, and are increasing the > logging to determine the cause. Interestingly, it's all from gmail.com > addresses. > I confirm the receiving the similar message. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Nov 7 18:54:03 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 7 Nov 2016 12:54:03 -0600 Subject: [openssl-users] Duplicating const X509_NAME In-Reply-To: <3e6478aa-fa36-f970-7d80-88a79d0ab9ca@debian.org> References: <3e6478aa-fa36-f970-7d80-88a79d0ab9ca@debian.org> Message-ID: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com> On 11/07/2016 05:42 AM, Sascha Steinbiss wrote: > Hi all, > > I was wondering how to properly make a clone of a const X509_NAME in > OpenSSL 1.1? > > In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id() > and would like to pass it to X509_find_by_subject() which takes a > X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a > local copy -- which looked like the obvious approach -- but that also > only takes a non-const parameter. > > Any ideas? With > Hmm, seems like there may be a need for get1-style accessors, then. Supposedly missing accessors will get backported from master to the 1.1 branch (though making it in time for 1.1.0c later this week could be tough). It might be worth filing a pull request with such things. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From mofassir_haque at yahoo.com Tue Nov 8 02:36:21 2016 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Tue, 8 Nov 2016 02:36:21 +0000 (UTC) Subject: [openssl-users] Retrieving Root CA certificate using "openssl s_client -showcerts" command References: <1627041644.218333.1478572581889.ref@mail.yahoo.com> Message-ID: <1627041644.218333.1478572581889@mail.yahoo.com> Hi All, ? The output of "openssl s_client -showcerts -connect ......." command dose not include Root certificate (which is expected behaviour). However, is it possible to configure Server to return Root CA certificate also ? ? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From ajaygargnsit at gmail.com Tue Nov 8 05:26:39 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Tue, 8 Nov 2016 10:56:39 +0530 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: I tried configuring with no-asm, and then re-compiled. Now, I get stuck at *#error: MDC2 is disabled* If I then *also* add no-mdc2, I get stuck at *cannot open input file 'out32\ssleay32.lib*' Is compiling on windows always such a pain? :( On Linux, it compiled perfectly the first time itself. On Mon, Nov 7, 2016 at 9:52 PM, Ajay Garg wrote: > Oops.. sorry. > OpenSSL-version is 1.0.2d, and nasm-version is 2.12.02. > > > > On Mon, Nov 7, 2016 at 9:31 PM, Jeremy Farrell > wrote: > >> What version of OpenSSL? What version of nasm (nasm -v)? People are more >> likely to be able to help if you provide such basic information. >> >> Regards, >> jjf >> >> On 07/11/2016 11:42, Ajay Garg wrote: >> >> Oops... pardon me. >> The e) step was not done. >> >> The errors came right after step d) >> >> On 7 Nov 2016 3:36 p.m., "Ajay Garg" wrote: >> >>> Hi All. >>> >>> Following are the steps I followed : >>> >>> ############################################################ >>> ################### >>> a) >>> Downloaded nasm.exe from internet, and placed it in the include-path. >>> >>> b) >>> *perl Configure VC-WIN32* >>> >>> c) >>> >>> >>> *ms\do_nasm.bat * >>> d) >>> >>> >>> * nmake -f ms\nt.mak * >>> e) >>> *make* >>> >>> >>> >>> *############################################################################### >>> * >>> Compilation runs fine for some time, but then I get hundreds of >>> IDENTICAL errors as follows :: >>> >>> ############################################################ >>> ################### >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> *tmp32\sha1-586.asm:3964: warning: `PTR' is not a NASM keyword >>> tmp32\sha1-586.asm:3964: error: comma, colon, decorator or end of line >>> expecte after operand tmp32\sha1-586.asm:3970: error: symbol >>> `__sha1_block_data_order_avx' redefined tmp32\sha1-586.asm:3970: error: >>> parser: instruction expected tmp32\sha1-586.asm:3972: error: parser: >>> instruction expected tmp32\sha1-586.asm:3983: error: parser: instruction >>> expected tmp32\sha1-586.asm:3985: error: parser: instruction expected >>> tmp32\sha1-586.asm:3986: error: parser: instruction expected >>> tmp32\sha1-586.asm:3987: warning: label alone on a line without a colon >>> might in error NMAKE : fatal error U1077: '"C:\Program Files\Microsoft >>> Visual Studio 14.0\VC\ N\nasm.EXE"' : return code '0x1' Stop.* >>> >>> >>> *############################################################################### >>> * >>> Any pointers how to solve this? >>> I will heartfully grateful. >>> >>> Thanks and Regards, >>> Ajay >>> >> >> -- >> J. J. Farrell >> Not speaking for Oracle >> >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> > > > -- > Regards, > Ajay > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From kim.grasman at gmail.com Tue Nov 8 06:28:43 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Tue, 8 Nov 2016 07:28:43 +0100 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: On Tue, Nov 8, 2016 at 6:26 AM, Ajay Garg wrote: > > Is compiling on windows always such a pain? :( > On Linux, it compiled perfectly the first time itself. It's worked well for me in a similar environment. I use DLL builds, though, so `ntdll.mak` instead of `nt.mak`. One thing that looks suspicious is this: > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\ > N\nasm.EXE"' : return code '0x1' Have you put nasm.exe inside the Visual Studio install dir? That seems like an odd choice, not sure if the spaces in the path maybe confuses something? You also don't mention which directory you're in when running these commands. I've run everything inside the openssl-1.0.2h (using a different version) source directory. - Kim From joachim.person at gmail.com Tue Nov 8 07:24:33 2016 From: joachim.person at gmail.com (Joachim Person) Date: Tue, 8 Nov 2016 08:24:33 +0100 Subject: [openssl-users] Missing documentation Message-ID: Hi, It seems like the documentation for SSL_set_tlsext_host_name is gone. Does anyone know where I can find the documentation? I am interested in the return values right now. https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_tlsext_host_name.html (Page not found) BR Joachim -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Nov 8 07:37:22 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Nov 2016 08:37:22 +0100 (CET) Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: References: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20161108.083722.982336643109774878.levitte@openssl.org> In message on Mon, 7 Nov 2016 21:50:13 +0300, Dmitry Belyavsky said: beldmit> Hello Rich, beldmit> beldmit> On Mon, Nov 7, 2016 at 8:34 PM, Salz, Rich wrote: beldmit> beldmit> > I can find no evidence of "excessive bounces .." so I am just beldmit> asking here, is beldmit> > this a standard clean up of the ML or have you really received beldmit> excessive beldmit> > bounces from my email address ? beldmit> beldmit> The latter. beldmit> beldmit> We have seen some more reports of this recently, and are beldmit> increasing the logging to determine the cause. Interestingly, it's beldmit> all from gmail.com addresses. beldmit> beldmit> beldmit> I confirm the receiving the similar message. The issue is called DMARC, and most certainly with a reject policy, which basically tells recipients to reject messages that doesn't quite appear to come from the originator. This is problematic for mailing lists, that kind of act as a middle man, and even moreso because rejections end up as bounces to the mailing list software, which will end up disabling the bouncing address. So in the end, it becomes a story of how users from one domain are capable of throw out everyone else that checks their DMARC policy. Last time we went through this, we ignored the problem, for reasons I cannot remember now. I'll have a closer look at what mailman can offer and get back to you. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Tue Nov 8 08:19:06 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 08 Nov 2016 09:19:06 +0100 (CET) Subject: [openssl-users] mailing list registration renewal - clarify bounce errors In-Reply-To: <20161108.083722.982336643109774878.levitte@openssl.org> References: <2cf7b93033d64c05bc455d9249f36c2b@usma1ex-dag1mb1.msg.corp.akamai.com> <20161108.083722.982336643109774878.levitte@openssl.org> Message-ID: <20161108.091906.306606515293026630.levitte@openssl.org> In message <20161108.083722.982336643109774878.levitte at openssl.org> on Tue, 08 Nov 2016 08:37:22 +0100 (CET), Richard Levitte said: levitte> In message on Mon, 7 Nov 2016 21:50:13 +0300, Dmitry Belyavsky said: levitte> levitte> beldmit> Hello Rich, levitte> beldmit> levitte> beldmit> On Mon, Nov 7, 2016 at 8:34 PM, Salz, Rich wrote: levitte> beldmit> levitte> beldmit> > I can find no evidence of "excessive bounces .." so I am just levitte> beldmit> asking here, is levitte> beldmit> > this a standard clean up of the ML or have you really received levitte> beldmit> excessive levitte> beldmit> > bounces from my email address ? levitte> beldmit> levitte> beldmit> The latter. levitte> beldmit> levitte> beldmit> We have seen some more reports of this recently, and are levitte> beldmit> increasing the logging to determine the cause. Interestingly, it's levitte> beldmit> all from gmail.com addresses. levitte> beldmit> levitte> beldmit> levitte> beldmit> I confirm the receiving the similar message. levitte> levitte> The issue is called DMARC, and most certainly with a reject policy, levitte> which basically tells recipients to reject messages that doesn't quite levitte> appear to come from the originator. levitte> levitte> This is problematic for mailing lists, that kind of act as a middle levitte> man, and even moreso because rejections end up as bounces to the levitte> mailing list software, which will end up disabling the bouncing levitte> address. So in the end, it becomes a story of how users from one levitte> domain are capable of throw out everyone else that checks their DMARC levitte> policy. levitte> levitte> Last time we went through this, we ignored the problem, for reasons I levitte> cannot remember now. I'll have a closer look at what mailman can levitte> offer and get back to you. So, I changed this mailing list to munge the From: header of any message coming from a domain that has a DMARC reject or quarantine policy. That should avoid any more silly bouncing of the sort we've experienced. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From ajaygargnsit at gmail.com Tue Nov 8 08:48:30 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Tue, 8 Nov 2016 14:18:30 +0530 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: Hi Kim. Thanks for the reply. On 8 Nov 2016 11:59 a.m., "Kim Gr?sman" wrote: > > On Tue, Nov 8, 2016 at 6:26 AM, Ajay Garg wrote: > > > > Is compiling on windows always such a pain? :( > > On Linux, it compiled perfectly the first time itself. > > It's worked well for me in a similar environment. I use DLL builds, > though, so `ntdll.mak` instead of `nt.mak`. Unfortunately, I need to link openssl statically to our framework. So DLL would not help, require .libs > > One thing that looks suspicious is this: > > > NMAKE : fatal error U1077: '"C:\Program Files\Microsoft Visual Studio 14.0\VC\ > > N\nasm.EXE"' : return code '0x1' > > Have you put nasm.exe inside the Visual Studio install dir? That seems > like an odd choice, not sure if the spaces in the path maybe confuses > something? I doubt, cl.exe is also inside this. > > You also don't mention which directory you're in when running these > commands. I've run everything inside the openssl-1.0.2h (using a > different version) source directory. I am running everything from the openssl source directory itself. Any chance I can get pre-compiled libraries for 1.0.2d, after which I can link them statically to our framework? Thanks in advance ? > > - Kim > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard.gappmeier at ascolab.com Tue Nov 8 08:48:54 2016 From: gerhard.gappmeier at ascolab.com (Gerhard Gappmeier) Date: Tue, 8 Nov 2016 09:48:54 +0100 Subject: [openssl-users] How to use EVP_aes_256_cbc_hmac_sha256 Message-ID: <58219176.7070309@ascolab.com> Hi, I'm trying to use EVP_EncryptUpdate() with EVP_aes_256_cbc_hmac_sha256() to speed up encryption. This "stiched" version should be faster than first hashing and then encrypt the data. See also https://software.intel.com/sites/default/files/open-ssl-performance-paper.pdf for some background. However I don't see a way to configure the offset between the data to be signed and the data to be encrypted. In my protocol (not TLS) we have a header of 16 byte that gets signed, but not encrypted. Some ASCII art to explain this (use fix size font to view this): /----signed-------------------\ |header|seqheader|body|padding|signature| \--------encrypted---------------/ I debugged already "openssl speed -evp aes-256-cbc-hmac-sha256" but this looks for me like the same data is signed and encrypted, and no offset is used. Is it possible somehow to define such a offset? I was expecting that the same is necessary for TLS, but I'm not a TLS expert :-) regards, Gerhard. From satta at debian.org Tue Nov 8 12:41:15 2016 From: satta at debian.org (Sascha Steinbiss) Date: Tue, 8 Nov 2016 13:41:15 +0100 Subject: [openssl-users] Fwd: Re: Duplicating const X509_NAME In-Reply-To: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com> References: <13cc08c6-0e3b-27c4-76d3-38a23838ec8b@akamai.com> Message-ID: Dear OpenSSL developer team, following up on the discussion quoted below on the openssl-users ML I would like to ask your opinions on adding a OCSP_resp_get1_id() function: int OCSP_resp_get1_id(const OCSP_BASICRESP *bs, ASN1_OCTET_STRING **pid, X509_NAME **pname); to allow API users to obtain non-const values from responses to pass on to downstream functions. Please also see my commit https://github.com/satta/openssl/commit/4392b12a0caa8f8e7df0bb6e1c94de7f744407ba implementing this. Looking forward to some comments -- if you are OK with it I would be happy to file a pull request. My CLA has been signed and emailed to OpenSSL Foundation's legal team. Unfortunately I could not find any existing tests for the get0 counterpart in the OpenSSL source. Did I miss something? That's the reason why I haven't included tests yet, having read the contributor's guide. Thanks and kind regards Sascha -------- Forwarded Message -------- Subject: Re: [openssl-users] Duplicating const X509_NAME Date: Mon, 7 Nov 2016 12:54:03 -0600 From: Benjamin Kaduk Reply-To: openssl-users at openssl.org To: openssl-users at openssl.org On 11/07/2016 05:42 AM, Sascha Steinbiss wrote: > Hi all, > > I was wondering how to properly make a clone of a const X509_NAME in > OpenSSL 1.1? > > In particular, I am obtaining a const X509_NAME* via OCSP_resp_get0_id() > and would like to pass it to X509_find_by_subject() which takes a > X509_NAME* (non-const). I looked into using X509_NAME_dup() to obtain a > local copy -- which looked like the obvious approach -- but that also > only takes a non-const parameter. > > Any ideas? With > Hmm, seems like there may be a need for get1-style accessors, then. Supposedly missing accessors will get backported from master to the 1.1 branch (though making it in time for 1.1.0c later this week could be tough). It might be worth filing a pull request with such things. -Ben -------------- next part -------------- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From rsalz at akamai.com Tue Nov 8 12:48:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 8 Nov 2016 12:48:05 +0000 Subject: [openssl-users] Retrieving Root CA certificate using "openssl s_client -showcerts" command In-Reply-To: <1627041644.218333.1478572581889@mail.yahoo.com> References: <1627041644.218333.1478572581889.ref@mail.yahoo.com> <1627041644.218333.1478572581889@mail.yahoo.com> Message-ID: Yes, just put the entire chain in the server?s PEM file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Tue Nov 8 13:24:39 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 8 Nov 2016 13:24:39 +0000 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: [not quoting anything because Outlook can't quote HTML email properly] I build OpenSSL for static linking (though using a hacked configuration, since it's going to be linked into a DLL, and we do not want the C RTS linked statically). I've not seen any of these problems. We build on a variety of Windows versions, using a number of compiler versions (because inter-version compatibility still eludes Microsoft); we've been doing that since the 0.9.8 days, and now do it with each release of 1.0.2. My advice, frankly, is to study the OpenSSL build process until you understand it. We've had issues in the past with some Windows Perl implementations (currently we use Cygwin Perl with a wrapper program that corrects paths), and as I noted above, we've had to hack the configuration process (with scripts that run between the OpenSSL configuration step and the actual build). The OpenSSL build is not trivial, and the Windows toolchain is, in a word, terrible. I would also recommend getting nasm out of the Visual Studio tree, where it most definitely does not belong, and into a normal (non-spacey) path. Michael Wojcik Distinguished Engineer, Micro Focus From kim.grasman at gmail.com Tue Nov 8 13:44:01 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Tue, 8 Nov 2016 14:44:01 +0100 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik wrote: > > My advice, frankly, is to study the OpenSSL build process until you understand it. We've had > issues in the past with some Windows Perl implementations (currently we use Cygwin Perl with > a wrapper program that corrects paths) Forgot to mention; I'm building with ActiveState Perl from http://www.ActiveState.com. - Kim From Erwann.Abalea at docusign.com Tue Nov 8 09:26:59 2016 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Tue, 8 Nov 2016 09:26:59 +0000 Subject: [openssl-users] (SPAM) Retrieving Root CA certificate using "openssl s_client -showcerts" command In-Reply-To: <1627041644.218333.1478572581889@mail.yahoo.com> References: <1627041644.218333.1478572581889.ref@mail.yahoo.com> <1627041644.218333.1478572581889@mail.yahoo.com> Message-ID: Bonjour, The root certificate is not expected to be sent by the server, as it already needs to be known and trusted by the client. However, you?re free to configure your server to send it, for debugging or informational purposes. Cordialement, Erwann Abalea Le 8 nov. 2016 ? 03:36, Mofassir Ul Haque > a ?crit : Hi All, The output of "openssl s_client -showcerts -connect ......." command dose not include Root certificate (which is expected behaviour). However, is it possible to configure Server to return Root CA certificate also ? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Nov 8 14:05:16 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 8 Nov 2016 15:05:16 +0100 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: On 08/11/2016 14:44, Kim Gr?sman wrote: > On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik > wrote: >> My advice, frankly, is to study the OpenSSL build process until you understand it. We've had >> issues in the past with some Windows Perl implementations (currently we use Cygwin Perl with >> a wrapper program that corrects paths) > Forgot to mention; I'm building with ActiveState Perl from > http://www.ActiveState.com. > That is the Perl most often quoted as causing problems. Try Strawberry Perl from http://strawberryperl.com/(Strawberry Perl is derived from vanilla Perl, hence the name). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From kim.grasman at gmail.com Tue Nov 8 14:13:39 2016 From: kim.grasman at gmail.com (=?UTF-8?B?S2ltIEdyw6RzbWFu?=) Date: Tue, 8 Nov 2016 15:13:39 +0100 Subject: [openssl-users] Problem in compiling OpenSSL on Windows-7-32-bit In-Reply-To: References: Message-ID: On Tue, Nov 8, 2016 at 3:05 PM, Jakob Bohm wrote: > On 08/11/2016 14:44, Kim Gr?sman wrote: >> >> On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik >> wrote: >>> >>> My advice, frankly, is to study the OpenSSL build process until you >>> understand it. We've had >>> issues in the past with some Windows Perl implementations (currently we >>> use Cygwin Perl with >>> a wrapper program that corrects paths) >> >> Forgot to mention; I'm building with ActiveState Perl from >> http://www.ActiveState.com. >> > That is the Perl most often quoted as causing problems. > > Try Strawberry Perl from http://strawberryperl.com/(Strawberry Perl > is derived from vanilla Perl, hence the name). Thanks Jakob. Funny though, it's building successfully here. The OP hasn't reported his Perl dist yet. I'll make a note to try with Strawberry Perl moving forward. - Kim From hellonotelling at gmail.com Tue Nov 8 14:47:09 2016 From: hellonotelling at gmail.com (Hello Notelling) Date: Tue, 8 Nov 2016 06:47:09 -0800 Subject: [openssl-users] openssl-users Digest, Vol 24, Issue 16 In-Reply-To: References: Message-ID: Your query is being processed On 8 Nov 2016 2:14 p.m., wrote: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: Retrieving Root CA certificate using "openssl s_client > -showcerts" command (Salz, Rich) > 2. Re: Problem in compiling OpenSSL on Windows-7-32-bit > (Michael Wojcik) > 3. Re: Problem in compiling OpenSSL on Windows-7-32-bit (Kim Gr?sman) > 4. Re: (SPAM) Retrieving Root CA certificate using "openssl > s_client -showcerts" command (Erwann Abalea) > 5. Re: Problem in compiling OpenSSL on Windows-7-32-bit (Jakob Bohm) > 6. Re: Problem in compiling OpenSSL on Windows-7-32-bit (Kim Gr?sman) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 8 Nov 2016 12:48:05 +0000 > From: "Salz, Rich" > To: Mofassir Ul Haque , > "openssl-users at openssl.org" > Subject: Re: [openssl-users] Retrieving Root CA certificate using > "openssl s_client -showcerts" command > Message-ID: > akamai.com> > Content-Type: text/plain; charset="utf-8" > > Yes, just put the entire chain in the server?s PEM file. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161108/7be62e26/attachment-0001.html> > > ------------------------------ > > Message: 2 > Date: Tue, 8 Nov 2016 13:24:39 +0000 > From: Michael Wojcik > To: "openssl-users at openssl.org" > Subject: Re: [openssl-users] Problem in compiling OpenSSL on > Windows-7-32-bit > Message-ID: > microfocus.com> > Content-Type: text/plain; charset="utf-8" > > [not quoting anything because Outlook can't quote HTML email properly] > > I build OpenSSL for static linking (though using a hacked configuration, > since it's going to be linked into a DLL, and we do not want the C RTS > linked statically). I've not seen any of these problems. We build on a > variety of Windows versions, using a number of compiler versions (because > inter-version compatibility still eludes Microsoft); we've been doing that > since the 0.9.8 days, and now do it with each release of 1.0.2. > > My advice, frankly, is to study the OpenSSL build process until you > understand it. We've had issues in the past with some Windows Perl > implementations (currently we use Cygwin Perl with a wrapper program that > corrects paths), and as I noted above, we've had to hack the configuration > process (with scripts that run between the OpenSSL configuration step and > the actual build). The OpenSSL build is not trivial, and the Windows > toolchain is, in a word, terrible. > > I would also recommend getting nasm out of the Visual Studio tree, where > it most definitely does not belong, and into a normal (non-spacey) path. > > Michael Wojcik > Distinguished Engineer, Micro Focus > > > > ------------------------------ > > Message: 3 > Date: Tue, 8 Nov 2016 14:44:01 +0100 > From: Kim Gr?sman > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Problem in compiling OpenSSL on > Windows-7-32-bit > Message-ID: > gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik > wrote: > > > > My advice, frankly, is to study the OpenSSL build process until you > understand it. We've had > > issues in the past with some Windows Perl implementations (currently we > use Cygwin Perl with > > a wrapper program that corrects paths) > > Forgot to mention; I'm building with ActiveState Perl from > http://www.ActiveState.com. > > - Kim > > > ------------------------------ > > Message: 4 > Date: Tue, 8 Nov 2016 09:26:59 +0000 > From: Erwann Abalea > To: Mofassir Ul Haque , > "openssl-users at openssl.org" > Subject: Re: [openssl-users] (SPAM) Retrieving Root CA certificate > using "openssl s_client -showcerts" command > Message-ID: > Content-Type: text/plain; charset="utf-8" > > Bonjour, > > The root certificate is not expected to be sent by the server, as it > already needs to be known and trusted by the client. > However, you?re free to configure your server to send it, for debugging or > informational purposes. > > Cordialement, > Erwann Abalea > > Le 8 nov. 2016 ? 03:36, Mofassir Ul Haque mailto:mofassir_haque at yahoo.com>> a ?crit : > > Hi All, > > The output of "openssl s_client -showcerts -connect ......." command dose > not include Root certificate (which is expected behaviour). However, is it > possible to configure Server to return Root CA certificate also ? > > Thanks, > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20161108/92cdc4fb/attachment-0001.html> > > ------------------------------ > > Message: 5 > Date: Tue, 8 Nov 2016 15:05:16 +0100 > From: Jakob Bohm > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Problem in compiling OpenSSL on > Windows-7-32-bit > Message-ID: > Content-Type: text/plain; charset=windows-1252; format=flowed > > On 08/11/2016 14:44, Kim Gr?sman wrote: > > On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik > > wrote: > >> My advice, frankly, is to study the OpenSSL build process until you > understand it. We've had > >> issues in the past with some Windows Perl implementations (currently we > use Cygwin Perl with > >> a wrapper program that corrects paths) > > Forgot to mention; I'm building with ActiveState Perl from > > http://www.ActiveState.com. > > > That is the Perl most often quoted as causing problems. > > Try Strawberry Perl from http://strawberryperl.com/(Strawberry Perl > is derived from vanilla Perl, hence the name). > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > > > ------------------------------ > > Message: 6 > Date: Tue, 8 Nov 2016 15:13:39 +0100 > From: Kim Gr?sman > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Problem in compiling OpenSSL on > Windows-7-32-bit > Message-ID: > dA at mail.gmail.com> > Content-Type: text/plain; charset=UTF-8 > > On Tue, Nov 8, 2016 at 3:05 PM, Jakob Bohm wrote: > > On 08/11/2016 14:44, Kim Gr?sman wrote: > >> > >> On Tue, Nov 8, 2016 at 2:24 PM, Michael Wojcik > >> wrote: > >>> > >>> My advice, frankly, is to study the OpenSSL build process until you > >>> understand it. We've had > >>> issues in the past with some Windows Perl implementations (currently we > >>> use Cygwin Perl with > >>> a wrapper program that corrects paths) > >> > >> Forgot to mention; I'm building with ActiveState Perl from > >> http://www.ActiveState.com. > >> > > That is the Perl most often quoted as causing problems. > > > > Try Strawberry Perl from http://strawberryperl.com/(Strawberry Perl > > is derived from vanilla Perl, hence the name). > > Thanks Jakob. Funny though, it's building successfully here. The OP > hasn't reported his Perl dist yet. > > I'll make a note to try with Strawberry Perl moving forward. > > - Kim > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > openssl-users mailing list > openssl-users at openssl.org > https://mta.openssl.org/mailman/listinfo/openssl-users > > > ------------------------------ > > End of openssl-users Digest, Vol 24, Issue 16 > ********************************************* > -------------- next part -------------- An HTML attachment was scrubbed... URL: From swall at redcom.com Tue Nov 8 16:14:10 2016 From: swall at redcom.com (Wall, Stephen) Date: Tue, 8 Nov 2016 16:14:10 +0000 Subject: [openssl-users] openssl-users Digest, Vol 24, Issue 16 In-Reply-To: References: Message-ID: <107a4ef257f440918857ab865645628f@exch-02.redcom.com> Can this person be dropped from the list? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Hello Notelling Sent: Tuesday, November 08, 2016 9:47 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] openssl-users Digest, Vol 24, Issue 16 Your query is being processed -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.Ballreich at outlook.de Tue Nov 8 16:33:04 2016 From: Matthias.Ballreich at outlook.de (Matthias Ballreich) Date: Tue, 8 Nov 2016 16:33:04 +0000 Subject: [openssl-users] Access Mozilla NSS (shared) Database / PKCS#11 Modules via OpenSSL? Message-ID: Hi there, how can i access the Mozilla NSS (shared) Database (cert8 or cert9d.db) / PKCS#11-Modules via OpenSSL? I need read & write access to the NSS User Cert Database (softokn3) and to the Built-In Cert Database (nssckbi) under Windows. I tried it with Libp11 this way: int rc = 0; PKCS11_CTX *pkcs11_ctx; pkcs11_ctx = PKCS11_CTX_new(); PKCS11_CTX_init_args(pkcs11_ctx, "configdir=''C:/Users/Username/AppData/Roaming/Mozilla/Firefox/Profiles/5wzkdcjx.default' certPrefix='' keyPrefix='' secmod='secmod.db'"); rc = PKCS11_CTX_load(pkcs11_ctx, " C:/Program Files (x86)/Mozilla/Firefox/softokn3.dll "); printf("Desc: %s\n", pkcs11_ctx->description); if (rc) printf("Error loading Module"); But it return every time "-1" which tells me that the loading fails. So is this the right way? Or should I use another library? Or is my code not right? And can I edit the Trust Settings with that or another library like with NSS directly? Because I can't delete the built-in certs of nssckbi because this is read-only I can edit the Trust-Settings for that certificate. Can I do that with OpenSSL in combination with a library, too? Or should I better use NSS instead of OpenSSL? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Nov 8 17:47:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 8 Nov 2016 17:47:30 +0000 Subject: [openssl-users] openssl-users Digest, Vol 24, Issue 16 In-Reply-To: <107a4ef257f440918857ab865645628f@exch-02.redcom.com> References: <107a4ef257f440918857ab865645628f@exch-02.redcom.com> Message-ID: <93a476c5a2764d369539509db5513626@usma1ex-dag1mb1.msg.corp.akamai.com> I sent them a warning yesterday and today dropped/banned them. From bkaduk at akamai.com Tue Nov 8 18:14:30 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 8 Nov 2016 12:14:30 -0600 Subject: [openssl-users] Missing documentation In-Reply-To: References: Message-ID: On 11/08/2016 01:24 AM, Joachim Person wrote: > Hi, > > It seems like the documentation for SSL_set_tlsext_host_name is gone. > Does anyone know where I can find the documentation? I am interested > in the return values right now. > > https://www.openssl.org/docs/man1.1.0/ssl/SSL_set_tlsext_host_name.html > > (Page not found) You say "gone" as if they ever existed, but I don't see any evidence of that in the commit history for master or 1.0.2. It looks like they are just plain "missing", like so much other OpenSSL documentation. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Nov 8 19:04:44 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 8 Nov 2016 14:04:44 -0500 Subject: [openssl-users] (SPAM) Retrieving Root CA certificate using "openssl s_client -showcerts" command In-Reply-To: References: <1627041644.218333.1478572581889.ref@mail.yahoo.com> <1627041644.218333.1478572581889@mail.yahoo.com> Message-ID: <6B9974B5-4818-46F8-95BE-ABA5C0E09C69@dukhovni.org> > On Nov 8, 2016, at 4:26 AM, Erwann Abalea wrote: > > The root certificate is not expected to be sent by the server, as it already needs to be known and trusted by the client. > However, you?re free to configure your server to send it, for debugging or informational purposes. A root CA certificate MUST be sent when the server's DANE-TA(2) TLSA record designates that root as a trust-anchor. https://tools.ietf.org/html/rfc7671#section-5.2 -- Viktor. From fm at frank4dd.com Tue Nov 8 23:54:09 2016 From: fm at frank4dd.com (Frank Migge) Date: Wed, 09 Nov 2016 08:54:09 +0900 Subject: [openssl-users] Missing documentation In-Reply-To: References: Message-ID: <582265A1.2060004@frank4dd.com> Hi Joachim, >> It seems like the documentation for SSL_set_tlsext_host_name is gone. >> Does anyone know where I can find the documentation? I am interested in the return values right now. If I got it right: 1) ssl/tls1.h (line 334ff): # define SSL_set_tlsext_host_name(s,name) \ 334 SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char *)name) 2) https://www.openssl.org/docs/manmaster/man3/SSL_ctrl.html: The return values of the SSL*_ctrl() functions depend on the command supplied via the *cmd* parameter. 3) ssl/s3_lib.c (line 3311 ff): case SSL_CTRL_SET_TLSEXT_HOSTNAME: returns 1 on success, and 0 on failure which also writes the cause to the SSL error handler. Best wishes Frank -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Wed Nov 9 12:46:59 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 09 Nov 2016 13:46:59 +0100 Subject: [openssl-users] Access Mozilla NSS (shared) Database / PKCS#11 Modules via OpenSSL? In-Reply-To: References: Message-ID: <58231AC3.1080105@nikhef.nl> Hi, On 08/11/16 17:33, Matthias Ballreich wrote: > > Hi there, > > how can i access the Mozilla NSS (shared) Database (cert8 or > cert9d.db) / PKCS#11-Modules via OpenSSL? > > I need read & write access to the NSS User Cert Database (softokn3) > and to the Built-In Cert Database (nssckbi) under Windows. > > I tried it with Libp11 this way: > > int rc = 0; > PKCS11_CTX *pkcs11_ctx; > pkcs11_ctx = PKCS11_CTX_new(); > PKCS11_CTX_init_args(pkcs11_ctx, > "configdir=''C:/Users/Username/AppData/Roaming/Mozilla/Firefox/Profiles/5wzkdcjx.default' > certPrefix='' keyPrefix='' secmod='secmod.db'"); > rc = PKCS11_CTX_load(pkcs11_ctx, " C:/Program Files > (x86)/Mozilla/Firefox/softokn3.dll "); > printf("Desc: %s\n", pkcs11_ctx->description); > if (rc) > printf("Error loading Module"); > > But it return every time ?-1? which tells me that the loading fails. > So is this the right way? Or should I use another library? Or is my > code not right? > > And can I edit the Trust Settings with that or another library like > with NSS directly? Because I can?t delete the built-in certs of > nssckbi because this is read-only I can edit the Trust-Settings for > that certificate. Can I do that with OpenSSL in combination with a > library, too? Or should I better use NSS instead of OpenSSL? > > this is slightly off-topic for this mailinglist, but I'd try using p11-kit to access the NSS device; the problem with the softokn3 pseudo-pkcs11 device is/was that it did not follow the PKCS11 standard completely - this made the softokn3 device unusable for tools like libp11 and opensc ; however, there are links on the web stating that p11-kit does not how to read a nssdb file, e.g. https://wiki.gnome.org/Projects/CryptoGlue/Integration#NSS_libsoftokn3 and p11-kit has been ported to both mingw and cygwin. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From mofassir_haque at yahoo.com Thu Nov 10 08:44:49 2016 From: mofassir_haque at yahoo.com (Mofassir Ul Haque) Date: Thu, 10 Nov 2016 08:44:49 +0000 (UTC) Subject: [openssl-users] Retrieving Root CA certificate using "openssl s_client -showcerts" command In-Reply-To: References: <1627041644.218333.1478572581889.ref@mail.yahoo.com> <1627041644.218333.1478572581889@mail.yahoo.com> Message-ID: <1890678481.1094180.1478767489526@mail.yahoo.com> Hi Salz, Thanks for your reply and clarification. Best Regards, Mofassir On Wednesday, 9 November 2016 1:48 AM, "Salz, Rich" wrote: #yiv7868915218 -- filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv7868915218 p.yiv7868915218MsoNormal, #yiv7868915218 li.yiv7868915218MsoNormal, #yiv7868915218 div.yiv7868915218MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv7868915218 a:link, #yiv7868915218 span.yiv7868915218MsoHyperlink {color:blue;text-decoration:underline;}#yiv7868915218 a:visited, #yiv7868915218 span.yiv7868915218MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv7868915218 span.yiv7868915218EmailStyle17 {color:#1F497D;}#yiv7868915218 .yiv7868915218MsoChpDefault {font-size:10.0pt;}#yiv7868915218 filtered {margin:1.0in 1.0in 1.0in 1.0in;}#yiv7868915218 div.yiv7868915218WordSection1 {}#yiv7868915218 Yes, just put the entire chain in the server?s PEM file. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dracono at wp.pl Thu Nov 10 09:49:57 2016 From: dracono at wp.pl (Pawel Suwinski) Date: Thu, 10 Nov 2016 10:49:57 +0100 Subject: [openssl-users] smartcard/ pkcs11 - 'bad decrypt' error after upgrade from 0.9.8 to 1.0.1 Message-ID: <20161110094957.GA12455@mobile> Hello After openssl upgrade (new OS version, new machine) I get error decrypting SMIME messages using Alladin eToken SmardCard (pkcs11 engine). On old system (Debian 6.0 Squeeze-LTS)/ machine: #v+ [old]$ openssl version OpenSSL 0.9.8g 19 Oct 2007 (Library: OpenSSL 0.9.8o 01 Jun 2010) [old]$ openssl smime -decrypt -passin pass:XXXX -inform DER -in smime.p7m -engine pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $? engine "pkcs11" set. 0 #v- Now on the new system (Debian 8.6 Jessie)/ machine I get: #v+ [new]$ openssl version OpenSSL 1.0.1t 3 May 2016 [new]$ openssl smime -decrypt -passin pass:XXXX -inform DER -in smime.p7m -engine pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $? engine "pkcs11" set. Error decrypting PKCS#7 structure 3073701564:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:516: 4 #v- Of course smime.p7m file and smartcard are the same. Machines differs but smartcard reader on the new machine seams to work fine, for example I can access smartcard data: #v+ [new]$ pkcs11-dump dump /usr/lib/libeTPkcs11.so 0 XXXX | grep -1 CKA_ID: e3 c5 (...) #v- Config files are the same with additional pkcs11 engine section described in libengine-pkcs11-openssl package docs: #v+ # /etc/ssl/openssl.cnf (...) openssl_conf = openssl_def [openssl_def] engines = engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /usr/lib/engines/engine_pkcs11.so MODULE_PATH = /usr/lib/libeTPkcs11.so init = 0 (...) #v- I will be grateful for any hints why it does not work? Maybe I missed something in config file? -- regards Pawel Suwinski From openssl at openssl.org Thu Nov 10 14:29:43 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 10 Nov 2016 14:29:43 +0000 Subject: [openssl-users] OpenSSL version 1.1.0c published Message-ID: <20161110142943.GA31613@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0c released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0c of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0c is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0c.tar.gz Size: 5179668 SHA1 checksum: 920e6e7bdaccd94d7564af1097176f11900d20ca SHA256 checksum: fc436441a2e05752d31b4e46115eb89709a28aef96d4fe786abe92409b2fd6f5 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0c.tar.gz openssl sha256 openssl-1.1.0c.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYJIMiAAoJENnE0m0OYESRqeIH+QEu3e3rgFICNUG/4421l7Dy x42NVUuRvblJCOmAKy+mbt5iHIE1Z5yXOBmDq+1PoBFOSSWPl4NvO48lAkwPnand /65xOzcEre8JXC9dkk4COk8XRG1RCwTzTyLXa/0bO+FXCYVah9HTQHxVkDo1sXon Xrtt5c3vF09X5Jm7MJv9XC6WLFI4ts/GQ3PXoHRHHJnw7DeHAYmdKD9f9XGKiPX6 U3yYnFJw2a4EbXE8hc0MFLNZBJlMzhW2eMdwVC5GDtk/u/uvvM86XPi5/ZsuGZIy V4WSU4DNm/mqRFPVJL0/ANSrcYkDJEq7umarxspv6zb7QMmgl1dNa1ZxkbSwB3Y= =nU4P -----END PGP SIGNATURE----- From openssl at openssl.org Thu Nov 10 14:31:28 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 10 Nov 2016 14:31:28 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20161110143128.GA31777@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL Security Advisory [10 Nov 2016] ======================================== ChaCha20/Poly1305 heap-buffer-overflow (CVE-2016-7054) ====================================================== Severity: High TLS connections using *-CHACHA20-POLY1305 ciphersuites are susceptible to a DoS attack by corrupting larger payloads. This can result in an OpenSSL crash. This issue is not considered to be exploitable beyond a DoS. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.1.0 This issue was reported to OpenSSL on 25th September 2016 by Robert ?wi?cki (Google Security Team), and was found using honggfuzz. The fix was developed by Richard Levitte of the OpenSSL development team. CMS Null dereference (CVE-2016-7053) ==================================== Severity: Moderate Applications parsing invalid CMS structures can crash with a NULL pointer dereference. This is caused by a bug in the handling of the ASN.1 CHOICE type in OpenSSL 1.1.0 which can result in a NULL value being passed to the structure callback if an attempt is made to free certain invalid encodings. Only CHOICE structures using a callback which do not handle NULL value are affected. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.1.0 This issue was reported to OpenSSL on 12th October 2016 by Tyler Nighswander of ForAllSecure. The fix was developed by Stephen Henson of the OpenSSL development team. Montgomery multiplication may produce incorrect results (CVE-2016-7055) ======================================================================= Severity: Low There is a carry propagating bug in the Broadwell-specific Montgomery multiplication procedure that handles input lengths divisible by, but longer than 256 bits. Analysis suggests that attacks against RSA, DSA and DH private keys are impossible. This is because the subroutine in question is not used in operations with the private key itself and an input of the attacker's direct choice. Otherwise the bug can manifest itself as transient authentication and key negotiation failures or reproducible erroneous outcome of public-key operations with specially crafted input. Among EC algorithms only Brainpool P-512 curves are affected and one presumably can attack ECDH key negotiation. Impact was not analyzed in detail, because pre-requisites for attack are considered unlikely. Namely multiple clients have to choose the curve in question and the server has to share the private key among them, neither of which is default behaviour. Even then only clients that chose the curve will be affected. OpenSSL 1.1.0 users should upgrade to 1.1.0c This issue does not affect OpenSSL versions prior to 1.0.2. Due to the low severity of this defect we are not issuing a new 1.0.2 release at this time. We recommend that 1.0.2 users wait for the next 1.0.2 release for the fix to become available. The fix is also available in the OpenSSL git repository in commit 57c4b9f6a2. This issue was publicly reported as transient failures and was not initially recognized as a security issue. Thanks to Richard Morgan for providing reproducible case. The fix was developed by Andy Polyakov of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20161110.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYJH8JAAoJENnE0m0OYESRaZwH/1S6sjqemFtHXVk77xMMbUmY kKGJoo5/7wJQWdw9LMPoxjXDyW0fWTKI+Ly2qfP8ZwVizONndN1HCDdWPSbT9EvN 1OG6gr0BQBmlcENCBrSuGwojAtQuMd47q3IAR3ZSx5yvYby4Lg9tXk1FjvnQ600O Z19r1lvc6efeO1fXPBqIUUPJ4y2XN7P1DDlE5UWxacN5Xn+a6cqrieuj0g1aoZ0h rw4fEI7o3EEufYTtodos61xLqZWq8quaMuerWEq0HfEOyMGGyDkmnQkXdU0X7o4g U17vgzM7CvN7+weBz8hVHd0RARAl21vBjYV/G1kruBxD+cYjdavzGGAf/Z1o15w= =MmoX -----END PGP SIGNATURE----- From Benjamin.Flynn at bigfishgames.com Thu Nov 10 17:25:24 2016 From: Benjamin.Flynn at bigfishgames.com (Benjamin Flynn) Date: Thu, 10 Nov 2016 09:25:24 -0800 Subject: [openssl-users] OpenSSL s_client default certificates bug Message-ID: I've been experiencing an issue with local certificate issuance which I believe is the issue described here: https://rt.openssl.org/Ticket/Display.html?id=3697#txn-72271 I have pulled the latest dev version of OpenSSL from the main repo and the richsalz fork but still see the issue, as shown below. I was led to the issue report from here: http://security.stackexchange.com/q/142159/83556 ### Environment info bflynn at sdkteam01:/usr/local/projects/richsalz/openssl$ uname -a Linux sdkteam01.corp.bigfishgames.com 3.13.0-33-generic #58-Ubuntu SMP Tue Jul 29 16:45:05 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux ### OS Version info bflynn at sdkteam01:/usr/local/projects/richsalz/openssl$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 14.04.1 LTS Release: 14.04 Codename: trusty ### From the richsalz fork bflynn at sdkteam01:/usr/local/projects/richsalz/openssl$ openssl version OpenSSL 1.1.1-dev xx XXX xxxx ### Failure when CAfile not specified bflynn at sdkteam01:/usr/local/projects/richsalz/openssl$ openssl s_client -connect bigfishgames-a.akamaihd.net:443 CONNECTED(00000003) depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- MIIFvDCCBKSgAwIBAgIUdX7PAi9u9+89gbTBrsbWRijugR0wDQYJKoZIhvcNAQEL BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT HFZlcml6b24gRW50ZXJwcmlzZSBTb2x1dGlvbnMxEzARBgNVBAsTCkN5YmVydHJ1 c3QxLjAsBgNVBAMTJVZlcml6b24gQWthbWFpIFN1cmVTZXJ2ZXIgQ0EgRzE0LVNI QTIwHhcNMTYwNTI2MTYwNTEzWhcNMTcwNTI2MTYwNTEyWjBtMQswCQYDVQQGEwJV UzELMAkGA1UECBMCTUExEjAQBgNVBAcTCUNhbWJyaWRnZTEhMB8GA1UEChMYQWth bWFpIFRlY2hub2xvZ2llcyBJbmMuMRowGAYDVQQDExFhMjQ4LmUuYWthbWFpLm5l dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANUqLbfKS70TnRdVakBR SqHqRHLaC2l4qI/NSpFMJ0cvqi8UaL4MJZoQDikUSdk5kyyz1vBVfLyiFn8HYPxn dgSgaIrqHFxmb/a3bb2mnNg36UfxaNk/HR8S5wCJzdICCFianjdXJuIvT8EIIkjh n6gbbt0AqJyQpDKh5vuNwTKRx2luAl2G0a6K858ng+uTZHriud9G0nzBq50W3IZX ixdJqoeIboxlT4/4/RWSuZhpV4NwMagYSRs7TG7PECJsP3C4WEF1Z75fVwkvBRq9 sRIlAfi53a3uBaNHNyHAY/KJ1Pyd+9TZGJd7fdu4oA1HVOgnBzU1NLaBPJA1XFuK O5kCAwEAAaOCAjEwggItMAwGA1UdEwEB/wQCMAAwTAYDVR0gBEUwQzBBBgkrBgEE AbE+ATIwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly9zZWN1cmUub21uaXJvb3QuY29t L3JlcG9zaXRvcnkwga8GCCsGAQUFBwEBBIGiMIGfMC0GCCsGAQUFBzABhiFodHRw Oi8vdmFzc2cxNDIub2NzcC5vbW5pcm9vdC5jb20wNgYIKwYBBQUHMAKGKmh0dHBz Oi8vY2FjZXJ0LmEub21uaXJvb3QuY29tL3Zhc3NnMTQyLmNydDA2BggrBgEFBQcw AoYqaHR0cHM6Ly9jYWNlcnQuYS5vbW5pcm9vdC5jb20vdmFzc2cxNDIuZGVyMG4G A1UdEQRnMGWCEWEyNDguZS5ha2FtYWkubmV0gg8qLmFrYW1haXplZC5uZXSCFiou YWthbWFpaGQtc3RhZ2luZy5uZXSCDiouYWthbWFpaGQubmV0ghcqLmFrYW1haXpl ZC1zdGFnaW5nLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUH AwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFPi9+q9zd8bHG/lLTRGn0TOvr3IRMD4G A1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly92YXNzZzE0Mi5jcmwub21uaXJvb3QuY29t L3Zhc3NnMTQyLmNybDAdBgNVHQ4EFgQUVXIMYSGUcVqhFYe6ANcdpgz0xBMwDQYJ KoZIhvcNAQELBQADggEBAHYq/9CZP26438ls/dyrNSaz00XukLEAn4A0lMo6dQ9o BFd7r83oqXoMVnKQEo9D5uDsGKFUhoVDhGTFMwBqSO+X8nedHJimDnnaN29KB09o qryRkEqIVekB9yF6hSYJ2GaX4VwWn+xBNAaiPn1PtrbCOf1ARblVZJhJO0lqt08z uqKGRKFRS40FZ4p6nmaBuNhRGp6UHTtgyNvBFjjuIYu+rz+Rc/aNrMsVnhQ/RNjN swUrA4pQW4lgDHd04KxlcUcY1Bc6wgtxEXE2soLrgOFYulubdMI3SdCNB1HsVM90 xvfT6Y5MNep20bva7zUxROK9Ufj8u7NPqbV+8KaCaFQ= -----END CERTIFICATE----- subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4491 bytes and written 302 bytes Verification error: unable to get local issuer certificate --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: CAA6B55CF1160CF74DF986563E56CFCB11A24B2CDB35480048885F2B88B4947F Session-ID-ctx: Master-Key: 3AAC7100740F1A670EC8A63C9AD93656A3704C80CCFF1BD6554F4F055CF35DEEF1AAE9F4987465732E347A6E0E00CEDF PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 6a 1c 2d 9a f7 6b 30 c0-09 47 f9 2f 24 9a 01 79 j.-..k0..G./$..y 0010 - cd f5 07 a7 9d 02 76 21-ab d3 dc df 88 97 ae d1 ......v!........ 0020 - 51 f1 c0 a0 e6 01 cc a6-5b 08 a8 61 a6 2b f0 66 Q.......[..a.+.f 0030 - 31 fa a1 d2 b6 0c 5d 1d-d5 58 ff 6c 5e 27 bd a2 1.....]..X.l^'.. 0040 - c8 66 c4 af 9d 5d 55 93-8d e1 28 cb 77 32 0b 7f .f...]U...(.w2.. 0050 - f5 74 cc 6f 56 c3 40 f2-91 65 72 6a b5 84 4b 08 .t.oV. at ..erj..K. 0060 - 2c bd cc fd e5 93 c7 a3-82 67 a5 70 47 16 f7 bc ,........g.pG... 0070 - d5 1a 8a e3 1c 10 c4 21-86 06 58 44 ef c3 be ab .......!..XD.... 0080 - 72 8a f3 89 98 5f 85 79-b2 0c 92 0f 4a a6 f2 99 r...._.y....J... 0090 - bb 8c 50 a0 63 b6 29 9e-8e 03 f1 f9 41 bb 42 97 ..P.c.).....A.B. Start Time: 1478797302 Timeout : 7200 (sec) Verify return code: 20 (unable to get local issuer certificate) Extended master secret: no --- ### Successful when explicitly specifying the CAfile bflynn at sdkteam01:/usr/local/projects/richsalz/openssl$ openssl s_client -connect bigfishgames-a.akamaihd.net:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem CONNECTED(00000003) depth=3 C = US, O = GTE Corporation, OU = "GTE CyberTrust Solutions, Inc.", CN = GTE CyberTrust Global Root verify return:1 depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root verify return:1 depth=1 C = NL, L = Amsterdam, O = Verizon Enterprise Solutions, OU = Cybertrust, CN = Verizon Akamai SureServer CA G14-SHA2 verify return:1 depth=0 C = US, ST = MA, L = Cambridge, O = Akamai Technologies Inc., CN = a248.e.akamai.net verify return:1 --- Certificate chain 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root --- Server certificate -----BEGIN CERTIFICATE----- MIIFvDCCBKSgAwIBAgIUdX7PAi9u9+89gbTBrsbWRijugR0wDQYJKoZIhvcNAQEL BQAwgY0xCzAJBgNVBAYTAk5MMRIwEAYDVQQHEwlBbXN0ZXJkYW0xJTAjBgNVBAoT HFZlcml6b24gRW50ZXJwcmlzZSBTb2x1dGlvbnMxEzARBgNVBAsTCkN5YmVydHJ1 c3QxLjAsBgNVBAMTJVZlcml6b24gQWthbWFpIFN1cmVTZXJ2ZXIgQ0EgRzE0LVNI QTIwHhcNMTYwNTI2MTYwNTEzWhcNMTcwNTI2MTYwNTEyWjBtMQswCQYDVQQGEwJV UzELMAkGA1UECBMCTUExEjAQBgNVBAcTCUNhbWJyaWRnZTEhMB8GA1UEChMYQWth bWFpIFRlY2hub2xvZ2llcyBJbmMuMRowGAYDVQQDExFhMjQ4LmUuYWthbWFpLm5l dDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBANUqLbfKS70TnRdVakBR SqHqRHLaC2l4qI/NSpFMJ0cvqi8UaL4MJZoQDikUSdk5kyyz1vBVfLyiFn8HYPxn dgSgaIrqHFxmb/a3bb2mnNg36UfxaNk/HR8S5wCJzdICCFianjdXJuIvT8EIIkjh n6gbbt0AqJyQpDKh5vuNwTKRx2luAl2G0a6K858ng+uTZHriud9G0nzBq50W3IZX ixdJqoeIboxlT4/4/RWSuZhpV4NwMagYSRs7TG7PECJsP3C4WEF1Z75fVwkvBRq9 sRIlAfi53a3uBaNHNyHAY/KJ1Pyd+9TZGJd7fdu4oA1HVOgnBzU1NLaBPJA1XFuK O5kCAwEAAaOCAjEwggItMAwGA1UdEwEB/wQCMAAwTAYDVR0gBEUwQzBBBgkrBgEE AbE+ATIwNDAyBggrBgEFBQcCARYmaHR0cHM6Ly9zZWN1cmUub21uaXJvb3QuY29t L3JlcG9zaXRvcnkwga8GCCsGAQUFBwEBBIGiMIGfMC0GCCsGAQUFBzABhiFodHRw Oi8vdmFzc2cxNDIub2NzcC5vbW5pcm9vdC5jb20wNgYIKwYBBQUHMAKGKmh0dHBz Oi8vY2FjZXJ0LmEub21uaXJvb3QuY29tL3Zhc3NnMTQyLmNydDA2BggrBgEFBQcw AoYqaHR0cHM6Ly9jYWNlcnQuYS5vbW5pcm9vdC5jb20vdmFzc2cxNDIuZGVyMG4G A1UdEQRnMGWCEWEyNDguZS5ha2FtYWkubmV0gg8qLmFrYW1haXplZC5uZXSCFiou YWthbWFpaGQtc3RhZ2luZy5uZXSCDiouYWthbWFpaGQubmV0ghcqLmFrYW1haXpl ZC1zdGFnaW5nLm5ldDAOBgNVHQ8BAf8EBAMCBaAwHQYDVR0lBBYwFAYIKwYBBQUH AwEGCCsGAQUFBwMCMB8GA1UdIwQYMBaAFPi9+q9zd8bHG/lLTRGn0TOvr3IRMD4G A1UdHwQ3MDUwM6AxoC+GLWh0dHA6Ly92YXNzZzE0Mi5jcmwub21uaXJvb3QuY29t L3Zhc3NnMTQyLmNybDAdBgNVHQ4EFgQUVXIMYSGUcVqhFYe6ANcdpgz0xBMwDQYJ KoZIhvcNAQELBQADggEBAHYq/9CZP26438ls/dyrNSaz00XukLEAn4A0lMo6dQ9o BFd7r83oqXoMVnKQEo9D5uDsGKFUhoVDhGTFMwBqSO+X8nedHJimDnnaN29KB09o qryRkEqIVekB9yF6hSYJ2GaX4VwWn+xBNAaiPn1PtrbCOf1ARblVZJhJO0lqt08z uqKGRKFRS40FZ4p6nmaBuNhRGp6UHTtgyNvBFjjuIYu+rz+Rc/aNrMsVnhQ/RNjN swUrA4pQW4lgDHd04KxlcUcY1Bc6wgtxEXE2soLrgOFYulubdMI3SdCNB1HsVM90 xvfT6Y5MNep20bva7zUxROK9Ufj8u7NPqbV+8KaCaFQ= -----END CERTIFICATE----- subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 4491 bytes and written 302 bytes Verification: OK --- New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES256-GCM-SHA384 Session-ID: 651F9C114BCCFF3A94C084CD0B7D87F421149D7E74FC15E665F188558AA0B122 Session-ID-ctx: Master-Key: 652AD61496B685036E9DEC7EE586F071EBD49D5370777EAAF37F04CFA2F6BC20CC280B358D5C81F1A30E3564335ED75E PSK identity: None PSK identity hint: None SRP username: None TLS session ticket lifetime hint: 7200 (seconds) TLS session ticket: 0000 - 6a 1c 2d 9a f7 6b 30 c0-09 47 f9 2f 24 9a 01 79 j.-..k0..G./$..y 0010 - 46 87 fa 9e c8 ac 5d c9-4f a5 05 04 6c 83 d1 07 F.....].O...l... 0020 - 5b 2d d9 89 32 b5 9c 22-91 90 7e a5 ad 56 6d 92 [-..2.."..~..Vm. 0030 - f1 d7 36 77 9a a7 4a 41-e2 51 c8 90 9f 70 71 15 ..6w..JA.Q...pq. 0040 - f3 3e bf 01 9e 20 b2 9b-24 75 fc 33 0a 2d c5 16 .>... ..$u.3.-.. 0050 - 49 98 ff ba c4 fb 0d a5-a3 ab a5 94 38 c1 79 f1 I...........8.y. 0060 - c7 59 5d a0 64 39 6c 6e-b5 21 d1 53 56 e0 33 62 .Y].d9ln.!.SV.3b 0070 - ee 0f b4 75 a7 ef 68 01-57 9b cf 3e 55 bb 88 5b ...u..h.W..>U..[ 0080 - bc 69 7f c3 ab 47 8f af-7a 85 98 92 f8 9f 78 2d .i...G..z.....x- 0090 - 5f c0 d3 79 18 0e 09 64-15 bc 3a aa 70 b1 62 68 _..y...d..:.p.bh Start Time: 1478797334 Timeout : 7200 (sec) Verify return code: 0 (ok) Extended master secret: no --- Big Fish Games, Inc. A New Game Every Day! (r) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Nov 10 17:38:00 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 10 Nov 2016 17:38:00 +0000 Subject: [openssl-users] OpenSSL s_client default certificates bug In-Reply-To: References: Message-ID: <3848b7013aad4de2adc36990569a722e@usma1ex-dag1mb1.msg.corp.akamai.com> > I have pulled the latest dev version of OpenSSL from the main repo and the richsalz fork but still see the issue, as shown below. Didn't notice this in your email. My fork shouldn't be used by anyone but me :) From openssl-users at dukhovni.org Thu Nov 10 18:24:01 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 10 Nov 2016 13:24:01 -0500 Subject: [openssl-users] OpenSSL s_client default certificates bug In-Reply-To: References: Message-ID: <49D28A84-BD7B-44B3-8E28-AA31E61F54E7@dukhovni.org> > On Nov 10, 2016, at 12:25 PM, Benjamin Flynn wrote: > > ### Failure when CAfile not specified > > $ openssl s_client -connect bigfishgames-a.akamaihd.net:443 > CONNECTED(00000003) > depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore CyberTrust Root > verify error:num=20:unable to get local issuer certificate > --- > Certificate chain > 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net > i:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 > 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 > i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root > i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root > --- > Server certificate > -----BEGIN CERTIFICATE----- > ... > -----END CERTIFICATE----- > subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies Inc./CN=a248.e.akamai.net > issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 > --- > No client certificate CA names sent > Peer signing digest: SHA512 > Server Temp Key: ECDH, P-256, 256 bits > --- > SSL handshake has read 4491 bytes and written 302 bytes > Verification error: unable to get local issuer certificate > --- > New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 > Server public key is 2048 bit > Secure Renegotiation IS NOT supported > Compression: NONE > Expansion: NONE > No ALPN negotiated > SSL-Session: > Protocol : TLSv1.2 > Cipher : ECDHE-RSA-AES256-GCM-SHA384 > Session-ID: CAA6B55CF1160CF74DF986563E56CFCB11A24B2CDB35480048885F2B88B4947F > Session-ID-ctx: > Master-Key: 3AAC7100740F1A670EC8A63C9AD93656A3704C80CCFF1BD6554F4F055CF35DEEF1AAE9F4987465732E347A6E0E00CEDF > PSK identity: None > PSK identity hint: None > SRP username: None > TLS session ticket lifetime hint: 7200 (seconds) > TLS session ticket: > 0000 - 6a 1c 2d 9a f7 6b 30 c0-09 47 f9 2f 24 9a 01 79 j.-..k0..G./$..y > 0010 - cd f5 07 a7 9d 02 76 21-ab d3 dc df 88 97 ae d1 ......v!........ > 0020 - 51 f1 c0 a0 e6 01 cc a6-5b 08 a8 61 a6 2b f0 66 Q.......[..a.+.f > 0030 - 31 fa a1 d2 b6 0c 5d 1d-d5 58 ff 6c 5e 27 bd a2 1.....]..X.l^'.. > 0040 - c8 66 c4 af 9d 5d 55 93-8d e1 28 cb 77 32 0b 7f .f...]U...(.w2.. > 0050 - f5 74 cc 6f 56 c3 40 f2-91 65 72 6a b5 84 4b 08 .t.oV. at ..erj..K. > 0060 - 2c bd cc fd e5 93 c7 a3-82 67 a5 70 47 16 f7 bc ,........g.pG... > 0070 - d5 1a 8a e3 1c 10 c4 21-86 06 58 44 ef c3 be ab .......!..XD.... > 0080 - 72 8a f3 89 98 5f 85 79-b2 0c 92 0f 4a a6 f2 99 r...._.y....J... > 0090 - bb 8c 50 a0 63 b6 29 9e-8e 03 f1 f9 41 bb 42 97 ..P.c.).....A.B. > > Start Time: 1478797302 > Timeout : 7200 (sec) > Verify return code: 20 (unable to get local issuer certificate) > Extended master secret: no I am rather perplexed as to why you might expect verification success with no trusted CAs specified... What you report is exactly what should happen, unless: > /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE CyberTrust Global Root appears in the default system-wide CApath or CAfile locations as reported by $ openssl version -d to which path you can append either "/certs" or "cert.pem" to yield CApath or CAfie respectively. SSL_CTX_load_verify_locations(3): SSL_CTX_set_default_verify_paths() specifies that the default locations from which CA certificates are loaded should be used. There is one default directory and one default file. The default CA certificates directory is called "certs" in the default OpenSSL directory. Alternatively the SSL_CERT_DIR environment variable can be defined to override this location. The default CA certificates file is called "cert.pem" in the default OpenSSL directory. Alternatively the SSL_CERT_FILE environment variable can be defined to override this location. > $ openssl s_client -connect bigfishgames-a.akamaihd.net:443 -CAfile /etc/ssl/certs/GTE_CyberTrust_Global_Root.pem Presumably that file's parent directory (/etc/ssl/certs) is not the same as the directory as reported by "openssl -d" for the executable you're testing. -- Viktor. From Benjamin.Flynn at bigfishgames.com Thu Nov 10 19:58:11 2016 From: Benjamin.Flynn at bigfishgames.com (Benjamin Flynn) Date: Thu, 10 Nov 2016 11:58:11 -0800 Subject: [openssl-users] OpenSSL s_client default certificates bug In-Reply-To: <49D28A84-BD7B-44B3-8E28-AA31E61F54E7@dukhovni.org> References: <49D28A84-BD7B-44B3-8E28-AA31E61F54E7@dukhovni.org> Message-ID: Ah you are correct. My initial install of openssl was using /usr/lib/ssl as its directory but when I upgraded to 1.1 it changed to /usr/local/ssl which escaped my notice. I created the appropriate symlink and can confirm the issue is fixed. Thanks, Ben On 11/10/16, 10:24 AM, "openssl-users on behalf of Viktor Dukhovni" wrote: > >> On Nov 10, 2016, at 12:25 PM, Benjamin Flynn >> wrote: >> >> ### Failure when CAfile not specified >> >> $ openssl s_client -connect bigfishgames-a.akamaihd.net:443 >> CONNECTED(00000003) >> depth=2 C = IE, O = Baltimore, OU = CyberTrust, CN = Baltimore >>CyberTrust Root >> verify error:num=20:unable to get local issuer certificate >> --- >> Certificate chain >> 0 s:/C=US/ST=MA/L=Cambridge/O=Akamai Technologies >>Inc./CN=a248.e.akamai.net >> i:/C=NL/L=Amsterdam/O=Verizon Enterprise >>Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 >> 1 s:/C=NL/L=Amsterdam/O=Verizon Enterprise >>Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 >> i:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >> 2 s:/C=IE/O=Baltimore/OU=CyberTrust/CN=Baltimore CyberTrust Root >> i:/C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE >>CyberTrust Global Root >> --- >> Server certificate >> -----BEGIN CERTIFICATE----- >> ... >> -----END CERTIFICATE----- >> subject=/C=US/ST=MA/L=Cambridge/O=Akamai Technologies >>Inc./CN=a248.e.akamai.net >> issuer=/C=NL/L=Amsterdam/O=Verizon Enterprise >>Solutions/OU=Cybertrust/CN=Verizon Akamai SureServer CA G14-SHA2 >> --- >> No client certificate CA names sent >> Peer signing digest: SHA512 >> Server Temp Key: ECDH, P-256, 256 bits >> --- >> SSL handshake has read 4491 bytes and written 302 bytes >> Verification error: unable to get local issuer certificate >> --- >> New, TLSv1.2, Cipher is ECDHE-RSA-AES256-GCM-SHA384 >> Server public key is 2048 bit >> Secure Renegotiation IS NOT supported >> Compression: NONE >> Expansion: NONE >> No ALPN negotiated >> SSL-Session: >> Protocol : TLSv1.2 >> Cipher : ECDHE-RSA-AES256-GCM-SHA384 >> Session-ID: >>CAA6B55CF1160CF74DF986563E56CFCB11A24B2CDB35480048885F2B88B4947F >> Session-ID-ctx: >> Master-Key: >>3AAC7100740F1A670EC8A63C9AD93656A3704C80CCFF1BD6554F4F055CF35DEEF1AAE9F49 >>87465732E347A6E0E00CEDF >> PSK identity: None >> PSK identity hint: None >> SRP username: None >> TLS session ticket lifetime hint: 7200 (seconds) >> TLS session ticket: >> 0000 - 6a 1c 2d 9a f7 6b 30 c0-09 47 f9 2f 24 9a 01 79 >>j.-..k0..G./$..y >> 0010 - cd f5 07 a7 9d 02 76 21-ab d3 dc df 88 97 ae d1 >>......v!........ >> 0020 - 51 f1 c0 a0 e6 01 cc a6-5b 08 a8 61 a6 2b f0 66 >>Q.......[..a.+.f >> 0030 - 31 fa a1 d2 b6 0c 5d 1d-d5 58 ff 6c 5e 27 bd a2 >>1.....]..X.l^'.. >> 0040 - c8 66 c4 af 9d 5d 55 93-8d e1 28 cb 77 32 0b 7f >>.f...]U...(.w2.. >> 0050 - f5 74 cc 6f 56 c3 40 f2-91 65 72 6a b5 84 4b 08 >>.t.oV. at ..erj..K. >> 0060 - 2c bd cc fd e5 93 c7 a3-82 67 a5 70 47 16 f7 bc >>,........g.pG... >> 0070 - d5 1a 8a e3 1c 10 c4 21-86 06 58 44 ef c3 be ab >>.......!..XD.... >> 0080 - 72 8a f3 89 98 5f 85 79-b2 0c 92 0f 4a a6 f2 99 >>r...._.y....J... >> 0090 - bb 8c 50 a0 63 b6 29 9e-8e 03 f1 f9 41 bb 42 97 >>..P.c.).....A.B. >> >> Start Time: 1478797302 >> Timeout : 7200 (sec) >> Verify return code: 20 (unable to get local issuer certificate) >> Extended master secret: no > >I am rather perplexed as to why you might expect verification success >with no trusted CAs specified... What you report is exactly what should >happen, unless: > >> /C=US/O=GTE Corporation/OU=GTE CyberTrust Solutions, Inc./CN=GTE >>CyberTrust Global Root > > >appears in the default system-wide CApath or CAfile locations as reported >by > > $ openssl version -d > >to which path you can append either "/certs" or "cert.pem" to yield >CApath or CAfie respectively. > > SSL_CTX_load_verify_locations(3): > > SSL_CTX_set_default_verify_paths() specifies that the default >locations > from which CA certificates are loaded should be used. There is one > default directory and one default file. The default CA certificates > directory is called "certs" in the default OpenSSL directory. > Alternatively the SSL_CERT_DIR environment variable can be defined >to > override this location. The default CA certificates file is called > "cert.pem" in the default OpenSSL directory. Alternatively the > SSL_CERT_FILE environment variable can be defined to override this > location. > >> $ openssl s_client -connect bigfishgames-a.akamaihd.net:443 -CAfile >>/etc/ssl/certs/GTE_CyberTrust_Global_Root.pem > >Presumably that file's parent directory (/etc/ssl/certs) is not the same >as >the directory as reported by "openssl -d" for the executable you're >testing. > >-- > Viktor. > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Big Fish Games, Inc. A New Game Every Day! (R) From Benjamin.Flynn at bigfishgames.com Thu Nov 10 20:03:34 2016 From: Benjamin.Flynn at bigfishgames.com (Benjamin Flynn) Date: Thu, 10 Nov 2016 12:03:34 -0800 Subject: [openssl-users] OpenSSL s_client default certificates bug Message-ID: Ok, will switch back. I was grasping at straws. =) But as I noted in my email to the list, the error was mine, when I upgraded I built from source instead of the apt-get install and it used a different directory without my noticing. On 11/10/16, 9:38 AM, "openssl-users on behalf of Salz, Rich" wrote: >> I have pulled the latest dev version of OpenSSL from the main repo and >>the richsalz fork but still see the issue, as shown below. > >Didn't notice this in your email. My fork shouldn't be used by anyone >but me :) > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Big Fish Games, Inc. A New Game Every Day! (R) From noloader at gmail.com Thu Nov 10 20:12:29 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 10 Nov 2016 15:12:29 -0500 Subject: [openssl-users] OpenSSL s_client default certificates bug In-Reply-To: References: Message-ID: On Thu, Nov 10, 2016 at 3:03 PM, Benjamin Flynn wrote: > Ok, will switch back. I was grasping at straws. =) But as I noted in my > email to the list, the error was mine, when I upgraded I built from source > instead of the apt-get install and it used a different directory without > my noticing. It may not be over, though. Distros can tune the location and behavior. I seem to recall Debian, Ubuntu and Fedora each acted a bit differently from one another. I had a test script to see how a command error'd so I knew what to expect. I can't find it at the moment. Jeff From hkm73560 at gmail.com Fri Nov 11 02:12:23 2016 From: hkm73560 at gmail.com (Gyumin) Date: Fri, 11 Nov 2016 11:12:23 +0900 Subject: [openssl-users] What happened during compiling openssl? Message-ID: <58252907.2040505@gmail.com> Dear openssl developers, I modified openssl library to use my own static library which has global variables. When I run make then I can see some errors like|./libcrypto.so: undefined reference to my_own_function|and making static libraries is failed, but the shared libraries are compiled successfully. Finally, there is no issue to use the compiled shared library in my another application. The problem occurs when I link my static library to resolve the undefined error. The shared libraries and static libraries are compiled successfully, but when I use the shared libraries in my application, addresses of the global variables are different. For example, if the address of global variable 'A' in my application is 0x1234 then the address of the 'A' in the shared library is 0xABCD. Why does this situation happen? Thanks for your helps in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Nov 11 03:40:58 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 11 Nov 2016 04:40:58 +0100 Subject: [openssl-users] What happened during compiling openssl? In-Reply-To: <58252907.2040505@gmail.com> References: <58252907.2040505@gmail.com> Message-ID: <307be4be-e5bb-c69f-ddd1-11931cc7b5bf@wisemo.com> On 11/11/2016 03:12, Gyumin wrote: > > Dear openssl developers, > > I modified openssl library to use my own static library which has > global variables. > When I run make then I can see some errors like|./libcrypto.so: > undefined reference to my_own_function|and making static libraries is > failed, but the shared libraries are compiled successfully. > Finally, there is no issue to use the compiled shared library in my > another application. > The problem occurs when I link my static library to resolve the > undefined error. The shared libraries and static libraries are > compiled successfully, but when I use the shared libraries in my > application, addresses of the global variables are different. > For example, if the address of global variable 'A' in my application > is 0x1234 then the address of the 'A' in the shared library is 0xABCD. > Why does this situation happen? Thanks for your helps in advance. When you link a static library (your own in this case) into shared libraries (libcrypto.so and libssl.so in this case), each shared library gets its own copy of the stuff in your static library, including the variables. If you want the OpenSSL libraries to use the same copy of the variables in your own library as each other and as your application, you need to either use static openssl libraries or turn your own library into a shared library. I am guessing the error when compiling the static OpenSSL libraries is slightly different from what you wrote, reporting instead that "my_own_function" is missing when linking one or more OpenSSL programs or selftests against libcrypto.a and libssl.a. If that is the error message, you need to modify the CFLAGS used by the OpenSSL build to include the options to link in your own static library too. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From janjust at nikhef.nl Fri Nov 11 15:04:00 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Fri, 11 Nov 2016 16:04:00 +0100 Subject: [openssl-users] smartcard/ pkcs11 - 'bad decrypt' error after upgrade from 0.9.8 to 1.0.1 In-Reply-To: <20161110094957.GA12455@mobile> References: <20161110094957.GA12455@mobile> Message-ID: <5825DDE0.7070303@nikhef.nl> Hi, On 10/11/16 10:49, Pawel Suwinski wrote: > Hello > > > After openssl upgrade (new OS version, new machine) I get error > decrypting SMIME messages using Alladin eToken SmardCard (pkcs11 > engine). > > On old system (Debian 6.0 Squeeze-LTS)/ machine: > #v+ > [old]$ openssl version > OpenSSL 0.9.8g 19 Oct 2007 (Library: OpenSSL 0.9.8o 01 Jun 2010) > > [old]$ openssl smime -decrypt -passin pass:XXXX -inform DER -in smime.p7m -engine pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $? > engine "pkcs11" set. > 0 > #v- > > Now on the new system (Debian 8.6 Jessie)/ machine I get: > #v+ > [new]$ openssl version > OpenSSL 1.0.1t 3 May 2016 > [new]$ openssl smime -decrypt -passin pass:XXXX -inform DER -in smime.p7m -engine pkcs11 -inkey id_e3c5 -keyform engine > /dev/null ; echo $? > engine "pkcs11" set. > Error decrypting PKCS#7 structure > 3073701564:error:06065064:digital envelope > routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:516: > 4 > #v- > > Of course smime.p7m file and smartcard are the same. Machines differs > but smartcard reader on the new machine seams to work fine, for > example I can access smartcard data: > > #v+ > [new]$ pkcs11-dump dump /usr/lib/libeTPkcs11.so 0 XXXX | grep -1 > > CKA_ID: > e3 c5 > (...) > #v- > > > Config files are the same with additional pkcs11 engine section > described in libengine-pkcs11-openssl package docs: > > #v+ > # /etc/ssl/openssl.cnf > (...) > openssl_conf = openssl_def > > [openssl_def] > engines = engine_section > > [engine_section] > pkcs11 = pkcs11_section > > [pkcs11_section] > engine_id = pkcs11 > dynamic_path = /usr/lib/engines/engine_pkcs11.so > MODULE_PATH = /usr/lib/libeTPkcs11.so > init = 0 > (...) > #v- > > > I will be grateful for any hints why it does not work? Maybe I missed > something in config file? > This has little to do with openssl itself, but I am familiar with such issues. I'm using the same token with the same driver on CentOS 6, 7 and Fedora 20/22 without and issues. Your problem could be caused by numerous incompatibilities: - which version of opensc is installed - which version of engine_pkcs11 and libp11 are installed - which *exact* version of the eTPkcs11 driver are you using? Keep in mind that for the latest OSes you will need the SafeNet client v9 HTH, JJK From Saurabh.Gupta at cavium.com Fri Nov 11 14:46:23 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Fri, 11 Nov 2016 14:46:23 +0000 Subject: [openssl-users] Failed to load libssl.so.1.1 while execuitng openssl comand Message-ID: I tried to execute ./openssl s_server command in the latest Openssl Version 1.1.0c after doing Openssl compilation steps: ./config make make test make install and It's throwing this error below: ./openssl: error while loading shared libraries: libssl.so.1.1: cannot open shared object file: No such file or directory after debugging this issue I found this error is coming because libssl.so.1.1 is not present in /usr/lib64 directory. but by default it should search these library in /usr/local/lib64/ directory. Regards, Saurabh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Saurabh.Gupta at cavium.com Fri Nov 11 14:46:45 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Fri, 11 Nov 2016 14:46:45 +0000 Subject: [openssl-users] Facing issues with dynamic loading engine RSA methods using e_capi.so library in openssl-1.1.0b. Message-ID: I tried to dynamically load e_capi.so engine example on openssl version 1.1.0b present in the openssl engine directory but not able to offload RSA methods. Commands Used: (i) ./openssl speed rsa -engine ../engines/capi.so Error: speed: Unknown algorithm -engine (ii) ./openssl s_server -engine ../engines/capi.so Error: invalid engine "../engines/capi.so" 139890999146240:error:25066067:DSO support routines:dlfcn_load:could not load the shared library:crypto/dso/dso_dlfcn.c:113:filename(/usr/local/lib64/engines-1.1/../engines/capi.so): /usr/local/lib64/engines-1.1/../engines/capi.so: cannot open shared object file: No such file or directory 139890999146240:error:25070067:DSO support routines:DSO_load:could not load the shared library:crypto/dso/dso_lib.c:161: 139890999146240:error:260B6084:engine routines:dynamic_load:dso not found:crypto/engine/eng_dyn.c:414: 139890999146240:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:339:id=../engines/capi.so 139890999146240:error:260B606D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:485: Using default temp DH parameters ACCEPT We are facing similar issue with RSA while implementing our custom engine, please let me know if any one have a solution for this. We were able to use the RSA implementation upto 1.02h version, the problem is seen 1.1.0 series. Regards, Saurabh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bblack at wikimedia.org Sat Nov 12 16:29:25 2016 From: bblack at wikimedia.org (Brandon Black) Date: Sat, 12 Nov 2016 16:29:25 +0000 Subject: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0 Message-ID: Hi all, I'm running into an issue where if the server handshake response exceeds some value a little over 4K (which is pretty easy these days with a typical public cert, intermediate, and stapled OCSP response), we're suffering an extra RTT in our SSL negotiations with OpenSSL-1.1.0 (vs 1.0.2). The server software is nginx. You can see our internal ticket with more detail at: https://phabricator.wikimedia.org/T150561 . This same issue was already raised and fixed with nginx years ago against older OpenSSL versions in https://trac.nginx.org/nginx/ticket/413 . I suspect the workaround implemented at the time (which is obviously not an ideal use of the APIs to begin with, with that wbio vs rbio pointer comparison...) no longer works for 1.1.0. I've tried unconditionally calling BIO_set_write_buffer_size() in the same callback as well, but it didn't improve the situation. Is there an appropriate way to use the API to work around the write buffer limit at handshake time for a server application with 1.1.0, that we could patch up nginx with? Another alternative would be to raise the default buffer size to 8K to be more reflective of modern conditions. I've made such a commit at https://github.com/blblack/openssl/commit/5c3f1e46b61db591ea61d560ee51535286afa1a4 , but I haven't filed a pull request yet as I'm unsure on a couple of fronts here: (1) Whether there's an easier answer for server software developers within the existing APIs (the main question in this post) (2) With the default also currently being reused as the minimum possible buffer size, I'm not sure whether it would be acceptable to raise the minimum to 8K as well when changing the default. Splitting the two would be a bit more invasive. Thanks, -- Brandon From matt at openssl.org Mon Nov 14 10:04:34 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Nov 2016 10:04:34 +0000 Subject: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0 In-Reply-To: References: Message-ID: <234a6724-9a31-4015-31c3-19474537c287@openssl.org> On 12/11/16 16:29, Brandon Black wrote: > Hi all, > > I'm running into an issue where if the server handshake response > exceeds some value a little over 4K (which is pretty easy these days > with a typical public cert, intermediate, and stapled OCSP response), > we're suffering an extra RTT in our SSL negotiations with > OpenSSL-1.1.0 (vs 1.0.2). The server software is nginx. You can see > our internal ticket with more detail at: > https://phabricator.wikimedia.org/T150561 . > > This same issue was already raised and fixed with nginx years ago > against older OpenSSL versions in > https://trac.nginx.org/nginx/ticket/413 . > > I suspect the workaround implemented at the time (which is obviously > not an ideal use of the APIs to begin with, with that wbio vs rbio > pointer comparison...) no longer works for 1.1.0. I've tried > unconditionally calling BIO_set_write_buffer_size() in the same > callback as well, but it didn't improve the situation. During the handshake phase OpenSSL adds a buffering BIO in front of the wbio. However when you call SSL_get_wbio(), you get back the *real* wbio (without the bbio on the front). This is a change of behaviour between 1.1.0 and 1.0.2, and was because it was considered a bug that you could get back a different wbio from SSL_get_wbio() than the one that you originally set! So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio() is going to make no difference at all! Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0. I would certainly consider a pull request to add an accessor to get hold of it (missing accessors are considered as bug-fixes and so would be eligible for inclusion in a future 1.1.0d). Matt > > Is there an appropriate way to use the API to work around the write > buffer limit at handshake time for a server application with 1.1.0, > that we could patch up nginx with? > > Another alternative would be to raise the default buffer size to 8K to > be more reflective of modern conditions. I've made such a commit at > https://github.com/blblack/openssl/commit/5c3f1e46b61db591ea61d560ee51535286afa1a4 > , but I haven't filed a pull request yet as I'm unsure on a couple of > fronts here: > > (1) Whether there's an easier answer for server software developers > within the existing APIs (the main question in this post) > > (2) With the default also currently being reused as the minimum > possible buffer size, I'm not sure whether it would be acceptable to > raise the minimum to 8K as well when changing the default. Splitting > the two would be a bit more invasive. > > > Thanks, > -- Brandon > From bblack at wikimedia.org Mon Nov 14 13:37:13 2016 From: bblack at wikimedia.org (Brandon Black) Date: Mon, 14 Nov 2016 13:37:13 +0000 Subject: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0 In-Reply-To: <234a6724-9a31-4015-31c3-19474537c287@openssl.org> References: <234a6724-9a31-4015-31c3-19474537c287@openssl.org> Message-ID: On Mon, Nov 14, 2016 at 10:04 AM, Matt Caswell wrote: > During the handshake phase OpenSSL adds a buffering BIO in front of the > wbio. However when you call SSL_get_wbio(), you get back the *real* wbio > (without the bbio on the front). This is a change of behaviour between > 1.1.0 and 1.0.2, and was because it was considered a bug that you could > get back a different wbio from SSL_get_wbio() than the one that you > originally set! > > So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio() > is going to make no difference at all! > > Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0. > I would certainly consider a pull request to add an accessor to get hold > of it (missing accessors are considered as bug-fixes and so would be > eligible for inclusion in a future 1.1.0d). It would be pretty trivial to implement SSL_get_bbio(), and then we could patch up nginx to use it at the appropriate time (assuming CB_ACCEPT_LOOP is still the appropriate time - I haven't tried yet). But from an API usability standpoint for server implementation, this whole way of dealing with things seems pretty un-intuitive. Perhaps there should be SSL-level APIs for setting the write buffer size before the handshaking code is entered? SSL_set_write_buffer_size() intended to be used shortly after SSL_new(), but before handshaking begins, and SSL_CTX_set_write_buffer_size() to set the default inherited by SSL_new(). The implementation details of the buffer would then be more-opaque, and when the bbio is first initialized it can be sized appropriately from the parameter set by those functions and stored in ssl_session_st. -- Brandon From matt at openssl.org Mon Nov 14 14:08:20 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 14 Nov 2016 14:08:20 +0000 Subject: [openssl-users] Increasing the server write buffer for handshakes in 1.1.0 In-Reply-To: References: <234a6724-9a31-4015-31c3-19474537c287@openssl.org> Message-ID: <5aa77059-d058-764c-2737-0fba70c1b06d@openssl.org> On 14/11/16 13:37, Brandon Black wrote: > On Mon, Nov 14, 2016 at 10:04 AM, Matt Caswell wrote: >> During the handshake phase OpenSSL adds a buffering BIO in front of the >> wbio. However when you call SSL_get_wbio(), you get back the *real* wbio >> (without the bbio on the front). This is a change of behaviour between >> 1.1.0 and 1.0.2, and was because it was considered a bug that you could >> get back a different wbio from SSL_get_wbio() than the one that you >> originally set! >> >> So calling BIO_set_write_buffer_size() on the return from SSL_get_wbio() >> is going to make no difference at all! >> >> Unfortunately, I don't think there *is* a way to get the bbio in 1.1.0. >> I would certainly consider a pull request to add an accessor to get hold >> of it (missing accessors are considered as bug-fixes and so would be >> eligible for inclusion in a future 1.1.0d). > > It would be pretty trivial to implement SSL_get_bbio(), and then we > could patch up nginx to use it at the appropriate time (assuming > CB_ACCEPT_LOOP is still the appropriate time - I haven't tried yet). > But from an API usability standpoint for server implementation, this > whole way of dealing with things seems pretty un-intuitive. > > Perhaps there should be SSL-level APIs for setting the write buffer > size before the handshaking code is entered? > SSL_set_write_buffer_size() intended to be used shortly after > SSL_new(), but before handshaking begins, and > SSL_CTX_set_write_buffer_size() to set the default inherited by > SSL_new(). The implementation details of the buffer would then be > more-opaque, and when the bbio is first initialized it can be sized > appropriately from the parameter set by those functions and stored in > ssl_session_st. That would be good too, although that would be counted as a feature, not a bug fix so couldn't be in 1.1.0 (1.1.1 earliest). Perhaps we do both...again I'd be happy to look at PRs in this area. Matt From levitte at openssl.org Mon Nov 14 15:42:19 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 14 Nov 2016 16:42:19 +0100 (CET) Subject: [openssl-users] Failed to load libssl.so.1.1 while execuitng openssl comand In-Reply-To: References: Message-ID: <20161114.164219.1624119004523714158.levitte@openssl.org> In message on Fri, 11 Nov 2016 14:46:23 +0000, "Gupta, Saurabh" said: Saurabh.Gupta> I tried to execute ./openssl s_server command in the latest Openssl Saurabh.Gupta> Version 1.1.0c after doing Openssl compilation steps: Saurabh.Gupta> ./config Saurabh.Gupta> make Saurabh.Gupta> make test Saurabh.Gupta> make install Saurabh.Gupta> and It's throwing this error below: Saurabh.Gupta> ./openssl: error while loading shared libraries: libssl.so.1.1: cannot Saurabh.Gupta> open shared object file: No such file or directory Saurabh.Gupta> Saurabh.Gupta> after debugging this issue I found this error is coming because Saurabh.Gupta> libssl.so.1.1 is not present in /usr/lib64 directory. Saurabh.Gupta> but by default it should search these library in /usr/local/lib64/ Saurabh.Gupta> directory. Is that on Linux? Configure like this: ./config -Wl,--enable-new-dtags,-rpath,'$(LIBRPATH)' Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From levitte at openssl.org Mon Nov 14 15:44:26 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 14 Nov 2016 16:44:26 +0100 (CET) Subject: [openssl-users] Facing issues with dynamic loading engine RSA methods using e_capi.so library in openssl-1.1.0b. In-Reply-To: References: Message-ID: <20161114.164426.843130291445239740.levitte@openssl.org> What do you get from this command? ldd ../engines/capi.so? I think that the configuration example I gave you in my previous email will also help this... Cheers, Richard In message on Fri, 11 Nov 2016 14:46:45 +0000, "Gupta, Saurabh" said: Saurabh.Gupta> I tried to dynamically load e_capi.so engine example on openssl Saurabh.Gupta> version 1.1.0b present in the openssl engine directory but not able to Saurabh.Gupta> offload RSA methods. Saurabh.Gupta> Saurabh.Gupta> Commands Used: Saurabh.Gupta> (i) Saurabh.Gupta> ./openssl speed rsa -engine ../engines/capi.so Saurabh.Gupta> Error: Saurabh.Gupta> speed: Unknown algorithm -engine Saurabh.Gupta> Saurabh.Gupta> (ii) Saurabh.Gupta> ./openssl s_server -engine ../engines/capi.so Saurabh.Gupta> Error: Saurabh.Gupta> invalid engine "../engines/capi.so" Saurabh.Gupta> 139890999146240:error:25066067:DSO support routines:dlfcn_load:could Saurabh.Gupta> not load the shared library:crypto/dso/dso_dlfcn.c:113:filename Saurabh.Gupta> (/usr/local/lib64/engines-1.1/../engines/capi.so): Saurabh.Gupta> /usr/local/lib64/engines-1.1/../engines/capi.so: cannot open shared Saurabh.Gupta> object file: No such file or directory Saurabh.Gupta> 139890999146240:error:25070067:DSO support routines:DSO_load:could not Saurabh.Gupta> load the shared library:crypto/dso/dso_lib.c:161: Saurabh.Gupta> 139890999146240:error:260B6084:engine routines:dynamic_load:dso not Saurabh.Gupta> found:crypto/engine/eng_dyn.c:414: Saurabh.Gupta> 139890999146240:error:2606A074:engine routines:ENGINE_by_id:no such Saurabh.Gupta> engine:crypto/engine/eng_list.c:339:id=../engines/capi.so Saurabh.Gupta> 139890999146240:error:260B606D:engine routines:dynamic_load:init Saurabh.Gupta> failed:crypto/engine/eng_dyn.c:485: Saurabh.Gupta> Using default temp DH parameters Saurabh.Gupta> ACCEPT Saurabh.Gupta> Saurabh.Gupta> We are facing similar issue with RSA while implementing our custom Saurabh.Gupta> engine, please let me know if any one have a solution for this. We Saurabh.Gupta> were able to use the RSA implementation upto 1.02h version, the Saurabh.Gupta> problem is seen 1.1.0 series. Saurabh.Gupta> Saurabh.Gupta> Regards, Saurabh.Gupta> Saurabh From steve at openssl.org Mon Nov 14 20:02:00 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 14 Nov 2016 20:02:00 +0000 Subject: [openssl-users] X25519 not listed in ecparam -list_curves In-Reply-To: References: Message-ID: <20161114200200.GA5585@openssl.org> On Fri, Nov 04, 2016, Viktor J?gersk?pper wrote: > Hi, > > OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH > -curves X25519 -connect google.com:443" works as expected, and I get > "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the > output of "openssl ecparam -list_curves" in version 1.1.0b (I use > 1.1.0b-2 from Debian). Should it be listed there anyway? > The ecparam operation lists curves supported by the EC* API. The X25519 curve (for various reasons defined in the standards) is treated as a distinct algorithm so it is not listed by ecparam. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Mon Nov 14 20:11:09 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 14 Nov 2016 20:11:09 +0000 Subject: [openssl-users] C++ : Extracting CRL from a PKCS12 In-Reply-To: References: Message-ID: <20161114201109.GB5585@openssl.org> On Wed, Nov 02, 2016, Richard Stanek wrote: > My original requirements were to extract the user certificate, the > private key, and the CAs. For that I was using the call to > PKCS12_parse(...). This satisfied the original requirements. Very > easy to find, understand, and use. > > The new requirements that I have are that I also need to extract a CRL > from that PKCS12. I see that there is a CRLBag defined in the IETF > RFC 7292 PKCS12 Standard (https://tools.ietf.org/html/rfc7292), so I > know a CRL could exist inside a PKCS12. I can't seem to find any API > or C++ examples that extract a CRL from a PKSC12. > > Is there an API, example code, or advice on how to extract a CRL from a PKCS12? > I've never come across a PKCS#12 file containig a CRL before: would it be possible to send me a sample which obviously doesn't contain any important private keys. To answer your question, yes it is should be possible but it is messy. You need to parse the PKCS#12 file manually (see source to PKCS12_parse). In the funtion parse_bag you add an extra case for NID_crlBag and call PKCS12_SAFEBAG_get1_crl() on the bag, you should then get back an X509_CRL pointer or NULL on error. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Mon Nov 14 20:07:38 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 14 Nov 2016 20:07:38 +0000 Subject: [openssl-users] X25519 not listed in ecparam -list_curves Message-ID: <20161114200746.18280523.39961.101510@ll.mit.edu> As "-list-curves" is not supposed to work here, what would be a good way to tell if a given installation supports X25519? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Dr. Stephen Henson Sent: Monday, November 14, 2016 15:02 To: openssl-users at openssl.org Reply To: openssl-users at openssl.org Subject: Re: [openssl-users] X25519 not listed in ecparam -list_curves ? On Fri, Nov 04, 2016, Viktor J?gersk?pper wrote: > Hi, > > OpenSSL 1.1.0 implemented X25519. "openssl s_client -cipher kEECDH > -curves X25519 -connect google.com:443" works as expected, and I get > "Server Temp Key: X25519, 253 bits". But X25519 is not listed in the > output of "openssl ecparam -list_curves" in version 1.1.0b (I use > 1.1.0b-2 from Debian). Should it be listed there anyway? > ? The ecparam operation lists curves supported by the EC* API. The X25519 curve (for various reasons defined in the standards) is treated as a distinct algorithm so it is not listed by ecparam. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From richard.stanek at rockwellcollins.com Mon Nov 14 20:38:44 2016 From: richard.stanek at rockwellcollins.com (Richard Stanek) Date: Mon, 14 Nov 2016 14:38:44 -0600 Subject: [openssl-users] C++ : Extracting CRL from a PKCS12 In-Reply-To: <20161114201109.GB5585@openssl.org> References: <20161114201109.GB5585@openssl.org> Message-ID: Thanks for looking at this. I was insisting that nobody (in practice) puts CRLs inside of a PKCS12. Nobody does that... I could find no evidence that this is ever done, nor was there any support for this deviant behavior. ;-) I was handed a specification to implement that had CRLs inside of PKCS12. From the beginning, I doubted the writers of that specification knew what they were doing. And I expect that they don't have any test data, either. Over the last few days, I had being doing exactly what you suggested, a messy manual parsing process. I have achieved success in building a PKCS12 with CRLs and success in parsing that PKCS12. Again, thanks for looking at this and validating what I have been thinking and feeling about putting CRLs into PKCS12s. -Rick On Mon, Nov 14, 2016 at 2:11 PM, Dr. Stephen Henson wrote: > On Wed, Nov 02, 2016, Richard Stanek wrote: > >> My original requirements were to extract the user certificate, the >> private key, and the CAs. For that I was using the call to >> PKCS12_parse(...). This satisfied the original requirements. Very >> easy to find, understand, and use. >> >> The new requirements that I have are that I also need to extract a CRL >> from that PKCS12. I see that there is a CRLBag defined in the IETF >> RFC 7292 PKCS12 Standard (https://tools.ietf.org/html/rfc7292), so I >> know a CRL could exist inside a PKCS12. I can't seem to find any API >> or C++ examples that extract a CRL from a PKSC12. >> >> Is there an API, example code, or advice on how to extract a CRL from a PKCS12? >> > > I've never come across a PKCS#12 file containig a CRL before: would it be > possible to send me a sample which obviously doesn't contain any important > private keys. > > To answer your question, yes it is should be possible but it is messy. You > need to parse the PKCS#12 file manually (see source to PKCS12_parse). In > the funtion parse_bag you add an extra case for NID_crlBag and call > PKCS12_SAFEBAG_get1_crl() on the bag, you should then get back an X509_CRL > pointer or NULL on error. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Mon Nov 14 21:05:06 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 14 Nov 2016 21:05:06 +0000 Subject: [openssl-users] X25519 not listed in ecparam -list_curves In-Reply-To: <20161114200746.18280523.39961.101510@ll.mit.edu> References: <20161114200746.18280523.39961.101510@ll.mit.edu> Message-ID: <20161114210506.GA7041@openssl.org> On Mon, Nov 14, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > As "-list-curves" is not supposed to work here, what would be a good way to tell if a given installation supports X25519? > Well only OpenSSL 1.1.0 currently supports X25519. One way is to look at the output of: openssl list -public-key-algorithms Though that command doesn't exist before OpenSSL 1.1.0. Alternatively just generate a private key with: openssl genpkey -algorithm X25519 Which will work in OpenSSL 1.1.0 but give an error in previous versions. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From joachim.person at gmail.com Tue Nov 15 10:16:49 2016 From: joachim.person at gmail.com (Joachim Person) Date: Tue, 15 Nov 2016 11:16:49 +0100 Subject: [openssl-users] Missing documentation In-Reply-To: <582265A1.2060004@frank4dd.com> References: <582265A1.2060004@frank4dd.com> Message-ID: Thanks Frank, I assume that by "the SSL error handler" you mean that I can get the error by calling ERR_get_error() ? BR Joachim 2016-11-09 0:54 GMT+01:00 Frank Migge : > Hi Joachim, > > >> It seems like the documentation for SSL_set_tlsext_host_name is gone. > >> Does anyone know where I can find the documentation? I am interested in > the return values right now. > > If I got it right: > > 1) ssl/tls1.h (line 334ff): # define SSL_set_tlsext_host_name(s,name) \ > 334 SSL_ctrl(s,SSL_CTRL_SET_TLSEXT_HOSTNAME,TLSEXT_NAMETYPE_host_name,(char > *)name) > > 2) https://www.openssl.org/docs/manmaster/man3/SSL_ctrl.html: > The return values of the SSL*_ctrl() functions depend on the command > supplied via the *cmd* parameter. > > 3) ssl/s3_lib.c (line 3311 ff): case SSL_CTRL_SET_TLSEXT_HOSTNAME: > returns 1 on success, and 0 on failure which also writes the cause to the > SSL error handler. > > Best wishes > Frank > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From veredz at elta.co.il Wed Nov 16 20:17:31 2016 From: veredz at elta.co.il (Vered Zvi) Date: Wed, 16 Nov 2016 20:17:31 +0000 Subject: [openssl-users] How to authenticate an OpenSSL client in the server ? Message-ID: <1EFFBDE6584C794F8A0ADF2CAC8D60E09F8C7503@eltidex2.elta.co.il> Hello, My OpenSSL server has to authenticate that a valid OpenSSL client is asking for connection. Is this feature part of OpenSSL ? Can you please send a sample code doing this in the server side ? The motivation: If a client was stolen I can block it from asking for connection. The server + clients are in a local netowrk isolated from the global Internet. Thank you in advance, Z.V The information contained in this communication is proprietary to Israel Aerospace Industries Ltd. and/or third parties, may contain confidential or privileged information, and is intended only for the use of the intended addressee thereof. If you are not the intended addressee, please be aware that any use, disclosure, distribution and/or copying of this communication is strictly prohibited. If you receive this communication in error, please notify the sender immediately and delete it from your computer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Craig_Weeks at trendmicro.com Wed Nov 16 22:58:17 2016 From: Craig_Weeks at trendmicro.com (Craig_Weeks at trendmicro.com) Date: Wed, 16 Nov 2016 22:58:17 +0000 Subject: [openssl-users] Disable/Enable TLS versions for all connections at runtime Message-ID: I am an OpenSSL neophyte, so please bear with me if the answer is obvious in the documentation. Our product is going to provide runtime options to the user to enable and disable TLS 1.0, 1.1 and 1.2 in a discrete manner. For example: today enable 1.0 and 1.2, disable 1.1; tomorrow enable 1.1 and 1.2, disable 1.0. How do I use the available APIs to toggle the availability of these versions of TLS at runtime (as opposed to some compile time switch that permanently removes support for 1 or more versions)? I want these settings to apply to all new connections after they have been enabled or disabled. Craig Weeks | Senior Software Engineer, Support Response Team (SRT) craig_weeks at trendmicro.com 14231 Tandem Blvd, Austin TX 78728 www.trendmicro.com 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
-------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Nov 16 23:21:07 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 16 Nov 2016 23:21:07 +0000 Subject: [openssl-users] Disable/Enable TLS versions for all connections at runtime In-Reply-To: References: Message-ID: <20161116232107.GN26244@mournblade.imrryr.org> On Wed, Nov 16, 2016 at 10:58:17PM +0000, Craig_Weeks at trendmicro.com wrote: > Our product is going to provide runtime options to the user to enable and > disable TLS 1.0, 1.1 and 1.2 in a discrete manner. This is a bad interface. Do not implement this feature. Instead support only a contiguous range of protocol versions, by allowing the user to specify a lowest supported version and a highest supported version. This maps directly onto the OpenSSL 1.1.0 API, but in older versions you'll need to map these onto corresponding: SSL_OP_NO_... macros to disable all versions below the lowest, and if possible, at least one version above the highest. Note that that TLS 1.2 is the highest supported in OpenSSL 1.0.x, and no higher versions will be added. So "<= TLS 1.2" is the same as not bounded above. -- Viktor. From matt at openssl.org Wed Nov 16 23:22:11 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Nov 2016 23:22:11 +0000 Subject: [openssl-users] Disable/Enable TLS versions for all connections at runtime In-Reply-To: References: Message-ID: On 16/11/16 22:58, Craig_Weeks at trendmicro.com wrote: > I am an OpenSSL neophyte, so please bear with me if the answer is > obvious in the documentation. > > > > Our product is going to provide runtime options to the user to enable > and disable TLS 1.0, 1.1 and 1.2 in a discrete manner. For example: > today enable 1.0 and 1.2, disable 1.1; tomorrow enable 1.1 and 1.2, > disable 1.0. > > > > How do I use the available APIs to toggle the availability of these > versions of TLS at runtime (as opposed to some compile time switch that > permanently removes support for 1 or more versions)? I want these > settings to apply to all new connections after they have been enabled or > disabled. The preferred way to do this is using SSL_CTX_set_max_proto_version() and SSL_CTX_set_min_proto_version(): https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_max_proto_version.html Note these macros are only available in OpenSSL 1.1.0. If you need something that will work in OpenSSL 1.0.2 and 1.1.0 then you can use SSL_CTX_set_options() to disable specific protocol versions: https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_options.html Note: your example of "enable 1.0 and 1.2, disable 1.1" would be strongly discouraged. You are encouraged to only allow a contiguous set of protocol versions without any "holes". It is possible to do this with SSL_CTX_set_options() although you may get some unpredictable results around version negotiation. Matt From danchik at rebelbase.com Wed Nov 16 23:22:09 2016 From: danchik at rebelbase.com (Dan S) Date: Wed, 16 Nov 2016 15:22:09 -0800 Subject: [openssl-users] Disable/Enable TLS versions for all connections at runtime In-Reply-To: References: Message-ID: I thought there is anything that would stop you from compiling with everything and make choices at run time, (TLSv1_2_method, TLSv1_1_method, TLSv1_method, SSLv23_method etc... just set the right flags and cyphers) On Wed, Nov 16, 2016 at 2:58 PM, Craig_Weeks at trendmicro.com < Craig_Weeks at trendmicro.com> wrote: > I am an OpenSSL neophyte, so please bear with me if the answer is obvious > in the documentation. > > > > Our product is going to provide runtime options to the user to enable and > disable TLS 1.0, 1.1 and 1.2 in a discrete manner. For example: today > enable 1.0 and 1.2, disable 1.1; tomorrow enable 1.1 and 1.2, disable 1.0. > > > > How do I use the available APIs to toggle the availability of these > versions of TLS at runtime (as opposed to some compile time switch that > permanently removes support for 1 or more versions)? I want these settings > to apply to all new connections after they have been enabled or disabled. > > > > *Craig Weeks *| Senior Software Engineer, Support Response Team (SRT) > > > > craig_weeks at trendmicro.com > > > > 14231 Tandem Blvd, Austin TX 78728 > > > > www.trendmicro.com > > > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Nov 16 23:26:38 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Nov 2016 23:26:38 +0000 Subject: [openssl-users] Disable/Enable TLS versions for all connections at runtime In-Reply-To: References: Message-ID: <89c70f5a-782a-32e8-bee6-55adc5e69b31@openssl.org> On 16/11/16 23:22, Dan S wrote: > I thought there is anything that would stop you from compiling with > everything and make choices at run time, (TLSv1_2_method, > TLSv1_1_method, TLSv1_method, SSLv23_method etc... just set the right > flags and cyphers) Do not use the TLS*method() functions for this purpose. They will lock you into one specific protocol version. It is best to always use the version flexible method TLS_method() (this was called SSLv23_method() in 1.0.2 - but it is the same thing despite the confusing name), and then configure allowed versions with SSL_CTX_set_max_proto_version() and SSL_CTX_set_min_proto_version() as described in my other post. Matt > > On Wed, Nov 16, 2016 at 2:58 PM, Craig_Weeks at trendmicro.com > > wrote: > > I am an OpenSSL neophyte, so please bear with me if the answer is > obvious in the documentation.____ > > __ __ > > Our product is going to provide runtime options to the user to > enable and disable TLS 1.0, 1.1 and 1.2 in a discrete manner. For > example: today enable 1.0 and 1.2, disable 1.1; tomorrow enable 1.1 > and 1.2, disable 1.0.____ > > __ __ > > How do I use the available APIs to toggle the availability of these > versions of TLS at runtime (as opposed to some compile time switch > that permanently removes support for 1 or more versions)? I want > these settings to apply to all new connections after they have been > enabled or disabled.____ > > __ __ > > *Craig Weeks *| Senior Software Engineer, Support Response Team > (SRT)____ > > __ __ > > craig_weeks at trendmicro.com ____ > > __ __ > > 14231 Tandem Blvd, Austin TX 78728____ > > __ __ > > www.trendmicro.com ____ > > __ __ > > TREND MICRO EMAIL NOTICE > The information contained in this email and any attachments is confidential > and may be subject to copyright or other intellectual property protection. > If you are not the intended recipient, you are not authorized to use or > disclose this information, and we request that you notify us by reply mail or > telephone and delete the original message from your mail system. > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From kgoldman at us.ibm.com Wed Nov 16 23:34:39 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Wed, 16 Nov 2016 18:34:39 -0500 Subject: [openssl-users] Openssl 1.1 port - hash state serializing Message-ID: I have a simulation of a hardware device that has the following characteristics: - does hashing functions - resource constrained - multi-user Therefore, a typical pattern is that one application starts a digest calculation, then the hash state must get swapped out for another user. In 1.0, I did this by (cheating) serializing the hash state to swap out, than deserializing to swap back in. This required looking inside the hash state structure. I know it wasn't portable accross versions, but the structure was pretty stable. Is there a way to do this in 1.1? Can one be added? From noloader at gmail.com Thu Nov 17 00:55:28 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 16 Nov 2016 19:55:28 -0500 Subject: [openssl-users] CONF-less OpenSSL configuration? Message-ID: Is it possible to setup a CONF-less OpenSSL? If so, how? The use case is mobile apps, like Android, iOS and Windows Phone. There is no OPENSSLDIR per se; and the app's install directory will be a moving target like a UUID. I know hacks can be applied for iOS, like forgoing a macro and returning NSHomeDirectory(). But I think I would rather avoid the hack and go CONF-less. Jeff From danchik at rebelbase.com Thu Nov 17 01:08:39 2016 From: danchik at rebelbase.com (Dan S) Date: Wed, 16 Nov 2016 17:08:39 -0800 Subject: [openssl-users] CONF-less OpenSSL configuration? In-Reply-To: References: Message-ID: internal file structure of iOS app is well defined with API to access the directories without any hacks (I assume you weren't looking to access a directory outside of your app) https://developer.apple.com/library/content/documentation/FileManagement/Conceptual/FileSystemProgrammingGuide/FileSystemOverview/FileSystemOverview.html On Wed, Nov 16, 2016 at 4:55 PM, Jeffrey Walton wrote: > Is it possible to setup a CONF-less OpenSSL? If so, how? > > The use case is mobile apps, like Android, iOS and Windows Phone. > There is no OPENSSLDIR per se; and the app's install directory will be > a moving target like a UUID. > > I know hacks can be applied for iOS, like forgoing a macro and > returning NSHomeDirectory(). But I think I would rather avoid the hack > and go CONF-less. > > Jeff > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sivagopi059 at gmail.com Thu Nov 17 05:08:33 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Wed, 16 Nov 2016 22:08:33 -0700 (MST) Subject: [openssl-users] net_ratelimit: 3480 callbacks suppressed Message-ID: <1479359313038-69046.post@n7.nabble.com> Hi, As i know machine allowed 10 messages in 5 seconds as configured in the /proc/sys/kernel/printk_ratelimit and /proc/sys/kernel/printk_ratelimit_burst files. But my question is why this logging crosses 10 messages in 5 seconds and in which case it will happen. And why normally kernel will have default value to 10 messages in 5 seconds. And what is the main advantage of this scenario. Thanks, Gopi. -- View this message in context: http://openssl.6102.n7.nabble.com/net-ratelimit-3480-callbacks-suppressed-tp69046.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Saurabh.Gupta at cavium.com Fri Nov 18 10:18:55 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Fri, 18 Nov 2016 10:18:55 +0000 Subject: [openssl-users] Facing issue while using -engine flag for rsa/dsa speed test in openssl-1.1.0b Message-ID: Facing issue while using -engine flag for rsa/dsa speed test in openssl-1.1.0b but It's working for digest or symmetric apis. Commands Used: Not Working ./openssl speed rsa -engine ../engines/dasync.so Error: speed: Unknown algorithm -engine Commands Used: Working ./openssl speed -evp md5 -engine ../engines/dasync.so engine "dasync" set. Doing md5 for 3s on 16 size blocks: 9467552 md5's in 3.00s Doing md5 for 3s on 64 size blocks: 7379943 md5's in 3.00s Doing md5 for 3s on 256 size blocks: 4213375 md5's in 3.00s Doing md5 for 3s on 1024 size blocks: 1597182 md5's in 3.00s -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 18 10:25:11 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Nov 2016 10:25:11 +0000 Subject: [openssl-users] Facing issue while using -engine flag for rsa/dsa speed test in openssl-1.1.0b In-Reply-To: References: Message-ID: <8c85e0dc-e712-185d-38f7-3739bff5e7ce@openssl.org> When using the openssl command line you should put options (i.e. those with a "-" at the front) first, followed by any other arguments. On 18/11/16 10:18, Gupta, Saurabh wrote: > Facing issue while using -engine flag for rsa/dsa speed test in > openssl-1.1.0b but It's working for digest or symmetric apis. > > > Commands Used: Not Working > > ./openssl speed rsa -engine ../engines/dasync.so > Error: > speed: Unknown algorithm -engine rsa isn't an option just a normal command line argument so try: ./openssl speed -engine ../engines/dasync.so rsa > Commands Used: Working > ./openssl speed -evp md5 -engine ../engines/dasync.so This works because "md5" is a parameter to the "-evp" option. So you have obeyed the rule of putting the options before any other arguments (because there are no other arguments in this case). Matt From write2mukesh84 at gmail.com Fri Nov 18 14:30:32 2016 From: write2mukesh84 at gmail.com (Mukesh Yadav) Date: Fri, 18 Nov 2016 20:00:32 +0530 Subject: [openssl-users] Query for Openssl-1.1.0. Message-ID: HI, I am updating a solution from openssl-1.0.2 to openssl-1.1.0. Here I see most of earlier definations of struct like EVP_PKEY_CTX/HMAC_CTX are made local within Openssl. To access, thier internal struct member, new API's are introduced. Ex. const EVP_CIPHER *test = EVP_des_cbc(); int a = test->ctx_size; This old code doesnt work with new Openssl-1.1.0. To get this working, code need to be changed to int a = EVP_CIPHER_impl_ctx_size(EVP_des_cbc()); Similarly facing issue while using sizeof(HMAC_CTX). After browing/grep inside openssl-1.1.0, didnt saw any replacement for using code like sizeof(HMAC_CTX) outside library from application.. Error: a.c:24: error: invalid application of 'sizeof' to incomplete type 'HMAC_CTX' Any pointer for resolving this, will be helpful. Thanks in advance.. Thanks Mukesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 18 14:33:02 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Nov 2016 14:33:02 +0000 Subject: [openssl-users] Query for Openssl-1.1.0. In-Reply-To: References: Message-ID: <156e20d7-dd5b-d3cb-ae27-3178ca818a2c@openssl.org> On 18/11/16 14:30, Mukesh Yadav wrote: > HI, > > > I am updating a solution from openssl-1.0.2 to openssl-1.1.0. > > Here I see most of earlier definations of struct > like EVP_PKEY_CTX/HMAC_CTX are made local within Openssl. > > To access, thier internal struct member, new API's are introduced. > > > Ex. const EVP_CIPHER *test = EVP_des_cbc(); > int a = test->ctx_size; > > This old code doesnt work with new Openssl-1.1.0. > To get this working, code need to be changed to > int a = EVP_CIPHER_impl_ctx_size(EVP_des_cbc()); > > Similarly facing issue while using sizeof(HMAC_CTX). > After browing/grep inside openssl-1.1.0, didnt saw any replacement > for using code like sizeof(HMAC_CTX) outside library from application.. > > Error: > a.c:24: error: invalid application of 'sizeof' to incomplete type 'HMAC_CTX' > > Any pointer for resolving this, will be helpful. > Thanks in advance.. Why do you need to know this size? Can your code be rewritten to not need it? Matt From write2mukesh84 at gmail.com Fri Nov 18 15:16:23 2016 From: write2mukesh84 at gmail.com (Mukesh Yadav) Date: Fri, 18 Nov 2016 20:46:23 +0530 Subject: [openssl-users] Query for Openssl-1.1.0. In-Reply-To: <156e20d7-dd5b-d3cb-ae27-3178ca818a2c@openssl.org> References: <156e20d7-dd5b-d3cb-ae27-3178ca818a2c@openssl.org> Message-ID: Thanks Matt for quick reply. If there is not way to get the sizeof(XYZ), then yes application code will be changed. Actually since application is quite old and base is large, I am sure, will get more such instance. Hence before proceeding, wanted to confirm that there is no way with new openssl to get size and no api is provided to achieve same. Regards, Mukesh On 18 November 2016 at 20:03, Matt Caswell wrote: > > > On 18/11/16 14:30, Mukesh Yadav wrote: > > HI, > > > > > > I am updating a solution from openssl-1.0.2 to openssl-1.1.0. > > > > Here I see most of earlier definations of struct > > like EVP_PKEY_CTX/HMAC_CTX are made local within Openssl. > > > > To access, thier internal struct member, new API's are introduced. > > > > > > Ex. const EVP_CIPHER *test = EVP_des_cbc(); > > int a = test->ctx_size; > > > > This old code doesnt work with new Openssl-1.1.0. > > To get this working, code need to be changed to > > int a = EVP_CIPHER_impl_ctx_size(EVP_des_cbc()); > > > > Similarly facing issue while using sizeof(HMAC_CTX). > > After browing/grep inside openssl-1.1.0, didnt saw any replacement > > for using code like sizeof(HMAC_CTX) outside library from application.. > > > > Error: > > a.c:24: error: invalid application of 'sizeof' to incomplete type > 'HMAC_CTX' > > > > Any pointer for resolving this, will be helpful. > > Thanks in advance.. > > Why do you need to know this size? Can your code be rewritten to not > need it? > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 18 15:22:56 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 18 Nov 2016 15:22:56 +0000 Subject: [openssl-users] Query for Openssl-1.1.0. In-Reply-To: References: <156e20d7-dd5b-d3cb-ae27-3178ca818a2c@openssl.org> Message-ID: On 18/11/16 15:16, Mukesh Yadav wrote: > Thanks Matt for quick reply. > If there is not way to get the sizeof(XYZ), then yes application code > will be changed. > > Actually since application is quite old and base is large, I am sure, > will get more such instance. > Hence before proceeding, wanted to confirm that there is no way with new > openssl to get size and no api is provided to achieve same. No, there is no current way to get that size. Matt From hkm73560 at gmail.com Mon Nov 21 04:42:26 2016 From: hkm73560 at gmail.com (=?UTF-8?B?7Zmp6rec66+8?=) Date: Mon, 21 Nov 2016 13:42:26 +0900 Subject: [openssl-users] What is the purpose of util/mkdef.pl Message-ID: Hi, I have one question about the purpose of mkdef.pl. I noticed that some errors occur when I add my own function to the openssl library and compile it omitting a command lke this 'perl utile/mkdef.pl ssl update OR perl utile/mkdef.pl crypto update'. What is the mkdef.pl? and Why I need to update that file? Thank you for your helps in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Nov 21 12:53:45 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 21 Nov 2016 12:53:45 +0000 Subject: [openssl-users] What is the purpose of util/mkdef.pl In-Reply-To: References: Message-ID: <101d437a09d94049beca3a2652a43fa3@usma1ex-dag1mb1.msg.corp.akamai.com> If you add your own function, you need to run ?make update? which calls mkdef. It is needed for the build procedure. From John.Eichenberger at Honeywell.com Mon Nov 21 18:52:20 2016 From: John.Eichenberger at Honeywell.com (Eichenberger, John) Date: Mon, 21 Nov 2016 18:52:20 +0000 Subject: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k Message-ID: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> I am building both OpenSSL and WPA Supplicant for use on a Windows Mobile 6.5 platform. The WPA Supplicant version in use is based upon the hostap_2_0 tag from http://w1.fi/hostap.git. The version of OpenSSL that we have been using until now is based upon the OpenSSL_1_0_1g from https://github.com/openssl/openssl I can upgrade to OpenSSL_1_0_1j and still succeed. But when I merge changes from OpenSSL_1_0_1k, all 802.1x authentication fails. I narrowed this problem down to a single line in crypto/constant_time_locl.h. Attached is the patch set that I applied to resolve this issue for me. It is a confusing issue because I can compile that same bit of code in Visual Studio within a different trivial application and see that although the two methods for that bit of code produce slightly different assembly language, both should produce the same result. And for that trivial application they do! So why this difference breaks authentication for me when it is all thrown together makes no sense. In my patch set you can see that I also changed what compiler switches are used for the WinCE target. That change did not appear to fix or break anything. -Ike- John Eichenberger Intermec by Honeywell Principal Engineer: Sustaining Engineering 425.921.4507 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Avoid-the-VS-2008-compiler-bug-that-breaks-1.0.1k-th.patch Type: application/octet-stream Size: 1597 bytes Desc: 0001-Avoid-the-VS-2008-compiler-bug-that-breaks-1.0.1k-th.patch URL: From rsalz at akamai.com Mon Nov 21 21:37:58 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 21 Nov 2016 21:37:58 +0000 Subject: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k In-Reply-To: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> References: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> Message-ID: <3037146a1d824f9f887ae093a598e9a5@usma1ex-dag1mb1.msg.corp.akamai.com> Shouldn't you check for VS 2008 as well as MSC_VER ? From John.Eichenberger at Honeywell.com Mon Nov 21 23:59:39 2016 From: John.Eichenberger at Honeywell.com (Eichenberger, John) Date: Mon, 21 Nov 2016 23:59:39 +0000 Subject: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k In-Reply-To: <3037146a1d824f9f887ae093a598e9a5@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> <3037146a1d824f9f887ae093a598e9a5@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAFDD@de08ex3010.global.ds.honeywell.com> Possibly. I haven't scoped it any further than the fact that it fails for my build, which happens to use VS 2008. I am ill equipped to swap in different compiler versions and try again. -Ike- John Eichenberger Intermec by Honeywell Principal Engineer:?Sustaining Engineering 425.921.4507 -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Monday, November 21, 2016 1:38 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k Shouldn't you check for VS 2008 as well as MSC_VER ? -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From samullap at cisco.com Tue Nov 22 06:51:26 2016 From: samullap at cisco.com (Sashank Mullapudi (samullap)) Date: Tue, 22 Nov 2016 06:51:26 +0000 Subject: [openssl-users] Disabling Client-Initiated TLS renegotiation Message-ID: Hi, As part of securing our web interfaces, we wanted to disable client-initiated TLS renegotiation. The reasoning for this requirement is as follows- Generally, renegotiation of TLS sessions is much more resource-intensive for the server than the client, and should therefore not be performed at will to avoid degrading performance. Disabling client from renegotiating secures the server from undergoing a DoS attack due to continuous renegotiation requests. I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, but that is to secure the renegotiation, not disable it. I wanted to check if there is a patch or flag available to disable any negotiation initiated from the client side. Thanks and Regards, Sashank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Nov 22 07:49:02 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 22 Nov 2016 08:49:02 +0100 Subject: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k In-Reply-To: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> References: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> Message-ID: <1b0c86bc-79aa-99af-6174-0e556691fe83@wisemo.com> On 21/11/2016 19:52, Eichenberger, John wrote: > > I am building both OpenSSL and WPA Supplicant for use on a Windows > Mobile 6.5 platform. > > The WPA Supplicant version in use is based upon the hostap_2_0 tag > from http://w1.fi/hostap.git. > > The version of OpenSSL that we have been using until now is based upon > the OpenSSL_1_0_1g from https://github.com/openssl/openssl > > I can upgrade to OpenSSL_1_0_1j and still succeed. But when I merge > changes from OpenSSL_1_0_1k, all 802.1x authentication fails. > > I narrowed this problem down to a single line in > crypto/constant_time_locl.h. Attached is the patch set that I applied > to resolve this issue for me. > > It is a confusing issue because I can compile that same bit of code in > Visual Studio within a different trivial application and see that > although the two methods for that bit of code produce slightly > different assembly language, both should produce the same result. And > for that trivial application they do! So why this difference breaks > authentication for me when it is all thrown together makes no sense. > > In my patch set you can see that I also changed what compiler switches > are used for the WinCE target. That change did not appear to fix or > break anything. > > I presume you are building for the ARM architecture since you didn't specify. Have you checked if reverting to the old compiler switches makes 1.0.1k work properly (even though it didn't break 1.0.1j)? The entire thing looks like a compiler bug in handling the expression used in 1.0.1k? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From root at c-works.net Tue Nov 22 08:40:21 2016 From: root at c-works.net (Harald Koch) Date: Tue, 22 Nov 2016 09:40:21 +0100 Subject: [openssl-users] SMIME signing with SHA1 Message-ID: <2F146687-2799-44D4-AC45-A4739576A793@c-works.net> Hello, I?m facing a critical situation in my application when creating a signed SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. 1.0.2h), the following command worked as expected: /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer cert_key.pem -md sha1 The message output contains a header using sha1: Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="??7E9FFA1842442B7192D83A53D8D35C89" With openSSL 1.1.0c, I get a segmentation fault with the same command. Using md5 or sha256 (or even not providing the parameter ?-md?, resultig in sha256) the command works as expected. Trying to determine where the segmentation fault happen, I used my C program to step through every function call, it turns out that ?SMIME_write_PKCS7? seems to be the critical point. I?m sure I?m using the correct LD_LIBRARY_PATH environment variable value for every test in Linux. The platforms I tested are Linux 32bit & 64bit, Mac OS 10.12.1. Thank you for any help. Harald Koch From ajaygargnsit at gmail.com Tue Nov 22 14:03:10 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Tue, 22 Nov 2016 19:33:10 +0530 Subject: [openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors Message-ID: Hi All. I wish to compile openssl libraries for a STM32-processor (which would then be linked statically with our application-framework code). Now. I believe that OpenSSL uses tonnes of "malloc"s and "free"s. But for bare-metal-systems (without any formal OSes), we generally don't have any heap-memory. So, what is the protocol for compiling OpenSSL for such systems? I am sorry, but this is the first time I would be compiling for a non-OS entity. Will be thankful for inputs. Thanks and Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From John.Eichenberger at Honeywell.com Tue Nov 22 17:04:18 2016 From: John.Eichenberger at Honeywell.com (Eichenberger, John) Date: Tue, 22 Nov 2016 17:04:18 +0000 Subject: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k In-Reply-To: <1b0c86bc-79aa-99af-6174-0e556691fe83@wisemo.com> References: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DAF1D@de08ex3010.global.ds.honeywell.com> <1b0c86bc-79aa-99af-6174-0e556691fe83@wisemo.com> Message-ID: <4B52C7E72CDDF34C8BF907FD9EBEAE1B1F3DB0E6@de08ex3010.global.ds.honeywell.com> Yes. The build methods were kept constant at first as I tried to upgrade. Currently I am using STANDARDSDK_500 to build for CE50_ARMV4I, or at least that is the build target that was tested. We also build for many other target platforms as well, I haven't tested any of them yet. Details could probably be provided if that is of any use. We use Ant/Ivy and Jenkins in our build system. But most of the builds I performed locally without much of those details involved. Batch files get launched that set up the details of the build. Slight modifications have been made to the Perl scripts to enhance the product. For example, the standard scripts avoid the use of resource files for /CE/ builds. I not only use resource files, but improve the content of those files to indicate our build version together with the OpenSSL version tag that it is based upon. We also support FIPS so the resource file can indicate which builds are FIPS compatible and which ones are not. Ultimately I built all of the following versions: * 1.0.1g -- legacy version that has been working for years * 1.0.1t -- built without error, failed to authenticate any 802.1x protocol such as PEAP with our WPA supplicant. * 1.0.2h -- built without error even easier than 1.0.1t, failed to authenticate any 802.1x protocol such as PEAP with our WPA supplicant. * 1.0.1n -- failed the same as the others that failed * 1.0.1i -- works the same as 1.0.1g * 1.0.1l -- failed the same as the others that failed * 1.0.1k -- failed to compile until I ported a one-line fix from a later version, then built okay but failed to function correctly * 1.0.1j -- works * I tediously sliced up the differences between 1.0.1j and 1.0.1k to discover first the file and then the minimum set of changes required to reproduce failures. * Have since then ported that conditional to our 1.0.2j build. It works and that gets us to where we need to be right now. I realize that the conditional I used may be overkill. But working is good enough for the company. Even it if it not good enough for the open source community. I further pursued the differences between working and not working, but haven't been able to reproduce failure apart from a full OpenSSL build. In other words, in a small test program both methods for computing constant_time_msb worked fine. The assembly language is slightly different from one another since the new method uses a logical shift operation whereas the previous method uses an arithmetic shift operation, but never the less I was unable to reproduce a compiler error using the same version of Microsoft compiler. I've seen issues like this before where compiler errors depend upon more than just the lines in question. Unfortunately I haven't the time to dedicate to determining anything more about this issue since I have a working version that meets our needs. As indicated in the original email, the change to compiler switches neither fixed nor broke anything. I only made that change after all of the tests above, as an attempt to see if I could forgo changing source code altogether. I prefer using the same optimization switches used for Win32 builds so I left that change in even though it did not fix the compiler bug. So ultimately this email is about reporting an issue that perhaps deserves nothing more than a comment in source code, I don't know. I can keep an eye on this issue and report any further developments as they are discovered. But it will likely be a long time before we need to revisit work on OpenSSL. -Ike- John Eichenberger Intermec by Honeywell Principal Engineer:?Sustaining Engineering 425.921.4507 -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: Monday, November 21, 2016 11:49 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] FW: Visual Studio compiler error for WinCE since OpenSSL version 1.0.1k On 21/11/2016 19:52, Eichenberger, John wrote: > > I am building both OpenSSL and WPA Supplicant for use on a Windows > Mobile 6.5 platform. > > The WPA Supplicant version in use is based upon the hostap_2_0 tag > from http://w1.fi/hostap.git. > > The version of OpenSSL that we have been using until now is based upon > the OpenSSL_1_0_1g from https://github.com/openssl/openssl > > I can upgrade to OpenSSL_1_0_1j and still succeed. But when I merge > changes from OpenSSL_1_0_1k, all 802.1x authentication fails. > > I narrowed this problem down to a single line in > crypto/constant_time_locl.h. Attached is the patch set that I applied > to resolve this issue for me. > > It is a confusing issue because I can compile that same bit of code in > Visual Studio within a different trivial application and see that > although the two methods for that bit of code produce slightly > different assembly language, both should produce the same result. And > for that trivial application they do! So why this difference breaks > authentication for me when it is all thrown together makes no sense. > > In my patch set you can see that I also changed what compiler switches > are used for the WinCE target. That change did not appear to fix or > break anything. > > I presume you are building for the ARM architecture since you didn't specify. Have you checked if reverting to the old compiler switches makes 1.0.1k work properly (even though it didn't break 1.0.1j)? The entire thing looks like a compiler bug in handling the expression used in 1.0.1k? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Tue Nov 22 22:25:58 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 22 Nov 2016 22:25:58 +0000 Subject: [openssl-users] SMIME signing with SHA1 In-Reply-To: <2F146687-2799-44D4-AC45-A4739576A793@c-works.net> References: <2F146687-2799-44D4-AC45-A4739576A793@c-works.net> Message-ID: <20161122222558.GA24285@openssl.org> On Tue, Nov 22, 2016, Harald Koch wrote: > Hello, > > I???m facing a critical situation in my application when creating a signed SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. 1.0.2h), the following command worked as expected: > > /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer cert_key.pem -md sha1 > > The message output contains a header using sha1: > > Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="??????7E9FFA1842442B7192D83A53D8D35C89" > > > With openSSL 1.1.0c, I get a segmentation fault with the same command. Using md5 or sha256 (or even not providing the parameter ???-md???, resultig in sha256) the command works as expected. Trying to determine where the segmentation fault happen, I used my C program to step through every function call, it turns out that ???SMIME_write_PKCS7??? seems to be the critical point. > > I???m sure I???m using the correct LD_LIBRARY_PATH environment variable value for every test in Linux. The platforms I tested are Linux 32bit & 64bit, Mac OS 10.12.1. > It's a bug in OpenSSL 1.1.0. Fix is: https://github.com/openssl/openssl/pull/1985 Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From root at c-works.net Tue Nov 22 22:39:12 2016 From: root at c-works.net (Harald Koch) Date: Tue, 22 Nov 2016 23:39:12 +0100 Subject: [openssl-users] SMIME signing with SHA1 In-Reply-To: <20161122222558.GA24285@openssl.org> References: <2F146687-2799-44D4-AC45-A4739576A793@c-works.net> <20161122222558.GA24285@openssl.org> Message-ID: Hello, > Am 22.11.2016 um 23:25 schrieb Dr. Stephen Henson : > > On Tue, Nov 22, 2016, Harald Koch wrote: > >> Hello, >> >> I???m facing a critical situation in my application when creating a signed SMIME message using SHA1 as message digest algorithm. In openSSL 1.0.2 (i.e. 1.0.2h), the following command worked as expected: >> >> /opt/openssl-1.0.2h/bin/openssl smime -sign -in original_message -signer cert_key.pem -md sha1 >> >> The message output contains a header using sha1: >> >> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg="sha1"; boundary="??????7E9FFA1842442B7192D83A53D8D35C89" >> >> >> With openSSL 1.1.0c, I get a segmentation fault with the same command. Using md5 or sha256 (or even not providing the parameter ???-md???, resultig in sha256) the command works as expected. Trying to determine where the segmentation fault happen, I used my C program to step through every function call, it turns out that ???SMIME_write_PKCS7??? seems to be the critical point. >> >> I???m sure I???m using the correct LD_LIBRARY_PATH environment variable value for every test in Linux. The platforms I tested are Linux 32bit & 64bit, Mac OS 10.12.1. >> > > It's a bug in OpenSSL 1.1.0. Fix is: > > https://github.com/openssl/openssl/pull/1985 Thank you very much for your fast response, we will wait for the next release to have this issue fixed. Thank you for your work making the world a better place! Harald From wiml at omnigroup.com Wed Nov 23 01:09:55 2016 From: wiml at omnigroup.com (Wim Lewis) Date: Tue, 22 Nov 2016 17:09:55 -0800 Subject: [openssl-users] How to produce a nested CMS / PKCS#7 structure? Message-ID: <8C39211D-A475-4686-8975-4E6F08E9783B@omnigroup.com> I'm trying to produce nested structures, like signed-enveloped-signed data. This is explicitly described in the various RFCs, but I can't figure out how to get OpenSSL to produce valid output, and I can't find any code examples of doing this. What I'm doing (which doesn't quite work) is this: first I create the inner content using (e.g.) CMS_encrypt(), getting a CMS_ContentInfo structure. This works correctly and if I write it out I get what I expect. Then I want to create another CMS_ContentInfo, e.g. using CMS_sign(), which envelops the first one. How do I cause the ContentInfo of the SignedData structure to be the ContentInfo I obtained from CMS_encrypt()? The closest I can come is code like this: CMS_ContentInfo *innerCms = ....; // Create the inner CMS content. BIO *inbetween = BIO_new(BIO_s_mem()); // Write it to a buffer. i2d_CMS_bio(inbetween, innerCms); CMS_ContentInfo *outerCms = CMS_sign(cert, key, NULL, inbetween, CMS_BINARY|CMS_PARTIAL|CMS_NOSMIMECAP); CMS_set1_eContentType(outerCms, OBJ_nid2obj(NID of innerCms)); // Set the content-type CMS_final(outerCms, inbetween, NULL, CMS_BINARY|CMS_NOSMIMECAP); // Finalize the CMS structure (My actual code checks all the return values, but I left those off for clarity.) Unfortunately, this produces output like this: ContentInfo { contentType = :pkcs7-signedData; content = SignedData { ... various ... contentInfo = ContentInfo { contentType = :pkcs7-envelopedData; content = [0] EXPLICIT OctetString{...} } } } where the inner OCTET STRING contains *another* ContentInfo, which then contains the nested object. But from my understanding, the correct syntax for a nested CMS structure is this: ContentInfo { contentType = :pkcs7-signedData; content = SignedData { ... various ... contentInfo = ContentInfo { contentType = :pkcs7-envelopedData; content = [0] EXPLICIT EnvelopedData { ...fields of the EnvelopedData structure... } } } } In other words, I have two extra, incorrect levels of encapsulation: the OCTET STRING and the extra ContentInfo. In order to get the right output, I think I would need both a way to tell the CMS structure to use the correct data type *and* the correct contentType OID, and also a way to get to the EnvelopedData structure inside of the innerCms structure. But neither of those things seems to be accessible using the OpenSSL API. Any hints? Surely someone has used OpenSSL to create nested structures in the past? From ajaygargnsit at gmail.com Wed Nov 23 12:54:25 2016 From: ajaygargnsit at gmail.com (Ajay Garg) Date: Wed, 23 Nov 2016 18:24:25 +0530 Subject: [openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors In-Reply-To: References: Message-ID: Ping !!! Upon code-browsing, I am beginning to feel that OpenSSL uses program-buffer, which is used for malloc/free. Am I right? If yes, is there a place where the maximum-size of "in-program-buffer-heap" is defined? On Tue, Nov 22, 2016 at 7:33 PM, Ajay Garg wrote: > Hi All. > > I wish to compile openssl libraries for a STM32-processor (which would > then be linked statically with our application-framework code). > > > Now. I believe that OpenSSL uses tonnes of "malloc"s and "free"s. But for > bare-metal-systems (without any formal OSes), we generally don't have any > heap-memory. > > So, what is the protocol for compiling OpenSSL for such systems? > I am sorry, but this is the first time I would be compiling for a non-OS > entity. > > > Will be thankful for inputs. > > > Thanks and Regards, > Ajay > -- Regards, Ajay -------------- next part -------------- An HTML attachment was scrubbed... URL: From Saurabh.Gupta at cavium.com Wed Nov 23 10:36:16 2016 From: Saurabh.Gupta at cavium.com (Gupta, Saurabh) Date: Wed, 23 Nov 2016 10:36:16 +0000 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? Message-ID: Can you please suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0 because we are supporting both openssl versions and To maintain these sources we are using #ifdef and #else preprocessor statement. We are looking some technical to make the difference between these sources. #ifdef // openssl 1.1.0 sources #else // openssl 1.0.2 sources #endif -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Nov 23 13:50:09 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Nov 2016 13:50:09 +0000 Subject: [openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors In-Reply-To: References: Message-ID: <35ad23a80dd64bf68ab49a3f421309ad@usma1ex-dag1mb1.msg.corp.akamai.com> > Ping !!! You didn't get a reply in 24 hours from an open source mailing list? A little patience. > Upon code-browsing, I am beginning to feel that OpenSSL uses program-buffer, which is used for malloc/free. OpenSSL uses malloc, etc. Look at crypto/mem.c and (in 1.1.0 and master) the manpage for CRYPTO_malloc. >If yes, is there a place where the maximum-size of "in-program-buffer-heap" is defined? Nothing like that exists. From rsalz at akamai.com Wed Nov 23 13:50:09 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 23 Nov 2016 13:50:09 +0000 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: References: Message-ID: Look at the OPENSSL version define. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludwig.mark at siemens.com Wed Nov 23 20:00:00 2016 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Wed, 23 Nov 2016 20:00:00 +0000 Subject: [openssl-users] Any advice/recommendation for watching TLS version negotiation Message-ID: Greetings, We have embedded OpenSSL 1.0.2j in our application order to securely communicate with a Java Servlet engine (such as Tomcat). Our application uses SSLv23_method(), so I expect it to negotiate up through TLS 1.2 (right?). A customer claims to have configured the web (app) server to only allow TLS 1.2 (by disallowing up through TLS 1.1), and says that the client code (which we know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS 1.1. We are setting up a similar environment internally to diagnose what's happening, and I wonder if anyone has any advice on the "best" tool for "watching" the TLS version negotiation when the connection is being established. The client environment is Solaris 10. I'm obtaining the necessary privileges to use the snoop command. Does anyone have any do's or don'ts for using snoop? Thanks in advance! Mark Ludwig Siemens Product Lifecycle Management Software Inc. Communications and Government Affairs Product Lifecycle Management Lifecycle Coll 5939 Rice Creek Parkway Shoreview, MN 55126 United States Tel. :+1 (651) 855-6140 Fax :+1 (651) 855-6280 ludwig.mark at siemens.com www.siemens.com/plm From openssl-users at eldondev.com Wed Nov 23 23:55:09 2016 From: openssl-users at eldondev.com (openssl-users at eldondev.com) Date: Wed, 23 Nov 2016 18:55:09 -0500 Subject: [openssl-users] Code-Architecture questions while compiling OpenSSL for STM32-processors In-Reply-To: References: Message-ID: <20161123235509.GI30791@npcomp.net> Someone correct me if I'm wrong, but I'm afraid it's not likely that openssl will work for your use case. You might try wolfSSL, polarSSL, or some purpose-built embedded encryption librarly. If you have a specific cryptographic operation to achieve, it might help point you in the right direction. From doctor at doctor.nl2k.ab.ca Thu Nov 24 13:58:32 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Thu, 24 Nov 2016 06:58:32 -0700 Subject: [openssl-users] Still seeing openssl 1.0.2 Daily snap issue Message-ID: <20161124135832.GA87939@doctor.nl2k.ab.ca> Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value -1, received 0 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value -1, received 0 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161124/test *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161124 root at doctor:/usr/source/openssl-1.0.2-stable-SNAP-20161124 # exit exit Script done on Thu Nov 24 05:39:49 2016 Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From doctor at doctor.nl2k.ab.ca Fri Nov 25 07:46:37 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 25 Nov 2016 00:46:37 -0700 Subject: [openssl-users] Still problems with openssl 1.0.2 snapshot Message-ID: <20161125074637.GA49089@doctor.nl2k.ab.ca> ALL OCSP TESTS SUCCESSFUL Test X509v3_check_* ../util/shlib_wrap.sh ./v3nametest ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value -1, received 0 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value -1, received 0 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161125/test *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161125 Please fix -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From ekscrypto at gmail.com Fri Nov 25 14:42:30 2016 From: ekscrypto at gmail.com (Dave Poirier) Date: Fri, 25 Nov 2016 09:42:30 -0500 Subject: [openssl-users] How to do AES-256-CBC encryption with EVP_CIPHER_CTX now opaque? Message-ID: <2F55C9FA-3533-4992-BBA4-903DC1B09F4F@gmail.com> Hello, I am relatively new to using OpenSSL libraries in C so please accept my apologies if this may sound simple for most of you. I have an algorithm that I implemented in 1.0.1c to perform AES-256-CBC encryption, which no longer compiles due to EVP_CIPHER_CTX now being opaque in 1.1.0+. Here is the algorithm in question (Objective-C mixed in..): +(NSData *)encryptReport:(NSData *)report usingKey:(NSData *)key withIV:(NSData *)iv { const unsigned BUFSIZE=4096; unsigned char *read_buf = malloc(BUFSIZE); unsigned char *cipher_buf; unsigned blocksize; int out_len; int reportIndex = 0; EVP_CIPHER_CTX ctx; EVP_CipherInit(&ctx, EVP_aes_256_cbc(), key.bytes, iv.bytes, 1); blocksize = EVP_CIPHER_CTX_block_size(&ctx); cipher_buf = malloc(BUFSIZE + blocksize); memset(cipher_buf,0,BUFSIZE + blocksize); NSMutableData *encryptedData = [NSMutableData dataWithCapacity:report.length + blocksize]; while (1) { // Read in data in blocks until EOF. Update the ciphering with each read. int numRead = MIN(BUFSIZE,(int)report.length-reportIndex); memcpy(read_buf, &report.bytes[reportIndex], numRead); EVP_CipherUpdate(&ctx, cipher_buf, &out_len, read_buf, numRead); [encryptedData appendBytes:cipher_buf length:out_len]; if (numRead < BUFSIZE) { // EOF break; } reportIndex += numRead; } // Now cipher the final block and write it out. EVP_CipherFinal(&ctx, cipher_buf, &out_len); [encryptedData appendBytes:cipher_buf length:out_len]; // Free memory free(cipher_buf); free(read_buf); return [NSData dataWithData:encryptedData]; } The error I get is ?Variable has incomplete type ?EVP_CIPHER_CTX? (aka ?struct evp_cipher_ctx_st?)?. Looking at the diff between the releases, I can see the structure definition has been removed. Question 1: Are there other functions I should have been using to implement AES-256-CBC than the EVP methods above? Question 2: If EVP is the way to go for implementing AES-256-CBC, which functions should I be looking at to not require EVP_CIPHER_CTX variable declaration? Thanks! Dave Poirier skype: ekscrypto twitter: @ekscrypto facebook: /ekscrypto email: ekscrypto at gmail.com All I need is a towel, everything else can be answered by 42. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Nov 25 14:49:40 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 25 Nov 2016 14:49:40 +0000 Subject: [openssl-users] How to do AES-256-CBC encryption with EVP_CIPHER_CTX now opaque? In-Reply-To: <2F55C9FA-3533-4992-BBA4-903DC1B09F4F@gmail.com> References: <2F55C9FA-3533-4992-BBA4-903DC1B09F4F@gmail.com> Message-ID: <2ee164ba-673d-d579-47e8-b963d9910cfd@openssl.org> On 25/11/16 14:42, Dave Poirier wrote: > *Question 1: Are there other functions I should have been using to > implement AES-256-CBC than the EVP methods above?* EVP is the correct thing to be using. > > Question 2: If EVP is the way to go for implementing AES-256-CBC, which > functions should I be looking at to not require EVP_CIPHER_CTX variable > declaration? You still use an EVP_CIPHER_CTX, you just don't allocate it on the stack like you have in your code: EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new(); if (ctx == NULL) /* Do some error handling */ ...do your crypto stuff.... /* Free the allocated EVP_CIPHER_CTX */ EVP_CIPHER_CTX_free(ctx); Matt From steve at openssl.org Fri Nov 25 20:43:56 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Fri, 25 Nov 2016 20:43:56 +0000 Subject: [openssl-users] How to produce a nested CMS / PKCS#7 structure? In-Reply-To: <8C39211D-A475-4686-8975-4E6F08E9783B@omnigroup.com> References: <8C39211D-A475-4686-8975-4E6F08E9783B@omnigroup.com> Message-ID: <20161125204356.GA5611@openssl.org> On Tue, Nov 22, 2016, Wim Lewis wrote: > I'm trying to produce nested structures, like signed-enveloped-signed data. This is explicitly described in the various RFCs, but I can't figure out how to get OpenSSL to produce valid output, and I can't find any code examples of doing this. > > What I'm doing (which doesn't quite work) is this: first I create the inner content using (e.g.) CMS_encrypt(), getting a CMS_ContentInfo structure. This works correctly and if I write it out I get what I expect. Then I want to create another CMS_ContentInfo, e.g. using CMS_sign(), which envelops the first one. How do I cause the ContentInfo of the SignedData structure to be the ContentInfo I obtained from CMS_encrypt()? The closest I can come is code like this: > > > CMS_ContentInfo *innerCms = ....; // Create the inner CMS content. > BIO *inbetween = BIO_new(BIO_s_mem()); // Write it to a buffer. > i2d_CMS_bio(inbetween, innerCms); > CMS_ContentInfo *outerCms = CMS_sign(cert, key, NULL, inbetween, CMS_BINARY|CMS_PARTIAL|CMS_NOSMIMECAP); > CMS_set1_eContentType(outerCms, OBJ_nid2obj(NID of innerCms)); // Set the content-type > CMS_final(outerCms, inbetween, NULL, CMS_BINARY|CMS_NOSMIMECAP); // Finalize the CMS structure > > (My actual code checks all the return values, but I left those off for clarity.) > > Unfortunately, this produces output like this: > > ContentInfo { > contentType = :pkcs7-signedData; > content = SignedData { > ... various ... > contentInfo = ContentInfo { > contentType = :pkcs7-envelopedData; > content = [0] EXPLICIT OctetString{...} > } > } > } > > where the inner OCTET STRING contains *another* ContentInfo, which then contains the nested object. > > But from my understanding, the correct syntax for a nested CMS structure is this: > > ContentInfo { > contentType = :pkcs7-signedData; > content = SignedData { > ... various ... > contentInfo = ContentInfo { > contentType = :pkcs7-envelopedData; > content = [0] EXPLICIT EnvelopedData { > ...fields of the EnvelopedData structure... > } > } > } > } > > In other words, I have two extra, incorrect levels of encapsulation: the OCTET STRING and the extra ContentInfo. > Something like that did happen for PKCS#7 but the OCTET STRING encapsulation is correct for CMS. If you look in RFC5652: SignedData ::= SEQUENCE { version CMSVersion, digestAlgorithms DigestAlgorithmIdentifiers, encapContentInfo EncapsulatedContentInfo, certificates [0] IMPLICIT CertificateSet OPTIONAL, crls [1] IMPLICIT RevocationInfoChoices OPTIONAL, signerInfos SignerInfos } The content is of type Encapsulated ConentInfo: EncapsulatedContentInfo ::= SEQUENCE { eContentType ContentType, eContent [0] EXPLICIT OCTET STRING OPTIONAL } ContentType ::= OBJECT IDENTIFIER Here eContent is always an OCTET STRING if it is present. It also says: eContent is the content itself, carried as an octet string. The eContent need not be DER encoded. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From rsalz at akamai.com Sat Nov 26 00:31:03 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 26 Nov 2016 00:31:03 +0000 Subject: [openssl-users] [openssl-dev] Still problems with openssl 1.0.2 snapshot In-Reply-To: <20161125074637.GA49089@doctor.nl2k.ab.ca> References: <20161125074637.GA49089@doctor.nl2k.ab.ca> Message-ID: How do you configure? > test_dtls1_not_bleeding failed: expected return value -1, received 0 > ** test_dtls1_not_bleeding failed ** ... > 4 tests failed > *** Error code 1 From doctor at doctor.nl2k.ab.ca Sat Nov 26 12:25:52 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 26 Nov 2016 05:25:52 -0700 Subject: [openssl-users] Still showing openssl 1.0.2 snapshot issue Message-ID: <20161126122552.GA19838@doctor.nl2k.ab.ca> How long for this to get fixed? ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value -1, received 0 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value -1, received 0 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161126/test *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161126 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From rsalz at akamai.com Sat Nov 26 13:58:46 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 26 Nov 2016 13:58:46 +0000 Subject: [openssl-users] [openssl-dev] Still showing openssl 1.0.2 snapshot issue In-Reply-To: <20161126122552.GA19838@doctor.nl2k.ab.ca> References: <20161126122552.GA19838@doctor.nl2k.ab.ca> Message-ID: <8763b8210d19494bab40e3d7ea390ae5@usma1ex-dag1mb1.msg.corp.akamai.com> > How long for this to get fixed? > > ../util/shlib_wrap.sh ./heartbeat_test I posted yesterday, what's your config. I standard config/make does not do this for me. From Michal.Trojnara at stunnel.org Sat Nov 26 22:26:04 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Sat, 26 Nov 2016 23:26:04 +0100 Subject: [openssl-users] stunnel 5.38 released Message-ID: Dear Users, I have released version 5.38 of stunnel. Version 5.38, 2016.11.26, urgency: MEDIUM * New features - "sni=" can be used to prevent sending the SNI extension. - The AI_ADDRCONFIG resolver flag is used when available. - Merged Debian 06-lfs.patch (thx Peter Pentchev). * Bugfixes - Fixed a memory allocation bug causing crashes with OpenSSL 1.1.0. - Fixed error handling for mixed IPv4/IPv6 destinations. - Merged Debian 08-typos.patch (thx Peter Pentchev). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 09ada29ba1683ab1fd1f31d7bed8305127a0876537e836a40cb83851da034fd5 stunnel-5.38.tar.gz 8480dd90fbba19324f916267d38835e631b28ffd6b11f9526319c5e8399f4a2f stunnel-5.38-installer.exe 3d77a3becb6d123eaf3c9abba0ba8b96c1893bdad534710dc7094b5449cfc795 stunnel-5.38-android.zip Best regards, Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 884 bytes Desc: OpenPGP digital signature URL: From norm.green at gemtalksystems.com Sun Nov 27 01:02:30 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Sat, 26 Nov 2016 17:02:30 -0800 Subject: [openssl-users] OpenSSL 1.1 on solaris x86 32 bit Message-ID: The CHANGES file for 1.1 contains this note regarding this platform: *) solaris-x86-cc, i.e. 32-bit configuration with vendor compiler, had to be removed. Primary reason is that vendor assembler can't assemble our modules with -KPIC flag. As result it, assembly support, was not even available as option. But its lack means lack of side-channel resistant code, which is incompatible with security by todays standards. Fortunately gcc is readily available prepackaged option, which we firmly point at... [Andy Polyakov] Can someone please publish some more details about what Solaris and/or compiler versions showed problems? Also were tests failing or were compiles/links failing? I've tested this configuration with 1.1.0c using an older vendor compiler version and everything seems to work just fine using the -KPIC flag. I don't see anywhere in the build log where the assembler is being invoked directly. My compiler is: cc: Sun C 5.10 SunOS_i386 Patch 142363-05 2010/04/28 usage: cc [ options] files. Use 'cc -flags' for details thanks, Norm Green From doctor at doctor.nl2k.ab.ca Sun Nov 27 13:27:54 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 27 Nov 2016 06:27:54 -0700 Subject: [openssl-users] openssl 1.0.2 SNAP stable 20161127 issue Message-ID: <20161127132754.GA9061@doctor.nl2k.ab.ca> Can you get his fixed? ../util/shlib_wrap.sh ./heartbeat_test test_dtls1_not_bleeding failed: expected return value -1, received 0 ** test_dtls1_not_bleeding failed ** -------- test_dtls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_dtls1_not_bleeding_empty_payload failed ** -------- test_tls1_not_bleeding failed: expected return value -1, received 0 ** test_tls1_not_bleeding failed ** -------- test_tls1_not_bleeding_empty_payload failed: expected return value -1, received 0 ** test_tls1_not_bleeding_empty_payload failed ** -------- 4 tests failed *** Error code 1 Stop. make[1]: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127/test *** Error code 1 Stop. make: stopped in /usr/source/openssl-1.0.2-stable-SNAP-20161127 -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Merry Christmas 2016 and Happy New Year 2017 From rsalz at akamai.com Sun Nov 27 14:21:25 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 27 Nov 2016 14:21:25 +0000 Subject: [openssl-users] [openssl-dev] openssl 1.0.2 SNAP stable 20161127 issue In-Reply-To: <20161127132754.GA9061@doctor.nl2k.ab.ca> References: <20161127132754.GA9061@doctor.nl2k.ab.ca> Message-ID: <3bbd178a07b04948acbbef1b4c084bfb@usma1ex-dag1mb1.msg.corp.akamai.com> > Can you get his fixed? > > ../util/shlib_wrap.sh ./heartbeat_test > test_dtls1_not_bleeding failed: expected return value -1, received 0 > ** test_dtls1_not_bleeding failed ** Again: How are you configuring ? It does not fail for me. From noloader at gmail.com Sun Nov 27 15:21:24 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 27 Nov 2016 10:21:24 -0500 Subject: [openssl-users] How to use Poly1305 with EVP interfaces? Message-ID: I'm working from Master. I'm having trouble locating the message digest for Poly1305, and how to use it with https://wiki.openssl.org/index.php/EVP_Message_Digests. At the moment I can only find EVP_chacha20_poly1305. It seems like if Poly1305 is going to be paired with something, it would be AES, and not TLS-ChaCha. I tried to use it with EVP_Message_Digests, but its having a lot of trouble. >From the type of EVP_chacha20_poly1305() and some of the error messages, it looks like I may need to use the authenticated encryption interfaces. I guess (maybe?) use AAD data only? If so, how do we handle the per-message nonce? How do I use the EVP interfaces to create a MAC with Poly1305? Thanks in advance. From fedor_qd at mail.ru Mon Nov 28 10:44:33 2016 From: fedor_qd at mail.ru (Fiodar Stryzhniou) Date: Mon, 28 Nov 2016 13:44:33 +0300 Subject: [openssl-users] Msys doesn't handle forward slashes in makefile Message-ID: Hi! I use Configure under Msys with crosscompiler arm-none-symbianelf. I edit accordingly Configure script of course. When I run make it prints "_some string_ path not found". I found this string and replace forward slashes to backslashes. I got same error for another string. I try "ls path2 file" from error message and got error "not found error". I change slashes and vise versa. How can tell configure to generate makefile with backslashes? May be another solutions exists? Fiodar Stryzhniou From swall at redcom.com Mon Nov 28 12:52:17 2016 From: swall at redcom.com (Wall, Stephen) Date: Mon, 28 Nov 2016 12:52:17 +0000 Subject: [openssl-users] Any advice/recommendation for watching TLS version negotiation In-Reply-To: References: Message-ID: <72c3d14817cb46c5ad8d522328b126cf@exch-02.redcom.com> > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Ludwig, Mark > > A customer claims to have configured the web (app) server to only allow > TLS 1.2 > (by disallowing up through TLS 1.1), and says that the client code > (which we > know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS > 1.1. We > are setting up a similar environment internally to diagnose what's > happening, > and I wonder if anyone has any advice on the "best" tool for "watching" > the TLS > version negotiation when the connection is being established. I've typically used Wireshark for this type of thing. If you are using RSA and have a copy of the server key, you can also examine the encrypted channel content. -Steve Wall From ravi02431 at gmail.com Mon Nov 28 17:34:50 2016 From: ravi02431 at gmail.com (ravi shankar) Date: Mon, 28 Nov 2016 23:04:50 +0530 Subject: [openssl-users] Query on BIO_do_accept in openssl server. Message-ID: Hi All, I am new to openssl and I am trying to achieve server client communication using Openssl with BIO interfaces. As per my understanding on the man page of BIO_do_accept(BIO *abio), first call to it will set's up accept BIO and Second call to the same is a blocking call and wait for incoming connections. In my server, i am being blocked at first call to BIO_do_accept. What all scenarios will make my call a blocking call?. Thanks for your help. a part of my Openssl server: if(BIO_do_accept(server) <= 0) /* place the underlying socket into listening mode */ { cout<<" Error setting up accept\n"< -------------- next part -------------- A non-text attachment was scrubbed... Name: SSL_Server.cpp Type: text/x-c++src Size: 1605 bytes Desc: not available URL: From kgoldman at us.ibm.com Mon Nov 28 19:50:01 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 28 Nov 2016 14:50:01 -0500 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: References: Message-ID: I'd like an answer to this one also. I could not find that define. I did find about 10 variations, all uncommented. Could someone simply post the definitive answer? On 11/23/2016 8:50 AM, Salz, Rich wrote: > Look at the OPENSSL version define. > > > From kgoldman at us.ibm.com Mon Nov 28 20:13:15 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 28 Nov 2016 15:13:15 -0500 Subject: [openssl-users] openssl-1.1.0b : Getting keys from TPM In-Reply-To: References: <5A5D364E552E43F791DD320DA928607C@DESKTOPIMSMU5Q> Message-ID: To read a public key, use the TPM2_ReadPublic command. I have an open source utility (tpm2pem) that converts that TPM format key to PEM. If you need the private key, you will have to "duplicate" it to a key you know and then use that key to decrypt it. It's possible. However, it defeats the purpose of using the TPM as a hardware key store. It would be better to use the TPM to do the private key operations. For a TSS, I offer this, which has an ever expanding set of utilities and sample programs. Let me know what you need for sample code. https://sourceforge.net/projects/ibmtpm20tss/?source=navbar I also suggest debugging with a SW TPM. https://sourceforge.net/projects/ibmswtpm2/ The tpm2pem utility currently comes with the attestation client and server: https://sourceforge.net/projects/ibmtpm20acs/ On 11/3/2016 12:02 PM, Zvi Vered wrote: > Hi Ken, > > 1. I mean: read from TPM > > 2. In order to create an SSL session with the server, should I need also > the private key ? > > 3. I want to use TPM 2.0 > > > On 11/2/2016 11:06 PM, Zvi Vered wrote: > > > I want to use openssl in order to send\receive encrypted > messages to a > server. > > My Target has TPM. > > Can you please explain how to configure the openssl library to take > public+private keys from TPM ? > > Should I use a specific TPM library ? From jb-openssl at wisemo.com Mon Nov 28 20:28:36 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 28 Nov 2016 21:28:36 +0100 Subject: [openssl-users] Msys doesn't handle forward slashes in makefile In-Reply-To: References: Message-ID: On 28/11/2016 11:44, Fiodar Stryzhniou via openssl-users wrote: > Hi! I use Configure under Msys with crosscompiler arm-none-symbianelf. I edit accordingly Configure script of course. When I run make it prints "_some string_ path not found". I found this string and replace forward slashes to backslashes. I got same error for another string. > I try "ls path2 file" from error message and got error "not found error". I change slashes and vise versa. > How can tell configure to generate makefile with backslashes? May be another solutions exists? > Fiodar Stryzhniou > Hmm, maybe run perl -pe "s/\//\\/sg" on the Makefile as part of your higher level build script? But how do you run the code after the signing service was shut down at the Microsoft takeover? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From ludwig.mark at siemens.com Mon Nov 28 20:38:22 2016 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Mon, 28 Nov 2016 20:38:22 +0000 Subject: [openssl-users] Any advice/recommendation for watching TLS version negotiation In-Reply-To: <72c3d14817cb46c5ad8d522328b126cf@exch-02.redcom.com> References: <72c3d14817cb46c5ad8d522328b126cf@exch-02.redcom.com> Message-ID: > From: Wall, Stephen, Monday, November 28, 2016 6:52 AM > > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > > Behalf Of Ludwig, Mark > > > > A customer claims to have configured the web (app) server to only allow > > TLS 1.2 > > (by disallowing up through TLS 1.1), and says that the client code > > (which we > > know is based on OpenSSL 1.0.2j) is nevertheless connecting using TLS > > 1.1. We > > are setting up a similar environment internally to diagnose what's > > happening, > > and I wonder if anyone has any advice on the "best" tool for "watching" > > the TLS > > version negotiation when the connection is being established. > > I've typically used Wireshark for this type of thing. If you are using RSA and have > a copy of the server key, you can also examine the encrypted channel content. Yes, thanks, a colleague today enlightened me that Wireshark will read the captured data from snoop. Voila! I didn't bother to get the key -- not sure it's RSA -- because I'm not interested in the encrypted data. I only want to see the TLS handshake, which Wireshark decodes nicely. Best, Mark From rsalz at akamai.com Mon Nov 28 20:40:39 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 28 Nov 2016 20:40:39 +0000 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: References: Message-ID: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> Perhaps I didn't understand the original question. If all you want to do is compare 1.0.2 and 1.1.0, then look at OPENSSL_VERSION_NUMBER; if defined at it's 0x10101000L or greater, then you;'re on the 1.1.x branch, otherwise you are not and therefore on 1.0.2 or earlier. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From openssl-users at dukhovni.org Mon Nov 28 20:50:15 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 28 Nov 2016 15:50:15 -0500 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <8E96DB54-FDC7-4846-A838-2A10085A3D3D@dukhovni.org> > On Nov 28, 2016, at 3:40 PM, Salz, Rich wrote: > > Perhaps I didn't understand the original question. If all you want to do is compare 1.0.2 and 1.1.0, then look at OPENSSL_VERSION_NUMBER; if defined at it's 0x10101000L or greater, then you;'re on the 1.1.x branch, otherwise you are not and therefore on 1.0.2 or earlier. The OPENSSL_VERSION_NUMBER macro dates back to some of the earliest OpenSSL releases, and is therefore always defined. Postfix has the following comment in src/tls/tls_misc.c which covers the relevant history: /* * OPENSSL_VERSION_NUMBER(3): * * OPENSSL_VERSION_NUMBER is a numeric release version identifier: * * MMNNFFPPS: major minor fix patch status * * The status nibble has one of the values 0 for development, 1 to e for * betas 1 to 14, and f for release. Parsed OpenSSL version number. for * example * * 0x000906000 == 0.9.6 dev 0x000906023 == 0.9.6b beta 3 0x00090605f == * 0.9.6e release * * Versions prior to 0.9.3 have identifiers < 0x0930. Versions between * 0.9.3 and 0.9.5 had a version identifier with this interpretation: * * MMNNFFRBB major minor fix final beta/patch * * for example * * 0x000904100 == 0.9.4 release 0x000905000 == 0.9.5 dev * * Version 0.9.5a had an interim interpretation that is like the current * one, except the patch level got the highest bit set, to keep continu- * ity. The number was therefore 0x0090581f. */ -- Viktor. From kgoldman at us.ibm.com Mon Nov 28 21:06:33 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 28 Nov 2016 16:06:33 -0500 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 11/28/2016 3:40 PM, Salz, Rich wrote: > Perhaps I didn't understand the original question. If all you want > to do is compare 1.0.2 and 1.1.0, then look at > OPENSSL_VERSION_NUMBER; if defined at it's 0x10101000L or greater, > then you;'re on the 1.1.x branch, otherwise you are not and therefore > on 1.0.2 or earlier. I want to compare pre 1.1 (typically 1.0) and 1.1 and up. My 1.0 has ./opensslv.h:#define OPENSSL_VERSION_NUMBER 0x1000105fL My 1.1 has ./openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER 0x1010003fL Neither agree with your example, but would comparing to 0x10100000 work? From openssl-users at dukhovni.org Mon Nov 28 21:15:16 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 28 Nov 2016 21:15:16 +0000 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: References: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20161128211516.GI26244@mournblade.imrryr.org> On Mon, Nov 28, 2016 at 04:06:33PM -0500, Ken Goldman wrote: > On 11/28/2016 3:40 PM, Salz, Rich wrote: > >Perhaps I didn't understand the original question. If all you want > >to do is compare 1.0.2 and 1.1.0, then look at > >OPENSSL_VERSION_NUMBER; if defined at it's 0x10101000L or greater, > >then you;'re on the 1.1.x branch, otherwise you are not and therefore > >on 1.0.2 or earlier. > > I want to compare pre 1.1 (typically 1.0) and 1.1 and up. > > My 1.0 has > > ./opensslv.h:#define OPENSSL_VERSION_NUMBER 0x1000105fL > > My 1.1 has > > ./openssl/opensslv.h:# define OPENSSL_VERSION_NUMBER 0x1010003fL > > Neither agree with your example, but would comparing to 0x10100000 work? To test for 1.1.0 and up: #if OPENSSL_VERSION_NUMBER > 0x10100000 ... #endif (testing for equality is not needed, that would be a a dev release that predates all the betas). -- Viktor. From wiml at omnigroup.com Mon Nov 28 21:33:51 2016 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 28 Nov 2016 13:33:51 -0800 Subject: [openssl-users] How to produce a nested CMS / PKCS#7 structure? In-Reply-To: <20161125204356.GA5611@openssl.org> References: <8C39211D-A475-4686-8975-4E6F08E9783B@omnigroup.com> <20161125204356.GA5611@openssl.org> Message-ID: <3F9C62BE-FB90-40CF-9C20-E09CCB29EC0F@omnigroup.com> On Nov 25, 2016, at 12:43 PM, Dr. Stephen Henson wrote: > Something like that did happen for PKCS#7 but the OCTET STRING encapsulation > is correct for CMS. Aha, and this difference is called out in RFC5652 [5.2.1]. Thanks, that clarifies things for me a little. So typically it's only the outermost ContentInfo that directly embeds a CMS object without an intervening OCTET STRING, and other structures use EncapsulatedContentInfo instead of ContentInfo. However, I think the other half of my problem remains: if I'm putting another CMS object into a SignedData, AuthEnvelopedData, or other kind of wrapper, the OCTET STRING should contain the encoding of that object's structure (e.g. a BER-encoded AuthEnvelopedData, SignedData, ContentWithAttributes, etc. structure), not a ContentInfo *containing* that structure, right? How do I get OpenSSL to give me that encoded object without an enclosing ContentInfo? -------------- next part -------------- An HTML attachment was scrubbed... URL: From samullap at cisco.com Tue Nov 29 03:55:47 2016 From: samullap at cisco.com (Sashank Mullapudi (samullap)) Date: Tue, 29 Nov 2016 03:55:47 +0000 Subject: [openssl-users] Disabling Client-Initiated TLS renegotiation In-Reply-To: References: Message-ID: Resending this hoping for a response from someone who has information on disabling TLS renegotiation from the Client side. Thanks, Sashank From: samullap > Date: Tuesday, 22 November 2016 at 12:21 PM To: "openssl-users at openssl.org" > Cc: "Ram Mohan R (rmohanr)" >, "Anil Kumar (anilkum)" >, "Nikhil Mittal (nimittal)" > Subject: Disabling Client-Initiated TLS renegotiation Hi, As part of securing our web interfaces, we wanted to disable client-initiated TLS renegotiation. The reasoning for this requirement is as follows- Generally, renegotiation of TLS sessions is much more resource-intensive for the server than the client, and should therefore not be performed at will to avoid degrading performance. Disabling client from renegotiating secures the server from undergoing a DoS attack due to continuous renegotiation requests. I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, but that is to secure the renegotiation, not disable it. I wanted to check if there is a patch or flag available to disable any negotiation initiated from the client side. Thanks and Regards, Sashank -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedor_qd at mail.ru Tue Nov 29 05:26:17 2016 From: fedor_qd at mail.ru (Fiodar Stryzhniou) Date: Tue, 29 Nov 2016 08:26:17 +0300 Subject: [openssl-users] Msys doesn't handle forward slashes in makefile Message-ID: <0tnQxNnsN3Bl.7lFfy3Jz@smtp.mail.ru> I need in autogenerated files headers, asm, others. Project will migrate to Symbian build system then. Fiodar Stryzhniou ???????? ??? ????: Re: [openssl-users] Msys doesn't handle forward slashes in makefile ??: Jakob Bohm ????: 28.11.2016 23.29 On 28/11/2016 11:44, Fiodar Stryzhniou via openssl-users wrote: > Hi! I use Configure under Msys with crosscompiler arm-none-symbianelf. I edit accordingly Configure script of course. When I run make it prints "_some string_ path not found". I found this string and replace forward slashes to backslashes. I got same error for another string. > I try "ls path2 file" from error message and got error "not found error". I change slashes and vise versa. > How can tell configure to generate makefile with backslashes? May be another solutions exists? > Fiodar Stryzhniou > Hmm, maybe run perl -pe "s/\//\\/sg" on the Makefile as part of your higher level build script? I found recipe on stack overflow "sed -i s/\//\\/g Makefile". Paths can have back and forward slashes at one time in makefile, lol. I don't use build script except Configure. But how do you run the code after the signing service was shut down at the Microsoft takeover? I hack my phone and forget about it. Also I saw in internet how make own devcert. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From swall at redcom.com Tue Nov 29 13:35:45 2016 From: swall at redcom.com (Wall, Stephen) Date: Tue, 29 Nov 2016 13:35:45 +0000 Subject: [openssl-users] Disabling Client-Initiated TLS renegotiation In-Reply-To: References: Message-ID: <326b7aade9114fefa6eb6bb9b4d5355e@exch-02.redcom.com> I suppose one could abuse SSL_set_msg_callback() to create a filter that rewrites the initial re-handshake message into something innocuous. Though I doubt that would work, once the client starts a handshake, it expects a response from the server, and may well time out and close if it does not get one. The way TLS works, it is always the client starting a renegotiation. The server can send a message asking the client to renegotiate, but the client can ignore that. I don't believe the opposite is true. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Sashank Mullapudi (samullap) Sent: Monday, November 28, 2016 10:56 PM To: openssl-users at openssl.org Cc: Ram Mohan R (rmohanr) ; Nikhil Mittal (nimittal) ; Anil Kumar (anilkum) Subject: Re: [openssl-users] Disabling Client-Initiated TLS renegotiation Resending this hoping for a response from someone who has information on disabling TLS renegotiation from the Client side. Thanks, Sashank From: samullap > Date: Tuesday, 22 November 2016 at 12:21 PM To: "openssl-users at openssl.org" > Cc: "Ram Mohan R (rmohanr)" >, "Anil Kumar (anilkum)" >, "Nikhil Mittal (nimittal)" > Subject: Disabling Client-Initiated TLS renegotiation Hi, As part of securing our web interfaces, we wanted to disable client-initiated TLS renegotiation. The reasoning for this requirement is as follows- Generally, renegotiation of TLS sessions is much more resource-intensive for the server than the client, and should therefore not be performed at will to avoid degrading performance. Disabling client from renegotiating secures the server from undergoing a DoS attack due to continuous renegotiation requests. I see that there is an option SSL_OP_ALLOW_UNSAFE_LEGACY_RENEGOTIATION, but that is to secure the renegotiation, not disable it. I wanted to check if there is a patch or flag available to disable any negotiation initiated from the client side. Thanks and Regards, Sashank -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Nov 29 15:12:57 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 29 Nov 2016 16:12:57 +0100 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: <8E96DB54-FDC7-4846-A838-2A10085A3D3D@dukhovni.org> References: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> <8E96DB54-FDC7-4846-A838-2A10085A3D3D@dukhovni.org> Message-ID: On 28/11/2016 21:50, Viktor Dukhovni wrote: >> On Nov 28, 2016, at 3:40 PM, Salz, Rich wrote: >> >> Perhaps I didn't understand the original question. If all you want to do is compare 1.0.2 and 1.1.0, then look at OPENSSL_VERSION_NUMBER; if defined at it's 0x10101000L or greater, then you;'re on the 1.1.x branch, otherwise you are not and therefore on 1.0.2 or earlier. > The OPENSSL_VERSION_NUMBER macro dates back to some of the earliest > OpenSSL releases, and is therefore always defined. Postfix has the > following comment in src/tls/tls_misc.c which covers the relevant > history: > > /* > * OPENSSL_VERSION_NUMBER(3): > * > * OPENSSL_VERSION_NUMBER is a numeric release version identifier: > * > * MMNNFFPPS: major minor fix patch status > * Shouldn't this be MNNFFPPS: major minor fix patch status (only 1 nibble for major) > * The status nibble has one of the values 0 for development, 1 to e for > * betas 1 to 14, and f for release. Parsed OpenSSL version number. for > * example > * > * 0x000906000 == 0.9.6 dev 0x000906023 == 0.9.6b beta 3 0x00090605f == > * 0.9.6e release > * > * Versions prior to 0.9.3 have identifiers < 0x0930. Versions between > * 0.9.3 and 0.9.5 had a version identifier with this interpretation: > * > * MMNNFFRBB major minor fix final beta/patch > * > * for example > * > * 0x000904100 == 0.9.4 release 0x000905000 == 0.9.5 dev > * > * Version 0.9.5a had an interim interpretation that is like the current > * one, except the patch level got the highest bit set, to keep continu- > * ity. The number was therefore 0x0090581f. > */ > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From steve at openssl.org Tue Nov 29 16:00:01 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 29 Nov 2016 16:00:01 +0000 Subject: [openssl-users] How to produce a nested CMS / PKCS#7 structure? In-Reply-To: <3F9C62BE-FB90-40CF-9C20-E09CCB29EC0F@omnigroup.com> References: <8C39211D-A475-4686-8975-4E6F08E9783B@omnigroup.com> <20161125204356.GA5611@openssl.org> <3F9C62BE-FB90-40CF-9C20-E09CCB29EC0F@omnigroup.com> Message-ID: <20161129160001.GA1606@openssl.org> On Mon, Nov 28, 2016, Wim Lewis wrote: > > However, I think the other half of my problem remains: if I'm putting > another CMS object into a SignedData, AuthEnvelopedData, or other kind of > wrapper, the OCTET STRING should contain the encoding of that object's > structure (e.g. a BER-encoded AuthEnvelopedData, SignedData, > ContentWithAttributes, etc. structure), not a ContentInfo *containing* that > structure, right? How do I get OpenSSL to give me that encoded object > without an enclosing ContentInfo? > It's my understanding that the content should be a ContentInfo but I can't see a definitive reference to this. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Tue Nov 29 18:31:35 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 29 Nov 2016 13:31:35 -0500 Subject: [openssl-users] Can you suggest any technical name for changing sources from openssl-1.0.2 to openssl-1.1.0? In-Reply-To: References: <76c607ca978245a2a8009ce81755a57c@usma1ex-dag1mb1.msg.corp.akamai.com> <8E96DB54-FDC7-4846-A838-2A10085A3D3D@dukhovni.org> Message-ID: > On Nov 29, 2016, at 10:12 AM, Jakob Bohm wrote: > >> /* >> * OPENSSL_VERSION_NUMBER(3): >> * >> * OPENSSL_VERSION_NUMBER is a numeric release version identifier: >> * >> * MMNNFFPPS: major minor fix patch status >> * > > Shouldn't this be > MNNFFPPS: major minor fix patch status (only 1 nibble for major) Yes, the comment in that file has an extra nibble for the major number, but for portability reasons the version number is only 32 bits. The code below the comment parses the unsigned long version number as follows: if (version < 0x0930) { info->status = 0; info->patch = version & 0x0f; version >>= 4; info->micro = version & 0x0f; version >>= 4; info->minor = version & 0x0f; version >>= 4; info->major = version & 0x0f; } else if (version < 0x00905800L) { info->patch = version & 0xff; version >>= 8; info->status = version & 0xf; version >>= 4; info->micro = version & 0xff; version >>= 8; info->minor = version & 0xff; version >>= 8; info->major = version & 0xff; } else { info->status = version & 0xf; version >>= 4; info->patch = version & 0xff; version >>= 8; info->micro = version & 0xff; version >>= 8; info->minor = version & 0xff; version >>= 8; info->major = version & 0xff; if (version < 0x00906000L) info->patch &= ~0x80; } So it could produce a major version > 15 on systems where long is > 32 bits, but that's unlikely on the OpenSSL side at present. -- Viktor. From joachim.person at gmail.com Tue Nov 29 17:06:33 2016 From: joachim.person at gmail.com (jockep) Date: Tue, 29 Nov 2016 10:06:33 -0700 (MST) Subject: [openssl-users] =?utf-8?b?4oCcbm8gc2hhcmVkIGNpcGhlcuKAnSBhdCBz?= =?utf-8?b?c2xfYWNjZXB0LCB3aHk/?= Message-ID: <1480439193080-69201.post@n7.nabble.com> Have googled a lot, not found any answer to the following problem: Created server code and client code, but get error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher at the server when doing SSL_connect. The code below is narrowed down to the sequence of the SSL / socket related function calls only. Error handling code has been applied where applicable to make sure calls before SSL_accept / SSL_connect does not return any failure codes. I have also left out initialization methods. I do not know if it matters, but I run both server and client on localhost. There might be obvious errors, but I am quite new with OpenSSL. Client code (inparams: hostname, certificate_chain_file, ca_certificate_file): SSL_library_init(); OpenSSL_add_all_algorithms(); SSL_load_error_strings(); ERR_load_crypto_strings(); OpenSSL_add_all_ciphers(); SSL_METHOD const * method = SSLv23_method(); SSL_CTX * ctx = SSL_CTX_new(method); SSL_CTX_use_certificate_chain_file(ctx, certificate_chain_file)); const long flags = SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_COMPRESSION; SSL_CTX_set_options(ctx, flags); SSL_CTX_load_verify_locations(ctx, ca_certificate_file, NULL)); struct hostent * host = gethostbyname(hostname); int client_sd = socket(PF_INET, SOCK_STREAM, 0); struct sockaddr_in server; memset(&server, 0, sizeof(server)); server.sin_family = AF_INET; server.sin_port = htons(6789); server.sin_addr.s_addr = *(long *) (host->h_addr); connect(client_sd, (struct sockaddr *) &server, sizeof(server)); SSL * ssl = SSL_new(ctx); SSL_set_fd(ssl, client_sd); const char * const preferred_ciphers = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4"; SSL_set_cipher_list(ssl, preferred_ciphers); SSL_set_tlsext_host_name(ssl, hostname); mydata_t mydata; mydata_index_client = SSL_get_ex_new_index(0, (void *) "mydata index", NULL, NULL, NULL); SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback_client); SSL_CTX_set_verify_depth(ctx, 1); mydata.verify_depth = 0; SSL_set_ex_data(ssl, mydata_index_client, &mydata); int connection_result = SSL_connect(ssl); if (connection_result < 0) { // Comes in here and ERR_get_error indicates // error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure } else if (connection_result == 0) { } else if (connection_result == 1) { } else { } Server code (inparams: certificate_chain_file, ca_certificate_file): SSL_library_init(); OpenSSL_add_all_algorithms(); SSL_load_error_strings(); SSL_METHOD const * method = SSLv23_method(); SSL_CTX * ctx = SSL_CTX_new(method); SSL_CTX_use_certificate_chain_file(ctx, certificate_chain_file); //Contains only root CA SSL_CTX_set_default_passwd_cb_userdata(ctx, (void *) private_key_file_password); SSL_CTX_set_default_passwd_cb(ctx, pem_passwd_cb); SSL_CTX_load_verify_locations(ctx, ca_certificate_file, NULL); struct sockaddr_in addr; int server_sd = create_socket(addr, 6789); bind(server_sd, (struct sockaddr *) &addr, sizeof(addr)); listen(server_sd, max_nr_of_simultaneous_connections); sockaddr_in client; client.sin_family = AF_INET; socklen_t c_len = sizeof(client); int client_sd = accept(server_sd, (sockaddr *) &client, &c_len); char remote_addr[INET_ADDRSTRLEN]; inet_ntop(client.sin_family, &(client.sin_addr), remote_addr, INET_ADDRSTRLEN); SSL * ssl = SSL_new(ctx); SSL_set_fd(ssl, client_sd); const char * const preferred_ciphers = "HIGH:!aNULL:!kRSA:!PSK:!SRP:!MD5:!RC4"; SSL_set_cipher_list(ssl, preferred_ciphers); STACK_OF(X509_NAME) * cert_names = SSL_load_client_CA_file(certificate_chain_file); if (cert_names != NULL) { SSL_CTX_set_client_CA_list(ctx, cert_names); } mydata_t mydata; mydata_index_server = SSL_get_ex_new_index(0, (void *) "mydata index", NULL, NULL, NULL); SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, verify_callback_server); SSL_CTX_set_verify_depth(ctx, 1); mydata.verify_depth = 1; SSL_set_ex_data(ssl, mydata_index_server, &mydata); int accept_result = SSL_accept(ssl); if (accept_result == 0) { } else if (accept_result < 0) { // Comes in here and ERR_get_error indicates // error:1408A0C1:SSL routines:SSL3_GET_CLIENT_HELLO:no shared cipher } openssl-ca.cnf: HOME = . RANDFILE = $ENV::HOME/.rnd #################################################################### [ ca ] default_ca = CA_default # The default ca section #################################################################### [ CA_default ] default_days = 1000 # how long to certify for default_crl_days = 30 # how long before next CRL default_md = sha256 # use public key default MD preserve = no # keep passed DN ordering x509_extensions = ca_extensions # The extensions to add to the cert email_in_dn = no # Don't concat the email in the DN copy_extensions = copy # Required to copy SANs from CSR to cert base_dir = . certificate = $base_dir/certs/ca_fromweb.cert.pem # The CA certifcate private_key = $base_dir/private/ca.key.pem # The CA private key new_certs_dir = $base_dir # Location for new certs after signing database = $base_dir/index2.txt # Database index file serial = $base_dir/serial2.txt # The current serial number unique_subject = no # Set to 'no' to allow creation of # several certificates with same subject. #################################################################### [ req ] default_bits = 4096 default_keyfile = ./private/ca.key.pem distinguished_name = ca_distinguished_name x509_extensions = ca_extensions string_mask = utf8only #################################################################### [ ca_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = SE stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = ?sterg?tland localityName = Locality Name (eg, city) localityName_default = organizationName = Organization Name (eg, company) organizationName_default = organizationalUnitName = Organizational Unit (eg, division) organizationalUnitName_default = commonName = Common Name (e.g. server FQDN or YOUR name) commonName_default = emailAddress = Email Address emailAddress_default = #################################################################### [ ca_extensions ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always, issuer basicConstraints = critical, CA:true keyUsage = keyCertSign, cRLSign #################################################################### [ signing_policy ] countryName = optional stateOrProvinceName = optional localityName = optional organizationName = optional organizationalUnitName = optional commonName = supplied emailAddress = optional #################################################################### [ signing_req ] subjectKeyIdentifier = hash authorityKeyIdentifier = keyid,issuer basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment openssl-server.cnf: HOME = . RANDFILE = $ENV::HOME/.rnd #################################################################### [ req ] default_bits = 2048 default_keyfile = ./intermediate/private/my.example.com.key.pem distinguished_name = server_distinguished_name req_extensions = server_req_extensions string_mask = utf8only #################################################################### [ server_distinguished_name ] countryName = Country Name (2 letter code) countryName_default = SE stateOrProvinceName = State or Province Name (full name) stateOrProvinceName_default = ?sterg?tland localityName = Locality Name (eg, city) localityName_default = Link?ping organizationName = Organization Name (eg, company) organizationName_default = commonName = Common Name (e.g. server FQDN or YOUR name) commonName_default = emailAddress = Email Address emailAddress_default = #################################################################### [ server_req_extensions ] subjectKeyIdentifier = hash basicConstraints = CA:FALSE keyUsage = digitalSignature, keyEncipherment subjectAltName = @alternate_names nsComment = "OpenSSL Generated Certificate" #################################################################### [ alternate_names ] DNS.1 = my.example.com Commands: touch index.txt echo 1000 > serial openssl genrsa -aes256 -out ca.key.pem 4096 chmod 400 private/ca.key.pem openssl req -config openssl-ca.cnf -key ca.key.pem -new -x509 -days 7300 -sha256 -extensions ca_extensions -out ca.cert.pem chmod 444 ca.cert.pem openssl genrsa -aes256 -out server.key.pem 4096 openssl req -config openssl-server.cnf -new -sha256 -key server.key.pem -out my.example.com.csr.pem openssl ca -config openssl-ca.cnf -policy signing_policy -extensions signing_req -out my.example.com.cert.pem -infiles my.example.com.csr.pem chmod 444 my.example.com.cert.pem cat ca.cert.pem > ca_chain.cert.pem Why is there still "no shared ciphers"? -- View this message in context: http://openssl.6102.n7.nabble.com/no-shared-cipher-at-ssl-accept-why-tp69201.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From wieland at purdue.edu Tue Nov 29 19:31:54 2016 From: wieland at purdue.edu (Jeff Wieland) Date: Tue, 29 Nov 2016 14:31:54 -0500 Subject: [openssl-users] OpenSSL 1.0.2h reports speed test results as 0 secs and Infk ops/sec In-Reply-To: <9dab5edc-8f7b-1d1d-718f-3eaac007e84a@blastwave.org> References: <7d4322cf-1a4b-0b8a-e82d-2dcc8e05282c@blastwave.org> <57D5B40C.5090607@purdue.edu> <1e0c1c7c-4315-586e-4363-0b94bd1518cb@blastwave.org> <57D6DD96.9030308@purdue.edu> <98f0419d-8c78-0e19-9b58-427df1ac1e6e@blastwave.org> <57D74EAB.1090805@purdue.edu> <9dab5edc-8f7b-1d1d-718f-3eaac007e84a@blastwave.org> Message-ID: <583DD7AA.1020800@purdue.edu> Dennis Clarke wrote: > >> Have you tried running Oracle's builds of OpenSSL? They do the same >> thing on the UltraSPARC 2e: > > This is officially a bug. I'll file it and start looking into this one. > > Very odd. > > I will try this on a few other RISC architectures and see what I see. > Starting with Power6. > > Dennis > It's been a while for this :-). I'm thinking that this is a Solaris bug. Have you opened a ticket with Oracle about it? I just patched one of my UltraSPARC 2e systems with the latest patches, and the problem remains. It's still easy to demonstrate: On UltraSPARC 3i: $ /bin/time tar cf /dev/null /opt/solstudio12.2 real 48.7 user 0.5 sys 4.4 On UltraSPARC 2e: $ /bin/time tar cf /dev/null /opt/solstudio12.2 real 1:08.1 user 0.0 sys 0.0 On the UltraSPARC 2e (in this case a Sun Blade 150), the user and sys times shouldn't be 0.0. -- Jeff Wieland, UNIX/Network Systems Administrator Purdue University IT Infrastructure Services UNIX Platforms From rossimattia92 at gmail.com Wed Nov 30 09:35:02 2016 From: rossimattia92 at gmail.com (Mattia Rossi) Date: Wed, 30 Nov 2016 10:35:02 +0100 Subject: [openssl-users] When ciphers are deprecated? Message-ID: Hi all, After updating from 1.0.2h to 1.0.2j some of my PHP script is broken, because it can't connect to the server, after some research the server supports very old TLSv1.0 ciphers. So i check what ciphers PHP query for and with different versions of openssl i get different result, so in libssl 1.0.2h i have these chipers: - EDH-RSA-DES-CBC3-SHA - DES-CBC3-SHA In the last version i haven't. Where is the information when ciphers are dropped? and why? Thanks! From matt at openssl.org Wed Nov 30 09:58:03 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 30 Nov 2016 09:58:03 +0000 Subject: [openssl-users] When ciphers are deprecated? In-Reply-To: References: Message-ID: <819425fd-6449-c6f5-c94f-7d638f29016c@openssl.org> On 30/11/16 09:35, Mattia Rossi wrote: > Hi all, > > After updating from 1.0.2h to 1.0.2j some of my PHP script is broken, > because it can't connect to the server, after some research the server > supports very old TLSv1.0 ciphers. > > So i check what ciphers PHP query for and with different versions of > openssl i get different result, so in libssl 1.0.2h i have these > chipers: > - EDH-RSA-DES-CBC3-SHA > - DES-CBC3-SHA > > In the last version i haven't. > > Where is the information when ciphers are dropped? and why? These ciphers have not been dropped in 1.0.2, but reclassified from the "HIGH" cipherstring keyword to the "MEDIUM" cipherstring keyword. Major changes such as these are normally described in the CHANGES file: https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/CHANGES In this case, the following entry is relevant: *) In order to mitigate the SWEET32 attack, the DES ciphers were moved from HIGH to MEDIUM. This issue was reported to OpenSSL Karthikeyan Bhargavan and Gaetan Leurent (INRIA) (CVE-2016-2183) [Rich Salz] You can read more about SWEET32 here: https://www.openssl.org/blog/blog/2016/08/24/sweet32/ Matt From rossimattia92 at gmail.com Wed Nov 30 10:18:18 2016 From: rossimattia92 at gmail.com (Mattia Rossi) Date: Wed, 30 Nov 2016 11:18:18 +0100 Subject: [openssl-users] When ciphers are deprecated? In-Reply-To: <819425fd-6449-c6f5-c94f-7d638f29016c@openssl.org> References: <819425fd-6449-c6f5-c94f-7d638f29016c@openssl.org> Message-ID: Thanks Matt, it's all i need! 2016-11-30 10:58 GMT+01:00 Matt Caswell : > > > On 30/11/16 09:35, Mattia Rossi wrote: >> Hi all, >> >> After updating from 1.0.2h to 1.0.2j some of my PHP script is broken, >> because it can't connect to the server, after some research the server >> supports very old TLSv1.0 ciphers. >> >> So i check what ciphers PHP query for and with different versions of >> openssl i get different result, so in libssl 1.0.2h i have these >> chipers: >> - EDH-RSA-DES-CBC3-SHA >> - DES-CBC3-SHA >> >> In the last version i haven't. >> >> Where is the information when ciphers are dropped? and why? > > These ciphers have not been dropped in 1.0.2, but reclassified from the > "HIGH" cipherstring keyword to the "MEDIUM" cipherstring keyword. Major > changes such as these are normally described in the CHANGES file: > > https://github.com/openssl/openssl/blob/OpenSSL_1_0_2-stable/CHANGES > > In this case, the following entry is relevant: > > > *) In order to mitigate the SWEET32 attack, the DES ciphers were moved > from > HIGH to MEDIUM. > > This issue was reported to OpenSSL Karthikeyan Bhargavan and Gaetan > Leurent (INRIA) > (CVE-2016-2183) > [Rich Salz] > > > You can read more about SWEET32 here: > > https://www.openssl.org/blog/blog/2016/08/24/sweet32/ > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From ludwig.mark at siemens.com Wed Nov 30 13:26:33 2016 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Wed, 30 Nov 2016 13:26:33 +0000 Subject: [openssl-users] Return type of SSL_ctrl Message-ID: Greetings, We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and noticed that the SSL functions based on SSL_ctrl() changed from returning type int to returning type long. It's not clear why this is necessary, by spot-checking the documented numerical domain of the return values of the SSL functions (macros) deriving from SSL_ctrl().? Why was this done? (I don't see mention of this in the CHANGES file.) Thanks, Mark Ludwig Siemens Product Lifecycle Management Software Inc. Communications and Government Affairs Product Lifecycle Management Lifecycle Coll 5939 Rice Creek Parkway Shoreview, MN? 55126 United States Tel.????? :+1 (651) 855-6140 Fax????? :+1 (651) 855-6280 ludwig.mark at siemens.com www.siemens.com/plm From rsalz at akamai.com Wed Nov 30 15:37:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Nov 2016 15:37:41 +0000 Subject: [openssl-users] Return type of SSL_ctrl In-Reply-To: References: Message-ID: > We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and > noticed that the SSL functions based on SSL_ctrl() changed from returning > type int to returning type long. The when and the why is probably lost to history. Doing 'git log' and looking for SSL_ctrl doesn't show anything. Oh well. The "proper" answer is to not use long, but rather sized types, which we are slowly moving toward. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From ludwig.mark at siemens.com Wed Nov 30 17:38:46 2016 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Wed, 30 Nov 2016 17:38:46 +0000 Subject: [openssl-users] Return type of SSL_ctrl In-Reply-To: References: Message-ID: > From: Salz, Rich, Wednesday, November 30, 2016 9:38 AM > > > We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and > > noticed that the SSL functions based on SSL_ctrl() changed from returning > > type int to returning type long. > > The "proper" answer is to not use long, but rather sized types, which we are > slowly moving toward. Funny you should mention this, because this topic arose internally after someone decided to change the return type of SSL_ctrl() to intprt_t. I have no idea why, since as far as I can tell, all of the return values would fit in a 32-bit integer; thus my question about why it was changed to long, which is either 32 bits or 64 bits, depending on platform. I suspect it was the use of long that tricked someone into thinking it might be holding a pointer, and thus led to the change to intptr_t, so it would fit on Windows. (Blind/stupid global replacement.) (Does OpenSSL support any platform in which type int is 16 bits?) Thanks, Mark From rsalz at akamai.com Wed Nov 30 18:06:50 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Nov 2016 18:06:50 +0000 Subject: [openssl-users] Return type of SSL_ctrl In-Reply-To: References: Message-ID: <6aad2c39d2e8468ab7ea0773d68d5996@usma1ex-dag1mb1.msg.corp.akamai.com> > (Does OpenSSL support any platform in which type int is 16 bits?) No. From jeremy.farrell at oracle.com Wed Nov 30 18:24:56 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Wed, 30 Nov 2016 18:24:56 +0000 Subject: [openssl-users] Return type of SSL_ctrl In-Reply-To: References: Message-ID: <83ae88ad-113c-313b-0c7b-33ac64667136@oracle.com> On 30/11/2016 17:38, Ludwig, Mark wrote: >> From: Salz, Rich, Wednesday, November 30, 2016 9:38 AM >> >>> We're moving up to OpenSSL 1.0.2j from OpenSSL 0.9.8, and >>> noticed that the SSL functions based on SSL_ctrl() changed from returning type int to returning type long. >> The "proper" answer is to not use long, but rather sized types, which we are slowly moving toward. > Funny you should mention this, because this topic arose > internally after someone decided to change the return type > of SSL_ctrl() to intprt_t. I have no idea why, since as far > as I can tell, all of the return values would fit in a > 32-bit integer; thus my question about why it was changed to > long, which is either 32 bits or 64 bits, depending on > platform. I suspect it was the use of long that tricked someone > into thinking it might be holding a pointer, and thus led to the > change to intptr_t, so it would fit on Windows. (Blind/stupid > global replacement.) > > (Does OpenSSL support any platform in which type int is 16 bits?) Some confusion here. SSL_ctrl() was defined as returning long in 0.9.8a, and from what (little) I can see it looks like it was that way back in 0.6.4. Regards, jjf -- J. J. Farrell Not speaking for Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From ludwig.mark at siemens.com Wed Nov 30 23:46:53 2016 From: ludwig.mark at siemens.com (Ludwig, Mark) Date: Wed, 30 Nov 2016 23:46:53 +0000 Subject: [openssl-users] Return type of SSL_ctrl In-Reply-To: <83ae88ad-113c-313b-0c7b-33ac64667136@oracle.com> References: <83ae88ad-113c-313b-0c7b-33ac64667136@oracle.com> Message-ID: > From: Jeremy Farrell, Wednesday, November 30, 2016 12:25 PM > Some confusion here. SSL_ctrl() was defined as returning long in 0.9.8a, and from what (little) I can see it looks like it was that way back in 0.6.4. Right, I was confused by looking in derived internal source. I had no idea we had modified it to change the return type from long to int. (*Shrug*) Thanks, Mark