From rschm2 at unh.newhaven.edu Mon May 1 03:08:08 2017 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Mon, 1 May 2017 03:08:08 +0000 Subject: [openssl-users] Documentation for Integrating New Cipher Creation Request Message-ID: <32A0EC26-EC1A-4837-89F9-5483E0215BEC@unh.newhaven.edu> Hello, Over the past several months through trial and error I have at last been able to integrate a new symmetric cipher into OpenSSL. After following this email chain for these past months I?ve noticed that once in a blue moon other users would ask how to integrate a new cipher into both libcrypto and libssl. While the process is still fresh in my head, I was wondering if the community would benefit in having some documentation on the process to follow and issues that may arise? Possibly add this into the OpenSSL wiki? I would love for this to be my first contribution to an open source project and help others who may find themselves in similar situations in the future. Please let me know your thoughts. Best, Rob Schmicker From rsalz at akamai.com Mon May 1 12:17:43 2017 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 1 May 2017 12:17:43 +0000 Subject: [openssl-users] Documentation for Integrating New Cipher Creation Request In-Reply-To: <32A0EC26-EC1A-4837-89F9-5483E0215BEC@unh.newhaven.edu> References: <32A0EC26-EC1A-4837-89F9-5483E0215BEC@unh.newhaven.edu> Message-ID: <0c9d29b257e24cf58e8daa3406f1bcb2@ustx2ex-dag1mb1.msg.corp.akamai.com> > While the process is still fresh in my head, I was wondering if the community > would benefit in having some documentation on the process to follow and > issues that may arise? Possibly add this into the OpenSSL wiki? This would be a great idea. From jcondren at hcpci.com Mon May 1 15:02:41 2017 From: jcondren at hcpci.com (James Condren) Date: Mon, 1 May 2017 15:02:41 +0000 Subject: [openssl-users] NMAKE error Message-ID: Getting the following error when attempting to make: NMAKE : fatal error U1073: don't know how to make '"crypto\include\internal\bn_conf.h.in"' Stop. Here's the lines from the makefile that are creating the error: crypto\include\internal\bn_conf.h: "crypto\include\internal\bn_conf.h.in" "configdata.pm" "$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \ "-omakefile" "crypto\include\internal\bn_conf.h.in" > $@ If I remove '"crypto\include\internal\bn_conf.h.in"', it then gives me the following error: NMAKE : fatal error U1073: don't know how to make '".\Configure"' Stop. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon May 1 15:37:39 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 1 May 2017 10:37:39 -0500 Subject: [openssl-users] NMAKE error In-Reply-To: References: Message-ID: <9a0fd6a6-67d7-9015-211e-74571f3af0bb@akamai.com> On 05/01/2017 10:02 AM, James Condren wrote: > > Getting the following error when attempting to make: > > NMAKE : fatal error U1073: don't know how to make > '"crypto\include\internal\bn_conf.h.in"' > > Stop. > > > > Here?s the lines from the makefile that are creating the error: > > crypto\include\internal\bn_conf.h: > "crypto\include\internal\bn_conf.h.in" "configdata.pm" > > "$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \ > > "-omakefile" "crypto\include\internal\bn_conf.h.in" > > $@ > > > > > > If I remove '"crypto\include\internal\bn_conf.h.in"', it then gives me > the following error: > > NMAKE : fatal error U1073: don't know how to make '".\Configure"' > > Stop. > > What version of openssl? What steps did you take prior to running nmake? -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcondren at hcpci.com Mon May 1 15:53:28 2017 From: jcondren at hcpci.com (James Condren) Date: Mon, 1 May 2017 15:53:28 +0000 Subject: [openssl-users] NMAKE error In-Reply-To: <9a0fd6a6-67d7-9015-211e-74571f3af0bb@akamai.com> References: <9a0fd6a6-67d7-9015-211e-74571f3af0bb@akamai.com> Message-ID: Thanks for the prompt response. Just a little background: I am trying to install OpenSSL on a Windows PC so I can view a server cert. I downloaded the latest openssl version from github. Here are the steps I performed so far: 1. Downloaded latest version of openssl from git to C:\Workspaces\Harmony\openssl1 2. Downloaded NASM 3. Added Test::More and Text::Template perl modules to Perl location 4. SET PATH=%PATH%;C:\Workspaces\Harmony\openssl1 5. Executed perl Configure VC-WIN64A (got makefile) 6. Set SRCDIR in makefile to "C:\Workspaces\ Harmony\openssl1" Doing step #6 got me past the issues I originally logged but now I am getting "NMAKE : fatal error U1073: don't know how to make '""'". Not sure where the makefile is erroring out. I tried to add console output to the makefile but it is erroring on the @echo lines. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Benjamin Kaduk via openssl-users Sent: Monday, May 1, 2017 11:38 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] NMAKE error On 05/01/2017 10:02 AM, James Condren wrote: Getting the following error when attempting to make: NMAKE : fatal error U1073: don't know how to make '"crypto\include\internal\bn_conf.h.in"' Stop. Here's the lines from the makefile that are creating the error: crypto\include\internal\bn_conf.h: "crypto\include\internal\bn_conf.h.in" "configdata.pm" "$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \ "-omakefile" "crypto\include\internal\bn_conf.h.in" > $@ If I remove '"crypto\include\internal\bn_conf.h.in"', it then gives me the following error: NMAKE : fatal error U1073: don't know how to make '".\Configure"' Stop. What version of openssl? What steps did you take prior to running nmake? -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon May 1 15:57:52 2017 From: levitte at openssl.org (Richard Levitte) Date: Mon, 01 May 2017 17:57:52 +0200 (CEST) Subject: [openssl-users] NMAKE error In-Reply-To: References: Message-ID: <20170501.175752.2054503478440755266.levitte@openssl.org> Can you verify that crypto\include\internal\bn_conf.h.in exists? It should, it's part of the source. Can you check if there's a file with a similar name in crypto\include\internal? Cheers, Richard ( am wondering if there are tar implementations that screw up file name with more than one period... ) In message on Mon, 1 May 2017 15:02:41 +0000, James Condren said: jcondren> Getting the following error when attempting to make: jcondren> jcondren> NMAKE : fatal error U1073: don't know how to make jcondren> '"crypto\include\internal\bn_conf.h.in"' jcondren> jcondren> Stop. jcondren> jcondren> Here?s the lines from the makefile that are creating the error: jcondren> jcondren> crypto\include\internal\bn_conf.h: jcondren> "crypto\include\internal\bn_conf.h.in" "configdata.pm" jcondren> jcondren> "$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \ jcondren> jcondren> "-omakefile" "crypto\include\internal\bn_conf.h.in" > $@ jcondren> jcondren> If I remove '"crypto\include\internal\bn_conf.h.in"', it then gives me jcondren> the following error: jcondren> jcondren> NMAKE : fatal error U1073: don't know how to make '".\Configure"' jcondren> jcondren> Stop. jcondren> From jcondren at hcpci.com Mon May 1 16:02:17 2017 From: jcondren at hcpci.com (James Condren) Date: Mon, 1 May 2017 16:02:17 +0000 Subject: [openssl-users] NMAKE error In-Reply-To: <20170501.175752.2054503478440755266.levitte@openssl.org> References: <20170501.175752.2054503478440755266.levitte@openssl.org> Message-ID: Thanks for the prompt response. Just a little background: I am trying to install OpenSSL on a Windows PC so I can view a server cert. I have verified that the file exists and is part of the source. I set SRCDIR in makefile to "C:\Workspaces\ Harmony\openssl1" (it was set to ".") and by doing so, it got me past the issues I originally logged but now I am getting "NMAKE : fatal error U1073: don't know how to make '""'". Not sure where the makefile is erroring out. I tried to add console output to the makefile but it is erroring on the @echo lines. -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Richard Levitte Sent: Monday, May 1, 2017 11:58 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] NMAKE error Can you verify that crypto\include\internal\bn_conf.h.in exists? It should, it's part of the source. Can you check if there's a file with a similar name in crypto\include\internal? Cheers, Richard ( am wondering if there are tar implementations that screw up file name with more than one period... ) In message on Mon, 1 May 2017 15:02:41 +0000, James Condren said: jcondren> Getting the following error when attempting to make: jcondren> jcondren> NMAKE : fatal error U1073: don't know how to make jcondren> '"crypto\include\internal\bn_conf.h.in"' jcondren> jcondren> Stop. jcondren> jcondren> Here?s the lines from the makefile that are creating the error: jcondren> jcondren> crypto\include\internal\bn_conf.h: jcondren> "crypto\include\internal\bn_conf.h.in" "configdata.pm" jcondren> jcondren> "$(PERL)" "-I$(BLDDIR)" -Mconfigdata "util\dofile.pl" \ jcondren> jcondren> "-omakefile" "crypto\include\internal\bn_conf.h.in" > $@ jcondren> jcondren> If I remove '"crypto\include\internal\bn_conf.h.in"', it then jcondren> gives me the following error: jcondren> jcondren> NMAKE : fatal error U1073: don't know how to make '".\Configure"' jcondren> jcondren> Stop. jcondren> -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at jordan.maileater.net Mon May 1 16:00:23 2017 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 1 May 2017 09:00:23 -0700 Subject: [openssl-users] NMAKE error In-Reply-To: References: <9a0fd6a6-67d7-9015-211e-74571f3af0bb@akamai.com> Message-ID: On 5/1/2017 8:53 AM, James Condren wrote: > > Thanks for the prompt response. Just a little background: I am > trying to install OpenSSL on a Windows PC so I can view a server cert. > It might be simpler to install cygwin and an already-built OpenSSL. http://cygwin.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Mon May 1 16:56:47 2017 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 1 May 2017 12:56:47 -0400 Subject: [openssl-users] NMAKE error In-Reply-To: References: <9a0fd6a6-67d7-9015-211e-74571f3af0bb@akamai.com> Message-ID: On 5/1/2017 12:00 PM, Jordan Brown wrote: > On 5/1/2017 8:53 AM, James Condren wrote: >> >> Thanks for the prompt response. Just a little background: I am >> trying to install OpenSSL on a Windows PC so I can view a server cert. >> > > It might be simpler to install cygwin and an already-built OpenSSL. If installing prebuilt binaries is possible, this is far easier than cygwin: http://slproweb.com/products/Win32OpenSSL.html From jonacoons at gmail.com Mon May 1 23:02:54 2017 From: jonacoons at gmail.com (Jon Coons) Date: Mon, 1 May 2017 18:02:54 -0500 Subject: [openssl-users] Win 10 failure on install Message-ID: Hello, I keep running into a Win 10 failure using nmake for SSL installation. Here is the CLI info: c:\openssl>nmake Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" depend && "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" _all Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright (C) Microsoft Corporation. All rights reserved. ias -d debug -ocrypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm" 'ias' is not recognized as an internal or external command, operable program or batch file. NMAKE : fatal error U1077: 'ias' : return code '0x1' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' Stop. Has anyone run into this, and is there a workaround? Thanks, Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From Nathan.Glasser at dialogic.com Mon May 1 22:00:22 2017 From: Nathan.Glasser at dialogic.com (Nathan Glasser) Date: Mon, 1 May 2017 22:00:22 +0000 Subject: [openssl-users] Problem building Linux shared library with static FIPS capable OpenSSL Message-ID: Hello, We are using openssl-fips 2.0.14 with OpenSSL 1.0.2j. We have a shared library on both Linux and Windows which uses static OpenSSL libraries. We'd like it to use static FIPS-capable OpenSSL libraries. On Windows, everything is fine. On Linux, I have a problem. I am doing my tests on RedHat 6.0. I am able to make standalone executables just fine, but shared library (.so) building does not work. I am linking using supplied the fipsld script. The script gets error 139, which means a segmentation fault. Modifying the fipsld script to uncomment the "set -x" at the top shows me that the following is where the segmentation fault is occurring. # generate signature... SIG=`"${TARGET}"` It is attempting to run ${TARGET}, which is the .so file that has just been generated in the first link step. (It's not suprising to me that this results in a segmentation fault.) If I run the file which is left after the building aborts, I also get a segmentation fault. I can see that there is another case - when the filename matches lib*|*.dll, which it does not. If I try renaming the target to have "lib" at the start of the name, then when it runs this part # generate signature... SIG=`"${PREMAIN_DSO}" "${TARGET}"` it fails because there is no fips_premain_dso program. Nor can I find this anywhere in the openssl-fips or openssl packages. Should this have gotten built automatically in an earlier step? I created a simplified test which consists of the fips_hmac sample (included in the OpenSSL Fips 2.0 manual), with main renamed to something else. Can someone on this list please point me in the right direction for getting this to work? Thanks. Below are my makefile and build log. Here is the makefile I am using. The directory names included reflect my local environment, but they are all using the versions I stated. -------------------- CC = gcc OPENSSLDIR = ../openssl/export_openssl/ FIPSDIR=export_fips/linux/4.4 LIBCRYPTO = $(OPENSSLDIR)/linux/4.4/libcrypto.a INCLUDES = -I$(OPENSSLDIR)/include CMD = fips_hmac OBJS = $(CMD).o $(CMD).so: $(OBJS) FIPSLD_CC=$(CC) $(FIPSDIR)/bin/fipsld -m32 -shared -Wl,-Bsymbolic -o $(CMD).so $(OBJS) $(LIBCRYPTO) -ldl $(OBJS): $(CMD).c $(CC) -c $(CMD).c $(INCLUDES) -m32 clean: rm $(OBJS) -------------------- Here is the output from the build using the modified fipsld to include "set -x". -------------------- gcc -c fips_hmac.c -I../openssl/export_openssl//include -m32 FIPSLD_CC=gcc export_fips/linux/4.4/bin/fipsld -m32 -shared -Wl,-Bsymbolic -o fips_hmac.so fips_hmac.o ../openssl/export_openssl//linux/4.4/libcrypto.a -ldl + CC=gcc + '[' -n gcc ']' + '[' x-m32 '!=' x -a x-m32 '!=' x-c -a x-m32 '!=' x-E ']' + shift + '[' x-shared '!=' x -a x-shared '!=' x-c -a x-shared '!=' x-E ']' + shift + '[' x-Wl,-Bsymbolic '!=' x -a x-Wl,-Bsymbolic '!=' x-c -a x-Wl,-Bsymbolic '!=' x-E ']' + shift + '[' x-o '!=' x -a x-o '!=' x-c -a x-o '!=' x-E ']' + shift + '[' xfips_hmac.so '!=' x -a xfips_hmac.so '!=' x-c -a xfips_hmac.so '!=' x-E ']' + shift + '[' xfips_hmac.o '!=' x -a xfips_hmac.o '!=' x-c -a xfips_hmac.o '!=' x-E ']' + shift + '[' x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x -a x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x-c -a x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x-E ']' + shift + '[' x-ldl '!=' x -a x-ldl '!=' x-c -a x-ldl '!=' x-E ']' + shift + '[' x '!=' x -a x '!=' x-c -a x '!=' x-E ']' + '[' 0 -ge 1 ']' ++ '[' x-m32 '!=' x -a x-m32 '!=' x-o ']' ++ shift ++ '[' x-shared '!=' x -a x-shared '!=' x-o ']' ++ shift ++ '[' x-Wl,-Bsymbolic '!=' x -a x-Wl,-Bsymbolic '!=' x-o ']' ++ shift ++ '[' x-o '!=' x -a x-o '!=' x-o ']' ++ echo fips_hmac.so + TARGET=fips_hmac.so + case `basename "${TARGET}"` in ++ basename fips_hmac.so + case "$*" in + '[' -n fips_hmac.so ']' + '[' x-m32 '!=' x -a x-m32 '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x-shared '!=' x -a x-shared '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x-Wl,-Bsymbolic '!=' x -a x-Wl,-Bsymbolic '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x-o '!=' x -a x-o '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' xfips_hmac.so '!=' x -a xfips_hmac.so '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' xfips_hmac.o '!=' x -a xfips_hmac.o '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x -a x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x-ldl '!=' x -a x-ldl '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + shift + '[' x '!=' x -a x '!=' x-DDEBUG_FINGERPRINT_PREMAIN ']' + '[' 0 -ge 1 ']' ++ echo export_fips/linux/4.4/bin/fipsld ++ sed -e 's|[^/]*$||' + THERE=export_fips/linux/4.4/bin/.. ++ '[' x-m32 '!=' x ']' ++ case "$1" in ++ shift ++ '[' x-shared '!=' x ']' ++ case "$1" in ++ shift ++ '[' x-Wl,-Bsymbolic '!=' x ']' ++ case "$1" in ++ shift ++ '[' x-o '!=' x ']' ++ case "$1" in ++ shift ++ '[' xfips_hmac.so '!=' x ']' ++ case "$1" in ++ shift ++ '[' xfips_hmac.o '!=' x ']' ++ case "$1" in ++ shift ++ '[' x../openssl/export_openssl//linux/4.4/libcrypto.a '!=' x ']' ++ case "$1" in ++ shift ++ '[' x-ldl '!=' x ']' ++ case "$1" in ++ shift ++ '[' x '!=' x ']' + CANISTER_O= + '[' -z '' ']' + '[' -n '' ']' + '[' -f export_fips/linux/4.4/bin/../fips/fipscanister.o ']' + '[' -f export_fips/linux/4.4/bin/../lib/fipscanister.o ']' + CANISTER_O=export_fips/linux/4.4/bin/../lib/fipscanister.o + CANISTER_O_CMD=export_fips/linux/4.4/bin/../lib/fipscanister.o + '[' -f export_fips/linux/4.4/bin/../lib/fipscanister.o ']' ++ dirname export_fips/linux/4.4/bin/../lib/fipscanister.o + PREMAIN_C=export_fips/linux/4.4/bin/../lib/fips_premain.c + HMAC_KEY=etaonrishdlcupfm + case "`(uname -s) 2>/dev/null`" in + case "${TARGET}" in + TARGET=./fips_hmac.so + case `basename "${TARGET}"` in ++ basename ./fips_hmac.so + '[' -x export_fips/linux/4.4/bin/../fips/fips_standalone_sha1 ']' + '[' -x export_fips/linux/4.4/bin/../bin/fips_standalone_sha1 ']' + FINGERTYPE=export_fips/linux/4.4/bin/../bin/fips_standalone_sha1 + export_fips/linux/4.4/bin/../bin/fips_standalone_sha1 export_fips/linux/4.4/bin/../lib/fipscanister.o + sed 's/(.*\//(/' + diff -w export_fips/linux/4.4/bin/../lib/fipscanister.o.sha1 - + export_fips/linux/4.4/bin/../bin/fips_standalone_sha1 export_fips/linux/4.4/bin/../lib/fips_premain.c + sed 's/(.*\//(/' + diff -w export_fips/linux/4.4/bin/../lib/fips_premain.c.sha1 - + /bin/rm -f ./fips_hmac.so + gcc export_fips/linux/4.4/bin/../lib/fipscanister.o export_fips/linux/4.4/bin/../lib/fips_premain.c -m32 -shared -Wl,-Bsymbolic -o fips_hmac.so fips_hmac.o ../openssl/export_openssl//linux/4.4/libcrypto.a -ldl + '[' x '!=' x ']' ++ ./fips_hmac.so + SIG= make: *** [fips_hmac.so] Error 139 -------------------- Thanks, Nathan From paul.dale at oracle.com Tue May 2 01:38:37 2017 From: paul.dale at oracle.com (Paul Dale) Date: Mon, 1 May 2017 18:38:37 -0700 (PDT) Subject: [openssl-users] Documentation for Integrating New Cipher Creation Request In-Reply-To: <32A0EC26-EC1A-4837-89F9-5483E0215BEC@unh.newhaven.edu> References: <32A0EC26-EC1A-4837-89F9-5483E0215BEC@unh.newhaven.edu> Message-ID: <01431ea1-f270-4d74-a76e-49ff62d28827@default> I think this is worthwhile too. Just before I submitted the ARIA addition, I drafted such a document which you could use as a basis. The PR had some modifications made before being merged, so it isn't completely accurate. I'll forward this directly. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Schmicker, Robert [mailto:rschm2 at unh.newhaven.edu] Sent: Monday, 1 May 2017 1:08 PM To: openssl-users at openssl.org Subject: [openssl-users] Documentation for Integrating New Cipher Creation Request Hello, Over the past several months through trial and error I have at last been able to integrate a new symmetric cipher into OpenSSL. After following this email chain for these past months I?ve noticed that once in a blue moon other users would ask how to integrate a new cipher into both libcrypto and libssl. While the process is still fresh in my head, I was wondering if the community would benefit in having some documentation on the process to follow and issues that may arise? Possibly add this into the OpenSSL wiki? I would love for this to be my first contribution to an open source project and help others who may find themselves in similar situations in the future. Please let me know your thoughts. Best, Rob Schmicker -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Tue May 2 02:16:24 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 2 May 2017 02:16:24 +0000 Subject: [openssl-users] Problem building Linux shared library with static FIPS capable OpenSSL In-Reply-To: References: Message-ID: <20170502021624.GA16232@openssl.org> On Mon, May 01, 2017, Nathan Glasser wrote: > Hello, > > We are using openssl-fips 2.0.14 with OpenSSL 1.0.2j. > > We have a shared library on both Linux and Windows which uses static OpenSSL > libraries. We'd like it to use static FIPS-capable OpenSSL libraries. > > On Windows, everything is fine. On Linux, I have a problem. I am > doing my tests on RedHat 6.0. > > I am able to make standalone executables just fine, but shared library (.so) > building does not work. I am linking using supplied the fipsld script. > > The script gets error 139, which means a segmentation fault. Modifying > the fipsld script to uncomment the "set -x" at the top shows me that > the following is where the segmentation fault is occurring. > > # generate signature... > SIG=`"${TARGET}"` > > It is attempting to run ${TARGET}, which is the .so file that has just been > generated in the first link step. (It's not suprising to me that this results > in a segmentation fault.) If I run the file which is left after the building > aborts, I also get a segmentation fault. > > I can see that there is another case - when the filename matches > lib*|*.dll, which it does not. > > If I try renaming the target to have "lib" at the start of the name, > then when it runs this part > > # generate signature... > SIG=`"${PREMAIN_DSO}" "${TARGET}"` > > it fails because there is no fips_premain_dso program. Nor can I find > this anywhere in the openssl-fips or openssl packages. Should this have > gotten built automatically in an earlier step? > > I created a simplified test which consists of the fips_hmac sample (included > in the OpenSSL Fips 2.0 manual), with main renamed to something else. > > Can someone on this list please point me in the right direction for > getting this to work? Thanks. Below are my makefile and build log. > Try a shared build of the FIPS capable OpenSSL. You should then get fips_premain_dso built as part of that process. Alternatively just do: make fips_premain_dso The fips_premain_dso executable isn't anything special: all it does is load the library. It should then print out the signature which can then be embedded for the second link step. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From mahesh116 at gmail.com Tue May 2 05:59:29 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 2 May 2017 11:29:29 +0530 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: Hi Matt, Sorry for delayed response. I was on leave. Yes, ours is a library and we do not wish to ignore the signal process wide because the consumer of our library (application) might want to handle the SIGPIPE for there own socket handling. Thanks, Mahesh G S On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell wrote: > > > On 27/04/17 11:56, mahesh gs wrote: > > Hi, > > > > We are using Openssl for establish a secure communications for both > > TCP/SCTP connections. > > > > In our application it is possible that remote end forcefully disconnect > > the connection due to which > > > > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl > > > > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket > > layer) ? > > No, there is no option to do that at the moment. > > > > > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE" as it is > > not supported by LINUX > > > > and also we are unable to stop the SIGPIPE with function call > > signal(SIGPIPE, SIG_IGN). > > Unable because you want SIGPIPE for other areas of your application? Or > for some other reason? > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Tue May 2 06:03:11 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 2 May 2017 11:33:11 +0530 Subject: [openssl-users] Query regarding DTLS handshake In-Reply-To: References: <5D0F0206-79FB-48CD-89D6-A3A7264A0A18@lurchi.franken.de> <3edfe49d-6774-caae-d162-9c745a0f6b56@openssl.org> <93cc1ed2-ff68-5517-693e-6473a0483d9a@openssl.org> <8956d1ee-2844-6bbb-ebe3-0a63cbacd9c4@xura.com> <66229075-e3dd-29aa-e4c5-7337abd6315f@openssl.org> <2a85c3f5-a595-6c7b-5de2-48b33f586d70@xura.com> Message-ID: On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen < Michael.Tuexen at lurchi.franken.de> wrote: > > On 20. Apr 2017, at 20:01, mahesh gs wrote: > > > > Hi, > > > > This issue occur purely based on the time (sequence of events) at which > SSL read_state_machine enter the post processing of certificate verify > which is received from client. > > > > Handshake works fine if the certificate verify post processing is done > before the next message arrives at SCTP socket layer (In your case may be > there is a delay in receiving the next message at SCTP layer). Handshake > works fine even in my environment some times. > Can you try the attached patch and report if it fixes the issue for you? > I have tried with the patch provided by Matt. Our test results are successful. Issue is fixed with the patch. > > Best regards > Michael > > > > > > > > > I added some debug statements, below is the debug statements. > > > > > > Debug statements when the handshake does not work > > > > > > > > Length of the next packet (Cipher spec change) is exactly 14 as i > mentioned in - https://github.com/openssl/openssl/issues/3251 > > > > Debug logs when the handshake is successful > > > > > > > > If no message is waiting to be received at socket layer then handshake > is successful. If message is waiting to be received at socket layer then > the handshake will never be completed. > > > > > > Thanks, > > Mahesh G S > > > > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha < > martin.brejcha at mavenir.com> wrote: > > > > > > Matt Caswell wrote on 04/20/2017 03:23 PM: > > > > > > > > > On 20/04/17 14:19, Martin Brejcha wrote: > > >> > > >> > > >> Matt Caswell wrote on 04/20/2017 01:29 PM: > > >>> > > >>> > > >>> On 20/04/17 12:26, mahesh gs wrote: > > >>>> Hi Matt, > > >>>> > > >>>> Yes I raised github case for the same issue. I also tried running > this > > >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and > > >>>> handshake is successful with the latest SNAPSHOT code which is not > an > > >>>> official release. > > >>>> > > >>>> I checked the github repo history and observer that during commits > on > > >>>> (11 th Jan) as a part of "Move state machine knowledge out of the > record > > >>>> layer". "renegotiate" bit that is set to "2" in function > > >>>> "tls_post_process_client_hello" has been removed. May be that is > causing > > >>>> the call flow to be successful in the latest SNAPSHOT release. > > >>>> > > >>>> I am assuming commits that are done on 11th Jan or later are not > part of > > >>>> release openssl 01.01.00e > > >>> > > >>> Ah. No. That commit is in the dev branch only (scheduled for version > > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why > that > > >>> commit might help things, but probably a different solution is more > > >>> appropriate for 1.1.0. > > >>> > > >>> I'm looking at this issue at the moment. > > >>> > > >>> Matt > > >>> > > >> > > >> hi, > > >> > > >> btw: I've tested similar scenario and handshake works fine. > > >> test env: client and server on different VMs (rhel7.2, openssl > 1.1.0e, non-blocking sockets and segmented certificate) > > >> So, it should work also with 1.1.0e version. > > > > > > Thanks. Did your handshake include client auth? I think this issue only > > > arises in that case. > > > > > > Matt > > > > > > > > > > yes, client auth with segmented certificate has been included. > > > > Martin > > > > > > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Tuexen at lurchi.franken.de Tue May 2 06:21:05 2017 From: Michael.Tuexen at lurchi.franken.de (Michael Tuexen) Date: Tue, 2 May 2017 08:21:05 +0200 Subject: [openssl-users] Query regarding DTLS handshake In-Reply-To: References: <5D0F0206-79FB-48CD-89D6-A3A7264A0A18@lurchi.franken.de> <3edfe49d-6774-caae-d162-9c745a0f6b56@openssl.org> <93cc1ed2-ff68-5517-693e-6473a0483d9a@openssl.org> <8956d1ee-2844-6bbb-ebe3-0a63cbacd9c4@xura.com> <66229075-e3dd-29aa-e4c5-7337abd6315f@openssl.org> <2a85c3f5-a595-6c7b-5de2-48b33f586d70@xura.com> Message-ID: <4F8F4F36-D02C-46E3-AC07-C09DFA19541C@lurchi.franken.de> > On 2. May 2017, at 08:03, mahesh gs wrote: > > > > On Sun, Apr 30, 2017 at 11:11 PM, Michael Tuexen wrote: > > On 20. Apr 2017, at 20:01, mahesh gs wrote: > > > > Hi, > > > > This issue occur purely based on the time (sequence of events) at which SSL read_state_machine enter the post processing of certificate verify which is received from client. > > > > Handshake works fine if the certificate verify post processing is done before the next message arrives at SCTP socket layer (In your case may be there is a delay in receiving the next message at SCTP layer). Handshake works fine even in my environment some times. > Can you try the attached patch and report if it fixes the issue for you? > > I have tried with the patch provided by Matt. Our test results are successful. Issue is fixed with the patch. OK, I see. It isn't fixed in our case. That is why I sent the patch. Thanks for the feedback. Best regards Michael > > Best regards > Michael > > > > > > > > > I added some debug statements, below is the debug statements. > > > > > > Debug statements when the handshake does not work > > > > > > > > Length of the next packet (Cipher spec change) is exactly 14 as i mentioned in - https://github.com/openssl/openssl/issues/3251 > > > > Debug logs when the handshake is successful > > > > > > > > If no message is waiting to be received at socket layer then handshake is successful. If message is waiting to be received at socket layer then the handshake will never be completed. > > > > > > Thanks, > > Mahesh G S > > > > On Thu, Apr 20, 2017 at 7:17 PM, Martin Brejcha wrote: > > > > > > Matt Caswell wrote on 04/20/2017 03:23 PM: > > > > > > > > > On 20/04/17 14:19, Martin Brejcha wrote: > > >> > > >> > > >> Matt Caswell wrote on 04/20/2017 01:29 PM: > > >>> > > >>> > > >>> On 20/04/17 12:26, mahesh gs wrote: > > >>>> Hi Matt, > > >>>> > > >>>> Yes I raised github case for the same issue. I also tried running this > > >>>> call flow with the latest SNAPSHOT code (openssl-SNAP-20170419) and > > >>>> handshake is successful with the latest SNAPSHOT code which is not an > > >>>> official release. > > >>>> > > >>>> I checked the github repo history and observer that during commits on > > >>>> (11 th Jan) as a part of "Move state machine knowledge out of the record > > >>>> layer". "renegotiate" bit that is set to "2" in function > > >>>> "tls_post_process_client_hello" has been removed. May be that is causing > > >>>> the call flow to be successful in the latest SNAPSHOT release. > > >>>> > > >>>> I am assuming commits that are done on 11th Jan or later are not part of > > >>>> release openssl 01.01.00e > > >>> > > >>> Ah. No. That commit is in the dev branch only (scheduled for version > > >>> 1.1.1) and won't be backported to the 1.1.0 branch. I can see why that > > >>> commit might help things, but probably a different solution is more > > >>> appropriate for 1.1.0. > > >>> > > >>> I'm looking at this issue at the moment. > > >>> > > >>> Matt > > >>> > > >> > > >> hi, > > >> > > >> btw: I've tested similar scenario and handshake works fine. > > >> test env: client and server on different VMs (rhel7.2, openssl 1.1.0e, non-blocking sockets and segmented certificate) > > >> So, it should work also with 1.1.0e version. > > > > > > Thanks. Did your handshake include client auth? I think this issue only > > > arises in that case. > > > > > > Matt > > > > > > > > > > yes, client auth with segmented certificate has been included. > > > > Martin > > > > > > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From levitte at openssl.org Tue May 2 06:29:25 2017 From: levitte at openssl.org (Richard Levitte) Date: Tue, 02 May 2017 08:29:25 +0200 (CEST) Subject: [openssl-users] Win 10 failure on install In-Reply-To: References: Message-ID: <20170502.082925.300884007252308697.levitte@openssl.org> Are you running on an Itanium? If not, VC-WIN64I is not for you, please configure with VC-WIN64A instead. Cheers, Richard In message on Mon, 1 May 2017 18:02:54 -0500, Jon Coons said: jonacoons> Hello, jonacoons> jonacoons> I keep running into a Win 10 failure using nmake for SSL installation. jonacoons> Here is the CLI info: jonacoons> jonacoons> c:\openssl>nmake jonacoons> jonacoons> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 jonacoons> Copyright (C) Microsoft Corporation. All rights reserved. jonacoons> jonacoons> "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.exe" jonacoons> depend && "C:\Program Files (x86)\Microsoft Visual Studio jonacoons> 14.0\VC\BIN\nmake.exe" _all jonacoons> jonacoons> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 jonacoons> Copyright (C) Microsoft Corporation. All rights reserved. jonacoons> jonacoons> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 jonacoons> Copyright (C) Microsoft Corporation. All rights reserved. jonacoons> jonacoons> ias -d debug -ocrypto\aes\aes-ia64.obj "crypto\aes\aes-ia64.asm" jonacoons> 'ias' is not recognized as an internal or external command, jonacoons> operable program or batch file. jonacoons> NMAKE : fatal error U1077: 'ias' : return code '0x1' jonacoons> Stop. jonacoons> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual jonacoons> Studio 14.0\VC\BIN\nmake.exe"' : return code '0x2' jonacoons> Stop. jonacoons> jonacoons> Has anyone run into this, and is there a workaround? jonacoons> jonacoons> Thanks, jonacoons> jonacoons> Jon From matt at openssl.org Tue May 2 08:40:37 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 May 2017 09:40:37 +0100 Subject: [openssl-users] Doubt regarding ExtendedMasterSecret In-Reply-To: References: Message-ID: On 30/04/17 19:51, Stiju Easo wrote: > Hi , > > I got the answer to this, and now the question looks bit stupid. > Generation of master key is different in case of "Extended Master > Secret" , > > I still have a doubt, what would be the contents in SSL* > s->s3->handshake_buffer? > I need to manually set this for my tool, i assume it holds both > client and server handshakes, am i right? > > > if i am right , in openssl , i just need to populate > s3->handshake_buffer and set flags to s->session->flags & > SSL_SESS_FLAG_EXTMS. > only unknown thing i have is s3->handshake_buffer , what value to > copy there. handshake_buffer is a mem BIO that contains a copy of all the handshake messages sent and received so far - but only sometimes. Dependant on how the handshake proceeds sometimes this buffer stays active for a while. Other times it gets released early and instead we keep a rolling hash of the handshake messages. The problem is your code is reaching right into the internals of libssl and playing around with the internal state. In OpenSSL 1.1.0 you will be unable to do that (the SSL struct is opaque). Matt From matt at openssl.org Tue May 2 09:06:37 2017 From: matt at openssl.org (Matt Caswell) Date: Tue, 2 May 2017 10:06:37 +0100 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: On 02/05/17 06:59, mahesh gs wrote: > Hi Matt, > > Sorry for delayed response. I was on leave. > > Yes, ours is a library and we do not wish to ignore the signal process > wide because the consumer of our library (application) might want to > handle the SIGPIPE for there own socket handling. Could you use pthread_sigmask() to only block SIGPIPE for the current thread (perhaps unblocking it again before returning control back to the caller of your library)? Matt > > Thanks, > Mahesh G S > > On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell > wrote: > > > > On 27/04/17 11:56, mahesh gs wrote: > > Hi, > > > > We are using Openssl for establish a secure communications for both > > TCP/SCTP connections. > > > > In our application it is possible that remote end forcefully disconnect > > the connection due to which > > > > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl > > > > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP socket > > layer) ? > > No, there is no option to do that at the moment. > > > > > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE" as it is > > not supported by LINUX > > > > and also we are unable to stop the SIGPIPE with function call > > signal(SIGPIPE, SIG_IGN). > > Unable because you want SIGPIPE for other areas of your application? Or > for some other reason? > > Matt > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > From glosterj9 at gmail.com Tue May 2 10:11:26 2017 From: glosterj9 at gmail.com (john gloster) Date: Tue, 2 May 2017 15:41:26 +0530 Subject: [openssl-users] SSL_VERIFY_PEER Message-ID: Hi, I needed to validate different extensions of each of the Issuer certificate in the chain. Snippet rom https://linux.die.net/man/3/ssl_set_verify: "The certificate chain is checked starting with the deepest nesting level (the root CA certificate) and worked upward to the peer's certificate. At each level signatures and issuer attributes are checked. " When we say "issuer attributes", could someone let me know what different stuffs in the CA certificate are validated? Thanks in advance. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mahesh116 at gmail.com Tue May 2 10:59:29 2017 From: mahesh116 at gmail.com (mahesh gs) Date: Tue, 2 May 2017 16:29:29 +0530 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: On Tue, May 2, 2017 at 2:36 PM, Matt Caswell wrote: > > > On 02/05/17 06:59, mahesh gs wrote: > > Hi Matt, > > > > Sorry for delayed response. I was on leave. > > > > Yes, ours is a library and we do not wish to ignore the signal process > > wide because the consumer of our library (application) might want to > > handle the SIGPIPE for there own socket handling. > > Could you use pthread_sigmask() to only block SIGPIPE for the current > thread (perhaps unblocking it again before returning control back to the > caller of your library)? > > Thanks for your suggestion. We will try to adapt this work around. > > > > > > Thanks, > > Mahesh G S > > > > On Thu, Apr 27, 2017 at 4:36 PM, Matt Caswell > > wrote: > > > > > > > > On 27/04/17 11:56, mahesh gs wrote: > > > Hi, > > > > > > We are using Openssl for establish a secure communications for both > > > TCP/SCTP connections. > > > > > > In our application it is possible that remote end forcefully > disconnect > > > the connection due to which > > > > > > SSL_Write raises a SIGPIPE which we want to suppress. Does openssl > > > > > > provide any way to set MSG_NOSIGNAL on sendmsg (Underlying TCP/IP > socket > > > layer) ? > > > > No, there is no option to do that at the moment. > > > > > > > > Unfortunately we cannot use "setsockopt" with "SO_NOSIGPIPE" as > it is > > > not supported by LINUX > > > > > > and also we are unable to stop the SIGPIPE with function call > > > signal(SIGPIPE, SIG_IGN). > > > > Unable because you want SIGPIPE for other areas of your application? > Or > > for some other reason? > > > > Matt > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue May 2 14:04:50 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 May 2017 10:04:50 -0400 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: <7A8827B7-D83F-4503-9EFC-5CED8940C286@dukhovni.org> > On May 2, 2017, at 5:06 AM, Matt Caswell wrote: > >> Yes, ours is a library and we do not wish to ignore the signal process >> wide because the consumer of our library (application) might want to >> handle the SIGPIPE for there own socket handling. > > Could you use pthread_sigmask() to only block SIGPIPE for the current > thread (perhaps unblocking it again before returning control back to the > caller of your library)? Presumably, the signal will be delivered as soon as it unblocked, and likely before "returning control to the caller". So I think this just delays the problem, but does not fix it. Blocking a signal is not the same as ignoring it. Multi-threaded programs should avoid having signals delivered to some random thread that happens to be "on CPU", by blocking signals permanently in all but a single signal-handling thread, but such design decisions are made in main() and not in libraries. -- Viktor. From Michael.Wojcik at microfocus.com Tue May 2 15:27:20 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 2 May 2017 15:27:20 +0000 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: It may be worth noting that nearly all well-written UNIX applications should set the disposition of SIGPIPE to SIG_IGN. (Preferably using sigaction, simply because that's now the preferred API, but doing it with signal is essentially equivalent in this case.) SIGPIPE is a hack. It exists only to terminate poorly-written programs that could otherwise block a pipeline. See Bach, The Design of the UNIX Operating System; if memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was introduced because some poorly-written programs did not check the return code from write.[1] Catching SIGPIPE in a custom handler is nearly always the Wrong Thing. The correct approach, 99.9% of the time, is to set the disposition to SIG_IGN and check the results of each system call. Personally, I think it's completely acceptable for a library to note in its documentation that the calling program MUST ignore SIGPIPE, or the library may not function properly. It's arguably OK for a library to check the disposition of SIGPIPE and if it's SIG_DFL, change it to SIG_IGN, on the grounds that the calling program is not well-written so it doesn't deserve to govern its own signal handling; but it's probably better to just fail in that case, either immediately (with a diagnostic that tells the user that the developer forgot to set the disposition of SIGPIPE) or when a SIGPIPE occurs. Libraries can't accommodate all forms of invalid behavior. You can do a certain amount of defensive coding, but at some point you're diminishing functionality for well-behaved applications in order to coddle bad ones. Don't do that. [1] There were no send, sendto, or sendmsg calls at the time. Now the argument applies equally to them. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of mahesh gs Sent: Monday, May 01, 2017 23:59 To: openssl-users at openssl.org Subject: Re: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write Yes, ours is a library and we do not wish to ignore the signal process wide because the consumer of our library (application) might want to handle the SIGPIPE for there own socket handling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at stroeder.com Tue May 2 18:02:38 2017 From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=) Date: Tue, 2 May 2017 20:02:38 +0200 Subject: [openssl-users] Segmentation fault ssl23_connect() In-Reply-To: References: Message-ID: <072d65e8-391a-41d9-bfca-4dc3c8eb1777@stroeder.com> Sanjaya Joshi wrote: > I use openldap_2.3.39 to initiate secure LDAP connection (starttls) to external LDAP > server. The used openssl version is 1.0.2k. I'm not sure whether OpenSSL 1.0.2k is even usable with this ancient OpenLDAP version. Especially it was set to historic status by the OpenLDAP project several years ago. I'd strongly recommend to use a recent OpenLDAP release before trying anything else. Ciao, Michael. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3829 bytes Desc: S/MIME Cryptographic Signature URL: From openssl-users at dukhovni.org Tue May 2 18:18:07 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 2 May 2017 14:18:07 -0400 Subject: [openssl-users] Segmentation fault ssl23_connect() In-Reply-To: <072d65e8-391a-41d9-bfca-4dc3c8eb1777@stroeder.com> References: <072d65e8-391a-41d9-bfca-4dc3c8eb1777@stroeder.com> Message-ID: > On May 2, 2017, at 2:02 PM, Michael Str?der wrote: > > I'm not sure whether OpenSSL 1.0.2k is even usable with this ancient OpenLDAP version. > Especially it was set to historic status by the OpenLDAP project several years ago. > > I'd strongly recommend to use a recent OpenLDAP release before trying anything else. It should "just work". The OpenSSL 1.0.2 branch is expected to provide ABI compatibility with older software built against OpenSSL 1.0.0, 1.0.1 and older patch levels of 1.0.2. There could of course be unfixed bugs in that OpenLDAP version that a newer version of OpenSSL happens to expose, but generally speaking what worked with 1.0.0 or 1.0.1 should continue to work with 1.0.2. -- Viktor. From Nathan.Glasser at dialogic.com Tue May 2 20:30:08 2017 From: Nathan.Glasser at dialogic.com (Nathan Glasser) Date: Tue, 2 May 2017 20:30:08 +0000 Subject: [openssl-users] Problem building Linux shared library with static FIPS capable OpenSSL In-Reply-To: <20170502021624.GA16232@openssl.org> References: <20170502021624.GA16232@openssl.org> Message-ID: >Try a shared build of the FIPS capable OpenSSL. You should then get >fips_premain_dso built as part of that process. Alternatively just do: > make fips_premain_dso >The fips_premain_dso executable isn't anything special: all it does is load >the library. It should then print out the signature which can then be embedded >for the second link step. Thanks, Steve. With your help I was able to get this to work. It's sort of hokey process - 1) Run an extra undocumented make step (make fips_premain_dso). 2) Change my target shared library (.so) file to start with "lib". 3) Put the fips_premain_dso program into the directory from which fipsld is being run. 4) Rename the target shared library back to its intended name. But it does work. Problem solved. Thanks, Nathan From jb-openssl at wisemo.com Wed May 3 02:18:36 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 3 May 2017 04:18:36 +0200 Subject: [openssl-users] Is there a "Golden" CA makefile? In-Reply-To: References: Message-ID: On 30/04/2017 13:52, Jochen Bern wrote: > On 04/29/2017 09:55 PM, John Lewis got digested: >> I am looking for a CA makefile to use with a openvpn tutorial I am >> writing https://github.com/Oflameo/openvpn_ws. Is there one officially >> endorsed by the openssl project? > Since you're specifically mentioning Open*VPN*, let me mention that > EasyRSA is a spin-off of that project. Not makefiles based, and working > with sub-CAs certainly isn't easy (though *possible* with version 3), > but if you want to see how the OpenVPN people think "their" CAs *should* > be run, that's what I'ld suggest to look at. > > In a more general sense, the policies and technical limitations of CAs > vary too much for their operators to even agree on what color gold has, > I guess ... > > (Not-quite-random example: Out of the box, OpenSSL dislikes CAs issuing > same-DN certs with overlapping validity periods. OpenVPN, again out of > the box, bases the mechanism of peer-specific configs on the CN. So if > you want to renew the cert of some device you're managing remotely > *through* the very VPN, you may(*) have an interest to *defeat* the > OpenSSL behavior, so as to issue the new cert before the old one expires > and saws off the branch you're adminning from. > (*) Of course, there *are* other techniques to work around the problem, > but.) > > Not as much "defeat", as setting the relevant option by adding the following command during CA (and SubCA) setup: echo "unique_subject = no" > ${CADIR}/db/index.attr 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 liork.cryptobiu at gmail.com Wed May 3 08:43:25 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 11:43:25 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() Message-ID: Hi, I'm using EVP_aes_128_gcm and have problem with compiling it with OpenSSL 1.1.0 (earlier versions are compiling). Although I included I got this error : error: ?EVP_aes_128_gcm? was not declared in this scope. I'm using CentOS 7.3. Which file I need to include in order to compile EVP_aes_128_gcm ? ?Best Regards,? -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 09:07:05 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 10:07:05 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: Message-ID: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> On 03/05/17 09:43, Lior Koskas wrote: > Hi, > > I'm using EVP_aes_128_gcm and have problem with compiling it with > OpenSSL 1.1.0 (earlier versions are compiling). > Although I included I got this error : error: > ?EVP_aes_128_gcm? was not declared in this scope. > > I'm using CentOS 7.3. > > Which file I need to include in order to compile EVP_aes_128_gcm ? It's still declared in evp.h: const EVP_CIPHER *EVP_aes_128_gcm(void); Perhaps you are not picking up the version of evp.h that you think you are? Matt From HKirov at technologica.com Wed May 3 09:11:58 2017 From: HKirov at technologica.com (Hristiyan Kirov) Date: Wed, 3 May 2017 09:11:58 +0000 Subject: [openssl-users] CRL list with size more than 4MB Message-ID: <0B3C37BD3EBF7C4A957BC6F106267381C10AA5@mx2.technologica.com> Hello, We have a system in which the access control is done via SSL certificates. The end-users provide their personal certificate and we let them in. We have Oracle Linux 6.8 with apache 2.4 and openssl 1.0.1e. We have problem with one of the issuers of certificates (CA) in our country. Their CRL files are larger than 4MB. When a client with certificate issued from them try to login the following error is generated: [Wed Apr 12 18:48:37.694046 2017] [ssl:info] [pid 9123] [client xxxxxxxxxxx:51018] AH02276: Certificate Verification: Error (3): unable to get certificate CRL Other users with certificates from other issuers (CAs) are able to login correctly. Our apache is configured with the following directives: SSLCARevocationCheck leaf SSLCARevocationPath /etc/rh/root/etc/httpd24/conf/keystore/crl/ and in SSLCARevocationPath we have symbolic links to the CRL file named hash-value.rN. The CRL files are downloaded everyday via crontab. All CRL files (except the ones from problematic CA) are smaller than 4MB. We found a documentation from Oracle that their Oracle HTTP Server (based on apache) is not able to process CRL files larger than 4MB. One additional comment, we have a similar legacy system but with apache 2.2 and openssl 0.9.8 and the login is successful there with CRLs larger than 4MB - but we assume that this is during the fact that in apache 2.2 if there is no CRL, the system will let you pass. We can provide more information for the problem and trace files from openssl commands that checks the certificates but after weeks of troubleshooting we came up to the size of the revocation list... So, have any of you guys managed to process correctly CRL file larger than 4MB? Thanks Regards, Hristiyan Kirov -------------- next part -------------- An HTML attachment was scrubbed... URL: From liork.cryptobiu at gmail.com Wed May 3 09:33:02 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 12:33:02 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> Message-ID: I viewed the file and the definition exists. I also checked that I'm picking the correct version. My problem is this line : EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); I also tried to change the code to this two lines : EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); After the change I got this error : expected initializer before ?evp_gcm? What am I doing wrong? On 3 May 2017 at 12:07, Matt Caswell wrote: > > > On 03/05/17 09:43, Lior Koskas wrote: > > Hi, > > > > I'm using EVP_aes_128_gcm and have problem with compiling it with > > OpenSSL 1.1.0 (earlier versions are compiling). > > Although I included I got this error : error: > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > I'm using CentOS 7.3. > > > > Which file I need to include in order to compile EVP_aes_128_gcm ? > > It's still declared in evp.h: > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > Perhaps you are not picking up the version of evp.h that you think you are? > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 09:57:07 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 10:57:07 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> Message-ID: <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> On 03/05/17 10:33, Lior Koskas wrote: > I viewed the file and the definition exists. > I also checked that I'm picking the correct version. > > My problem is this line : EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), > NULL, NULL, NULL); > > I also tried to change the code to this two lines : > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); You have one too many "EVP"'s in there. It should be: const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); Although, that really shouldn't be necessary and your original version looks ok. What doesn't look quite right is the "&_ctx" bit. In 1.1.0 an EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete instances of it directly. Where previously you might have had: EVP_CIPHER_CTX _ctx; EVP_CIPHER_CTX_init(&_ctx); EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); You now need to do: EVP_CIPHER_CTX *_ctx; _ctx = EVP_CIPHER_CTX_new(); EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); ... EVP_CIPHER_CTX_free(_ctx); I have omitted error checking code for brevity. Matt > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > After the change I got this error : expected initializer before ?evp_gcm? > > What am I doing wrong? > > On 3 May 2017 at 12:07, Matt Caswell > wrote: > > > > On 03/05/17 09:43, Lior Koskas wrote: > > Hi, > > > > I'm using EVP_aes_128_gcm and have problem with compiling it with > > OpenSSL 1.1.0 (earlier versions are compiling). > > Although I included I got this error : error: > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > I'm using CentOS 7.3. > > > > Which file I need to include in order to compile EVP_aes_128_gcm ? > > It's still declared in evp.h: > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > Perhaps you are not picking up the version of evp.h that you think > you are? > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > Lior Koskas > Software Engineer > > From glosterj9 at gmail.com Wed May 3 09:58:00 2017 From: glosterj9 at gmail.com (john gloster) Date: Wed, 3 May 2017 15:28:00 +0530 Subject: [openssl-users] Regarding SSL_VERIFY_PEER Message-ID: Hi, I needed to validate different extensions of each of the Issuer certificate in the chain. Snippet rom https://linux.die.net/man/3/ssl_set_verify: "The certificate chain is checked starting with the deepest nesting level (the root CA certificate) and worked upward to the peer's certificate. At each level signatures and issuer attributes are checked. " When we say "issuer attributes", could someone let me know what different stuffs in the CA certificate are validated? Thanks in advance. John. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kartik.chandrashekar at innoviti.com Wed May 3 11:29:25 2017 From: kartik.chandrashekar at innoviti.com (Kartik Chandrashekar Iyer) Date: Wed, 3 May 2017 16:59:25 +0530 Subject: [openssl-users] client DLL going in hang mode during SSL_library_init() call Message-ID: <543ee4244d7c30c3f6a8e432c0d91a4a@mail.gmail.com> Hi Team, I compiled openssl-1.0.2k version using the below website link and I was able to build it successfully and get the static and dynamic libraries to be added in visual studio for my application dll build. http://p-nand-q.com/programming/windows/building_openssl_with_visual_studio_2013.html I used the build automatically option. Now I added the static libraries in my visual studio project and compiled my application. Build was successful and output was my_app.dll file. I also copied the dynamic libraries for the respective static libraries in the folder where I will initiate the application and my dll will be loaded. Its getting loaded but during SSL_library_init(), my_app.dll does not respond further. It calls this function and just hangs. I am not able to make out what the issue can be. Also, If I am using precompiled libraries from the below site, I am able to initiate the ssl library and I am able to do my work. https://www.npcglib.org/~stathis/blog/precompiled-openssl/ am I missing something while build process of openssl. Or is there something missing in the visual studio settings. Regards, Kartik -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed May 3 12:39:43 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 3 May 2017 08:39:43 -0400 Subject: [openssl-users] Regarding SSL_VERIFY_PEER In-Reply-To: References: Message-ID: <2768A55F-B1AC-42E6-90F4-C271FFEF3CA9@dukhovni.org> > On May 3, 2017, at 5:58 AM, john gloster wrote: > > Hi, > > I needed to validate different extensions of each of the Issuer certificate in the chain. > > Snippet rom https://linux.die.net/man/3/ssl_set_verify: > > "The certificate chain is checked starting with the deepest nesting level (the root CA certificate) and worked upward to the peer's certificate. At each level signatures and issuer attributes are checked. " > > When we say "issuer attributes", could someone let me know what different stuffs in the CA certificate are validated? For the full verification process see: https://github.com/openssl/openssl/blob/f0ef20bf386b5c37ba5a4ce5c1de9a819bbeffb2/crypto/x509/x509_vfy.c#L208 which happens after checking that the peer's key meets the required security level at: https://github.com/openssl/openssl/blob/f0ef20bf386b5c37ba5a4ce5c1de9a819bbeffb2/crypto/x509/x509_vfy.c#L286 The specific chain checks you may be thinking of are: https://github.com/openssl/openssl/blob/f0ef20bf386b5c37ba5a4ce5c1de9a819bbeffb2/crypto/x509/x509_vfy.c#L448 -- Viktor. From liork.cryptobiu at gmail.com Wed May 3 14:19:33 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 17:19:33 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> Message-ID: Thank you for your answer. I made all the changes and the code isn't compiling. I'm using cmake in order to build the code. my CMakeLists.txt contains this line in order to include openssl headers: INCLUDE_DIRECTORIES(/usr/include/openssl/ /usr/local/include/openssl/) The constructor of my code is : HashEncrypt::HashEncrypt(const unsigned char *key, const unsigned char *iv, size_t ivSizeBytes) { // copy the 128-bit key memcpy(_key, key, 16); //copy the iv: EVP_CIPHER_CTX *_ctx; _iv = new unsigned char[ivSizeBytes]; memcpy(_iv, iv, ivSizeBytes); //EVP_CIPHER_CTX_init(&_ctx); _ctx = EVP_CIPHER_CTX_new(); EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, ivSizeBytes, NULL); EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); } What I'm missing? On 3 May 2017 at 12:57, Matt Caswell wrote: > > > On 03/05/17 10:33, Lior Koskas wrote: > > I viewed the file and the definition exists. > > I also checked that I'm picking the correct version. > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), > > NULL, NULL, NULL); > > > > I also tried to change the code to this two lines : > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > You have one too many "EVP"'s in there. It should be: > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > Although, that really shouldn't be necessary and your original version > looks ok. What doesn't look quite right is the "&_ctx" bit. In 1.1.0 an > EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete instances > of it directly. > > Where previously you might have had: > > EVP_CIPHER_CTX _ctx; > > EVP_CIPHER_CTX_init(&_ctx); > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > You now need to do: > > EVP_CIPHER_CTX *_ctx; > > _ctx = EVP_CIPHER_CTX_new(); > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > ... > EVP_CIPHER_CTX_free(_ctx); > > > I have omitted error checking code for brevity. > > Matt > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > After the change I got this error : expected initializer before ?evp_gcm? > > > > What am I doing wrong? > > > > On 3 May 2017 at 12:07, Matt Caswell > > wrote: > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > Hi, > > > > > > I'm using EVP_aes_128_gcm and have problem with compiling it with > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > Although I included I got this error : error: > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > I'm using CentOS 7.3. > > > > > > Which file I need to include in order to compile EVP_aes_128_gcm ? > > > > It's still declared in evp.h: > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > Perhaps you are not picking up the version of evp.h that you think > > you are? > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 14:32:51 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 15:32:51 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> Message-ID: On 03/05/17 15:19, Lior Koskas wrote: > Thank you for your answer. > > I made all the changes and the code isn't compiling. > > I'm using cmake in order to build the code. > > my CMakeLists.txt contains this line in order to include openssl headers: > > INCLUDE_DIRECTORIES(/usr/include/openssl/ /usr/local/include/openssl/) Where did you install OpenSSL? By default OpenSSL 1.1.0 will install to /usr/local, and the headers will be in /usr/local/include. The final "openssl" directory name in the path to the individual header files should not be included in the include directory path. My guess is that you are picking up the system openssl headers rather than the ones from your 1.1.0 installation. Most likely this needs to be: INCLUDE_DIRECTORIES(/usr/local/include) But it does depend on options that you gave to config when you compiled OpenSSL (also I don't use cmake so I could be wrong). > > The constructor of my code is : > > HashEncrypt::HashEncrypt(const unsigned char *key, const unsigned char > *iv, size_t ivSizeBytes) > { > // copy the 128-bit key > memcpy(_key, key, 16); > > //copy the iv: > EVP_CIPHER_CTX *_ctx; > _iv = new unsigned char[ivSizeBytes]; > memcpy(_iv, iv, ivSizeBytes); > > //EVP_CIPHER_CTX_init(&_ctx); > _ctx = EVP_CIPHER_CTX_new(); > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, ivSizeBytes, NULL); > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); You need a call to EVP_CIPHER_CTX_free(_ctx) at the end too...plus check the return values from these function calls for errors. Matt > > } > > What I'm missing? > > > > > On 3 May 2017 at 12:57, Matt Caswell > wrote: > > > > On 03/05/17 10:33, Lior Koskas wrote: > > I viewed the file and the definition exists. > > I also checked that I'm picking the correct version. > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), > > NULL, NULL, NULL); > > > > I also tried to change the code to this two lines : > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > You have one too many "EVP"'s in there. It should be: > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > Although, that really shouldn't be necessary and your original version > looks ok. What doesn't look quite right is the "&_ctx" bit. In 1.1.0 an > EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete instances > of it directly. > > Where previously you might have had: > > EVP_CIPHER_CTX _ctx; > > EVP_CIPHER_CTX_init(&_ctx); > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > You now need to do: > > EVP_CIPHER_CTX *_ctx; > > _ctx = EVP_CIPHER_CTX_new(); > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > ... > EVP_CIPHER_CTX_free(_ctx); > > > I have omitted error checking code for brevity. > > Matt > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > After the change I got this error : expected initializer before ?evp_gcm? > > > > What am I doing wrong? > > > > On 3 May 2017 at 12:07, Matt Caswell > > >> wrote: > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > Hi, > > > > > > I'm using EVP_aes_128_gcm and have problem with compiling it > with > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > Although I included I got this error : error: > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > I'm using CentOS 7.3. > > > > > > Which file I need to include in order to compile > EVP_aes_128_gcm ? > > > > It's still declared in evp.h: > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > Perhaps you are not picking up the version of evp.h that you think > > you are? > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > Lior Koskas > Software Engineer > > From liork.cryptobiu at gmail.com Wed May 3 15:10:58 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 18:10:58 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> Message-ID: I checked the evp.h file in the path /usr/local/include and indeed it's not contain any gcm functions. I installed openssl via yum install openssl-devel in the past. On 3 May 2017 at 17:32, Matt Caswell wrote: > > > On 03/05/17 15:19, Lior Koskas wrote: > > Thank you for your answer. > > > > I made all the changes and the code isn't compiling. > > > > I'm using cmake in order to build the code. > > > > my CMakeLists.txt contains this line in order to include openssl headers: > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ /usr/local/include/openssl/) > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will install to > /usr/local, and the headers will be in /usr/local/include. The final > "openssl" directory name in the path to the individual header files > should not be included in the include directory path. > > My guess is that you are picking up the system openssl headers rather > than the ones from your 1.1.0 installation. > > Most likely this needs to be: > > INCLUDE_DIRECTORIES(/usr/local/include) > > But it does depend on options that you gave to config when you compiled > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > The constructor of my code is : > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const unsigned char > > *iv, size_t ivSizeBytes) > > { > > // copy the 128-bit key > > memcpy(_key, key, 16); > > > > //copy the iv: > > EVP_CIPHER_CTX *_ctx; > > _iv = new unsigned char[ivSizeBytes]; > > memcpy(_iv, iv, ivSizeBytes); > > > > //EVP_CIPHER_CTX_init(&_ctx); > > _ctx = EVP_CIPHER_CTX_new(); > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, ivSizeBytes, NULL); > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end too...plus check > the return values from these function calls for errors. > > Matt > > > > > } > > > > What I'm missing? > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > wrote: > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > I viewed the file and the definition exists. > > > I also checked that I'm picking the correct version. > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > EVP_aes_128_gcm(), > > > NULL, NULL, NULL); > > > > > > I also tried to change the code to this two lines : > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > You have one too many "EVP"'s in there. It should be: > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > Although, that really shouldn't be necessary and your original > version > > looks ok. What doesn't look quite right is the "&_ctx" bit. In 1.1.0 > an > > EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete > instances > > of it directly. > > > > Where previously you might have had: > > > > EVP_CIPHER_CTX _ctx; > > > > EVP_CIPHER_CTX_init(&_ctx); > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > > > You now need to do: > > > > EVP_CIPHER_CTX *_ctx; > > > > _ctx = EVP_CIPHER_CTX_new(); > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > ... > > EVP_CIPHER_CTX_free(_ctx); > > > > > > I have omitted error checking code for brevity. > > > > Matt > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > > > After the change I got this error : expected initializer before > ?evp_gcm? > > > > > > What am I doing wrong? > > > > > > On 3 May 2017 at 12:07, Matt Caswell matt at openssl.org> > > > >> wrote: > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > Hi, > > > > > > > > I'm using EVP_aes_128_gcm and have problem with compiling it > > with > > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > > Although I included I got this error : error: > > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > > > I'm using CentOS 7.3. > > > > > > > > Which file I need to include in order to compile > > EVP_aes_128_gcm ? > > > > > > It's still declared in evp.h: > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > Perhaps you are not picking up the version of evp.h that you > think > > > you are? > > > > > > Matt > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 15:13:49 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 16:13:49 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> Message-ID: <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> On 03/05/17 16:10, Lior Koskas wrote: > I checked the evp.h file in the path /usr/local/include and indeed it's > not contain any gcm functions. > I installed openssl via yum install openssl-devel in the past. So, how did you install OpenSSL this time? Matt > > On 3 May 2017 at 17:32, Matt Caswell > wrote: > > > > On 03/05/17 15:19, Lior Koskas wrote: > > Thank you for your answer. > > > > I made all the changes and the code isn't compiling. > > > > I'm using cmake in order to build the code. > > > > my CMakeLists.txt contains this line in order to include openssl headers: > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ /usr/local/include/openssl/) > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will install to > /usr/local, and the headers will be in /usr/local/include. The final > "openssl" directory name in the path to the individual header files > should not be included in the include directory path. > > My guess is that you are picking up the system openssl headers rather > than the ones from your 1.1.0 installation. > > Most likely this needs to be: > > INCLUDE_DIRECTORIES(/usr/local/include) > > But it does depend on options that you gave to config when you compiled > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > The constructor of my code is : > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const unsigned char > > *iv, size_t ivSizeBytes) > > { > > // copy the 128-bit key > > memcpy(_key, key, 16); > > > > //copy the iv: > > EVP_CIPHER_CTX *_ctx; > > _iv = new unsigned char[ivSizeBytes]; > > memcpy(_iv, iv, ivSizeBytes); > > > > //EVP_CIPHER_CTX_init(&_ctx); > > _ctx = EVP_CIPHER_CTX_new(); > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, ivSizeBytes, NULL); > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end too...plus check > the return values from these function calls for errors. > > Matt > > > > > } > > > > What I'm missing? > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > >> wrote: > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > I viewed the file and the definition exists. > > > I also checked that I'm picking the correct version. > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > EVP_aes_128_gcm(), > > > NULL, NULL, NULL); > > > > > > I also tried to change the code to this two lines : > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > You have one too many "EVP"'s in there. It should be: > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > Although, that really shouldn't be necessary and your original > version > > looks ok. What doesn't look quite right is the "&_ctx" bit. In > 1.1.0 an > > EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete > instances > > of it directly. > > > > Where previously you might have had: > > > > EVP_CIPHER_CTX _ctx; > > > > EVP_CIPHER_CTX_init(&_ctx); > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > > > You now need to do: > > > > EVP_CIPHER_CTX *_ctx; > > > > _ctx = EVP_CIPHER_CTX_new(); > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > ... > > EVP_CIPHER_CTX_free(_ctx); > > > > > > I have omitted error checking code for brevity. > > > > Matt > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > > > After the change I got this error : expected initializer > before ?evp_gcm? > > > > > > What am I doing wrong? > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > >>> wrote: > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > Hi, > > > > > > > > I'm using EVP_aes_128_gcm and have problem with > compiling it > > with > > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > > Although I included I got this error : > error: > > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > > > I'm using CentOS 7.3. > > > > > > > > Which file I need to include in order to compile > > EVP_aes_128_gcm ? > > > > > > It's still declared in evp.h: > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > Perhaps you are not picking up the version of evp.h that > you think > > > you are? > > > > > > Matt > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > Lior Koskas > Software Engineer > > From liork.cryptobiu at gmail.com Wed May 3 15:16:03 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 18:16:03 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> Message-ID: In the same way. This is the first time I'm checking the code on my CentOS machine. On 3 May 2017 at 18:13, Matt Caswell wrote: > > > On 03/05/17 16:10, Lior Koskas wrote: > > I checked the evp.h file in the path /usr/local/include and indeed it's > > not contain any gcm functions. > > I installed openssl via yum install openssl-devel in the past. > > So, how did you install OpenSSL this time? > > Matt > > > > > > On 3 May 2017 at 17:32, Matt Caswell > > wrote: > > > > > > > > On 03/05/17 15:19, Lior Koskas wrote: > > > Thank you for your answer. > > > > > > I made all the changes and the code isn't compiling. > > > > > > I'm using cmake in order to build the code. > > > > > > my CMakeLists.txt contains this line in order to include openssl > headers: > > > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ > /usr/local/include/openssl/) > > > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will install > to > > /usr/local, and the headers will be in /usr/local/include. The final > > "openssl" directory name in the path to the individual header files > > should not be included in the include directory path. > > > > My guess is that you are picking up the system openssl headers rather > > than the ones from your 1.1.0 installation. > > > > Most likely this needs to be: > > > > INCLUDE_DIRECTORIES(/usr/local/include) > > > > But it does depend on options that you gave to config when you > compiled > > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > > > > > The constructor of my code is : > > > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const unsigned > char > > > *iv, size_t ivSizeBytes) > > > { > > > // copy the 128-bit key > > > memcpy(_key, key, 16); > > > > > > //copy the iv: > > > EVP_CIPHER_CTX *_ctx; > > > _iv = new unsigned char[ivSizeBytes]; > > > memcpy(_iv, iv, ivSizeBytes); > > > > > > //EVP_CIPHER_CTX_init(&_ctx); > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, ivSizeBytes, > NULL); > > > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end too...plus > check > > the return values from these function calls for errors. > > > > Matt > > > > > > > > } > > > > > > What I'm missing? > > > > > > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell matt at openssl.org> > > > >> wrote: > > > > > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > > I viewed the file and the definition exists. > > > > I also checked that I'm picking the correct version. > > > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > > EVP_aes_128_gcm(), > > > > NULL, NULL, NULL); > > > > > > > > I also tried to change the code to this two lines : > > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > > > You have one too many "EVP"'s in there. It should be: > > > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > > > Although, that really shouldn't be necessary and your original > > version > > > looks ok. What doesn't look quite right is the "&_ctx" bit. In > > 1.1.0 an > > > EVP_CIPHER_CTX is an opaque type. You cannot allocate concrete > > instances > > > of it directly. > > > > > > Where previously you might have had: > > > > > > EVP_CIPHER_CTX _ctx; > > > > > > EVP_CIPHER_CTX_init(&_ctx); > > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > > > > > > You now need to do: > > > > > > EVP_CIPHER_CTX *_ctx; > > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, NULL); > > > > > > ... > > > EVP_CIPHER_CTX_free(_ctx); > > > > > > > > > I have omitted error checking code for brevity. > > > > > > Matt > > > > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > > > > > After the change I got this error : expected initializer > > before ?evp_gcm? > > > > > > > > What am I doing wrong? > > > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > > Hi, > > > > > > > > > > I'm using EVP_aes_128_gcm and have problem with > > compiling it > > > with > > > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > > > Although I included I got this error : > > error: > > > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > > > > > I'm using CentOS 7.3. > > > > > > > > > > Which file I need to include in order to compile > > > EVP_aes_128_gcm ? > > > > > > > > It's still declared in evp.h: > > > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > > > Perhaps you are not picking up the version of evp.h that > > you think > > > > you are? > > > > > > > > Matt > > > > > > > > -- > > > > openssl-users mailing list > > > > To unsubscribe: > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > Lior Koskas > > > > Software Engineer > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 15:20:52 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 16:20:52 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> Message-ID: <32f3c227-876e-86c5-18a3-75ef0e50b70e@openssl.org> On 03/05/17 16:16, Lior Koskas wrote: > In the same way. This is the first time I'm checking the code on my > CentOS machine. So right at the beginning of this thread you said you were using OpenSSL 1.1.0. How do you know you have that version installed? What does the command "openssl version" report? Matt > > On 3 May 2017 at 18:13, Matt Caswell > wrote: > > > > On 03/05/17 16:10, Lior Koskas wrote: > > I checked the evp.h file in the path /usr/local/include and indeed it's > > not contain any gcm functions. > > I installed openssl via yum install openssl-devel in the past. > > So, how did you install OpenSSL this time? > > Matt > > > > > > On 3 May 2017 at 17:32, Matt Caswell > > >> wrote: > > > > > > > > On 03/05/17 15:19, Lior Koskas wrote: > > > Thank you for your answer. > > > > > > I made all the changes and the code isn't compiling. > > > > > > I'm using cmake in order to build the code. > > > > > > my CMakeLists.txt contains this line in order to include > openssl headers: > > > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ > /usr/local/include/openssl/) > > > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will > install to > > /usr/local, and the headers will be in /usr/local/include. The > final > > "openssl" directory name in the path to the individual header > files > > should not be included in the include directory path. > > > > My guess is that you are picking up the system openssl headers > rather > > than the ones from your 1.1.0 installation. > > > > Most likely this needs to be: > > > > INCLUDE_DIRECTORIES(/usr/local/include) > > > > But it does depend on options that you gave to config when you > compiled > > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > > > > > The constructor of my code is : > > > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const > unsigned char > > > *iv, size_t ivSizeBytes) > > > { > > > // copy the 128-bit key > > > memcpy(_key, key, 16); > > > > > > //copy the iv: > > > EVP_CIPHER_CTX *_ctx; > > > _iv = new unsigned char[ivSizeBytes]; > > > memcpy(_iv, iv, ivSizeBytes); > > > > > > //EVP_CIPHER_CTX_init(&_ctx); > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, > NULL); > > > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, > ivSizeBytes, NULL); > > > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end > too...plus check > > the return values from these function calls for errors. > > > > Matt > > > > > > > > } > > > > > > What I'm missing? > > > > > > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > > > > >>> wrote: > > > > > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > > I viewed the file and the definition exists. > > > > I also checked that I'm picking the correct version. > > > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > > EVP_aes_128_gcm(), > > > > NULL, NULL, NULL); > > > > > > > > I also tried to change the code to this two lines : > > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > > > You have one too many "EVP"'s in there. It should be: > > > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > > > Although, that really shouldn't be necessary and your > original > > version > > > looks ok. What doesn't look quite right is the "&_ctx" > bit. In > > 1.1.0 an > > > EVP_CIPHER_CTX is an opaque type. You cannot allocate > concrete > > instances > > > of it directly. > > > > > > Where previously you might have had: > > > > > > EVP_CIPHER_CTX _ctx; > > > > > > EVP_CIPHER_CTX_init(&_ctx); > > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, > NULL); > > > > > > > > > You now need to do: > > > > > > EVP_CIPHER_CTX *_ctx; > > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, > NULL); > > > > > > ... > > > EVP_CIPHER_CTX_free(_ctx); > > > > > > > > > I have omitted error checking code for brevity. > > > > > > Matt > > > > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > > > > > After the change I got this error : expected initializer > > before ?evp_gcm? > > > > > > > > What am I doing wrong? > > > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > > >> > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > > Hi, > > > > > > > > > > I'm using EVP_aes_128_gcm and have problem with > > compiling it > > > with > > > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > > > Although I included I got this > error : > > error: > > > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > > > > > I'm using CentOS 7.3. > > > > > > > > > > Which file I need to include in order to compile > > > EVP_aes_128_gcm ? > > > > > > > > It's still declared in evp.h: > > > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > > > Perhaps you are not picking up the version of > evp.h that > > you think > > > > you are? > > > > > > > > Matt > > > > > > > > -- > > > > openssl-users mailing list > > > > To unsubscribe: > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > -- > > > > Lior Koskas > > > > Software Engineer > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > Lior Koskas > Software Engineer > > From liork.cryptobiu at gmail.com Wed May 3 15:48:57 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 18:48:57 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: <32f3c227-876e-86c5-18a3-75ef0e50b70e@openssl.org> References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> <32f3c227-876e-86c5-18a3-75ef0e50b70e@openssl.org> Message-ID: This is a little bit weird. The command `openssl version` returns `OpenSSL 0.9.8l 5 Nov 2009.` When I'm running the command `yum install -y openssl-devel` it returns `openssl-1.0.1e-60.el7_3.1.x86_64 already installed and latest version. Nothing to do` On 3 May 2017 at 18:20, Matt Caswell wrote: > > > On 03/05/17 16:16, Lior Koskas wrote: > > In the same way. This is the first time I'm checking the code on my > > CentOS machine. > > So right at the beginning of this thread you said you were using OpenSSL > 1.1.0. How do you know you have that version installed? > > What does the command "openssl version" report? > > Matt > > > > > On 3 May 2017 at 18:13, Matt Caswell > > wrote: > > > > > > > > On 03/05/17 16:10, Lior Koskas wrote: > > > I checked the evp.h file in the path /usr/local/include and indeed > it's > > > not contain any gcm functions. > > > I installed openssl via yum install openssl-devel in the past. > > > > So, how did you install OpenSSL this time? > > > > Matt > > > > > > > > > > On 3 May 2017 at 17:32, Matt Caswell matt at openssl.org> > > > >> wrote: > > > > > > > > > > > > On 03/05/17 15:19, Lior Koskas wrote: > > > > Thank you for your answer. > > > > > > > > I made all the changes and the code isn't compiling. > > > > > > > > I'm using cmake in order to build the code. > > > > > > > > my CMakeLists.txt contains this line in order to include > > openssl headers: > > > > > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ > > /usr/local/include/openssl/) > > > > > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will > > install to > > > /usr/local, and the headers will be in /usr/local/include. The > > final > > > "openssl" directory name in the path to the individual header > > files > > > should not be included in the include directory path. > > > > > > My guess is that you are picking up the system openssl headers > > rather > > > than the ones from your 1.1.0 installation. > > > > > > Most likely this needs to be: > > > > > > INCLUDE_DIRECTORIES(/usr/local/include) > > > > > > But it does depend on options that you gave to config when you > > compiled > > > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > > > > > > > > > The constructor of my code is : > > > > > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const > > unsigned char > > > > *iv, size_t ivSizeBytes) > > > > { > > > > // copy the 128-bit key > > > > memcpy(_key, key, 16); > > > > > > > > //copy the iv: > > > > EVP_CIPHER_CTX *_ctx; > > > > _iv = new unsigned char[ivSizeBytes]; > > > > memcpy(_iv, iv, ivSizeBytes); > > > > > > > > //EVP_CIPHER_CTX_init(&_ctx); > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, > > NULL); > > > > > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, > > ivSizeBytes, NULL); > > > > > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > > > > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end > > too...plus check > > > the return values from these function calls for errors. > > > > > > Matt > > > > > > > > > > > } > > > > > > > > What I'm missing? > > > > > > > > > > > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > > > I viewed the file and the definition exists. > > > > > I also checked that I'm picking the correct version. > > > > > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > > > EVP_aes_128_gcm(), > > > > > NULL, NULL, NULL); > > > > > > > > > > I also tried to change the code to this two lines : > > > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > > > > > You have one too many "EVP"'s in there. It should be: > > > > > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > > > > > Although, that really shouldn't be necessary and your > > original > > > version > > > > looks ok. What doesn't look quite right is the "&_ctx" > > bit. In > > > 1.1.0 an > > > > EVP_CIPHER_CTX is an opaque type. You cannot allocate > > concrete > > > instances > > > > of it directly. > > > > > > > > Where previously you might have had: > > > > > > > > EVP_CIPHER_CTX _ctx; > > > > > > > > EVP_CIPHER_CTX_init(&_ctx); > > > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, NULL, > > NULL); > > > > > > > > > > > > You now need to do: > > > > > > > > EVP_CIPHER_CTX *_ctx; > > > > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, NULL, > > NULL); > > > > > > > > ... > > > > EVP_CIPHER_CTX_free(_ctx); > > > > > > > > > > > > I have omitted error checking code for brevity. > > > > > > > > Matt > > > > > > > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, NULL); > > > > > > > > > > After the change I got this error : expected > initializer > > > before ?evp_gcm? > > > > > > > > > > What am I doing wrong? > > > > > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > > > > > > >> > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > > > Hi, > > > > > > > > > > > > I'm using EVP_aes_128_gcm and have problem with > > > compiling it > > > > with > > > > > > OpenSSL 1.1.0 (earlier versions are compiling). > > > > > > Although I included I got this > > error : > > > error: > > > > > > ?EVP_aes_128_gcm? was not declared in this scope. > > > > > > > > > > > > I'm using CentOS 7.3. > > > > > > > > > > > > Which file I need to include in order to compile > > > > EVP_aes_128_gcm ? > > > > > > > > > > It's still declared in evp.h: > > > > > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > > > > > Perhaps you are not picking up the version of > > evp.h that > > > you think > > > > > you are? > > > > > > > > > > Matt > > > > > > > > > > -- > > > > > openssl-users mailing list > > > > > To unsubscribe: > > > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Lior Koskas > > > > > Software Engineer > > > > > > > > > > > > > > -- > > > > openssl-users mailing list > > > > To unsubscribe: > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > Lior Koskas > > > > Software Engineer > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 3 15:56:13 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 3 May 2017 16:56:13 +0100 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> <32f3c227-876e-86c5-18a3-75ef0e50b70e@openssl.org> Message-ID: On 03/05/17 16:48, Lior Koskas wrote: > This is a little bit weird. > The command `openssl version` returns `OpenSSL 0.9.8l 5 Nov 2009.` > When I'm running the command `yum install -y openssl-devel` it returns > `openssl-1.0.1e-60.el7_3.1.x86_64 already installed and latest > version. Nothing to do` And neither version is OpenSSL 1.1.0!! Most likely you are picking up 0.9.8 headers (version 0.9.8 is ancient and does not support GCM). Version 1.0.1 does support GCM so that would probably work for you if you can figure out where the headers and libraries are installed - although it too is very old. Both versions are out of support from an OpenSSL Project perspective - although your OS vendor may still be supporting them. Matt > > On 3 May 2017 at 18:20, Matt Caswell > wrote: > > > > On 03/05/17 16:16, Lior Koskas wrote: > > In the same way. This is the first time I'm checking the code on my > > CentOS machine. > > So right at the beginning of this thread you said you were using OpenSSL > 1.1.0. How do you know you have that version installed? > > What does the command "openssl version" report? > > Matt > > > > > On 3 May 2017 at 18:13, Matt Caswell > > >> wrote: > > > > > > > > On 03/05/17 16:10, Lior Koskas wrote: > > > I checked the evp.h file in the path /usr/local/include and indeed it's > > > not contain any gcm functions. > > > I installed openssl via yum install openssl-devel in the past. > > > > So, how did you install OpenSSL this time? > > > > Matt > > > > > > > > > > On 3 May 2017 at 17:32, Matt Caswell > > > > > >>> wrote: > > > > > > > > > > > > On 03/05/17 15:19, Lior Koskas wrote: > > > > Thank you for your answer. > > > > > > > > I made all the changes and the code isn't compiling. > > > > > > > > I'm using cmake in order to build the code. > > > > > > > > my CMakeLists.txt contains this line in order to include > > openssl headers: > > > > > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ > > /usr/local/include/openssl/) > > > > > > Where did you install OpenSSL? By default OpenSSL 1.1.0 will > > install to > > > /usr/local, and the headers will be in > /usr/local/include. The > > final > > > "openssl" directory name in the path to the individual > header > > files > > > should not be included in the include directory path. > > > > > > My guess is that you are picking up the system openssl > headers > > rather > > > than the ones from your 1.1.0 installation. > > > > > > Most likely this needs to be: > > > > > > INCLUDE_DIRECTORIES(/usr/local/include) > > > > > > But it does depend on options that you gave to config > when you > > compiled > > > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > > > > > > > > > The constructor of my code is : > > > > > > > > HashEncrypt::HashEncrypt(const unsigned char *key, const > > unsigned char > > > > *iv, size_t ivSizeBytes) > > > > { > > > > // copy the 128-bit key > > > > memcpy(_key, key, 16); > > > > > > > > //copy the iv: > > > > EVP_CIPHER_CTX *_ctx; > > > > _iv = new unsigned char[ivSizeBytes]; > > > > memcpy(_iv, iv, ivSizeBytes); > > > > > > > > //EVP_CIPHER_CTX_init(&_ctx); > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, > NULL, > > NULL); > > > > > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, > > ivSizeBytes, NULL); > > > > > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > > > > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end > > too...plus check > > > the return values from these function calls for errors. > > > > > > Matt > > > > > > > > > > > } > > > > > > > > What I'm missing? > > > > > > > > > > > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > > > > > >> > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > > > I viewed the file and the definition exists. > > > > > I also checked that I'm picking the correct version. > > > > > > > > > > My problem is this line : EVP_EncryptInit_ex(&_ctx, > > > EVP_aes_128_gcm(), > > > > > NULL, NULL, NULL); > > > > > > > > > > I also tried to change the code to this two lines : > > > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > > > > > You have one too many "EVP"'s in there. It should be: > > > > > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > > > > > Although, that really shouldn't be necessary and your > > original > > > version > > > > looks ok. What doesn't look quite right is the "&_ctx" > > bit. In > > > 1.1.0 an > > > > EVP_CIPHER_CTX is an opaque type. You cannot allocate > > concrete > > > instances > > > > of it directly. > > > > > > > > Where previously you might have had: > > > > > > > > EVP_CIPHER_CTX _ctx; > > > > > > > > EVP_CIPHER_CTX_init(&_ctx); > > > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, > NULL, > > NULL); > > > > > > > > > > > > You now need to do: > > > > > > > > EVP_CIPHER_CTX *_ctx; > > > > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, > NULL, > > NULL); > > > > > > > > ... > > > > EVP_CIPHER_CTX_free(_ctx); > > > > > > > > > > > > I have omitted error checking code for brevity. > > > > > > > > Matt > > > > > > > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, > NULL); > > > > > > > > > > After the change I got this error : expected > initializer > > > before ?evp_gcm? > > > > > > > > > > What am I doing wrong? > > > > > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > > > > >> > > > > > > > > >>> > > > > > > > > > >> > > > > > > > > >>>>> wrote: > > > > > > > > > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > > > Hi, > > > > > > > > > > > > I'm using EVP_aes_128_gcm and have problem > with > > > compiling it > > > > with > > > > > > OpenSSL 1.1.0 (earlier versions are > compiling). > > > > > > Although I included I got this > > error : > > > error: > > > > > > ?EVP_aes_128_gcm? was not declared in this > scope. > > > > > > > > > > > > I'm using CentOS 7.3. > > > > > > > > > > > > Which file I need to include in order to > compile > > > > EVP_aes_128_gcm ? > > > > > > > > > > It's still declared in evp.h: > > > > > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > > > > > Perhaps you are not picking up the version of > > evp.h that > > > you think > > > > > you are? > > > > > > > > > > Matt > > > > > > > > > > -- > > > > > openssl-users mailing list > > > > > To unsubscribe: > > > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Lior Koskas > > > > > Software Engineer > > > > > > > > > > > > > > -- > > > > openssl-users mailing list > > > > To unsubscribe: > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > -- > > > > Lior Koskas > > > > Software Engineer > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > >> > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > Lior Koskas > Software Engineer > > From liork.cryptobiu at gmail.com Wed May 3 15:58:42 2017 From: liork.cryptobiu at gmail.com (Lior Koskas) Date: Wed, 3 May 2017 18:58:42 +0300 Subject: [openssl-users] Problem compiling EVP_aes_128_gcm() In-Reply-To: References: <2c15b90a-6afa-8f0c-6693-943b319b7bb7@openssl.org> <77aa570d-46cf-e3da-dc01-ef2e931dd96b@openssl.org> <7eb075f6-916e-2da2-2c07-27ef3f986687@openssl.org> <32f3c227-876e-86c5-18a3-75ef0e50b70e@openssl.org> Message-ID: Thank you very much for your help! I will raised this bug to my vendor support. On 3 May 2017 at 18:56, Matt Caswell wrote: > > > On 03/05/17 16:48, Lior Koskas wrote: > > This is a little bit weird. > > The command `openssl version` returns `OpenSSL 0.9.8l 5 Nov 2009.` > > When I'm running the command `yum install -y openssl-devel` it returns > > `openssl-1.0.1e-60.el7_3.1.x86_64 already installed and latest > > version. Nothing to do` > > And neither version is OpenSSL 1.1.0!! > > Most likely you are picking up 0.9.8 headers (version 0.9.8 is ancient > and does not support GCM). Version 1.0.1 does support GCM so that would > probably work for you if you can figure out where the headers and > libraries are installed - although it too is very old. Both versions are > out of support from an OpenSSL Project perspective - although your OS > vendor may still be supporting them. > > Matt > > > > > On 3 May 2017 at 18:20, Matt Caswell > > wrote: > > > > > > > > On 03/05/17 16:16, Lior Koskas wrote: > > > In the same way. This is the first time I'm checking the code on my > > > CentOS machine. > > > > So right at the beginning of this thread you said you were using > OpenSSL > > 1.1.0. How do you know you have that version installed? > > > > What does the command "openssl version" report? > > > > Matt > > > > > > > > On 3 May 2017 at 18:13, Matt Caswell matt at openssl.org> > > > >> wrote: > > > > > > > > > > > > On 03/05/17 16:10, Lior Koskas wrote: > > > > I checked the evp.h file in the path /usr/local/include and > indeed it's > > > > not contain any gcm functions. > > > > I installed openssl via yum install openssl-devel in the > past. > > > > > > So, how did you install OpenSSL this time? > > > > > > Matt > > > > > > > > > > > > > > On 3 May 2017 at 17:32, Matt Caswell > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 03/05/17 15:19, Lior Koskas wrote: > > > > > Thank you for your answer. > > > > > > > > > > I made all the changes and the code isn't compiling. > > > > > > > > > > I'm using cmake in order to build the code. > > > > > > > > > > my CMakeLists.txt contains this line in order to > include > > > openssl headers: > > > > > > > > > > INCLUDE_DIRECTORIES(/usr/include/openssl/ > > > /usr/local/include/openssl/) > > > > > > > > Where did you install OpenSSL? By default OpenSSL 1.1.0 > will > > > install to > > > > /usr/local, and the headers will be in > > /usr/local/include. The > > > final > > > > "openssl" directory name in the path to the individual > > header > > > files > > > > should not be included in the include directory path. > > > > > > > > My guess is that you are picking up the system openssl > > headers > > > rather > > > > than the ones from your 1.1.0 installation. > > > > > > > > Most likely this needs to be: > > > > > > > > INCLUDE_DIRECTORIES(/usr/local/include) > > > > > > > > But it does depend on options that you gave to config > > when you > > > compiled > > > > OpenSSL (also I don't use cmake so I could be wrong). > > > > > > > > > > > > > > > > > > The constructor of my code is : > > > > > > > > > > HashEncrypt::HashEncrypt(const unsigned char *key, > const > > > unsigned char > > > > > *iv, size_t ivSizeBytes) > > > > > { > > > > > // copy the 128-bit key > > > > > memcpy(_key, key, 16); > > > > > > > > > > //copy the iv: > > > > > EVP_CIPHER_CTX *_ctx; > > > > > _iv = new unsigned char[ivSizeBytes]; > > > > > memcpy(_iv, iv, ivSizeBytes); > > > > > > > > > > //EVP_CIPHER_CTX_init(&_ctx); > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, > > NULL, > > > NULL); > > > > > > > > > > EVP_CIPHER_CTX_ctrl(_ctx, EVP_CTRL_GCM_SET_IVLEN, > > > ivSizeBytes, NULL); > > > > > > > > > > EVP_EncryptInit_ex(_ctx, NULL, NULL, _key, _iv); > > > > > > > > You need a call to EVP_CIPHER_CTX_free(_ctx) at the end > > > too...plus check > > > > the return values from these function calls for errors. > > > > > > > > Matt > > > > > > > > > > > > > > } > > > > > > > > > > What I'm missing? > > > > > > > > > > > > > > > > > > > > > > > > > On 3 May 2017 at 12:57, Matt Caswell > > > > > > > > > > >> > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > > > On 03/05/17 10:33, Lior Koskas wrote: > > > > > > I viewed the file and the definition exists. > > > > > > I also checked that I'm picking the correct > version. > > > > > > > > > > > > My problem is this line : > EVP_EncryptInit_ex(&_ctx, > > > > EVP_aes_128_gcm(), > > > > > > NULL, NULL, NULL); > > > > > > > > > > > > I also tried to change the code to this two > lines : > > > > > > EVP_CIPHER *EVP evp_gcm = EVP_aes_128_gcm(); > > > > > > > > > > You have one too many "EVP"'s in there. It should > be: > > > > > > > > > > const EVP_CIPHER *evp_gcm = EVP_aes_128_gcm(); > > > > > > > > > > Although, that really shouldn't be necessary and > your > > > original > > > > version > > > > > looks ok. What doesn't look quite right is the > "&_ctx" > > > bit. In > > > > 1.1.0 an > > > > > EVP_CIPHER_CTX is an opaque type. You cannot > allocate > > > concrete > > > > instances > > > > > of it directly. > > > > > > > > > > Where previously you might have had: > > > > > > > > > > EVP_CIPHER_CTX _ctx; > > > > > > > > > > EVP_CIPHER_CTX_init(&_ctx); > > > > > EVP_EncryptInit_ex(&_ctx, EVP_aes_128_gcm(), NULL, > > NULL, > > > NULL); > > > > > > > > > > > > > > > You now need to do: > > > > > > > > > > EVP_CIPHER_CTX *_ctx; > > > > > > > > > > _ctx = EVP_CIPHER_CTX_new(); > > > > > EVP_EncryptInit_ex(_ctx, EVP_aes_128_gcm(), NULL, > > NULL, > > > NULL); > > > > > > > > > > ... > > > > > EVP_CIPHER_CTX_free(_ctx); > > > > > > > > > > > > > > > I have omitted error checking code for brevity. > > > > > > > > > > Matt > > > > > > > > > > > > > > > > EVP_EncryptInit_ex(&_ctx, evp_gcm, NULL, NULL, > > NULL); > > > > > > > > > > > > After the change I got this error : expected > > initializer > > > > before ?evp_gcm? > > > > > > > > > > > > What am I doing wrong? > > > > > > > > > > > > On 3 May 2017 at 12:07, Matt Caswell > > > > > > > > > > > > >> > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >> > > > > > > > > > > > > >>>>> wrote: > > > > > > > > > > > > > > > > > > > > > > > > On 03/05/17 09:43, Lior Koskas wrote: > > > > > > > Hi, > > > > > > > > > > > > > > I'm using EVP_aes_128_gcm and have problem > > with > > > > compiling it > > > > > with > > > > > > > OpenSSL 1.1.0 (earlier versions are > > compiling). > > > > > > > Although I included I got > this > > > error : > > > > error: > > > > > > > ?EVP_aes_128_gcm? was not declared in this > > scope. > > > > > > > > > > > > > > I'm using CentOS 7.3. > > > > > > > > > > > > > > Which file I need to include in order to > > compile > > > > > EVP_aes_128_gcm ? > > > > > > > > > > > > It's still declared in evp.h: > > > > > > > > > > > > const EVP_CIPHER *EVP_aes_128_gcm(void); > > > > > > > > > > > > Perhaps you are not picking up the version of > > > evp.h that > > > > you think > > > > > > you are? > > > > > > > > > > > > Matt > > > > > > > > > > > > -- > > > > > > openssl-users mailing list > > > > > > To unsubscribe: > > > > > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >>>> > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > Lior Koskas > > > > > > Software Engineer > > > > > > > > > > > > > > > > > -- > > > > > openssl-users mailing list > > > > > To unsubscribe: > > > > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > Lior Koskas > > > > > Software Engineer > > > > > > > > > > > > > > -- > > > > openssl-users mailing list > > > > To unsubscribe: > > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > >> > > > > > > > > > > > > > > > > > > > > -- > > > > Lior Koskas > > > > Software Engineer > > > > > > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > > > > > > > > > > -- > > > Lior Koskas > > > Software Engineer > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > -- > > Lior Koskas > > Software Engineer > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Lior Koskas Software Engineer -------------- next part -------------- An HTML attachment was scrubbed... URL: From kudzu at tenebras.com Wed May 3 16:09:49 2017 From: kudzu at tenebras.com (Michael Sierchio) Date: Wed, 3 May 2017 09:09:49 -0700 Subject: [openssl-users] Query regarding MSG_NOSIGNAL with SSL_Write In-Reply-To: References: <3525946d-d66b-4748-9ec8-15621f8cb661@openssl.org> Message-ID: On Tue, May 2, 2017 at 8:27 AM, Michael Wojcik < Michael.Wojcik at microfocus.com > wrote: It may be worth noting that nearly all well-written UNIX applications > should set the disposition of SIGPIPE to SIG_IGN. SIGPIPE is a hack. It > exists only to terminate poorly-written programs that could otherwise block > a pipeline. See Bach, *The Design of the UNIX Operating System*; if > memory serves, Bach quotes Dennis Ritchie on this point. SIGPIPE was > introduced because some poorly-written programs did not check the return > code from write.[1] > ... This is excellent advice. In principle, I am in complete agreement. We should not write code that depends on this artifact. We should treat it as deprecated. However ... ;-) It's probably also true that there is a lot of code that depends on it. True to form for "deprecated" - M -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Wed May 3 16:27:34 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 3 May 2017 16:27:34 +0000 Subject: [openssl-users] Regarding SSL_VERIFY_PEER In-Reply-To: <2768A55F-B1AC-42E6-90F4-C271FFEF3CA9@dukhovni.org> References: <2768A55F-B1AC-42E6-90F4-C271FFEF3CA9@dukhovni.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Viktor Dukhovni > Sent: Wednesday, May 03, 2017 06:40 > > For the full verification process see: > > > https://github.com/openssl/openssl/blob/f0ef20bf386b5c37ba5a4ce5c1de9a > 819bbeffb2/crypto/x509/x509_vfy.c#L208 I haven't looked at x509_vfy.c in 1.1.0, but in the 1.0.x code it's fairly involved. When I implemented custom chain validation for a product, I stepped through the code under the debugger for a handful of different cases, to get a better idea of what it was doing. I recommend the exercise for anyone who wants to intervene in OpenSSL's chain validation. My custom validation code uses the OpenSSL validation callback, making some additional checks and allowing some exceptions, based on application configuration. I assume John is doing something similar, and not trying to implement chain validation from scratch. I definitely wouldn't recommend that, given the Byzantine complexity of X.509v3 PKI, unless you really must (e.g. because you want a non-hierarchical PKI topology). Michael Wojcik Distinguished Engineer, Micro Focus From glosterj9 at gmail.com Thu May 4 05:49:29 2017 From: glosterj9 at gmail.com (john gloster) Date: Thu, 4 May 2017 11:19:29 +0530 Subject: [openssl-users] Regarding SSL_VERIFY_PEER In-Reply-To: References: <2768A55F-B1AC-42E6-90F4-C271FFEF3CA9@dukhovni.org> Message-ID: Hi Victor and Michael, Thanks for your respective response. I need to make sure the following validation happens. - subject field in one certificate matches with the issuer field in the subsequent certificate - no duplicate certificate in the chain - basicConstraints : for CA certificate CA must be set to TRUE pathLenConstraints ? checking as per RFC5280; I want to check even to see no CA with pathLen set 0 is Issuer of another CA certificate - validity period check - revocation status check - keyUsage : Eg. to make sure *keyCertSign *indicator set for the CA certificates in the chain - Criticality check - Signature validation As per RFC5280, subjectKeyIdentifier and authorityKeyIdentifier matching is not required to be done by application. Section 4.2.1.2 . ?Applications are not required to verify that key identifiers match when performing certification path validation.? Is it possible to let me know what all from the BULLETED are validated at OpenSSL level? We are using 1.0.2k This helps in saving my time required for debugging. Thanks, John On Wed, May 3, 2017 at 9:57 PM, Michael Wojcik < Michael.Wojcik at microfocus.com> wrote: > > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > > Of Viktor Dukhovni > > Sent: Wednesday, May 03, 2017 06:40 > > > > For the full verification process see: > > > > > > https://github.com/openssl/openssl/blob/f0ef20bf386b5c37ba5a4ce5c1de9a > > 819bbeffb2/crypto/x509/x509_vfy.c#L208 > > I haven't looked at x509_vfy.c in 1.1.0, but in the 1.0.x code it's fairly > involved. When I implemented custom chain validation for a product, I > stepped through the code under the debugger for a handful of different > cases, to get a better idea of what it was doing. I recommend the exercise > for anyone who wants to intervene in OpenSSL's chain validation. > > My custom validation code uses the OpenSSL validation callback, making > some additional checks and allowing some exceptions, based on application > configuration. I assume John is doing something similar, and not trying to > implement chain validation from scratch. I definitely wouldn't recommend > that, given the Byzantine complexity of X.509v3 PKI, unless you really must > (e.g. because you want a non-hierarchical PKI topology). > > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -- > 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 Thu May 4 13:21:39 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 4 May 2017 14:21:39 +0100 Subject: [openssl-users] Using TLS1.3 with OpenSSL Message-ID: <4cb4f07b-0200-8572-429c-bada345f93b4@openssl.org> Hi all OpenSSL 1.1.1, when it is released, will support TLSv1.3 and it will be binary and source compatible with OpenSSL 1.1.0. If your application already supports 1.1.0 then, in theory, all you need to do to support TLSv1.3 is to drop in the new OpenSSL version. However there are various issues that application developers and application deployers need to be aware of. I have written a blog post to cover some of those things. You can read it here: https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ Matt From rec at Rcousins.com Fri May 5 20:31:39 2017 From: rec at Rcousins.com (Robert Cousins) Date: Fri, 5 May 2017 13:31:39 -0700 Subject: [openssl-users] forking server question Message-ID: <7fb5b360-996f-6380-4e24-99a00fca2a32@Rcousins.com> Please excuse what is a simple question: what is the proper way to clean up in the parent and child when writing a forking server using OpenSSL? (I expected this would be a FAQ, but I couldn't find it.) I have code which works, but I have the nagging feeling that I'm leaking on the parent side. Here is my main program: int main(int argc, char *argv[]) { BIO *acc; SSL_CTX *ctx; install_sigchld(); /* Install signal handlers */ init_OpenSSL( ); /* Initialize library, RNG, etc. */ ctx = setup_server_ctx( ); /* Build Context */ if (!(acc = BIO_new_accept(PORT))) /* Get ready for connection */ int_error("Error creating server socket"); if (BIO_do_accept(acc) <= 0) /* Bind to socket */ int_error("Error binding server socket"); while (1) { SSL *ssl; int fd = -1; if (BIO_do_accept(acc) <= 0) /* Accept the connection */ int_error("Error accepting connection"); BIO *client = BIO_pop(acc); /* get the client off BIO */ switch (fork()) { case -1: err(1,"Fork failed"); /* error */ default: /* parent */ BIO_get_fd(client,&fd); /* close the socket on parent side */ close(fd); break; case 0: /* child */ if (!(ssl = SSL_new(ctx))) /* create new context */ int_error("Error creating SSL context"); SSL_set_accept_state(ssl); SSL_set_bio(ssl, client, client); do_work(ssl); /* go do some work */ exit(0); /* leave (we'll get sigchld) */ } } SSL_CTX_free(ctx); BIO_free(acc); return 0; } From Matthias.Ballreich at outlook.de Thu May 4 08:41:15 2017 From: Matthias.Ballreich at outlook.de (Matthias Ballreich) Date: Thu, 4 May 2017 08:41:15 +0000 Subject: [openssl-users] QcStatements with OpenSSL (C++)? In-Reply-To: <59d55785-d018-9d91-9793-9c3a0983034f@rustichelli.net> References: , <59d55785-d018-9d91-9793-9c3a0983034f@rustichelli.net> Message-ID: thanks :) But can you explain how i got the concrete data like QCStatement? Because there is no defined structure in OpenSSL like for example CRLDistributionPoints. So which structure and functions i have to use, to get the matching data? QCStatement ::= SEQUENCE { statementId QC-STATEMENT.&Id({SupportedStatements}), statementInfo QC-STATEMENT.&Type ({SupportedStatements}{@statementId}) OPTIONAL } thanks again! ________________________________ Von: openssl-users im Auftrag von lists Gesendet: Mittwoch, 26. April 2017 17:06:58 An: openssl-users at openssl.org Betreff: Re: [openssl-users] QcStatements with OpenSSL (C++)? On 04/17/2017 06:40 PM, Matthias Ballreich wrote: Hi there, can OpenSSL pasre QcStatement X509v3 Extension btw. Did OpenSSL Support these? Any Piece of example Code of how can i parse the data? To my knowledge, there is direct support for the qcStatements, you must parse it yourself. I asked for some help on the list more or less a month ago, I was trying to develop the required structures but apparently I got lost in the OpenSSL macro jungle, finally I had to quit working on it. What you can do is search for specific statements of interest to you (there are quite a bit) by parsing the attribute. Get the attribute NID of the object in the extension and see if it matches the NID of qcStatements: oneObj = X509_EXTENSION_get_object(oneExt); objnid = OBJ_obj2nid(theObj); if (objnid == NID_qcStatements) { printf("DEBUG:ext:GOTCHA!:this is qcStatements!\n"); } you then extract the data from the object and parse it. For the moment I have this ugly quick way of doing it, for instance for a simple one: #define UC_id_etsi_qcs_QcCompliance "0.4.0.1862.1.1" if (strstr(extdump, UC_id_etsi_qcs_QcCompliance) == NULL) { printf("INFO:QcCompliance:no:\n"); } else { printf("INFO:QcCompliance:yes:\n"); } Thanks Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat May 6 12:19:42 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 6 May 2017 12:19:42 +0000 Subject: [openssl-users] forking server question In-Reply-To: <7fb5b360-996f-6380-4e24-99a00fca2a32@Rcousins.com> References: <7fb5b360-996f-6380-4e24-99a00fca2a32@Rcousins.com> Message-ID: > Please excuse what is a simple question: what is the proper way to clean up > in the parent and child when writing a forking server using OpenSSL? It's not simple. Can you have the parent just do socket stuff, and then accept/fork and have the child do all the OpenSSL calls? Having two processes, both with OpenSSL state, are going to be hard to handle. From stiju.easo at gmail.com Sun May 7 18:10:19 2017 From: stiju.easo at gmail.com (Stiju Easo) Date: Sun, 7 May 2017 23:40:19 +0530 Subject: [openssl-users] Doubt regarding ExtendedMasterSecret In-Reply-To: References: Message-ID: On Tue, May 2, 2017 at 2:10 PM, Matt Caswell wrote: > > > On 30/04/17 19:51, Stiju Easo wrote: > > Hi , > > > > I got the answer to this, and now the question looks bit stupid. > > Generation of master key is different in case of "Extended Master > > Secret" , > > > > I still have a doubt, what would be the contents in SSL* > > s->s3->handshake_buffer? > > I need to manually set this for my tool, i assume it holds both > > client and server handshakes, am i right? > > > > > > if i am right , in openssl , i just need to populate > > s3->handshake_buffer and set flags to s->session->flags & > > SSL_SESS_FLAG_EXTMS. > > only unknown thing i have is s3->handshake_buffer , what value to > > copy there. > > handshake_buffer is a mem BIO that contains a copy of all the handshake > messages sent and received so far - but only sometimes. Dependant on how > the handshake proceeds sometimes this buffer stays active for a while. > Other times it gets released early and instead we keep a rolling hash of > the handshake messages. > as per my understanding, if I set Handshake_buffer with all SSL3_RT_HANDSHAKE, it should work, right? I had gone through RFC's regarding this, there is no clear statement regarding what is included. I assume everything from CLIENT HELLO to FINISHED. I had verified implementation in Wireshark, they generate Extended master secret by hashing all handshakes. > > The problem is your code is reaching right into the internals of libssl > and playing around with the internal state. In OpenSSL 1.1.0 you will be > unable to do that (the SSL struct is opaque). > This is hurting me, right now. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Stiju Easo The unexamined life is not worth living for man. Socrates, in Plato, Dialogues, Apology Greek philosopher in Athens (469 BC - 399 BC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Sun May 7 18:22:04 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sun, 7 May 2017 20:22:04 +0200 Subject: [openssl-users] forking server question In-Reply-To: References: <7fb5b360-996f-6380-4e24-99a00fca2a32@Rcousins.com> Message-ID: <98542c7b-771d-5d55-01ca-41a797f3d062@wisemo.com> On 06/05/2017 14:19, Salz, Rich via openssl-users wrote: >> Please excuse what is a simple question: what is the proper way to clean up >> in the parent and child when writing a forking server using OpenSSL? > It's not simple. > > Can you have the parent just do socket stuff, and then accept/fork and have the child do all the OpenSSL calls? That would violate best security practice regarding chroot() calls and loading of private keys. (Because the secure sequence is load private keys (possibly with one-time external decryption assistance), bind to privileged port (such as 443 or 25), chroot/drop all privileges, accept connection, fork(), handshake, data exchange). Things become even more complicated if a program wants to do a second level of per message privilege drops, as seen in the exim4 mail server. > > Having two processes, both with OpenSSL state, are going to be hard to handle. > > Make that N processes, and understand why this should be a FAQ. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 Soborg, 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 rsalz at akamai.com Sun May 7 22:16:53 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 7 May 2017 22:16:53 +0000 Subject: [openssl-users] forking server question In-Reply-To: <98542c7b-771d-5d55-01ca-41a797f3d062@wisemo.com> References: <7fb5b360-996f-6380-4e24-99a00fca2a32@Rcousins.com> <98542c7b-771d-5d55-01ca-41a797f3d062@wisemo.com> Message-ID: > Make that N processes, and understand why this should be a FAQ. Have no problem with adding to the FAQ. It's likely to be our next code-health target :) From matt at openssl.org Mon May 8 07:48:56 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 8 May 2017 08:48:56 +0100 Subject: [openssl-users] Doubt regarding ExtendedMasterSecret In-Reply-To: References: Message-ID: <8395241d-80af-58a6-0dde-afb542b515f2@openssl.org> On 07/05/17 19:10, Stiju Easo wrote: > On Tue, May 2, 2017 at 2:10 PM, Matt Caswell > wrote: > > > > On 30/04/17 19:51, Stiju Easo wrote: > > Hi , > > > > I got the answer to this, and now the question looks bit stupid. > > Generation of master key is different in case of "Extended Master > > Secret" , > > > > I still have a doubt, what would be the contents in SSL* > > s->s3->handshake_buffer? > > I need to manually set this for my tool, i assume it holds both > > client and server handshakes, am i right? > > > > > > if i am right , in openssl , i just need to populate > > s3->handshake_buffer and set flags to s->session->flags & > > SSL_SESS_FLAG_EXTMS. > > only unknown thing i have is s3->handshake_buffer , what value to > > copy there. > > handshake_buffer is a mem BIO that contains a copy of all the handshake > messages sent and received so far - but only sometimes. Dependant on how > the handshake proceeds sometimes this buffer stays active for a while. > Other times it gets released early and instead we keep a rolling hash of > the handshake messages. > > > as per my understanding, if I set Handshake_buffer with all > SSL3_RT_HANDSHAKE, it should work, right? > I had gone through RFC's regarding this, there is no clear statement > regarding what is included. > I assume everything from CLIENT HELLO to FINISHED. Yeah, that should probably work, although most likely you would be keeping it beyond the point that is necessary. Typically the handshake_buffer gets freed mid-handshake when we no longer need it (and we swap to a rolling hash instead). You'd have to read the code to understand the precise details of that. I'm not sure if there would be ill effects to having it set up longer than necessary. Either way, you are "voiding your warranty" by playing around with this stuff. Matt > > I had verified implementation in Wireshark, they generate > Extended master secret by hashing all handshakes. > > > The problem is your code is reaching right into the internals of libssl > and playing around with the internal state. In OpenSSL 1.1.0 you will be > unable to do that (the SSL struct is opaque). > > > This is hurting me, right now. > > > > Matt > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > > Stiju Easo > > > The unexamined life is not worth living for man. > Socrates, in Plato, Dialogues, Apology > Greek philosopher in Athens (469 BC - 399 BC) > > > From harakiri_23 at yahoo.com Mon May 8 08:48:20 2017 From: harakiri_23 at yahoo.com (Harakiri) Date: Mon, 8 May 2017 08:48:20 +0000 (UTC) Subject: [openssl-users] Some S/MIME CMS encrypted messages produce invalid key length when using the debug_decrypt option References: <1255095675.2660197.1494233300987.ref@mail.yahoo.com> Message-ID: <1255095675.2660197.1494233300987@mail.yahoo.com> Im using the cmd client openssl cms -decrypt with the "debug_decrypt" option to have the same behaviour as before the bleichenbach security patch to use decryption without recipient public keys. For some reason, some messages will produce the following error on?OpenSSL 1.0.2d and even OpenSSL 1.0.2k Error decrypting CMS structure6828:error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length:evp_enc.c:593:6828:error:2E078076:CMS routines:cms_EncryptedContent_init_bio:invalid key length:cms_enc.c:163: Calling cms -decrypt without the debug_decrypt option produces no error. What is weird, is that its always basically the same source e-mail encrypted using openssl cms with?aes-128-cbc and?rsaesOaep and sometimes the resulting messagewill produce this error and other times it works. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Mon May 8 23:04:34 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 8 May 2017 23:04:34 +0000 Subject: [openssl-users] Some S/MIME CMS encrypted messages produce invalid key length when using the debug_decrypt option In-Reply-To: <1255095675.2660197.1494233300987@mail.yahoo.com> References: <1255095675.2660197.1494233300987.ref@mail.yahoo.com> <1255095675.2660197.1494233300987@mail.yahoo.com> Message-ID: <20170508230434.GA18897@openssl.org> On Mon, May 08, 2017, Harakiri via openssl-users wrote: > Im using the cmd client openssl cms -decrypt with the "debug_decrypt" option to have the same behaviour as before the bleichenbach security patch to use decryption without recipient public keys. > For some reason, some messages will produce the following error on?OpenSSL 1.0.2d and even OpenSSL 1.0.2k > Error decrypting CMS structure6828:error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length:evp_enc.c:593:6828:error:2E078076:CMS routines:cms_EncryptedContent_init_bio:invalid key length:cms_enc.c:163: > Calling cms -decrypt without the debug_decrypt option produces no error. > What is weird, is that its always basically the same source e-mail encrypted using openssl cms with?aes-128-cbc and?rsaesOaep and sometimes the resulting messagewill produce this error and other times it works. > > That's odd. What command line are you using to create the messages? Would it be possible to create a test case that reproduces this error? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From Matthias.Ballreich at outlook.de Tue May 9 07:17:31 2017 From: Matthias.Ballreich at outlook.de (Matthias Ballreich) Date: Tue, 9 May 2017 07:17:31 +0000 Subject: [openssl-users] C++ How to parse Subject Directory Attributes Extension? In-Reply-To: References: Message-ID: Here are nor some more details, which may help you to better understand. My Certificate contains the SubjectDirectoryAttributes-Extension with the following Attributes: OID : Value ------------------------------------------------------------------- (1.3.6.1.5.5.7.9.4) countryOfCitizenship : DE (1.3.6.1.5.5.7.9.3) gender : F (1.3.6.1.5.5.7.9.1) dateOfBirth : 1971-10-14 12:00:00 UTC (1.3.6.1.5.5.7.9.2) placeOfBirth : Darmstadt So i want to get these pairs of OID and Value. I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can use. I got the Extension this way: int loc = X509_get_ext_by_NID(certificate, NID_subject_directory_attributes, -1); X509_EXTENSION *ex = X509_get_ext(certificate, loc); But how can i get then all the data, which means all the OIDs and Values to the OIDs? The ASN.1 Structure is: SubjectDirectoryAttributes ::= Attributes Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute Attribute ::= SEQUENCE { type AttributeType values SET OF AttributeValue } AttributeType ::= OBJECT IDENTIFIER AttributeValue ::= ANY DEFINED BY AttributeType I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY). Then i tried to get the number of attributes by calling the sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. X509_NAME.entries, but i got not the right number. I expect to get the number 3 or 4 (don't know the exactly internal counting - but the example cert contains 4 Attributes, so the output should be 3 or 4 depending if the counting will start at 0 or 1). But instead of 3 or 4 i got a much larger number like 34335029 and this number is different every time i run the code. So i think there is a problem with the casting or i did not choose the right Data-Type(s). I'm using OpenSSL 1.0.2j. So what's wrong and how can i fix it? - Thanks in advice! Here a short excerpt of my code: X509_EXTENSION *ex = .... STACK_OF(X509_NAME_ENTRY) *st = (STACK_OF(X509_NAME_ENTRY)*) X509_EXTENSION_get_data(ex); printf(sk_X509_NAME_ENTRY_num(st)); // or alternative X509_Name *name = (X509_Name*) X509_EXTENSION_get_data(ex); printf(sk_X509_NAME_ENTRY_num(name.entries)); Here i append the certificate if you need it. It's from the RFC specification: -----BEGIN CERTIFICATE----- MIIDEDCCAnmgAwIBAgIESZYC0jANBgkqhkiG9w0BAQUFADBIMQswCQYDVQQGEwJE RTE5MDcGA1UECgwwR01EIC0gRm9yc2NodW5nc3plbnRydW0gSW5mb3JtYXRpb25z dGVjaG5payBHbWJIMB4XDTA0MDIwMTEwMDAwMFoXDTA4MDIwMTEwMDAwMFowZTEL MAkGA1UEBhMCREUxNzA1BgNVBAoMLkdNRCBGb3JzY2h1bmdzemVudHJ1bSBJbmZv cm1hdGlvbnN0ZWNobmlrIEdtYkgxHTAMBgNVBCoMBVBldHJhMA0GA1UEBAwGQmFy emluMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDc50zVodVa6wHPXswg88P8 p4fPy1caIaqKIK1d/wFRMN5yTl7T+VOS57sWxKcdDzGzqZJqjwjqAP3DqPK7AW3s o7lBG6JZmiqMtlXG3+olv+3cc7WU+qDv5ZXGEqauW4x/DKGc7E/nq2BUZ2hLsjh9 Xy9+vbw+8KYE9rQEARdpJQIDAQABo4HpMIHmMGQGA1UdCQRdMFswEAYIKwYBBQUH CQQxBBMCREUwDwYIKwYBBQUHCQMxAxMBRjAdBggrBgEFBQcJATERGA8xOTcxMTAx NDEyMDAwMFowFwYIKwYBBQUHCQIxCwwJRGFybXN0YWR0MA4GA1UdDwEB/wQEAwIG QDASBgNVHSAECzAJMAcGBSskCAEBMB8GA1UdIwQYMBaAFAABAgMEBQYHCAkKCwwN Dg/+3LqYMDkGCCsGAQUFBwEDBC0wKzApBggrBgEFBQcLAjAdMBuBGW11bmljaXBh bGl0eUBkYXJtc3RhZHQuZGUwDQYJKoZIhvcNAQEFBQADgYEAj4yAu7LYa3X04h+C 7+DyD2xViJCm5zEYg1m5x4znHJIMZsYAU/vJJIJQkPKVsIgm6vP/H1kXyAu0g2Ep z+VWPnhZK1uw+ay1KRXw8rw2mR8hQ2Ug6QZHYdky2HH3H/69rWSPp888G8CW8RLU uIKzn+GhapCuGoC4qWdlGLWqfpc= -----END CERTIFICATE----- ________________________________ Von: Matthias Ballreich Gesendet: Sonntag, 30. April 2017 13:44:48 An: openssl-users at openssl.org Betreff: C++ How to parse Subject Directory Attributes Extension? Hi there, can anyone tell me how to parse a the Subject Directory Attribute Extension of a X509-Certificate in C++ with OpenSSL? I don't found any documentation or piece of code in the Github Repo of OpenSSL. I read the Extension this way: int loc = X509_get_ext_by_NID(cert, NID_subject_directory_attributes, -1); X509_EXTENSION *ex = X509_get_ext(cert, loc); But i stuck on how to continue and get the TypeValue-Stuff. Would be very helpful if someone can help me. thanks and best regards Matthias -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue May 9 13:54:33 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 May 2017 13:54:33 +0000 Subject: [openssl-users] C++ How to parse Subject Directory Attributes Extension? In-Reply-To: References: Message-ID: <9f245964140b4ef38c7dfc2364fb3780@usma1ex-dag1mb1.msg.corp.akamai.com> That attribute is not currently supported. Someone would have to write ASN1 parsing code. There are examples all over the place within OpenSSL; see the various d2i_XXX and i2d_XXX functions. There are macro/define?s available to make the job easier. But, it is not really documented. Maybe there are other people here who are interested, and could write the code and make a pull request on GitHub. I doubt the team will get to it quickly. Sorry, but I just want to be realistic. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue May 9 16:05:45 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 9 May 2017 16:05:45 +0000 Subject: [openssl-users] C++ How to parse Subject Directory Attributes Extension? In-Reply-To: References: Message-ID: <20170509160545.GA31570@openssl.org> On Tue, May 09, 2017, Matthias Ballreich wrote: > Here are nor some more details, which may help you to better understand. > > > My Certificate contains the SubjectDirectoryAttributes-Extension with the following Attributes: > > OID : Value > ------------------------------------------------------------------- > (1.3.6.1.5.5.7.9.4) countryOfCitizenship : DE > (1.3.6.1.5.5.7.9.3) gender : F > (1.3.6.1.5.5.7.9.1) dateOfBirth : 1971-10-14 12:00:00 UTC > (1.3.6.1.5.5.7.9.2) placeOfBirth : Darmstadt > > So i want to get these pairs of OID and Value. > > I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can use. I got the Extension this way: > > int loc = X509_get_ext_by_NID(certificate, NID_subject_directory_attributes, -1); > X509_EXTENSION *ex = X509_get_ext(certificate, loc); > > But how can i get then all the data, which means all the OIDs and Values to the OIDs? The ASN.1 Structure is: > > SubjectDirectoryAttributes ::= Attributes > > Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute > > Attribute ::= SEQUENCE > { > type AttributeType > values SET OF AttributeValue > } > > AttributeType ::= OBJECT IDENTIFIER > AttributeValue ::= ANY DEFINED BY AttributeType > > I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY). > > Then i tried to get the number of attributes by calling the sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. X509_NAME.entries, but i got not the right number. I expect to get the number 3 or 4 (don't know the exactly internal counting - but the example cert contains 4 Attributes, so the output should be 3 or 4 depending if the counting will start at 0 or 1). But instead of 3 or 4 i got a much larger number like 34335029 and this number is different every time i run the code. So i think there is a problem with the casting or i did not choose the right Data-Type(s). > > I'm using OpenSSL 1.0.2j. > > So what's wrong and how can i fix it? - Thanks in advice! > Looks like the type isn't X509_NAME_ENTRY but X509_ATTRIBUTE and the extension is a SEQUENCE OF Attribute. We don't have the direct equivalent as a specific type IIRC but it isn't hard to add one just follow what is done for GENERAL_NAMES which is a SEQUENCE OF GENERAL_NAME. You can either add a custom extension or just parse the structure from the extentsion contents. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From Matthias.Ballreich at outlook.de Tue May 9 16:10:14 2017 From: Matthias.Ballreich at outlook.de (Matthias Ballreich) Date: Tue, 9 May 2017 16:10:14 +0000 Subject: [openssl-users] C++ How to parse Subject Directory Attributes Extension? In-Reply-To: <20170509160545.GA31570@openssl.org> References: <20170509160545.GA31570@openssl.org> Message-ID: I will take a look on it. Thanks. Can you explain it a little bit more what you mean with "You can either add a custom extension or just parse the structure from the extentsion contents." ? -----Urspr?ngliche Nachricht----- Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Dr. Stephen Henson Gesendet: Dienstag, 9. Mai 2017 18:06 An: openssl-users at openssl.org Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension? On Tue, May 09, 2017, Matthias Ballreich wrote: > Here are nor some more details, which may help you to better understand. > > > My Certificate contains the SubjectDirectoryAttributes-Extension with the following Attributes: > > OID : Value > ------------------------------------------------------------------- > (1.3.6.1.5.5.7.9.4) countryOfCitizenship : DE > (1.3.6.1.5.5.7.9.3) gender : F > (1.3.6.1.5.5.7.9.1) dateOfBirth : 1971-10-14 12:00:00 UTC > (1.3.6.1.5.5.7.9.2) placeOfBirth : Darmstadt > > So i want to get these pairs of OID and Value. > > I found no Struct like SUBJECT_DIRECTORY_ATTRIBUTES in the Source-Code i can use. I got the Extension this way: > > int loc = X509_get_ext_by_NID(certificate, > NID_subject_directory_attributes, -1); X509_EXTENSION *ex = > X509_get_ext(certificate, loc); > > But how can i get then all the data, which means all the OIDs and Values to the OIDs? The ASN.1 Structure is: > > SubjectDirectoryAttributes ::= Attributes > > Attributes ::= SEQUENCE SIZE (1..MAX) OF Attribute > > Attribute ::= SEQUENCE > { > type AttributeType > values SET OF AttributeValue > } > > AttributeType ::= OBJECT IDENTIFIER > AttributeValue ::= ANY DEFINED BY AttributeType > > I found out that i get a custom extension with: X509_EXTENSION_get_object(ex) and that the OpenSSL-Type X509_NAME_ENTRY is the equvivalent to the ASN.1-Structure Attribute resp. AttributeTypeAndValue. So i tried to cast the result of X509_EXTENSION_get_data(ex) to a STACK_OF(X509_NAME_ENTRY) and to X509_NAME. But X509_NAME is the same as STACK_OF(X509_NAME_ENTRY). > > Then i tried to get the number of attributes by calling the sk_X509_NAME_ENTRY_num() function on the STACK_OF(X509_NAME_ENTRY) resp. X509_NAME.entries, but i got not the right number. I expect to get the number 3 or 4 (don't know the exactly internal counting - but the example cert contains 4 Attributes, so the output should be 3 or 4 depending if the counting will start at 0 or 1). But instead of 3 or 4 i got a much larger number like 34335029 and this number is different every time i run the code. So i think there is a problem with the casting or i did not choose the right Data-Type(s). > > I'm using OpenSSL 1.0.2j. > > So what's wrong and how can i fix it? - Thanks in advice! > Looks like the type isn't X509_NAME_ENTRY but X509_ATTRIBUTE and the extension is a SEQUENCE OF Attribute. We don't have the direct equivalent as a specific type IIRC but it isn't hard to add one just follow what is done for GENERAL_NAMES which is a SEQUENCE OF GENERAL_NAME. You can either add a custom extension or just parse the structure from the extentsion contents. 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 Matthias.Ballreich at outlook.de Tue May 9 16:01:54 2017 From: Matthias.Ballreich at outlook.de (Matthias Ballreich) Date: Tue, 9 May 2017 16:01:54 +0000 Subject: [openssl-users] C++ How to parse Subject Directory Attributes Extension? In-Reply-To: <9f245964140b4ef38c7dfc2364fb3780@usma1ex-dag1mb1.msg.corp.akamai.com> References: <9f245964140b4ef38c7dfc2364fb3780@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Thanks for reply. Ohh that's bad news. So I have will look at the various d2i_XXX and i2d_XXX functions you mentioned. Von: openssl-users [mailto:openssl-users-bounces at openssl.org] Im Auftrag von Salz, Rich via openssl-users Gesendet: Dienstag, 9. Mai 2017 15:55 An: openssl-users at openssl.org Betreff: Re: [openssl-users] C++ How to parse Subject Directory Attributes Extension? That attribute is not currently supported. Someone would have to write ASN1 parsing code. There are examples all over the place within OpenSSL; see the various d2i_XXX and i2d_XXX functions. There are macro/define's available to make the job easier. But, it is not really documented. Maybe there are other people here who are interested, and could write the code and make a pull request on GitHub. I doubt the team will get to it quickly. Sorry, but I just want to be realistic. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanumesh at in.ibm.com Wed May 10 07:02:28 2017 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Wed, 10 May 2017 12:32:28 +0530 Subject: [openssl-users] Using TLS1.3 with OpenSSL In-Reply-To: <4cb4f07b-0200-8572-429c-bada345f93b4@openssl.org> References: <4cb4f07b-0200-8572-429c-bada345f93b4@openssl.org> Message-ID: Hello Matt Are you planning to provide TLSv1.3 support for openSSL 1.0.2 version ? Thanks Sandeep From: Matt Caswell To: "openssl-users at openssl.org" , "openssl-dev at openssl.org" Date: 05/04/2017 06:52 PM Subject: [openssl-users] Using TLS1.3 with OpenSSL Sent by: "openssl-users" Hi all OpenSSL 1.1.1, when it is released, will support TLSv1.3 and it will be binary and source compatible with OpenSSL 1.1.0. If your application already supports 1.1.0 then, in theory, all you need to do to support TLSv1.3 is to drop in the new OpenSSL version. However there are various issues that application developers and application deployers need to be aware of. I have written a blog post to cover some of those things. You can read it here: https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From matt at openssl.org Wed May 10 07:52:28 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 10 May 2017 08:52:28 +0100 Subject: [openssl-users] Using TLS1.3 with OpenSSL In-Reply-To: References: <4cb4f07b-0200-8572-429c-bada345f93b4@openssl.org> Message-ID: On 10/05/17 08:02, Sandeep Umesh wrote: > Hello Matt > > Are you planning to provide TLSv1.3 support for openSSL 1.0.2 version ? No. 1.0.2 is a stable release which only receives security and other bug fixes - not new features (such as TLSv1.3). New features always go into new releases. Matt > > Thanks > Sandeep > > > Inactive hide details for Matt Caswell ---05/04/2017 06:52:28 PM---Hi > all OpenSSL 1.1.1, when it is released, will support TLSvMatt Caswell > ---05/04/2017 06:52:28 PM---Hi all OpenSSL 1.1.1, when it is released, > will support TLSv1.3 and it will be > > From: Matt Caswell > To: "openssl-users at openssl.org" , > "openssl-dev at openssl.org" > Date: 05/04/2017 06:52 PM > Subject: [openssl-users] Using TLS1.3 with OpenSSL > Sent by: "openssl-users" > > ------------------------------------------------------------------------ > > > > Hi all > > OpenSSL 1.1.1, when it is released, will support TLSv1.3 and it will be > binary and source compatible with OpenSSL 1.1.0. If your application > already supports 1.1.0 then, in theory, all you need to do to support > TLSv1.3 is to drop in the new OpenSSL version. However there are various > issues that application developers and application deployers need to be > aware of. I have written a blog post to cover some of those things. You > can read it here: > > https://www.openssl.org/blog/blog/2017/05/04/tlsv1.3/ > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From hrf-ssl at itg.hitachi.co.jp Wed May 10 07:55:41 2017 From: hrf-ssl at itg.hitachi.co.jp (=?iso-2022-jp?B?GyRCNiZETDRwSFcjUyNTI0whTjZITDMjSSNEIU8bKEIgLyBDT01NT05T?= =?iso-2022-jp?B?U0wbJEIhJBsoQkdZT1VNVQ==?=) Date: Wed, 10 May 2017 07:55:41 +0000 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems Message-ID: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> Hello, I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. But, there is not yet the machine for build, so I cannot do actual machine verification. The CPU is not Intel architecture, is probably z/Architecture. I want to know beforehand the appropriate command-line parameters for executing "Configure". Is it right to specify "linux64-s390x" as follows? (1)cd //openssl-1.0.2k (2)./Configure linux64-s390x Thanks in advance. Regards, Manabu -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhilashkv at gmail.com Wed May 10 12:26:38 2017 From: abhilashkv at gmail.com (Abhilash K.V) Date: Wed, 10 May 2017 16:26:38 +0400 Subject: [openssl-users] Regarding pkcs_9_at_signingDescription(1.2.840.113549.1.9.13) Message-ID: Hello, Whats the equivalant of *pkcs_9_at_signingDescription in openssl C version ?* Thanks, Abhilash. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mariem.mhiri at outlook.com Wed May 10 12:31:25 2017 From: mariem.mhiri at outlook.com (Openssl.User) Date: Wed, 10 May 2017 05:31:25 -0700 (MST) Subject: [openssl-users] Openssl-1.0.2h failed compilation Message-ID: <1494419485842-70737.post@n7.nabble.com> Hello, I try to cross-compile openssl-1.02h on ARM. First, I set the environment variable: export ARCH=arm64 export CROSS_COMPILE=aarch64-poky-linux- Then I configured it: ./config shared --prefix=/opt/poky/aarch64-poky-linux/usr When I do make I have the following error: aarch64-poky-linux-gcc: error: unrecognized command line option '-m64' : recipe for target 'cryptlib.o' failed make[1]: *** [cryptlib.o] Error 1 make[1]: Leaving directory '/opt/poky/libssl1.0.2/openssl-1.0.2h/crypto' Makefile:285: recipe for target 'build_crypto' failed make: *** [build_crypto] Error 1 How can I fix this problem? -- View this message in context: http://openssl.6102.n7.nabble.com/Openssl-1-0-2h-failed-compilation-tp70737.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Wed May 10 12:46:55 2017 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 May 2017 12:46:55 +0000 Subject: [openssl-users] Regarding pkcs_9_at_signingDescription(1.2.840.113549.1.9.13) In-Reply-To: References: Message-ID: <6cc31ee956b843a381dc0430e9e416a3@usma1ex-dag1mb1.msg.corp.akamai.com> Doesn?t seem to be supported in openssl. Whats the equivalant of pkcs_9_at_signingDescription in openssl C version ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rpo at compumatica.com Thu May 11 09:33:52 2017 From: rpo at compumatica.com (RudyAC) Date: Thu, 11 May 2017 02:33:52 -0700 (MST) Subject: [openssl-users] RSA_PKCS1_OAEP_PADDING Message-ID: <1494495232360-70741.post@n7.nabble.com> Hello, I have the requirement to encrypt e-mails using RSA-OAEP padding. I use the library openssl-1.0.2k and encrypt with CMS container. The following function describes my method. My problem is that I'm not sure if this method really uses the RSA-OAEP padding. bool smime_encrypt_cms(const std::string& infile, const std::string& outfile) { bool bResult = false; const char* inmode = "r"; const char* outmode = "w"; const EVP_CIPHER* cipher = NULL; STACK_OF(X509)* encerts = NULL; BIO* in = NULL; BIO* out = NULL; BIO* bio_err = NULL; int flags = 0; X509 *recip; int i = 0; unsigned char *oaep_label = NULL; int oaep_label_l = 0; int nflags = CMS_PARTIAL | CMS_KEY_PARAM; CMS_ContentInfo* cms = CMS_encrypt(NULL, NULL, cipher, nflags); EVP_PKEY_CTX* wrap_ctx = NULL; KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () started" ); cipher = get_cipher(); SMTPD_RAND_load_file ( NULL , bio_err , 0 ); encerts = sk_X509_new_null(); FOR_CONST_IT(EmailAndCertList, itRecip, _m_recipCertsList) { SMIME_key_list recip_encerts = (*itRecip)->smime_enc(); FOR_CONST_IT(SMIME_key_list, iter, recip_encerts) { sk_X509_push( encerts, (*iter).dup_cert()); } } if ( ! ( in = BIO_new_file ( infile.c_str() , inmode ))) { KWlog_appl ( EV_E_APPL_INFO , "Can't open input file %s", infile.c_str() ); _error_messages.push_back("Internal Error"); goto exit; } if ( ! ( out = BIO_new_file ( outfile.c_str() , outmode ))) { KWlog_appl ( EV_E_APPL_INFO , "Can't open output file %s", outfile.c_str() ); _error_messages.push_back("Internal Error"); goto exit; } for (i = 0; i < sk_X509_num(encerts); i++) { CMS_RecipientInfo* r_info; recip = sk_X509_value(encerts, i); r_info = CMS_add1_recipient_cert(cms, recip, nflags); if (!r_info) { KWlog_appl(EV_E_APPL_INFO, "smime_encrypt_cms(): Error while adding recipient certs to CMS info structure"); return false; } wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info); KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () Set OAEP Padding"); EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING); EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256()); EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256()); EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l); } CMS_final(cms, in, NULL, nflags); /* encrypt content */ cms = CMS_encrypt(encerts, in, cipher, flags); if( ! cms ) { KWlog ( EV_E_APPL_INFO , "Error creating CMS structure"); KWlog_SSL ; _error_messages.push_back("Internal Error"); goto exit; } flags |= SMIME_OLDMIME; /* Write out S/MIME message */ if (!SMIME_write_CMS(out, cms, in, flags)) goto exit; bResult = true; exit: SMTPD_RAND_write_file (NULL, bio_err); sk_X509_pop_free(encerts, X509_free); if (cms) CMS_ContentInfo_free(cms); BIO_free(in); BIO_free_all(out); KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () finished" ); return ( bResult ); } When using this function to encrypt an e-mail Thunderbird can decrypt the message. But is RSA-OAEP padding really used or is the default padding still used? How can I check this? For comments I would be very grateful Regards Rudy -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-PKCS1-OAEP-PADDING-tp70741.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From steve at openssl.org Thu May 11 15:10:32 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 May 2017 15:10:32 +0000 Subject: [openssl-users] RSA_PKCS1_OAEP_PADDING In-Reply-To: <1494495232360-70741.post@n7.nabble.com> References: <1494495232360-70741.post@n7.nabble.com> Message-ID: <20170511151032.GA9549@openssl.org> On Thu, May 11, 2017, RudyAC wrote: > Hello, > > I have the requirement to encrypt e-mails using RSA-OAEP padding. I use the > library openssl-1.0.2k and encrypt with CMS container. The following > function describes my method. My problem is that I'm not sure if this method > really uses the RSA-OAEP padding. > > bool > smime_encrypt_cms(const std::string& infile, const std::string& outfile) > { > bool bResult = false; > const char* inmode = "r"; > const char* outmode = "w"; > const EVP_CIPHER* cipher = NULL; > > > STACK_OF(X509)* encerts = NULL; > BIO* in = NULL; > BIO* out = NULL; > BIO* bio_err = NULL; > int flags = 0; > > X509 *recip; > int i = 0; > unsigned char *oaep_label = NULL; > int oaep_label_l = 0; > int nflags = CMS_PARTIAL | CMS_KEY_PARAM; > CMS_ContentInfo* cms = CMS_encrypt(NULL, NULL, cipher, nflags); > EVP_PKEY_CTX* wrap_ctx = NULL; > > KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () started" ); > > cipher = get_cipher(); > SMTPD_RAND_load_file ( NULL , bio_err , 0 ); > > encerts = sk_X509_new_null(); > > FOR_CONST_IT(EmailAndCertList, itRecip, _m_recipCertsList) > { > SMIME_key_list recip_encerts = (*itRecip)->smime_enc(); > > FOR_CONST_IT(SMIME_key_list, iter, recip_encerts) > { > sk_X509_push( encerts, (*iter).dup_cert()); > } > } > > > if ( ! ( in = BIO_new_file ( infile.c_str() , inmode ))) { > KWlog_appl ( EV_E_APPL_INFO , "Can't open input file %s", > infile.c_str() ); > _error_messages.push_back("Internal Error"); > goto exit; > } > > if ( ! ( out = BIO_new_file ( outfile.c_str() , outmode ))) { > KWlog_appl ( EV_E_APPL_INFO , "Can't open output file %s", > outfile.c_str() ); > _error_messages.push_back("Internal Error"); > goto exit; > } > > for (i = 0; i < sk_X509_num(encerts); i++) { > > CMS_RecipientInfo* r_info; > > recip = sk_X509_value(encerts, i); > r_info = CMS_add1_recipient_cert(cms, recip, nflags); > if (!r_info) { > KWlog_appl(EV_E_APPL_INFO, > "smime_encrypt_cms(): Error while adding recipient certs to CMS info > structure"); > return false; > } > wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info); > KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () Set OAEP Padding"); > EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING); > EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256()); > EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256()); > EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l); > } > > CMS_final(cms, in, NULL, nflags); > > /* encrypt content */ > cms = CMS_encrypt(encerts, in, cipher, flags); > > > if( ! cms ) { > KWlog ( EV_E_APPL_INFO , "Error creating CMS structure"); > KWlog_SSL ; > _error_messages.push_back("Internal Error"); > goto exit; > } > > flags |= SMIME_OLDMIME; > > /* Write out S/MIME message */ > if (!SMIME_write_CMS(out, cms, in, flags)) > goto exit; > > bResult = true; > > exit: > SMTPD_RAND_write_file (NULL, bio_err); > sk_X509_pop_free(encerts, X509_free); > if (cms) > CMS_ContentInfo_free(cms); > BIO_free(in); > BIO_free_all(out); > > KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () finished" ); > return ( bResult ); > } > > When using this function to encrypt an e-mail Thunderbird can decrypt the > message. But is RSA-OAEP padding really used or is the default padding still > used? How can I check this? > > For comments I would be very grateful > You can try printing out all the fields of the message with: openssl cms -cmsout -noout -print Near the top you should see: keyEncryptionAlgorithm: algorithm: rsaesOaep (1.2.840.113549.1.1.7) while the default padding give: keyEncryptionAlgorithm: algorithm: rsaEncryption (1.2.840.113549.1.1.1) Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From scott_n at xypro.com Thu May 11 16:07:35 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 11 May 2017 16:07:35 +0000 Subject: [openssl-users] Dumb question about DES Message-ID: Has DES been deprecated in OpenSSL? If so, what release? In particular the following ciphers 0.19 EDH-DSS-DES-CBC3-SHA 0.22 EDH-RSA-DES-CBC3-SHA 192.13 ECDH-RSA-DES-CBC3-SHA 192.3 ECDH-ECDSA-DES-CBC3-SHA 192.18 ECDHE-RSA-DES-CBC3-SHA 192.8 ECDHE-ECDSA-DES-CBC3-SHA --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu May 11 16:18:07 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 11 May 2017 11:18:07 -0500 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: Message-ID: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it away ... well, not exactly.) The single-DES ciphers were removed in release 1.1.0 (they are included in the "40 and 56 bit cipher support removed from libssl" item in the release notes), though the raw crypto primitives remain in libcrypto. -Ben On 05/11/2017 11:07 AM, Scott Neugroschl wrote: > > Has DES been deprecated in OpenSSL? If so, what release? In > particular the following ciphers > > > > 0.19 EDH-DSS-DES-CBC3-SHA > > 0.22 EDH-RSA-DES-CBC3-SHA > > 192.13 ECDH-RSA-DES-CBC3-SHA > > 192.3 ECDH-ECDSA-DES-CBC3-SHA > > 192.18 ECDHE-RSA-DES-CBC3-SHA > > 192.8 ECDHE-ECDSA-DES-CBC3-SHA > > > > > > > > --- > > Scott Neugroschl | XYPRO Technology Corporation > > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Thu May 11 18:13:07 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 11 May 2017 18:13:07 +0000 Subject: [openssl-users] Dumb question about DES In-Reply-To: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: OK. Are the 3DES CBC ciphers still part of DEFAULT? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Benjamin Kaduk via openssl-users Sent: Thursday, May 11, 2017 9:18 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Dumb question about DES Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it away ... well, not exactly.) The single-DES ciphers were removed in release 1.1.0 (they are included in the "40 and 56 bit cipher support removed from libssl" item in the release notes), though the raw crypto primitives remain in libcrypto. -Ben On 05/11/2017 11:07 AM, Scott Neugroschl wrote: Has DES been deprecated in OpenSSL? If so, what release? In particular the following ciphers 0.19 EDH-DSS-DES-CBC3-SHA 0.22 EDH-RSA-DES-CBC3-SHA 192.13 ECDH-RSA-DES-CBC3-SHA 192.3 ECDH-ECDSA-DES-CBC3-SHA 192.18 ECDHE-RSA-DES-CBC3-SHA 192.8 ECDHE-ECDSA-DES-CBC3-SHA --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu May 11 19:10:18 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 11 May 2017 14:10:18 -0500 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: <37d3313b-11e5-6045-a456-39516f160dd6@akamai.com> The triple-DES ciphers are not part of DEFAULT in 1.1.0e(what I happened to check). Though, the specific list of ciphers there does not quite match with your list below, so you should double-check if necessary. -Ben On 05/11/2017 01:13 PM, Scott Neugroschl wrote: > > OK. Are the 3DES CBC ciphers still part of DEFAULT? > > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Benjamin Kaduk via openssl-users > *Sent:* Thursday, May 11, 2017 9:18 AM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Dumb question about DES > > > > Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it > away ... well, not exactly.) > The single-DES ciphers were removed in release 1.1.0 (they are > included in the "40 and 56 bit cipher support removed from libssl" > item in the release notes), though the raw crypto primitives remain in > libcrypto. > > -Ben > > On 05/11/2017 11:07 AM, Scott Neugroschl wrote: > > Has DES been deprecated in OpenSSL? If so, what release? In > particular the following ciphers > > > > 0.19 EDH-DSS-DES-CBC3-SHA > > 0.22 EDH-RSA-DES-CBC3-SHA > > 192.13 ECDH-RSA-DES-CBC3-SHA > > 192.3 ECDH-ECDSA-DES-CBC3-SHA > > 192.18 ECDHE-RSA-DES-CBC3-SHA > > 192.8 ECDHE-ECDSA-DES-CBC3-SHA > > > > > > > > --- > > Scott Neugroschl | XYPRO Technology Corporation > > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone > 805 583-2874|Fax 805 583-0124 | > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu May 11 19:36:11 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 11 May 2017 15:36:11 -0400 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: <420C1575-BF58-423E-8796-02D5A2068FD5@dukhovni.org> > On May 11, 2017, at 2:13 PM, Scott Neugroschl wrote: > > OK. Are the 3DES CBC ciphers still part of DEFAULT? Normal builds of OpenSSL 1.1.0 disable the TLS 3DES ciphersuites at compile time. To make use of 3DES in TLS you need to configure your OpenSSL 1.1.0 build with the "enable-weak-ssl-ciphers" option. -- -- Viktor. From noloader at gmail.com Thu May 11 19:44:53 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 11 May 2017 15:44:53 -0400 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: On Thu, May 11, 2017 at 2:13 PM, Scott Neugroschl wrote: > OK. Are the 3DES CBC ciphers still part of DEFAULT? >From OpenSSL 1.0.1t: $ openssl ciphers "DEFAULT" 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-SH A:SRP-DSS-AES-256-CBC-SHA:SRP-RSA-AES-256-CBC-SHA:SRP-AES-256-CBC-SHA:DHE-D SS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-SHA256:DHE-DS S-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:DHE-RSA-CAMELLIA256-S HA: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:CAMELLIA2 56-SHA:PSK-AES256-CBC-SHA:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GC M-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128 -SHA:ECDHE-ECDSA-AES128-SHA:SRP-DSS-AES-128-CBC-SHA:SRP-RSA-AES-128-CBC-SHA :SRP-AES-128-CBC-SHA:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DH E-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128 -SHA:DHE-RSA-SEED-SHA:DHE-DSS-SEED-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAME LLIA128-SHA:ECDH-RSA-AES128-GCM-SHA256:ECDH-ECDSA-AES128-GCM-SHA256:ECDH-RS A-AES128-SHA256:ECDH-ECDSA-AES128-SHA256:ECDH-RSA-AES128-SHA:ECDH-ECDSA-AES 128-SHA:AES128-GCM-SHA256:AES128-SHA256:AES128-SHA:SEED-SHA:CAMELLIA128-SHA :PSK-AES128-CBC-SHA:ECDHE-RSA-RC4-SHA:ECDHE-ECDSA-RC4-SHA:ECDH-RSA-RC4-SHA: ECDH-ECDSA-RC4-SHA:RC4-SHA:RC4-MD5:PSK-RC4-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE -ECDSA-DES-CBC3-SHA:SRP-DSS-3DES-EDE-CBC-SHA:SRP-RSA-3DES-EDE-CBC-SHA:SRP-3 DES-EDE-CBC-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:ECDH-RSA-DES-CBC3 -SHA:ECDH-ECDSA-DES-CBC3-SHA:DES-CBC3-SHA:PSK-3DES-EDE-CBC-SHA From scott_n at xypro.com Thu May 11 20:17:25 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 11 May 2017 20:17:25 +0000 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: So if I'm using 1.0.2, and want to deprecate 3DES, I need to do that as part of my build? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Scott Neugroschl Sent: Thursday, May 11, 2017 11:13 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Dumb question about DES OK. Are the 3DES CBC ciphers still part of DEFAULT? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Benjamin Kaduk via openssl-users Sent: Thursday, May 11, 2017 9:18 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Dumb question about DES Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it away ... well, not exactly.) The single-DES ciphers were removed in release 1.1.0 (they are included in the "40 and 56 bit cipher support removed from libssl" item in the release notes), though the raw crypto primitives remain in libcrypto. -Ben On 05/11/2017 11:07 AM, Scott Neugroschl wrote: Has DES been deprecated in OpenSSL? If so, what release? In particular the following ciphers 0.19 EDH-DSS-DES-CBC3-SHA 0.22 EDH-RSA-DES-CBC3-SHA 192.13 ECDH-RSA-DES-CBC3-SHA 192.3 ECDH-ECDSA-DES-CBC3-SHA 192.18 ECDHE-RSA-DES-CBC3-SHA 192.8 ECDHE-ECDSA-DES-CBC3-SHA --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Thu May 11 20:30:54 2017 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 11 May 2017 15:30:54 -0500 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: <97ccda67-6ba4-6dde-0247-adcc9b716117@akamai.com> On 05/11/2017 03:17 PM, Scott Neugroschl wrote: > > So if I?m using 1.0.2, and want to deprecate 3DES, I need to do that > as part of my build? > > Yes. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri May 12 05:43:06 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 12 May 2017 07:43:06 +0200 Subject: [openssl-users] Dumb question about DES In-Reply-To: References: <205437d8-15a4-4b10-7fe0-11d649563047@akamai.com> Message-ID: <4791edc3-cc7c-13ac-a44c-f325057d3171@wisemo.com> (keeping TOFU style to keep thread consistent). You can also just use the cipher-list configuration option string that an OpenSSL 1.0.x should allow passing to OpenSSL. On 11/05/2017 22:17, Scott Neugroschl wrote: > > So if I?m using 1.0.2, and want to deprecate 3DES, I need to do that > as part of my build? > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Scott Neugroschl > *Sent:* Thursday, May 11, 2017 11:13 AM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Dumb question about DES > > OK. Are the 3DES CBC ciphers still part of DEFAULT? > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Benjamin Kaduk via openssl-users > *Sent:* Thursday, May 11, 2017 9:18 AM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Dumb question about DES > > Those ciphers are triple-DES, not single-DES. (The "CBC3" gives it > away ... well, not exactly.) > The single-DES ciphers were removed in release 1.1.0 (they are > included in the "40 and 56 bit cipher support removed from libssl" > item in the release notes), though the raw crypto primitives remain in > libcrypto. > > -Ben > > On 05/11/2017 11:07 AM, Scott Neugroschl wrote: > > Has DES been deprecated in OpenSSL? If so, what release? In > particular the following ciphers > > 0.19 EDH-DSS-DES-CBC3-SHA > > 0.22 EDH-RSA-DES-CBC3-SHA > > 192.13 ECDH-RSA-DES-CBC3-SHA > > 192.3 ECDH-ECDSA-DES-CBC3-SHA > > 192.18 ECDHE-RSA-DES-CBC3-SHA > > 192.8 ECDHE-ECDSA-DES-CBC3-SHA > 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 harakiri_23 at yahoo.com Fri May 12 05:52:34 2017 From: harakiri_23 at yahoo.com (Harakiri) Date: Fri, 12 May 2017 05:52:34 +0000 (UTC) Subject: [openssl-users] Some S/MIME CMS encrypted messages produce invalid key length when using the debug_decrypt option In-Reply-To: <1744746631.7734939.1494403063631@mail.yahoo.com> References: <1255095675.2660197.1494233300987.ref@mail.yahoo.com> <1255095675.2660197.1494233300987@mail.yahoo.com> <20170508230434.GA18897@openssl.org> <1744746631.7734939.1494403063631@mail.yahoo.com> Message-ID: <443835786.360359.1494568354430@mail.yahoo.com> The message is first signed then encrypted. Commands are as follows /usr/bin/openssl cms -encrypt -aes128 -in /tmp/OpenSSL5294490400891792656.eml -out /tmp/OpenSSL3519826551660167644.eml -subject 'subject' -from sender at sender.com -to recipient at recipient.com,recipient2 at recipient.com -recip cert1.pem -recip cert2.pem -keyopt rsa_padding_mode:oaepI maybe could provide a problematic e-mail including private keys - off the list - due privacy concerns to investigate - would that be acceptable ? If so - what e-mail address can i sent it to From: Dr. Stephen Henson To: Harakiri ; openssl-users at openssl.org Sent: Tuesday, May 9, 2017 1:04 AM Subject: Re: [openssl-users] Some S/MIME CMS encrypted messages produce invalid key length when using the debug_decrypt option On Mon, May 08, 2017, Harakiri via openssl-users wrote: > Im using the cmd client openssl cms -decrypt with the "debug_decrypt" option to have the same behaviour as before the bleichenbach security patch to use decryption without recipient public keys. > For some reason, some messages will produce the following error on?OpenSSL 1.0.2d and even OpenSSL 1.0.2k > Error decrypting CMS structure6828:error:0607A082:digital envelope routines:EVP_CIPHER_CTX_set_key_length:invalid key length:evp_enc.c:593:6828:error:2E078076:CMS routines:cms_EncryptedContent_init_bio:invalid key length:cms_enc.c:163: > Calling cms -decrypt without the debug_decrypt option produces no error. > What is weird, is that its always basically the same source e-mail encrypted using openssl cms with?aes-128-cbc and?rsaesOaep and sometimes the resulting messagewill produce this error and other times it works. > > That's odd. What command line are you using to create the messages? Would it be possible to create a test case that reproduces this error? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.francis.jr at pobox.com Fri May 12 19:55:26 2017 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Fri, 12 May 2017 15:55:26 -0400 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> Message-ID: <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU wrote: > Hello, > > I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. > > But, there is not yet the machine for build, so I cannot do actual > machine verification. > > The CPU is not Intel architecture, is probably z/Architecture. > > I want to know beforehand the appropriate command-line parameters for > executing "Configure". > > Is it right to specify "linux64-s390x" as follows? > > (1)cd //openssl-1.0.2k > > (2)./Configure linux64-s390x > > Thanks in advance. > > Regards, > > Manabu I'd suggest just running "./config". That will pick the appropriate 64-bit target. Only use Configure if you want to do something non-standard. :) TOM From thomas.francis.jr at pobox.com Fri May 12 19:55:26 2017 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Fri, 12 May 2017 15:55:26 -0400 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> Message-ID: <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU wrote: > Hello, > > I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. > > But, there is not yet the machine for build, so I cannot do actual > machine verification. > > The CPU is not Intel architecture, is probably z/Architecture. > > I want to know beforehand the appropriate command-line parameters for > executing "Configure". > > Is it right to specify "linux64-s390x" as follows? > > (1)cd //openssl-1.0.2k > > (2)./Configure linux64-s390x > > Thanks in advance. > > Regards, > > Manabu I'd suggest just running "./config". That will pick the appropriate 64-bit target. Only use Configure if you want to do something non-standard. :) TOM From Andrew_Porter at bmc.com Fri May 12 20:20:35 2017 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Fri, 12 May 2017 20:20:35 +0000 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> Message-ID: <0ebd05db916c48d9b114983e80022641@hou-exmbprd-02.adprod.bmc.com> ./config works just fine for me on a SLES 11.3 z/Linux, and yes it sets PLATFORM to "linux64-s390x" in MAKEFILE Andrew -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Thomas Francis, Jr. Sent: Friday, May 12, 2017 12:55 To: openssl-users at openssl.org; ????????????? / COMMONSSL?GYOUMU Subject: Re: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU wrote: > Hello, > > I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. > > But, there is not yet the machine for build, so I cannot do actual > machine verification. > > The CPU is not Intel architecture, is probably z/Architecture. > > I want to know beforehand the appropriate command-line parameters for > executing "Configure". > > Is it right to specify "linux64-s390x" as follows? > > (1)cd //openssl-1.0.2k > > (2)./Configure linux64-s390x > > Thanks in advance. > > Regards, > > Manabu I'd suggest just running "./config". That will pick the appropriate 64-bit target. Only use Configure if you want to do something non-standard. :) TOM -- openssl-users mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=DwIGaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=y_R1eCO_0tchTjqrQby7KgWKxasiJiYKVrkVRuGlQWk&s=lR-F70DHHpRhV_x7sg5Cr1RohGs7zFMNGUAGGiMWBRE&e= From Michael.Wojcik at microfocus.com Fri May 12 21:00:52 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 12 May 2017 21:00:52 +0000 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Thomas Francis, Jr. > Sent: Friday, May 12, 2017 15:55 > > On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU wrote: > > > > I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. What version of OpenSSL? > > But, there is not yet the machine for build, so I cannot do actual > > machine verification. > > > > The CPU is not Intel architecture, is probably z/Architecture. Yes, Linux for System z runs on z-architecture CPUs. > > I want to know beforehand the appropriate command-line parameters for > > executing "Configure". > > > > Is it right to specify "linux64-s390x" as follows? > > > > (1)cd //openssl-1.0.2k > > > > (2)./Configure linux64-s390x > > I'd suggest just running "./config". That will pick the appropriate > 64-bit target. Only use Configure if you want to do something > non-standard. :) That's certainly the place to start. Whether it will work is another question. When we build OpenSSL for z Linux (RHEL and SLES), we use a modified Configure that: * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into an archive library that is then linked into a shared object, so we have to force on the shared-object flags in Configure. * Replaces -O3 with -O1, preferring robustness (or, if you prefer, toleration for sloppiness and error) and ease of problem determination over performance. * Replaces the asm setting[1] with ${no_asm}, for the same reason. * For 32-bit, removes /highgprs. According to my notes, highgprs does not work correctly with some glibc versions on zLinux. The OP probably doesn't need the first three and may well not need the last. Depending on how clever one gets with building and using OpenSSL, though, config+Configure aren't always sufficient as supplied. That's not a criticism - trying to accommodate every use case is not a good use of the OpenSSL development team's time. But unless you're happy with the default build parameters and comfortable with your platform, be prepared to learn how the OpenSSL build works. [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit. The linux64-s390x target uses ${s390x_asm} for its asm section, but the linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm for both. Michael Wojcik Distinguished Engineer, Micro Focus From hareesh.dj at gmail.com Fri May 12 21:17:22 2017 From: hareesh.dj at gmail.com (Hareesh Joshi) Date: Sat, 13 May 2017 02:47:22 +0530 Subject: [openssl-users] /proc/sys/crypto/fips_enabled=1 is this enough to make OpenSSL to change its mode to FIPS? Message-ID: Hi, I've a CentOS machine with 1. FIPS capable OpenSSL module installed 2. Kernel switched to FIPS with /proc/sys/crypto/fips_enabled=1 Will this make OpenSSL to switch to FIPS mode as well? Or do I necessarily need to use OPENSSL_FIPS=1 ? Thank you, -Hareesh Joshi -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas.francis.jr at pobox.com Sat May 13 01:13:12 2017 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Fri, 12 May 2017 21:13:12 -0400 Subject: [openssl-users] Build OpenSSL on SUSE Linux Enterprise Server for z Systems In-Reply-To: References: <15CFFC2F2156164FA093C04D7DB5BFB322D74268@GSjpTK1DCembx01.service.hitachi.net> <544aff21-4552-ea94-61e1-257f87a19f50@pobox.com> Message-ID: <4DF90FD0-08D2-49F0-81B0-F3201DB7AEA5@pobox.com> On May 12, 2017, at 5:00 PM, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Thomas Francis, Jr. >> Sent: Friday, May 12, 2017 15:55 >> >>> On 5/10/17 3:55 AM, ????????????? / COMMONSSL?GYOUMU wrote: >>> >>> I will build OpenSSL on SUSE Linux Enterprise Server for z Systems. > > What version of OpenSSL? > >>> But, there is not yet the machine for build, so I cannot do actual >>> machine verification. >>> >>> The CPU is not Intel architecture, is probably z/Architecture. > > Yes, Linux for System z runs on z-architecture CPUs. > >>> I want to know beforehand the appropriate command-line parameters for >>> executing "Configure". >>> >>> Is it right to specify "linux64-s390x" as follows? >>> >>> (1)cd //openssl-1.0.2k >>> >>> (2)./Configure linux64-s390x >> >> I'd suggest just running "./config". That will pick the appropriate >> 64-bit target. Only use Configure if you want to do something >> non-standard. :) > > That's certainly the place to start. Whether it will work is another question. > > When we build OpenSSL for z Linux (RHEL and SLES), we use a modified Configure that: > > * Adds -fPIC and -mbackchain. This is because we compile OpenSSL into an archive library that is then linked into a shared object, so we have to force on the shared-object flags in Configure. > > * Replaces -O3 with -O1, preferring robustness (or, if you prefer, toleration for sloppiness and error) and ease of problem determination over performance. > > * Replaces the asm setting[1] with ${no_asm}, for the same reason. > > * For 32-bit, removes /highgprs. According to my notes, highgprs does not work correctly with some glibc versions on zLinux. > > The OP probably doesn't need the first three and may well not need the last. Depending on how clever one gets with building and using OpenSSL, though, config+Configure aren't always sufficient as supplied. That's not a criticism - trying to accommodate every use case is not a good use of the OpenSSL development team's time. > > But unless you're happy with the default build parameters and comfortable with your platform, be prepared to learn how the OpenSSL build works. I think in general, the same caveat applies for any system. The default build settings might not be what you want. But in most cases (including Linux for z), they will get you libraries that'll work with the system compiler toolchain if you pass only the minimum flags to specify where the headers and libraries can be found. I figure if you need something else you probably already know that, and can pass the appropriate flags in CFLAGS, CPPFLAGS, or LDFLAGS. :) Or create a custom target. TOM PS Regarding highgprs; I suspect that's actually a problem of mixing 32-bit s390x binaries with s390 binaries. There is a difference. But old bugs and miscommunication means that sometimes the s390 system will think it can load an s390x binary (and sometimes think it succeeded). :) > [1] There are two zLinux targets in the 1.0.2 Configure, for 64- and 32-bit. The linux64-s390x target uses ${s390x_asm} for its asm section, but the linux32-s90x uses an eval expression that edits $s390x_asm. We disable asm for both. > > > Michael Wojcik > Distinguished Engineer, Micro Focus From marquess at openssl.com Sat May 13 19:02:07 2017 From: marquess at openssl.com (Steve Marquess) Date: Sat, 13 May 2017 15:02:07 -0400 Subject: [openssl-users] /proc/sys/crypto/fips_enabled=1 is this enough to make OpenSSL to change its mode to FIPS? In-Reply-To: References: Message-ID: <6cea1a9c-51f7-c2a6-4d8f-80b682b788d0@openssl.com> On 05/12/2017 05:17 PM, Hareesh Joshi wrote: > Hi, > > I've a CentOS machine with > 1. FIPS capable OpenSSL module installed > 2. Kernel switched to FIPS with /proc/sys/crypto/fips_enabled=1 > > Will this make OpenSSL to switch to FIPS mode as well? Or do I > necessarily need to use OPENSSL_FIPS=1 ? > OpenSSL and the OpenSSL FIPS Object Module ignore /proc/sys/crypto/fips_enabled, that is presumably used by the Red Hat modified version of OpenSSL. You'll need to check with them about how that behaves. For a genuine FIPS capable OpenSSL you want to use FIPS_mode_set(); see the FIPS module user guide at https://www.openssl.org/docs/fips/UserGuide-2.0.pdf and/or the wiki at https://wiki.openssl.org/. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 301 874 2571 marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From sberla81 at hotmail.com Sat May 13 15:48:10 2017 From: sberla81 at hotmail.com (Massimo G.) Date: Sat, 13 May 2017 15:48:10 +0000 Subject: [openssl-users] SSL_CTX_set_tmp_ecdh_callback() - version 1.0.2k Message-ID: Hi all, my 'openssl version' is "1.0.2k-fips". The SSL_CTX_set_tmp_ecdh_callback() function is not included in the API list (Documentation - Manpages for 1.0.2). 1) Shouldn't I use that function? 2) Why isn't it listed in the manpages? 3) Should I refer to a different Manpages version? If so, why? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun May 14 13:33:18 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 14 May 2017 13:33:18 +0000 Subject: [openssl-users] SSL_CTX_set_tmp_ecdh_callback() - version 1.0.2k In-Reply-To: References: Message-ID: <5bd5f586f93540bb85365cf6b6c1f2d6@usma1ex-dag1mb1.msg.corp.akamai.com> > 2) Why isn't it listed in the manpages? Many fucntions aren't documented. We're all working on it. From openssl-users at dukhovni.org Sun May 14 20:16:56 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 14 May 2017 16:16:56 -0400 Subject: [openssl-users] SSL_CTX_set_tmp_ecdh_callback() - version 1.0.2k In-Reply-To: References: Message-ID: <27E28A51-06E2-4234-9845-F9ABF56D13D0@dukhovni.org> > On May 13, 2017, at 11:48 AM, Massimo G. wrote: > > Hi all, > my 'openssl version' is "1.0.2k-fips". > The SSL_CTX_set_tmp_ecdh_callback() function is not included in the API list (Documentation - Manpages for 1.0.2). > > 1) Shouldn't I use that function? You may, but SSL_CTX_set_ecdh_auto() is a better choice, since it picks the curve based on the client's list of supported curves. You can set the list of curves supported on your end via SSL_CTX_set1_curves() which takes a list of "nids". IIRC you should first check that all the "nids" are supported, before configuring the final list. Postfix setups the nid array, from a list of names as follows: while ((curve = mystrtok(&curves, CHARS_COMMA_SP)) != 0) { int nid = EC_curve_nist2nid(curve); if (nid == NID_undef) nid = OBJ_sn2nid(curve); if (nid == NID_undef) nid = OBJ_ln2nid(curve); if (nid == NID_undef) { msg_warn("ignoring unknown \"auto\" ECDHE curve \"%s\"", curve); continue; } /* * Validate the NID by trying it as the sole EC curve for a * throw-away SSL context. Silently skip unsupported code points. * This way, we can list X25519 and X448 as soon as the nids are * assigned, and before the supporting code is implemented. They'll * be silently skipped when not yet supported. */ if (SSL_CTX_set1_curves(tmpctx, &nid, 1) <= 0) { ++unknown; continue; } if (++n > space) { space *= 2; nids = myrealloc(nids, space * sizeof(int)); } nids[n - 1] = nid; } > 2) Why isn't it listed in the manpages? Someone has to contribute the manpage. > > 3) Should I refer to a different Manpages version? If so, why? The documentation is in better shape in 1.1.0 and continues to improve. -- Viktor. From rpo at compumatica.com Mon May 15 07:30:05 2017 From: rpo at compumatica.com (RudyAC) Date: Mon, 15 May 2017 00:30:05 -0700 (MST) Subject: [openssl-users] RSA_PKCS1_OAEP_PADDING In-Reply-To: <20170511151032.GA9549@openssl.org> References: <1494495232360-70741.post@n7.nabble.com> <20170511151032.GA9549@openssl.org> Message-ID: <1494833405720-70789.post@n7.nabble.com> Hello Steve, first of all thanks for helpful advice. When printing out all the fields of the message with the openssl command I got for every recipient two blocks. One block includes the OAEP padding and the other block (same recipient) includes the default padding. d.ktri: version: d.issuerAndSerialNumber: issuer: C=DE, O=extern, OU=host3, CN=CA - host3 serialNumber: 12302977334217659119 keyEncryptionAlgorithm: algorithm: rsaEncryption (1.2.840.113549.1.1.1) parameter: NULL d.ktri: version: d.issuerAndSerialNumber: issuer: C=DE, O=extern, OU=host3, CN=CA - host3 serialNumber: 12302977334217659119 keyEncryptionAlgorithm: algorithm: rsaesOaep (1.2.840.113549.1.1.7) parameter: SEQUENCE: 0:d=0 hl=2 l= 43 cons: SEQUENCE 2:d=1 hl=2 l= 13 cons: cont [ 0 ] 4:d=2 hl=2 l= 11 cons: SEQUENCE 6:d=3 hl=2 l= 9 prim: OBJECT :sha256 17:d=1 hl=2 l= 26 cons: cont [ 1 ] 19:d=2 hl=2 l= 24 cons: SEQUENCE 21:d=3 hl=2 l= 9 prim: OBJECT :mgf1 32:d=3 hl=2 l= 11 cons: SEQUENCE 34:d=4 hl=2 l= 9 prim: OBJECT :sha256 How can I make sure that only the OAEP padding is used? Regards Rudy -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-PKCS1-OAEP-PADDING-tp70741p70789.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From steve at openssl.org Mon May 15 12:08:30 2017 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 15 May 2017 12:08:30 +0000 Subject: [openssl-users] RSA_PKCS1_OAEP_PADDING In-Reply-To: <1494833405720-70789.post@n7.nabble.com> References: <1494495232360-70741.post@n7.nabble.com> <20170511151032.GA9549@openssl.org> <1494833405720-70789.post@n7.nabble.com> Message-ID: <20170515120830.GA15680@openssl.org> On Mon, May 15, 2017, RudyAC wrote: > Hello Steve, > > first of all thanks for helpful advice. When printing out all the fields of > the message with the openssl command > I got for every recipient two blocks. One block includes the OAEP padding > and the other block (same recipient) includes the default padding. > > d.ktri: > version: > d.issuerAndSerialNumber: > issuer: C=DE, O=extern, OU=host3, CN=CA - host3 > serialNumber: 12302977334217659119 > keyEncryptionAlgorithm: > algorithm: rsaEncryption (1.2.840.113549.1.1.1) > parameter: NULL > > d.ktri: > version: > d.issuerAndSerialNumber: > issuer: C=DE, O=extern, OU=host3, CN=CA - host3 > serialNumber: 12302977334217659119 > keyEncryptionAlgorithm: > algorithm: rsaesOaep (1.2.840.113549.1.1.7) > parameter: SEQUENCE: > 0:d=0 hl=2 l= 43 cons: SEQUENCE > 2:d=1 hl=2 l= 13 cons: cont [ 0 ] > 4:d=2 hl=2 l= 11 cons: SEQUENCE > 6:d=3 hl=2 l= 9 prim: OBJECT :sha256 > 17:d=1 hl=2 l= 26 cons: cont [ 1 ] > 19:d=2 hl=2 l= 24 cons: SEQUENCE > 21:d=3 hl=2 l= 9 prim: OBJECT :mgf1 > 32:d=3 hl=2 l= 11 cons: SEQUENCE > 34:d=4 hl=2 l= 9 prim: OBJECT :sha256 > > How can I make sure that only the OAEP padding is used? > What code are you using? The original you posted had a bug: CMS_final(cms, in, NULL, nflags); /* encrypt content */ cms = CMS_encrypt(encerts, in, cipher, flags); Which will overwrite the created cms structure. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From afenkart at gmail.com Mon May 15 15:54:24 2017 From: afenkart at gmail.com (Andreas Fenkart) Date: Mon, 15 May 2017 17:54:24 +0200 Subject: [openssl-users] gpgsm/openssl cms detached signatures verification fails Message-ID: Hi list, I'm experimenting with openssl/gnupg interoperability. It seems the least common multiple is cms. I didn't find a way to produce output with opengpg to work with 'openssl dgst' directly. Am I wrong, is there a simpler way? generate gpgsm keyring: https://lists.gt.net/gnupg/devel/53489 $ gpgsm --generate-key > x.pem; CN=Joe, O=Corp, C=unv $ gpgsm --import x.pem $ gpgsm -a --output pub.pem --export 0x3E3AB34C GNUPG -> OPENSSL: it works when using non-detached signatures $ gpgsm -as -o somefile.sig somefile $ sed -i 's/SIGNED MESSAGE/CMS/' somefile.sig $ openssl cms -verify -in somefile.sig -inform PEM -certfile pub.pem -noverify Verification successful But fails when using detached signatures: $ gpgsm -asb -o somefile.sig somefile $ sed -i 's/SIGNED MESSAGE/CMS/' somefile.sig $ openssl cms -verify -in somefile.sig -inform PEM -content somefile -certfile pub.pem -noverify OPENSSL -> GNUPG: create key: $ openssl req -x509 -newkey rsa:2048 -nodes -keyout mycert.key.pem \ -out mycert.cert.pem -subj "/O=SWUpdate /CN=target" $ gpgsm --import mycert.cert.pem again works with non-detached signature: $ openssl cms -sign -in somefile -out somefile.sig -nodetach \ -signer mycert.cert.pem -inkey mycert.key.pem -outform PEM -nosmimecap $ gpgsm --disable-crl-checks --verify somefile.sig gpgsm: Good signature from "/CN=target/O= SWUpdate" and fails with detached signatures: $ openssl cms -sign -in somefile -out somefile.sig \ -signer mycert.cert.pem -inkey mycert.key.pem -outform PEM -nosmimecap $ gpgsm --disable-crl-checks --verify somefile.sig somefile gpgsm: Signature made 2017-05-15 14:44:36 using certificate ID 0x5F7C51D8 gpgsm: invalid signature: message digest attribute does not match computed one COMPARING ASN1 output: I parsed the signatures using asn1parse, then compared the outputs: $ openssl asn1parse -in somefile.sig 998:d=7 hl=2 l= 9 prim: OBJECT :messageDigest 1009:d=7 hl=2 l= 34 cons: SET 1011:d=8 hl=2 l= 32 prim: OCTET STRING [HEX DUMP]:CC83AEAE49B66CCADA3DFFEB87E27AF53D99437F5E24485D31F4F11BF092FA6D 1045:d=5 hl=2 l= 13 cons: SEQUENCE 1047:d=6 hl=2 l= 9 prim: OBJECT :rsaEncryption 1058:d=6 hl=2 l= 0 prim: NULL 1060:d=5 hl=4 l= 256 prim: OCTET STRING [HEX DUMP]:7440A9007CACDD5484076661B57181AE64249506FF631CFF1EE5B0D74CBD431D9AB57533E44BE6B56F2D18DF52ED9B24C6DD040B6E8F9B3A6F1E3 The :messageDigest hash codes are the same for detached/non-detached but the :rsaEncryption differ (salt, timestamp?) The messageDigest does not match the output from sha256sum Repeating the some for the gpgsm genarated signatures, I can see that the messageDigest matches directly the output of sha256sum. So openssl cms/gpgsm compute the sha256sum differently in the detached case. Is there a hidden flag to make either tool behave like the other? /Andi From jb-openssl at wisemo.com Mon May 15 21:25:05 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 15 May 2017 23:25:05 +0200 Subject: [openssl-users] gpgsm/openssl cms detached signatures verification fails In-Reply-To: References: Message-ID: <6978f457-bb8a-44ca-674f-897a8c9288b8@wisemo.com> On 15/05/2017 17:54, Andreas Fenkart wrote: > Hi list, > I'm experimenting with openssl/gnupg interoperability. It seems the > least common multiple is cms. I didn't find a way to produce output > with opengpg to work with 'openssl dgst' directly. Am I wrong, is > there a simpler way? > ... > The :messageDigest hash codes are the same for detached/non-detached > but the :rsaEncryption differ (salt, timestamp?) The messageDigest > does not match the output from sha256sum > > Repeating the some for the gpgsm genarated signatures, I can see that > the messageDigest matches directly the output of sha256sum. > > So openssl cms/gpgsm compute the sha256sum differently in the detached case. > Is there a hidden flag to make either tool behave like the other? Look at the documentation of the openssl cms "-inform SMIME", "-outform SMIME" and "-binary" options. 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 minhtrang.hp010915 at gmail.com Tue May 16 06:12:52 2017 From: minhtrang.hp010915 at gmail.com (=?UTF-8?B?Q8OUTkcgTkdVWeG7hE4gVsSCTg==?=) Date: Tue, 16 May 2017 13:12:52 +0700 Subject: [openssl-users] (no subject) Message-ID: Nguy??n V?n C?ng.pdf -- Nguy??n V?n C?ng -------------- next part -------------- An HTML attachment was scrubbed... URL: From hiran.chaudhuri at mail.de Wed May 17 13:08:05 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Wed, 17 May 2017 15:08:05 +0200 Subject: [openssl-users] Build from source; library not found? Message-ID: <20170517130805.7600D400B7@smtp03.mail.de> Hi there. I have been building Openssl for quite some time now. Just recently I switched to shared mode that will also create shared libraries. What I am wondering about: After configure/make/make install I find the expected libraries in the desired output directory. Why can ldd not resolve a librarie's dependencies? The target file is just in the same directory! user at server:/prefix/openssl/lib> ls engines libcrypto.a libcrypto.so libcrypto.so.1.0.0 libssl.a libssl.so libssl.so.1.0.0 pkgconfig user at server:/prefix/openssl/lib> ldd libssl.so.1.0.0 linux-vdso.so.1 => (0x00007ffdae1fb000) libcrypto.so.1.0.0 => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007f8173425000) libc.so.6 => /lib64/libc.so.6 (0x00007f81730a9000) /lib64/ld-linux-x86-64.so.2 (0x00007f81738ad000) user at server:/prefix/openssl/lib> Is this normal behaviour? Or is it because I entered a prefix that is not part of the system's default lib path? Hiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Wed May 17 13:39:36 2017 From: levitte at openssl.org (Richard Levitte) Date: Wed, 17 May 2017 15:39:36 +0200 (CEST) Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170517130805.7600D400B7@smtp03.mail.de> References: <20170517130805.7600D400B7@smtp03.mail.de> Message-ID: <20170517.153936.126156533597692691.levitte@openssl.org> In message <20170517130805.7600D400B7 at smtp03.mail.de> on Wed, 17 May 2017 15:08:05 +0200, Hiran Chaudhuri said: hiran.chaudhuri> Hi there. hiran.chaudhuri> I have been building Openssl for quite some time now. Just recently I hiran.chaudhuri> switched to shared mode that will also create shared libraries. hiran.chaudhuri> What I am wondering about: After configure/make/make install I find hiran.chaudhuri> the expected libraries in the desired output directory. Why can ldd hiran.chaudhuri> not resolve a librarie's dependencies? The target file is just in the hiran.chaudhuri> same directory! hiran.chaudhuri> user at server:/prefix/openssl/lib> ls hiran.chaudhuri> engines libcrypto.a libcrypto.so libcrypto.so.1.0.0 libssl.a libssl.so hiran.chaudhuri> libssl.so.1.0.0 pkgconfig hiran.chaudhuri> user at server:/prefix/openssl/lib> ldd libssl.so.1.0.0 hiran.chaudhuri> linux-vdso.so.1 => (0x00007ffdae1fb000) hiran.chaudhuri> libcrypto.so.1.0.0 => not found hiran.chaudhuri> libdl.so.2 => /lib64/libdl.so.2 (0x00007f8173425000) hiran.chaudhuri> libc.so.6 => /lib64/libc.so.6 (0x00007f81730a9000) hiran.chaudhuri> /lib64/ld-linux-x86-64.so.2 (0x00007f81738ad000) hiran.chaudhuri> user at server:/prefix/openssl/lib> hiran.chaudhuri> Is this normal behaviour? Or is it because I entered a prefix that is hiran.chaudhuri> not part of the system's default lib path? That last question is the correct guess. /etc/ld.so.conf will tell you what your default paths are (and if it includes other files, so will they). The are two ways to handle this. One is with the usual setting of LD_LIBRARY_PATH: $ LD_LIBRARY_PATH=`pwd` ldd libssl.so.1.0.0 The other is, when you compile your application, to use -Wl,-rpath,/prefix/openssl/lib Incidently, I think that when you do this, you'll find that it finds your libraries all right: $ ldd /prefix/openssl/bin/openssl The reason is that the application has been built with said -rpath A last note: with OpenSSL 1.1.0 and on, rpath isn't automatically applied to the openssl application, but is a matter of extra configuration arguments. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From hiran.chaudhuri at mail.de Wed May 17 14:39:39 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Wed, 17 May 2017 16:39:39 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170517.153936.126156533597692691.levitte@openssl.org> References: <20170517.153936.126156533597692691.levitte@openssl.org> Message-ID: <20170517143939.7A4AC40107@smtp03.mail.de> Hi Richard. Thank you for the fast response. Am 17-May-2017 15:40:27 +0200 schrieb levitte at openssl.org: The are two ways to handle this. One is with the usual setting of LD_LIBRARY_PATH: $ LD_LIBRARY_PATH=`pwd` ldd libssl.so.1.0.0 Yes, this seems to work. Somehow I'd like to avoid having to tell every user to use the correct settings. The other is, when you compile your application, to use -Wl,-rpath,/prefix/openssl/lib Where would these options typically go? One of the applications is curl, which worked when I set "LDFLAGS=-R/prefix/openssl/lib" when doing configure/make/make install in the curl build directory. One of the applications is Apache httpd, which seems to not work when doing the same. So I'd definitely try your suggestion. Incidently, I think that when you do this, you'll find that it finds your libraries all right: $ ldd /prefix/openssl/bin/openssl Now this is interesting. Yes, openssl can find both the libraries libssl and libcrypto. Would that imply that rpath is only a setting for application (executables) but not for shared libraries? In that case the test I tried would be totally meaningless. Hiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From hiran.chaudhuri at mail.de Wed May 17 14:48:50 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Wed, 17 May 2017 16:48:50 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170517143939.7A4AC40107@smtp03.mail.de> References: <20170517143939.7A4AC40107@smtp03.mail.de> Message-ID: <20170517144850.A039640107@smtp03.mail.de> I just verified. The required shared libraries and runpath settings are part of the dynamic section in elf files. readelf -d openssl displays a runpath, while readelf -d libssl.so.1.0.0 does not show a runpath. Therefore my test was wrong. I cannot check shared libraries directly. Am 17-May-2017 16:40:40 +0200 schrieb hiran.chaudhuri at mail.de: Now this is interesting. Yes, openssl can find both the libraries libssl and libcrypto. Would that imply that rpath is only a setting for application (executables) but not for shared libraries? In that case the test I tried would be totally meaningless. Hiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From bhat.jayalakshmi at gmail.com Thu May 18 05:32:00 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 17 May 2017 23:32:00 -0600 Subject: [openssl-users] OpenSSL 1.1.1 release timeframe Message-ID: Hi All, Please can any one let me know the release date or time line for OpenSSL 1.1.1? Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu May 18 09:17:29 2017 From: matt at openssl.org (Matt Caswell) Date: Thu, 18 May 2017 10:17:29 +0100 Subject: [openssl-users] OpenSSL 1.1.1 release timeframe In-Reply-To: References: Message-ID: <9d2c80f2-c375-d4a4-4089-1c7079e5609c@openssl.org> On 18/05/17 06:32, Jayalakshmi bhat wrote: > Please can any one let me know the release date or time line for OpenSSL > 1.1.1? We have not set a date as yet. At the very least we will not be able to release until the IETF takes TLSv1.3 out of draft status - which is not in our control. Matt From bhat.jayalakshmi at gmail.com Thu May 18 10:00:12 2017 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 18 May 2017 15:30:12 +0530 Subject: [openssl-users] OpenSSL 1.1.1 release timeframe In-Reply-To: <9d2c80f2-c375-d4a4-4089-1c7079e5609c@openssl.org> References: <9d2c80f2-c375-d4a4-4089-1c7079e5609c@openssl.org> Message-ID: Hi Matt, I do understand. Thanks a lot for the reply. Regards Jayalakshmi On Thu, May 18, 2017 at 2:47 PM, Matt Caswell wrote: > > > On 18/05/17 06:32, Jayalakshmi bhat wrote: > > Please can any one let me know the release date or time line for OpenSSL > > 1.1.1? > > We have not set a date as yet. At the very least we will not be able to > release until the IETF takes TLSv1.3 out of draft status - which is not > in our control. > > Matt > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From varunml at amazon.com Thu May 18 19:28:02 2017 From: varunml at amazon.com (Lodaya, Varun) Date: Thu, 18 May 2017 19:28:02 +0000 Subject: [openssl-users] Question about fetching client ciphers Message-ID: <78B8ED2F-1C35-4D6E-86AB-4FDEC4225336@amazon.com> Hey Guys, Had a question about obtaining client ciphers from OpenSSL library. Currently we are doing SNI by registering to SSL_CTX_set_tlsext_servername_callback and taking a decision on the right certificate. We were trying to figure out how we can get more information like client ciphers, etc in that callback. I see the ?SSL_get_client_ciphers? API in newer (Openssl 1.1.0+), but not in the older versions (Openssl 1.0.2). Is there any other way we can read the client ciphersuite in the callback we register to SSL_CTX_set_tlsext_servername_callback Thanks, Varun -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Thu May 18 20:08:33 2017 From: levitte at openssl.org (Richard Levitte) Date: Thu, 18 May 2017 22:08:33 +0200 (CEST) Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170517143939.7A4AC40107@smtp03.mail.de> References: <20170517.153936.126156533597692691.levitte@openssl.org> <20170517143939.7A4AC40107@smtp03.mail.de> Message-ID: <20170518.220833.1222056080980820799.levitte@openssl.org> In message <20170517143939.7A4AC40107 at smtp03.mail.de> on Wed, 17 May 2017 16:39:39 +0200, Hiran Chaudhuri said: hiran.chaudhuri> Incidently, I think that when you do this, you'll find that it hiran.chaudhuri> finds hiran.chaudhuri> your libraries all right: hiran.chaudhuri> hiran.chaudhuri> $ ldd /prefix/openssl/bin/openssl hiran.chaudhuri> hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the libraries hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only a setting hiran.chaudhuri> for application (executables) but not for shared libraries? hiran.chaudhuri> In that case the test I tried would be totally meaningless. Yes, that's correct. -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Thu May 18 22:35:32 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 18 May 2017 18:35:32 -0400 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170518.220833.1222056080980820799.levitte@openssl.org> References: <20170517.153936.126156533597692691.levitte@openssl.org> <20170517143939.7A4AC40107@smtp03.mail.de> <20170518.220833.1222056080980820799.levitte@openssl.org> Message-ID: > On May 18, 2017, at 4:08 PM, Richard Levitte wrote: > > hiran.chaudhuri> Incidently, I think that when you do this, you'll find that it > hiran.chaudhuri> finds > hiran.chaudhuri> your libraries all right: > hiran.chaudhuri> > hiran.chaudhuri> $ ldd /prefix/openssl/bin/openssl > hiran.chaudhuri> > hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the libraries > hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only a setting > hiran.chaudhuri> for application (executables) but not for shared libraries? > hiran.chaudhuri> In that case the test I tried would be totally meaningless. > > Yes, that's correct. NO, it is not correct, shared libraries also have rpaths for their own dependencies. And when building OpenSSL for installation in non-default locations (not /usr/lib and the like) the libraries should have an rpath. -- Viktor. From ian.gilmour.x at gmail.com Fri May 19 11:02:50 2017 From: ian.gilmour.x at gmail.com (Ian Gilmour) Date: Fri, 19 May 2017 12:02:50 +0100 Subject: [openssl-users] SSL_read() = -1 and SSL_ERROR_SYSCALL, with mem BIO's Message-ID: <88a3617f-8be7-cb9b-c397-ba9aa92e1e46@gmail.com> Hi, I'm using a 3rd party library that maintains a TLS connection to a server using mem BIO's and in which, usually under load, SSL_read() occasionally returns -1, the SSL_get_error() returns SSL_ERROR_SYSCALL and ERR_get_error() returns 0 (errno is 0). Under these conditions the original code closes the existing connection and a few seconds later reopens a new connection to the server. I'd like to try and avoid these short offline periods if possible. When the system is under load I'm seeing this error occur every few minutes. As a test I modified the code to not close the connection on this specific error condition. With this mod in place and the system under load, the connection appears to stay up for hours rather than minutes, with no adverse affects that I can see. But is it valid to do this? Or is the fact that I'm seeing this error so frequently an indication of a problem elsewhere in the code? Thanks in advance, Ian G From jannis.ohms2 at ostfalia.de Fri May 19 12:13:55 2017 From: jannis.ohms2 at ostfalia.de (Jannis Ohms) Date: Fri, 19 May 2017 14:13:55 +0200 Subject: [openssl-users] automating my CA Message-ID: Hi, I need some kind of API which accepts CSRs and signs them Alot of Online certificate providers have some kind of REST API. Is there such an API available as OSS or do i have to write one myself From rpo at compumatica.com Fri May 19 12:23:35 2017 From: rpo at compumatica.com (RudyAC) Date: Fri, 19 May 2017 05:23:35 -0700 (MST) Subject: [openssl-users] RSA_PKCS1_OAEP_PADDING In-Reply-To: <20170515120830.GA15680@openssl.org> References: <1494495232360-70741.post@n7.nabble.com> <20170511151032.GA9549@openssl.org> <1494833405720-70789.post@n7.nabble.com> <20170515120830.GA15680@openssl.org> Message-ID: <1495196615954-70836.post@n7.nabble.com> Hello Steve, you are right. I corrected the code (see below). Now it works! Thank you very much for your quick response. ... /* encrypt content */ cms = CMS_encrypt(NULL, in, cipher, nflags); if(!cms) { KWlog_appl ( EV_D_APPL_INFO , "CMS not allocated!" ); } for (i = 0; i < sk_X509_num(encerts); i++) { CMS_RecipientInfo* r_info; EVP_PKEY_CTX* wrap_ctx = NULL; nflags |= CMS_KEY_PARAM; recip = sk_X509_value(encerts, i); r_info = CMS_add1_recipient_cert(cms, recip, nflags); if (!r_info) { KWlog_appl(EV_E_APPL_INFO, "smime_encrypt_cms(): Error while adding recipient certs to CMS info structure"); return false; } wrap_ctx = CMS_RecipientInfo_get0_pkey_ctx(r_info); KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () Set OAEP Padding"); if (EVP_PKEY_CTX_set_rsa_padding(wrap_ctx, RSA_PKCS1_OAEP_PADDING) <= 0) { KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () Error while setting OAEP Padding"); } EVP_PKEY_CTX_set_rsa_oaep_md(wrap_ctx, EVP_sha256()); EVP_PKEY_CTX_set_rsa_mgf1_md(wrap_ctx, EVP_sha256()); EVP_PKEY_CTX_set0_rsa_oaep_label(wrap_ctx, oaep_label, oaep_label_l); } KWlog ( EV_D_APPL_14 , "smime_encrypt_cms () CMS_final"); CMS_final(cms, in, NULL, nflags); ... Regards Rudy -- View this message in context: http://openssl.6102.n7.nabble.com/RSA-PKCS1-OAEP-PADDING-tp70741p70836.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rsalz at akamai.com Fri May 19 13:45:18 2017 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 19 May 2017 13:45:18 +0000 Subject: [openssl-users] automating my CA In-Reply-To: References: Message-ID: <81b1a3e25b5b4c7594cd88b07398550c@usma1ex-dag1mb1.msg.corp.akamai.com> > Alot of Online certificate providers have some kind of REST API. > > Is there such an API available as OSS or do i have to write one myself You might want to look at the IETF ACME protocol. There are many clients around. And the LetsEncrypt code is open source. From jb-openssl at wisemo.com Fri May 19 13:49:33 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 19 May 2017 15:49:33 +0200 Subject: [openssl-users] automating my CA In-Reply-To: <81b1a3e25b5b4c7594cd88b07398550c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <81b1a3e25b5b4c7594cd88b07398550c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <86aa5ded-367f-7cf5-9e6a-90bc20329910@wisemo.com> On 19/05/2017 15:45, Salz, Rich via openssl-users wrote: >> Alot of Online certificate providers have some kind of REST API. >> >> Is there such an API available as OSS or do i have to write one myself > You might want to look at the IETF ACME protocol. > > There are many clients around. And the LetsEncrypt code is open source. I think he wants the server side, and maybe not for DV certs. 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 hiran.chaudhuri at mail.de Sat May 20 11:10:46 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Sat, 20 May 2017 13:10:46 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: References: Message-ID: <20170520111046.7F38840020@smtp03.mail.de> Am 19-May-2017 00:36:18 +0200 schrieb openssl-users at dukhovni.org: > hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the libraries > hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only a setting > hiran.chaudhuri> for application (executables) but not for shared libraries? > hiran.chaudhuri> In that case the test I tried would be totally meaningless. > > Yes, that's correct. NO, it is not correct, shared libraries also have rpaths for their own dependencies. And when building OpenSSL for installation in non-default locations (not /usr/lib and the like) the libraries should have an rpath. -- Viktor. Hi Viktor. It would sound logical. But how could I then enforce the runpath to be set in the libraries? Hiran -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sat May 20 18:22:07 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sat, 20 May 2017 14:22:07 -0400 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170520111046.7F38840020@smtp03.mail.de> References: <20170520111046.7F38840020@smtp03.mail.de> Message-ID: On Sat, May 20, 2017 at 7:10 AM, Hiran Chaudhuri wrote: > Am 19-May-2017 00:36:18 +0200 schrieb openssl-users at dukhovni.org: > >> hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the >> libraries >> hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only >> a setting >> hiran.chaudhuri> for application (executables) but not for shared >> libraries? >> hiran.chaudhuri> In that case the test I tried would be totally >> meaningless. >> >> Yes, that's correct. > > NO, it is not correct, shared libraries also have rpaths for their > own dependencies. And when building OpenSSL for installation in > non-default locations (not /usr/lib and the like) the libraries > should have an rpath. > > It would sound logical. But how could I then enforce the runpath to be set > in the libraries? https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs. I've never understood the use case - build a new/updated openssl, compile time link against the new one, and then runtime link against the old one. Jeff From levitte at openssl.org Sun May 21 00:52:10 2017 From: levitte at openssl.org (Richard Levitte) Date: Sun, 21 May 2017 02:52:10 +0200 (CEST) Subject: [openssl-users] Build from source; library not found? In-Reply-To: References: <20170517143939.7A4AC40107@smtp03.mail.de> <20170518.220833.1222056080980820799.levitte@openssl.org> Message-ID: <20170521.025210.498132541816881143.levitte@openssl.org> In message on Thu, 18 May 2017 18:35:32 -0400, Viktor Dukhovni said: openssl-users> openssl-users> > On May 18, 2017, at 4:08 PM, Richard Levitte wrote: openssl-users> > openssl-users> > hiran.chaudhuri> Incidently, I think that when you do this, you'll find that it openssl-users> > hiran.chaudhuri> finds openssl-users> > hiran.chaudhuri> your libraries all right: openssl-users> > hiran.chaudhuri> openssl-users> > hiran.chaudhuri> $ ldd /prefix/openssl/bin/openssl openssl-users> > hiran.chaudhuri> openssl-users> > hiran.chaudhuri> Now this is interesting. Yes, openssl can find both the libraries openssl-users> > hiran.chaudhuri> libssl and libcrypto. Would that imply that rpath is only a setting openssl-users> > hiran.chaudhuri> for application (executables) but not for shared libraries? openssl-users> > hiran.chaudhuri> In that case the test I tried would be totally meaningless. openssl-users> > openssl-users> > Yes, that's correct. openssl-users> openssl-users> NO, it is not correct, shared libraries also have rpaths for their openssl-users> own dependencies. And when building OpenSSL for installation in openssl-users> non-default locations (not /usr/lib and the like) the libraries openssl-users> should have an rpath. Err, it is correct insofar that it is how OpenSSL 1.0.2{x} is built. It's possible it SHOULD be built differently, but that's a different story. Here, the question was what's actually done. (side note: BSD is treated differently, 'cause there was a time when the RPATH setting in executable binaries didn't propagate down to the libraries they loaded) -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From hiran.chaudhuri at mail.de Sun May 21 04:50:17 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Sun, 21 May 2017 06:50:17 +0200 Subject: [openssl-users] automating my CA In-Reply-To: References: Message-ID: <0C3E4D45-D178-4C14-887D-F61C17579966@mail.de> Check out "let's encrypt" and the ACME protocol. There is also a free O SS implementation available. Hiran Am 19. Mai 2017 14:13:55 MESZ schrieb Jannis Ohms : >Hi, > >I need some kind of API which accepts CSRs and signs them > >Alot of Online certificate providers have some kind of REST API. > >Is there such an API available as OSS or do i have to write one myself > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun May 21 04:50:56 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 21 May 2017 00:50:56 -0400 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170521.025210.498132541816881143.levitte@openssl.org> References: <20170517143939.7A4AC40107@smtp03.mail.de> <20170518.220833.1222056080980820799.levitte@openssl.org> <20170521.025210.498132541816881143.levitte@openssl.org> Message-ID: > On May 20, 2017, at 8:52 PM, Richard Levitte wrote: > > Err, it is correct insofar that it is how OpenSSL 1.0.2{x} is built. Perhaps by default, I routinely do builds of OpenSSL 1.0.2 in which the library rpaths are set. > It's possible it SHOULD be built differently, but that's a different > story. Here, the question was what's actually done. The choice of additional CFLAGS is up to the user. -- Viktor. From jannis.ohms2 at ostfalia.de Sun May 21 14:17:41 2017 From: jannis.ohms2 at ostfalia.de (Jannis Ohms) Date: Sun, 21 May 2017 16:17:41 +0200 Subject: [openssl-users] automating my CA In-Reply-To: <0C3E4D45-D178-4C14-887D-F61C17579966@mail.de> References: <0C3E4D45-D178-4C14-887D-F61C17579966@mail.de> Message-ID: <64064382-16fa-c35f-dcf6-f0733cca3dd3@ostfalia.de> Thanks Iam currently looking at it. There are alot of available clients for the ACME protocoll. But the only Server compnent I could find is boulder which is the CA of let's encrypt. And ACME is currently undeer standardisation by the IETF Am 21.05.2017 um 06:50 schrieb Hiran Chaudhuri: > Check out "let's encrypt" and the ACME protocol. There is also a free > O SS implementation available. > > Hiran > > Am 19. Mai 2017 14:13:55 MESZ schrieb Jannis Ohms > : > > Hi, > > I need some kind of API which accepts CSRs and signs them > > Alot of Online certificate providers have some kind of REST API. > > Is there such an API available as OSS or do i have to write one myself > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon May 22 16:04:30 2017 From: matt at openssl.org (Matt Caswell) Date: Mon, 22 May 2017 17:04:30 +0100 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2l and 1.1.0f. These releases will be made available on 25th May 2017 between approximately 1200-1600 UTC. Note: These are bug-fix only releases. No security defects are addressed in these releases. Please also note that, as per our previous announcements, support for 1.0.1 ended on 31st December 2016. Yours The OpenSSL Project Team -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 480 bytes Desc: OpenPGP digital signature URL: From varunml at amazon.com Mon May 22 16:50:26 2017 From: varunml at amazon.com (Lodaya, Varun) Date: Mon, 22 May 2017 16:50:26 +0000 Subject: [openssl-users] Question about fetching client ciphers In-Reply-To: <78B8ED2F-1C35-4D6E-86AB-4FDEC4225336@amazon.com> References: <78B8ED2F-1C35-4D6E-86AB-4FDEC4225336@amazon.com> Message-ID: <2502BE8F-0078-4042-8D43-1F8C6847A3BC@amazon.com> Retrying.. From: "Lodaya, Varun" Date: Thursday, May 18, 2017 at 12:28 PM To: "openssl-users at openssl.org" Subject: Question about fetching client ciphers Hey Guys, Had a question about obtaining client ciphers from OpenSSL library. Currently we are doing SNI by registering to SSL_CTX_set_tlsext_servername_callback and taking a decision on the right certificate. We were trying to figure out how we can get more information like client ciphers, etc in that callback. I see the ?SSL_get_client_ciphers? API in newer (Openssl 1.1.0+), but not in the older versions (Openssl 1.0.2). Is there any other way we can read the client ciphersuite or the client-server negotiated ciphersuite in the callback we register to SSL_CTX_set_tlsext_servername_callback? Thanks, Varun -------------- next part -------------- An HTML attachment was scrubbed... URL: From hiran.chaudhuri at mail.de Tue May 23 20:25:41 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Tue, 23 May 2017 22:25:41 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: References: Message-ID: <20170523202541.453604006A@smtp03.mail.de> Hello Victor. So you manage to build OpenSSL with rpaths. Would you like to let me know how this can be achieved? Is CFLAGS the only change required? (from the documentation mentioned earlier it seems I would have to modify the configure script). Hiran Am 21-May-2017 06:51:55 +0200 schrieb openssl-users at dukhovni.org: > On May 20, 2017, at 8:52 PM, Richard Levitte wrote: > > Err, it is correct insofar that it is how OpenSSL 1.0.2{x} is built. Perhaps by default, I routinely do builds of OpenSSL 1.0.2 in which the library rpaths are set. > It's possible it SHOULD be built differently, but that's a different > story. Here, the question was what's actually done. The choice of additional CFLAGS is up to the user. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Guido.Nierhauve at dentsplysirona.com Wed May 24 10:31:29 2017 From: Guido.Nierhauve at dentsplysirona.com (Nierhauve Guido) Date: Wed, 24 May 2017 10:31:29 +0000 Subject: [openssl-users] Build Fails with Error: CMP_CERTREPMESSAGE_PKIFailureInfoString_get0 does not have a number assigned Message-ID: <1E9E72A98BA18D41B922C4DD142FFBE4AD82F074@BHMF314A.SIRONA.ORG> Dear all, I tried to compile the latest cmpforopenssl snapshot with the following result: root at ubuntu:~/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69# make make depend && make _all make[1]: Entering directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' make[1]: Leaving directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' make[1]: Entering directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' make -f ./Makefile.shared -e \ PLATFORM=linux-x86_64 \ PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \ INSTALLTOP='/usr/local' LIBDIR='lib' \ LIBDEPS=' '""' -ldl ' \ LIBNAME=crypto LIBVERSION=1.1 \ LIBCOMPATVERSIONS=';' \ CC='gcc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE' \ LDFLAGS='' \ SHARED_LDFLAGS='-Wl,-znodelete -m64 ' SHLIB_EXT=.so.1.1 \ RC='windres' SHARED_RCFLAGS='' \ link_shlib.linux-shared make[2]: Entering directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' Error: CMP_CERTREPMESSAGE_PKIFailureInfoString_get0 does not have a number assigned LD_LIBRARY_PATH=: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" -Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE -Wl,-znodelete -m64 -shared -Wl,-Bsymbolic -Wl,-soname=libcrypto.so.1.1 -o ./libcrypto.so.1.1 -Wl,--whole-archive,--version-script=crypto.map ./libcrypto.a -Wl,--no-whole-archive -ldl /usr/bin/ld:crypto.map:609: syntax error in VERSION script collect2: error: ld returned 1 exit status Makefile.shared:197: recipe for target 'link_shlib.linux-shared' failed make[2]: *** [link_shlib.linux-shared] Error 1 make[2]: Leaving directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' Makefile:733: recipe for target 'libcrypto.so' failed make[1]: *** [libcrypto.so] Error 2 make[1]: Leaving directory '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' Makefile:133: recipe for target 'all' failed make: *** [all] Error 2 The system is: uname -a Linux ubuntu 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Regards, drnie ----------------------------------------------------------------------------------------------------------- Sirona Dental Systems GmbH ? HRB 24948 ? Vorsitzender des Aufsichtsrats: Dr. Erich Blum ? Sirona Dental Services GmbH ? HRB 25817 ? Gesch?ftsf?hrung: Rainer Berthan ? Michael Geil ? Sitz der Gesellschaften: Bensheim ? Registergericht: AG Darmstadt ? ------------------------------------------------------------------------------------------------------------ Diese E-Mail ist ausschliesslich fuer den angesprochenen Adressaten bestimmt und kann vertrauliche Informationen beinhalten. -- This e-mail is intended only for the designated recipient(s). It may contain confidential or proprietary information. ------------------------------------------------------------------------------------------------------------ -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 24 10:41:33 2017 From: matt at openssl.org (Matt Caswell) Date: Wed, 24 May 2017 11:41:33 +0100 Subject: [openssl-users] Build Fails with Error: CMP_CERTREPMESSAGE_PKIFailureInfoString_get0 does not have a number assigned In-Reply-To: <1E9E72A98BA18D41B922C4DD142FFBE4AD82F074@BHMF314A.SIRONA.ORG> References: <1E9E72A98BA18D41B922C4DD142FFBE4AD82F074@BHMF314A.SIRONA.ORG> Message-ID: <7ac397bb-28ca-06e5-fe0b-942b7d195ccd@openssl.org> On 24/05/17 11:31, Nierhauve Guido wrote: > Dear all, > > > > I tried to compile the latest cmpforopenssl snapshot with the following > result: This is a problem with the cmpforopenssl patch - not a problem with OpenSSL itself (although possibly a simple "make update" will fix it). Please raise this with the cmpforopenssl developers. Matt > > > > root at ubuntu:~/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69# make > > make depend && make _all > > make[1]: Entering directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > make[1]: Leaving directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > make[1]: Entering directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > make -f ./Makefile.shared -e \ > > PLATFORM=linux-x86_64 \ > > PERL="/usr/bin/perl" SRCDIR='.' DSTDIR="." \ > > INSTALLTOP='/usr/local' LIBDIR='lib' \ > > LIBDEPS=' '""' -ldl ' \ > > LIBNAME=crypto LIBVERSION=1.1 \ > > LIBCOMPATVERSIONS=';' \ > > CC='gcc' CFLAGS='-DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM > -DOPENSSLDIR="\"/usr/local/ssl\"" > -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -Wall -O3 -pthread -m64 > -DL_ENDIAN -Wa,--noexecstack -fPIC -DOPENSSL_USE_NODELETE' \ > > LDFLAGS='' \ > > SHARED_LDFLAGS='-Wl,-znodelete -m64 ' SHLIB_EXT=.so.1.1 \ > > RC='windres' SHARED_RCFLAGS='' \ > > link_shlib.linux-shared > > make[2]: Entering directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > Error: CMP_CERTREPMESSAGE_PKIFailureInfoString_get0 does not have a > number assigned > > LD_LIBRARY_PATH=: gcc -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG > -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC > -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM > -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM > -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM > -DOPENSSLDIR="/usr/local/ssl" -DENGINESDIR="/usr/local/lib/engines-1.1" > -Wall -O3 -pthread -m64 -DL_ENDIAN -Wa,--noexecstack -fPIC > -DOPENSSL_USE_NODELETE -Wl,-znodelete -m64 -shared -Wl,-Bsymbolic > -Wl,-soname=libcrypto.so.1.1 -o ./libcrypto.so.1.1 > -Wl,--whole-archive,--version-script=crypto.map ./libcrypto.a > -Wl,--no-whole-archive -ldl > > /usr/bin/ld:crypto.map:609: syntax error in VERSION script > > collect2: error: ld returned 1 exit status > > Makefile.shared:197: recipe for target 'link_shlib.linux-shared' failed > > make[2]: *** [link_shlib.linux-shared] Error 1 > > make[2]: Leaving directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > Makefile:733: recipe for target 'libcrypto.so' failed > > make[1]: *** [libcrypto.so] Error 2 > > make[1]: Leaving directory > '/root/cmpforopenssl-git-e0e35def4c96cdd3c5a956a529d5941649b1fb69' > > Makefile:133: recipe for target 'all' failed > > make: *** [all] Error 2 > > > > > > The system is: > > > > uname -a > > Linux ubuntu 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 > x86_64 x86_64 x86_64 GNU/Linux > > > > Regards, > > > > drnie > > > > ----------------------------------------------------------------------------------------------------------- > Sirona Dental Systems GmbH ? HRB 24948 ? > Vorsitzender des Aufsichtsrats: Dr. Erich Blum ? > Sirona Dental Services GmbH ? HRB 25817 ? > Gesch?ftsf?hrung: Rainer Berthan ? Michael Geil ? > Sitz der Gesellschaften: Bensheim ? Registergericht: AG Darmstadt ? > ------------------------------------------------------------------------------------------------------------ > Diese E-Mail ist ausschliesslich fuer den angesprochenen Adressaten > bestimmt und kann vertrauliche Informationen beinhalten. > -- > This e-mail is intended only for the designated recipient(s). It may > contain confidential or proprietary information. > ------------------------------------------------------------------------------------------------------------ > > > From openssl at openssl.org Thu May 25 13:57:56 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 May 2017 13:57:56 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published Message-ID: <20170525135756.GA25645@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.0.2l 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.0.2l 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.0.2-notes.html OpenSSL 1.0.2l 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.0.2l.tar.gz Size: 5365054 SHA1 checksum: b58d5d0e9cea20e571d903aafa853e2ccd914138 SHA256 checksum: ce07195b659e75f4e1db43552860070061f156a98bb37b672b101ba6e3ddf30c The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2l.tar.gz openssl sha256 openssl-1.0.2l.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZJtRNAAoJENnE0m0OYESROsEIALuf8f97c3YgUOz+72Cqrd+x NEDBmDASsRuIlqkXSkN6CunLUb/FQtCMP1n7POsYMAdNqJz+1tOxwxS42j4qsoxj AdNjf7qn/B0Jhd1A6q6GGxO25tmZne3GEga76ya99+/FRMmUWk/QFdCkaNlRtqf+ +6B3KLCAw/pOsGucS8FIk8Wlr1gR/VTiwlxY63ZhzQg941vVNaOsuz+CNWlTc1pW E06cEBnbkjo23LcZH3E07TWHJdDayfROsZTkOZ30uXXo4Xk/KK/Mk4lOAMd7UPMh gxt/jSNcIjf32sGsJRwydlUq7f4OjQQFkFmm8GDY6HgAyRyN4EKCfEWgrCqQs1w= =F+zf -----END PGP SIGNATURE----- From openssl at openssl.org Thu May 25 13:58:18 2017 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 May 2017 13:58:18 +0000 Subject: [openssl-users] OpenSSL version 1.1.0f published Message-ID: <20170525135818.GA26011@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 OpenSSL version 1.1.0f 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.0f 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.0f 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.0f.tar.gz Size: 5278176 SHA1 checksum: 9e3e02bc8b4965477a7a1d33be1249299a9deb15 SHA256 checksum: 12f746f3f2493b2f39da7ecf63d7ee19c6ac9ec6a4fcd8c229da8a522cb12765 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0f.tar.gz openssl sha256 openssl-1.1.0f.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZJtIgAAoJENnE0m0OYESRKjUH/RkGMsp/PM+PxHXgZ0K5nvYP jbxfoun1iQ27NkFKs/HTueWl5EgVEH4w/qT1SSXUQ8DM/2YY7Z8fDFUh7Xrx5mEM ud5q4pqbdDRjmF7HYMhbR1D6dvKjkOpHPV6OzD3iHg8ssUQNaZpvrn/1KCUZFxp+ tp/Mt9qAqlEAtFGo+qw7wIKa+8Do1y5L151HBk9jPSWIPPGnRzD8z+M0rbTD+bjx t/1emoySoRcUjwkq7xqdBix08Sc69RT8ms8AVhINC8gcMdN93UKu4P4JN7qf2Cai Krx1nkEYQJjp65WB0RGuLaZ0Bs80jJydknvTvFj3azeDfMLCjXg+GX1YSAh6R6k= =fyH8 -----END PGP SIGNATURE----- From mayweg at qint.de Thu May 25 14:14:29 2017 From: mayweg at qint.de (Patrick Mayweg) Date: Thu, 25 May 2017 16:14:29 +0200 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <20170525135756.GA25645@openssl.org> References: <20170525135756.GA25645@openssl.org> Message-ID: <61BED9A0-72AC-4C73-9391-8FF505845F7B@qint.de> Qint Software GmbH Marlene-Dietrich-Str.59 80636 M?nchen +49 172 8910563 Sitz: M?nchen HRB 117326 Gesch?ftsf?hrer: Patrick Mayweg. > On 25.05.2017, at 15:57, OpenSSL wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > OpenSSL version 1.0.2l 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.0.2l 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.0.2-notes.html > > OpenSSL 1.0.2l 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.0.2l.tar.gz > Size: 5365054 > SHA1 checksum: b58d5d0e9cea20e571d903aafa853e2ccd914138 > SHA256 checksum: ce07195b659e75f4e1db43552860070061f156a98bb37b672b101ba6e3ddf30c > > The checksums were calculated using the following commands: > > openssl sha1 openssl-1.0.2l.tar.gz > openssl sha256 openssl-1.0.2l.tar.gz > > Yours, > > The OpenSSL Project Team. > > -----BEGIN PGP SIGNATURE----- > > iQEcBAEBCAAGBQJZJtRNAAoJENnE0m0OYESROsEIALuf8f97c3YgUOz+72Cqrd+x > NEDBmDASsRuIlqkXSkN6CunLUb/FQtCMP1n7POsYMAdNqJz+1tOxwxS42j4qsoxj > AdNjf7qn/B0Jhd1A6q6GGxO25tmZne3GEga76ya99+/FRMmUWk/QFdCkaNlRtqf+ > +6B3KLCAw/pOsGucS8FIk8Wlr1gR/VTiwlxY63ZhzQg941vVNaOsuz+CNWlTc1pW > E06cEBnbkjo23LcZH3E07TWHJdDayfROsZTkOZ30uXXo4Xk/KK/Mk4lOAMd7UPMh > gxt/jSNcIjf32sGsJRwydlUq7f4OjQQFkFmm8GDY6HgAyRyN4EKCfEWgrCqQs1w= > =F+zf > -----END PGP SIGNATURE----- > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From daniel at pocock.pro Thu May 25 14:13:21 2017 From: daniel at pocock.pro (Daniel Pocock) Date: Thu, 25 May 2017 16:13:21 +0200 Subject: [openssl-users] certificate renewal without restarting processes Message-ID: <47a7903e-5fad-0c3b-863e-d9a1d9681175@pocock.pro> Hi, The reSIProcate project is using OpenSSL to load[1] certificates and private keys. It uses SSL_CTX_use_certificate_chain_file in some places and in other places it uses PEM_read_bio_X509 When these APIs are used, can the OpenSSL stack detect updated files on disk and reload them without any intervention from the application? If not, is there any alternative API function that can do that? If it can't be done within OpenSSL, what is the right way for the application developer to go about it? Can those methods simply be called again when a file has been updated, or is any cleanup needed before trying to load the new cert? Regards, Daniel 1. https://github.com/resiprocate/resiprocate/blob/master/resip/stack/ssl/Security.cxx#L386 From rsalz at akamai.com Thu May 25 14:28:30 2017 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 May 2017 14:28:30 +0000 Subject: [openssl-users] certificate renewal without restarting processes In-Reply-To: <47a7903e-5fad-0c3b-863e-d9a1d9681175@pocock.pro> References: <47a7903e-5fad-0c3b-863e-d9a1d9681175@pocock.pro> Message-ID: <7fbb07c60f5c4ee7ac81b740e302db4c@usma1ex-dag1mb1.msg.corp.akamai.com> > It uses SSL_CTX_use_certificate_chain_file in some places and in other places > it uses PEM_read_bio_X509 > > When these APIs are used, can the OpenSSL stack detect updated files on > disk and reload them without any intervention from the application? No, it's a load and use the current contents. You can call them multiple times; the old content will be removed and new content reloaded. From dclarke at blastwave.org Thu May 25 14:29:23 2017 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 25 May 2017 14:29:23 +0000 Subject: [openssl-users] OpenSSL version 1.0.2l published In-Reply-To: <20170525135756.GA25645@openssl.org> References: <20170525135756.GA25645@openssl.org> Message-ID: <866cd9cb-a01f-fd15-842d-640436818539@blastwave.org> So this is exclusively a change to support mingw64 ? That seems to be all that is said here : https://www.openssl.org/news/cl102.txt OpenSSL CHANGES _______________ Changes between 1.0.2l and 1.0.2m [xx XXX xxxx] *) Changes between 1.0.2k and 1.0.2l [25 May 2017] *) Have 'config' recognise 64-bit mingw and choose 'mingw64' as the target platform rather than 'mingw'. [Richard Levitte] . . . Dennis Clarke From openssl-users at dukhovni.org Thu May 25 16:14:44 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 25 May 2017 12:14:44 -0400 Subject: [openssl-users] certificate renewal without restarting processes In-Reply-To: <7fbb07c60f5c4ee7ac81b740e302db4c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <47a7903e-5fad-0c3b-863e-d9a1d9681175@pocock.pro> <7fbb07c60f5c4ee7ac81b740e302db4c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <84439294-1E17-4DAC-B641-D538EECC2B7A@dukhovni.org> > On May 25, 2017, at 10:28 AM, Salz, Rich via openssl-users wrote: > >> It uses SSL_CTX_use_certificate_chain_file in some places and in other places >> it uses PEM_read_bio_X509 >> >> When these APIs are used, can the OpenSSL stack detect updated files on >> disk and reload them without any intervention from the application? > > No, it's a load and use the current contents. > > You can call them multiple times; the old content will be removed and new content reloaded. I doubt this is safe in multi-threaded applications. The only way to do this safely in that situation is to create a new SSL_CTX with the new certificate chain, and arrange for *new* connections to use the new context, while existing connections continue to use the old context. It is possible to call SSL_CTX_free() on the old context even while it is in use, since the object is reference counted and will be finally freed by the last thread to release the object. However, care is required to avoid a race against new threads starting to still use the old context. So some sort of memory barrier is needed to ensure that the only the new context is used to start new connections before calling SSL_CTX_free() on the old. In practice you need some sort of lock that supports shared and exclusive access around whatever structure encapsulates the updatable SSL_CTX: worker thread: acquire read lock use current SSL_CTX to call SSL_new() release read lock update thread: acquire write lock: SSL_CTX_free current context set new context as current context release write lock -- Viktor. From mohit4677 at gmail.com Sun May 28 06:59:02 2017 From: mohit4677 at gmail.com (Mohit Batra) Date: Sun, 28 May 2017 12:29:02 +0530 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library Message-ID: Hello All, I am trying to compile / install a utility from Source on CentOS that utilizes OpenSSL 1.1.0 (latest version) . However, I get the following error: *configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS hostname verification will not be available.* Kindly help me out on this error. Thanks & Regards, Mohit Batra -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun May 28 20:43:01 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 May 2017 20:43:01 +0000 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: References: Message-ID: <8cc65eef4c8a4465a406da1e9ddbce72@usma1ex-dag1mb1.msg.corp.akamai.com> > I am trying to compile / install a utility from Source on CentOS that utilizes OpenSSL 1.1.0 (latest version) . However, I get the following error: > configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS hostname verification will not be available. Most likely, the utility you are trying to build is looking at the system-installed OpenSSL libraries. You have to install OpenSSL 1.1.0 and use those pathnames when you build/configure the utility. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From uri at ll.mit.edu Sun May 28 20:46:22 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Sun, 28 May 2017 20:46:22 +0000 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: <8cc65eef4c8a4465a406da1e9ddbce72@usma1ex-dag1mb1.msg.corp.akamai.com> References: <8cc65eef4c8a4465a406da1e9ddbce72@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: I concur with Rich. CentOS is known for having outdated packages. Regards, Uri Sent from my iPhone On May 28, 2017, at 16:43, Salz, Rich via openssl-users wrote: >> I am trying to compile / install a utility from Source on CentOS that utilizes OpenSSL 1.1.0 (latest version) . However, I get the following error: >> configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS hostname verification will not be available. > > Most likely, the utility you are trying to build is looking at the system-installed OpenSSL libraries. > > You have to install OpenSSL 1.1.0 and use those pathnames when you build/configure the utility. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz at jabber.at Twitter: RichSalz > > > -- > 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/pkcs7-signature Size: 4223 bytes Desc: not available URL: From noloader at gmail.com Sun May 28 20:47:56 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 28 May 2017 16:47:56 -0400 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: References: Message-ID: On Sun, May 28, 2017 at 2:59 AM, Mohit Batra wrote: > Hello All, > > I am trying to compile / install a utility from Source on CentOS that > utilizes OpenSSL 1.1.0 (latest version) . However, I get the following > error: > > configure: WARNING: Cannot find SSL_CTX_get0_param in libssl library. TLS > hostname verification will not be available. > > Kindly help me out on this error. When you build OpenSSL and your program, use an RPATH. Also see https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs . We still don't know what use case is being represented by omitting the RPATH in the OpenSSL build. Building OpenSSL with new library, but runtime link to old library after installation makes no sense to most users. You can probably do it using LD_LIBRARY_PATH, but RPATHs are easier. Jeff From hiran.chaudhuri at mail.de Sun May 28 21:16:58 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Sun, 28 May 2017 23:16:58 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170523202541.453604006A@smtp03.mail.de> References: <20170523202541.453604006A@smtp03.mail.de> Message-ID: <20170528211658.7D9C540026@smtp03.mail.de> It seems I misread the referenced documentation the first time. This stuff contains the answer, it just was not clear to me that also works on Linux. https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs. With that, the libraries have run paths that show the correct target directories. Thanks to all for the hint. Hiran Am 23-May-2017 22:26:38 +0200 schrieb hiran.chaudhuri at mail.de: Hello Victor. So you manage to build OpenSSL with rpaths. Would you like to let me know how this can be achieved? Is CFLAGS the only change required? (from the documentation mentioned earlier it seems I would have to modify the configure script). Hiran Am 21-May-2017 06:51:55 +0200 schrieb openssl-users at dukhovni.org: > On May 20, 2017, at 8:52 PM, Richard Levitte wrote: > > Err, it is correct insofar that it is how OpenSSL 1.0.2{x} is built. Perhaps by default, I routinely do builds of OpenSSL 1.0.2 in which the library rpaths are set. > It's possible it SHOULD be built differently, but that's a different > story. Here, the question was what's actually done. The choice of additional CFLAGS is up to the user. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun May 28 21:25:22 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 May 2017 21:25:22 +0000 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: References: Message-ID: > We still don't know what use case is being represented by omitting the > RPATH in the OpenSSL build. Because only one program, apps/openssl, presumably needs rpath. But that doesn't solve the problem for *external applications* that need to find OpenSSL in a different place, does it? From noloader at gmail.com Sun May 28 21:27:27 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 28 May 2017 17:27:27 -0400 Subject: [openssl-users] Build from source; library not found? In-Reply-To: <20170528211658.7D9C540026@smtp03.mail.de> References: <20170523202541.453604006A@smtp03.mail.de> <20170528211658.7D9C540026@smtp03.mail.de> Message-ID: On Sun, May 28, 2017 at 5:16 PM, Hiran Chaudhuri wrote: > It seems I misread the referenced documentation the first time. > > This stuff contains the answer, it just was not clear to me that also works > on Linux. > https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs. > > With that, the libraries have run paths that show the correct target > directories. Thanks to all for the hint. Arg... I consider confusing text a documentation bug. Is this better: https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs ? Jeff From noloader at gmail.com Sun May 28 21:30:18 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 28 May 2017 17:30:18 -0400 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: References: Message-ID: On Sun, May 28, 2017 at 5:25 PM, Salz, Rich wrote: >> We still don't know what use case is being represented by omitting the >> RPATH in the OpenSSL build. > > Because only one program, apps/openssl, presumably needs rpath. But that doesn't solve the problem for *external applications* that need to find OpenSSL in a different place, does it? > Without RPATH's (or some other mechanism, like making openssl a script that sets LD_LIBRARY_PATH), libssl.so will use the wrong libcrypto.so. The openssl program will use the wrong libssl.so and libcrypto.so. Jeff From rsalz at akamai.com Sun May 28 21:31:57 2017 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 28 May 2017 21:31:57 +0000 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: References: Message-ID: <3b2143f8017f428b80c9a4c1e45aff3b@usma1ex-dag1mb1.msg.corp.akamai.com> > The openssl program will use the wrong libssl.so and libcrypto.so. Yes, got it. But that's small potatoes compared to everyone else finding the wrong shared library, and just saying "use rpath" doesn't help all those others. From noloader at gmail.com Sun May 28 21:51:04 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 28 May 2017 17:51:04 -0400 Subject: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library) Message-ID: On Sun, May 28, 2017 at 5:31 PM, Salz, Rich wrote: >> The openssl program will use the wrong libssl.so and libcrypto.so. > > Yes, got it. > > But that's small potatoes compared to everyone else finding the wrong shared library, and just saying "use rpath" doesn't help all those others. OK, thanks. So what are the problems here that need to be addressed? I think I know some of them: 1. Build OpenSSL with an RPATH if installed in non-system location 2. Build user program with an RPATH if OpenSSL installed in non-system location 3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends) 4. External build tools like Autotools and Cmake Are there others? OpenSSL build system should fix problem (1), like it does with BSDs. The project should lead by example. For (2) and (3), I think the best that can be done is (a) lead by example as in (1); (b) ensure things like libcrypto.pc and libssl.pc are up-to-date; and and (c) educate users. I realize the problems with (c). If RTFM was going to work, then it would have happens in the last 50 years or so. There's not much you can do with(4). They pick shitty flags, and they are always going to be a problem. I advise *not* to build OpenSSL with them, but Fan Boi's will still flock to them. Jeff From hiran.chaudhuri at mail.de Sun May 28 23:31:48 2017 From: hiran.chaudhuri at mail.de (Hiran Chaudhuri) Date: Mon, 29 May 2017 01:31:48 +0200 Subject: [openssl-users] Build from source; library not found? In-Reply-To: References: <20170523202541.453604006A@smtp03.mail.de> <20170528211658.7D9C540026@smtp03.mail.de> Message-ID: <0701B517-31CE-4DE8-9406-6C75231FEFB5@mail.de> Quick reaction, I am impressed. The part that triggered my wrong thoughts was the first sentence: "RPATH's are supported by default on the BSD platforms, but not others." It seemed platforms other than BSD will not get RPATH unless I take action. With that in mind I somehow understood I need to patch the config or configure scripts to get along. Maybe it should read something like "on BSD the run paths are automatically set. For other platforms, add these parameters to your configure line... Hiran Am 28. Mai 2017 23:27:27 MESZ schrieb Jeffrey Walton : >On Sun, May 28, 2017 at 5:16 PM, Hiran Chaudhuri > wrote: >> It seems I misread the referenced documentation the first time. >> >> This stuff contains the answer, it just was not clear to me that also >works >> on Linux. >> >https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs. >> >> With that, the libraries have run paths that show the correct target >> directories. Thanks to all for the hint. > >Arg... I consider confusing text a documentation bug. > >Is this better: >https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs >? > >Jeff >-- >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 Mon May 29 14:39:56 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Mon, 29 May 2017 16:39:56 +0200 Subject: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library) In-Reply-To: References: Message-ID: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> On 28-05-17 23:51, Jeffrey Walton wrote: > So what are the problems here that need to be addressed? I think I > know some of them: > > 1. Build OpenSSL with an RPATH if installed in non-system location > 2. Build user program with an RPATH if OpenSSL installed in non-system location > 3. Use another mechanism when Linux RATH not available (OS X, Solaris, friends) RPATHs have advantages, but they have some major issues, too. For instance, if for whatever reason you need to move files around so that things are stored in a different location, suddenly you'll need to recompile everything -- because the RPATH is a hardcoded location of the library in use. This is very confusing, and not something that an average developer will expect. There is usually no need to hardcode the location of the library in use, provided the SONAME is configured correctly. Surprise surprise, OpenSSL actually does that right: wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.0.2 |grep SONAME SONAME libssl.so.1.0.2 wouter at gangtai:~$ objdump -p /usr/lib/x86_64-linux-gnu/libssl.so.1.1 |grep SONAME SONAME libssl.so.1.1 There is no way that ld.so will load libssl1.1 for an application that is compiled against libssl.so with an SONAME of libssl.1.0.2 -- unless, of course, you do things like muck about with RPATH and point it to the wrong version of the library. In that case, you broke it, you get to keep both pieces. > 4. External build tools like Autotools and Cmake Those are set up to assume that if a library has a particular SONAME, it will be compatible with other versions of that same library. That's usually the correct assumption. Ignoring bugs in configure.ac/Makefile.am and/or CMakeLists.txt files (those are just code too, you know), IME autotools and CMake usually just DTRT, by simply using things like pkg-config to produce the correct -I and/or -L search paths. If you insist on not using them though, that's also possible: %.o: %.c $(CC) -o $@ -c `pkg-config --cflags openssl` $^ target: foo.o bar.o baz.o $(CC) -o $@ `pkg-config --libs openssl` $^ The only reason why you would ever want to use RPATH with OpenSSL is because you need to install a particular old version of libssl (or libcrypto) that has the same SONAME as the system-default, but where you don't want to use that system-default one -- but why would you want to do that? Security updates are a good thing, usually. RPATH support is nice for corner cases, but it should not be the default, ever. -- Wouter Verhelst From Michael.Wojcik at microfocus.com Mon May 29 15:14:12 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 29 May 2017 15:14:12 +0000 Subject: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library) In-Reply-To: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Wouter Verhelst > Sent: Monday, May 29, 2017 10:40 > > RPATHs have advantages, but they have some major issues, too. For > instance, if for whatever reason you need to move files around so that > things are stored in a different location, suddenly you'll need to > recompile everything -- because the RPATH is a hardcoded location of the > library in use. This is very confusing, and not something that an > average developer will expect. Agreed, though in the particular case where library A depends on library B, and the two are normally kept together in the same directory (whatever that directory might be), library A could have an RPATH entry of $ORIGIN to help the loader find B in the same directory. In general, though, RPATHs are bad for software that's going to be distributed to other systems, since they bind an installation directory into the binary. As Wouter says, that violates the principle of least surprise. In the products I work on, we avoid this issue with OpenSSL in particular by building OpenSSL as dynamically-linkable code (PIC, etc, as necesary for each platform), but put the objects into static (Windows) or archive (*ix) libraries. Then we link those libraries into dynamic objects of our own, with additional code on top of the OpenSSL APIs. That prevents accidental run-time binding to some other OpenSSL build that happens to be on the system. It requires hacking the OpenSSL build process, though, which doesn't natively accommodate this "build static libraries for subsequent dynamic linking" model. -- Michael Wojcik Distinguished Engineer, Micro Focus From pgnet.dev at gmail.com Tue May 30 15:20:21 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 30 May 2017 08:20:21 -0700 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? Message-ID: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> I'm building separate local instances of latest Openssl v1.1.0 & v1.0.2 on linux64, to keep not-yet-v110-compliant apps happy. The results are both functional, but the v102l build is missing sha{224|256|384|512} digests v 1.0.2l /usr/local/openssl10/bin/openssl version OpenSSL 1.0.2l 26 Jan 2017 /usr/local/openssl10/bin/openssl version -f compiler: /usr/bin/gcc-7 -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -Wa,--noexecstack -Wall -fno-common -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM /usr/local/openssl10/bin/openssl help ... Message Digest commands (see the `dgst' command for more details) md4 md5 rmd160 sha sha1 ... ldd /usr/local/openssl10/bin/openssl | egrep 'lib(ssl|crypto)' libssl.so.1.0.0 => /usr/local/openssl10/lib64/libssl.so.1.0.0 (0x00007f1619534000) libcrypto.so.1.0.0 => /usr/local/openssl10/lib64/libcrypto.so.1.0.0 (0x00007f16190aa000) v 1.1.0f /usr/local/openssl11/bin/openssl version OpenSSL 1.1.0f 25 May 2017 /usr/local/openssl11/bin/openssl version -f /usr/local/openssl11/bin/openssl version -f compiler: /usr/bin/gcc-7 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_API_COMPAT=0x10100000L -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -DOPENSSLDIR="\"/usr/local/openssl11\"" -DENGINESDIR="\"/usr/local/openssl11/lib64/engines-1.1\"" -Wa,--noexecstack -Wall -fno-common -Wa,--noexecstack /usr/local/openssl11/bin/openssl help ... Message Digest commands (see the `dgst' command for more details) blake2b512 blake2s256 gost md4 md5 rmd160 sha1 sha224 sha256 sha384 sha512 ... ldd /usr/local/openssl11/bin/openssl | egrep 'lib(ssl|crypto)' libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x00007fc9c70f4000) libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x00007fc9c6c48000) The "-DSHA256_ASM" flag is present for the 102l build. Is there an additional, specific flag required to enable the higher bit-depth digests for v102l that I've missed. From rsalz at akamai.com Tue May 30 15:25:12 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 30 May 2017 15:25:12 +0000 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> Message-ID: <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> > The results are both functional, but the v102l build is missing > sha{224|256|384|512} digests Right; those digests are not in 1.0.2 From pgnet.dev at gmail.com Tue May 30 15:29:00 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 30 May 2017 08:29:00 -0700 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <36fff661-02cb-7a85-3bde-6a1ea91edf06@gmail.com> On 5/30/17 8:25 AM, Salz, Rich wrote: >> The results are both functional, but the v102l build is missing >> sha{224|256|384|512} digests > > Right; those digests are not in 1.0.2 > Then I've misunderstood the presence of the "-DSHA256_ASM" flag. What's it specifically used for? From jb-openssl at wisemo.com Tue May 30 15:58:14 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 May 2017 17:58:14 +0200 Subject: [openssl-users] OpenSSL and RPATH's (was: Cannot find SSL_CTX_get0_param in libssl library) In-Reply-To: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> Message-ID: On 29/05/2017 16:39, Wouter Verhelst wrote: > ... > The only reason why you would ever want to use RPATH with OpenSSL is > because you need to install a particular old version of libssl (or > libcrypto) that has the same SONAME as the system-default, but where you > don't want to use that system-default one -- but why would you want to > do that? Security updates are a good thing, usually. There is another, converse case: If the system comes with a (patched) old version of the OpenSSL libraries (for example, Debian 7 comes with a patched OpenSSL 1.0.1 that ensures 100% compatibility with programs compiled against version 1.0.1t headers), then you may also need a special SO name or RPATH to link locally compiled software against the latest 1.0.x release, rather than 1.0.1 . > RPATH support is nice for corner cases, but it should not be the > default, ever. > 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 jb-openssl at wisemo.com Tue May 30 16:01:31 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 May 2017 18:01:31 +0200 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> Message-ID: On 30/05/2017 17:20, PGNet Dev wrote: > I'm building separate local instances of latest Openssl v1.1.0 & v1.0.2 on linux64, to keep not-yet-v110-compliant apps happy. > > The results are both functional, but the v102l build is missing sha{224|256|384|512} digests > > v 1.0.2l > /usr/local/openssl10/bin/openssl version > OpenSSL 1.0.2l 26 Jan 2017 > /usr/local/openssl10/bin/openssl version -f > compiler: /usr/bin/gcc-7 -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -Wa,--noexecstack -Wall -fno-common -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > /usr/local/openssl10/bin/openssl help > ... > Message Digest commands (see the `dgst' command for more details) > md4 md5 rmd160 sha > sha1 > ... > ldd /usr/local/openssl10/bin/openssl | egrep 'lib(ssl|crypto)' > libssl.so.1.0.0 => /usr/local/openssl10/lib64/libssl.so.1.0.0 (0x00007f1619534000) > libcrypto.so.1.0.0 => /usr/local/openssl10/lib64/libcrypto.so.1.0.0 (0x00007f16190aa000) Actually, in my testing of earlier 1.0.x releases, sha256 etc. are only missing from the help message, they are actually there, also as commands. > v 1.1.0f > /usr/local/openssl11/bin/openssl version > OpenSSL 1.1.0f 25 May 2017 > /usr/local/openssl11/bin/openssl version -f > /usr/local/openssl11/bin/openssl version -f > compiler: /usr/bin/gcc-7 -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_API_COMPAT=0x10100000L -D_GNU_SOURCE -DOPENSSL_NO_BUF_FREELISTS -DOPENSSL_NO_HEARTBEAT -DPURIFY -DSSL_FORBID_ENULL -DTERMIO -DOPENSSLDIR="\"/usr/local/openssl11\"" -DENGINESDIR="\"/usr/local/openssl11/lib64/engines-1.1\"" -Wa,--noexecstack -Wall -fno-common -Wa,--noexecstack > /usr/local/openssl11/bin/openssl help > ... > Message Digest commands (see the `dgst' command for more details) > blake2b512 blake2s256 gost md4 > md5 rmd160 sha1 sha224 > sha256 sha384 sha512 > ... > ldd /usr/local/openssl11/bin/openssl | egrep 'lib(ssl|crypto)' > libssl.so.1.1 => /usr/local/openssl11/lib64/libssl.so.1.1 (0x00007fc9c70f4000) > libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x00007fc9c6c48000) > > > The "-DSHA256_ASM" flag is present for the 102l build. Is there an additional, specific flag required to enable the higher bit-depth digests for v102l that I've missed. > 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 pgnet.dev at gmail.com Tue May 30 16:12:28 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 30 May 2017 09:12:28 -0700 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> Message-ID: <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> >> The only reason why you would ever want to use RPATH with OpenSSL is >> because you need to install a particular old version of libssl (or >> libcrypto) that has the same SONAME as the system-default, but where you >> don't want to use that system-default one -- but why would you want to >> do that? Security updates are a good thing, usually. On 5/30/17 8:58 AM, Jakob Bohm wrote: > On 29/05/2017 16:39, Wouter Verhelst wrote: >> ... >> The only reason why you would ever want to use RPATH with OpenSSL is ... Well, 'different strokes' to be sure ... but, here, especially with lots of apps still not at all v110 compatible, or at best broken in their attempts, having local builds of both v110x and v102x is extremely useful -- and RPATH'ing makes that trivially manageable. My $.02. From rsalz at akamai.com Tue May 30 16:14:06 2017 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 30 May 2017 16:14:06 +0000 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: <36fff661-02cb-7a85-3bde-6a1ea91edf06@gmail.com> References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> <36fff661-02cb-7a85-3bde-6a1ea91edf06@gmail.com> Message-ID: <9a777fa437cf487da9947aec3cd18887@usma1ex-dag1mb1.msg.corp.akamai.com> > Then I've misunderstood the presence of the "-DSHA256_ASM" flag. > > What's it specifically used for? To remind me to double-check my answers? :( Sorry, they are present. The difference is that the help message in 1.0.2 isn't complete. Did you try the commands directly? From pgnet.dev at gmail.com Tue May 30 16:21:36 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Tue, 30 May 2017 09:21:36 -0700 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> Message-ID: <2b0a4ff6-44b7-c8fc-9f18-1532cea65ced@gmail.com> On 5/30/17 9:01 AM, Jakob Bohm wrote: > Actually, in my testing of earlier 1.0.x releases, sha256 etc. are > only missing from the help message, they are actually there, also as > commands. On 5/30/17 9:14 AM, Salz, Rich wrote: >> Then I've misunderstood the presence of the "-DSHA256_ASM" flag. >> >> What's it specifically used for? > > To remind me to double-check my answers? :( > > Sorry, they are present. The difference is that the help message in 1.0.2 isn't complete. Did you try the commands directly? Well, touch /tmp/test.txt /usr/local/openssl10/bin/openssl dgst -sha256 /tmp/test.txt SHA256(/tmp/test.txt)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 /usr/local/openssl11/bin/openssl dgst -sha256 /tmp/test.txt SHA256(/tmp/test.txt)= e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 NOW I have! See? THAT'S what you get when you waste time RTFM-ing! ;-) Thanks. From jb-openssl at wisemo.com Tue May 30 16:30:39 2017 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 May 2017 18:30:39 +0200 Subject: [openssl-users] Cannot find SSL_CTX_get0_param in libssl library In-Reply-To: <3b2143f8017f428b80c9a4c1e45aff3b@usma1ex-dag1mb1.msg.corp.akamai.com> References: <3b2143f8017f428b80c9a4c1e45aff3b@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <7d82d47e-0968-07f3-7c21-027529bdc08d@wisemo.com> On 28/05/2017 23:31, Salz, Rich via openssl-users wrote: >> The openssl program will use the wrong libssl.so and libcrypto.so. > Yes, got it. > > But that's small potatoes compared to everyone else finding the wrong shared library, and just saying "use rpath" doesn't help all those others. Change the /usr/lib/libssl.so symlink to point to libssl.so.1.1, not libssl.so.1.0 while compiling with OpenSSL 1.1.x headers. Ditto for libcrypto.so. Alternatively, place such symlinks in the lib directory that is next to the include directory with OpenSSL 1.1.x headers. This should cause the resulting programs to refer to the right so-name (libssl.so.1.1 etc.) and thus either load the right library generation (1.1.x) or report that it isn't installed on the local library path (typically, /lib/, /usr/lib/ and /usr/local/lib/ in some system dependent order). After all, this is the whole point of the versioned .so file names. 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 wouter.verhelst at fedict.be Tue May 30 15:44:25 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Tue, 30 May 2017 17:44:25 +0200 Subject: [openssl-users] sha256 digest support in v102l build missing; present in v110f. missing build flag? In-Reply-To: <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <4cb23172-a353-2d96-5cf5-002080c99c0c@gmail.com> <3e1758d7195d483b909c63c1a749bef6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <844f5054-1f0f-fd3a-95a9-e154e336491b@fedict.be> On 30-05-17 17:25, Salz, Rich via openssl-users wrote: >> The results are both functional, but the v102l build is missing >> sha{224|256|384|512} digests > > Right; those digests are not in 1.0.2 They are, they're just not advertised: $ openssl version OpenSSL 1.0.2k 26 Jan 2017 $ openssl help [...] Message Digest commands (see the `dgst' command for more details) md4 md5 mdc2 rmd160 sha sha1 [...] $ openssl dgst -sha256 .bash_history SHA256(.bash_history)= b8f9308c4b9141993b4af1cee6cdffe36339bc2e05c0bf16206f9944f85aa102 $ openssl sha224 .bash_history SHA224(.bash_history)= a13d7f83a0dc0dcfb6032cb3cd7c4669958a2fb0e01dbb72c95e1d02 etc. -- Wouter Verhelst From wouter.verhelst at fedict.be Wed May 31 10:16:53 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 31 May 2017 12:16:53 +0200 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> Message-ID: <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> On 30-05-17 18:12, PGNet Dev wrote: [...] > with lots of apps still not at all v110 > compatible, or at best broken in their attempts, having local builds of > both v110x and v102x is extremely useful -- and RPATH'ing makes that > trivially manageable. That's exactly my point -- you don't need to use RPATH to handle that (very common) case. You just need to link against the correct .so file at compile time (which can be handled by installing them in separate directories and using -L to specify which one to link to); the runtime dynamic linker will then find a v1.1 version of OpenSSL for applications compiled against 1.1.0x, or a v1.0.2 version for applications compiled against 1.0.2x. It's that simple. RPATH is useful if the SONAME is the same but the libraries aren't, for whatever reason (e.g., local patches). Other than that, you don't need it, and it's generally a bad idea. -- Wouter Verhelst From openssl-users at dukhovni.org Wed May 31 15:07:04 2017 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 31 May 2017 11:07:04 -0400 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> Message-ID: > On May 31, 2017, at 6:16 AM, Wouter Verhelst wrote: > > RPATH is useful if the SONAME is the same but the libraries aren't, for > whatever reason (e.g., local patches). Other than that, you don't need > it, and it's generally a bad idea. There's no need to take absolutist view on this subject. RPATHs are a tool that some will find useful, and others will prefer to avoid. -- -- Viktor. From pgnet.dev at gmail.com Wed May 31 15:11:31 2017 From: pgnet.dev at gmail.com (PGNet Dev) Date: Wed, 31 May 2017 08:11:31 -0700 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> Message-ID: <48ec6a61-7134-f3a8-128f-26c25d3eaa93@gmail.com> On 5/31/17 3:16 AM, Wouter Verhelst wrote: > On 30-05-17 18:12, PGNet Dev wrote: > [...] >> with lots of apps still not at all v110 >> compatible, or at best broken in their attempts, having local builds of >> both v110x and v102x is extremely useful -- and RPATH'ing makes that >> trivially manageable. > > That's exactly my point -- you don't need to use RPATH to handle that > (very common) case. You just need to link against the correct .so file > at compile time (which can be handled by installing them in separate > directories and using -L to specify which one to link to); the runtime > dynamic linker will then find a v1.1 version of OpenSSL for applications > compiled against 1.1.0x, or a v1.0.2 version for applications compiled > against 1.0.2x. It's that simple. > > RPATH is useful if the SONAME is the same but the libraries aren't, for > whatever reason (e.g., local patches). Other than that, you don't need > it, Not quite. System Install ls -al /usr/lib64/lib{ssl,crypto}.* lrwxrwxrwx 1 root root 25 Feb 16 16:54 /usr/lib64/libcrypto.so -> /lib64/libcrypto.so.1.0.0* lrwxrwxrwx 1 root root 22 Feb 16 16:54 /usr/lib64/libssl.so -> /lib64/libssl.so.1.0.0* ldd /usr/lib64/libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007f390d0eb000) Local Install ls -al /usr/local/openssl10/lib64/lib{ssl,crypto}.* -rw-r--r--+ 1 root root 4.7M May 30 08:38 /usr/local/openssl10/lib64/libcrypto.a lrwxrwxrwx 1 root root 18 May 30 08:38 /usr/local/openssl10/lib64/libcrypto.so -> libcrypto.so.1.0.0* -r-xr-xr-x+ 1 root root 2.9M May 30 08:38 /usr/local/openssl10/lib64/libcrypto.so.1.0.0* -rw-r--r--+ 1 root root 737K May 30 08:38 /usr/local/openssl10/lib64/libssl.a lrwxrwxrwx 1 root root 15 May 30 08:38 /usr/local/openssl10/lib64/libssl.so -> libssl.so.1.0.0* -r-xr-xr-x+ 1 root root 503K May 30 08:38 /usr/local/openssl10/lib64/libssl.so.1.0.0* ldd /usr/local/openssl10/lib64/libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /usr/local/openssl10/lib64/libcrypto.so.1.0.0 (0x00007f3bcd526000) Local Install ls -al /usr/local/openssl11/lib64/lib{ssl,crypto}.* -rw-r--r--+ 1 root root 4.9M May 30 08:50 /usr/local/openssl11/lib64/libcrypto.a lrwxrwxrwx 1 root root 16 May 30 08:50 /usr/local/openssl11/lib64/libcrypto.so -> libcrypto.so.1.1* -rwxr-xr-x+ 1 root root 3.0M May 30 08:50 /usr/local/openssl11/lib64/libcrypto.so.1.1* -rw-r--r--+ 1 root root 745K May 30 08:50 /usr/local/openssl11/lib64/libssl.a lrwxrwxrwx 1 root root 13 May 30 08:50 /usr/local/openssl11/lib64/libssl.so -> libssl.so.1.1* -rwxr-xr-x+ 1 root root 509K May 30 08:50 /usr/local/openssl11/lib64/libssl.so.1.1* ldd /usr/local/openssl11/lib64/libssl.so | egrep "ssl|crypto" libcrypto.so.1.1 => /usr/local/openssl11/lib64/libcrypto.so.1.1 (0x00007f4be3d5d000) etc ... > and it's generally a bad idea. And, IMO, that's just bad advice. RPATH is perfectly fine, and this^ is exactly what it exists for. Feel free to use it or not, but don't FUD perfectly legitimate functionality as a 'bad idea'. From Michael.Wojcik at microfocus.com Wed May 31 15:33:33 2017 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 31 May 2017 15:33:33 +0000 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: <48ec6a61-7134-f3a8-128f-26c25d3eaa93@gmail.com> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> <48ec6a61-7134-f3a8-128f-26c25d3eaa93@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of PGNet Dev > Sent: Wednesday, May 31, 2017 11:12 > > And, IMO, that's just bad advice. RPATH is perfectly fine, and this^ is exactly > what it exists for. Feel free to use it or not, but don't FUD perfectly > legitimate functionality as a 'bad idea'. I, on the other hand, agree with Wouter. Binding filesystem information into a binary is an inherently bad idea. It violates the principle of least surprise and goes against conventions of UNIX filesystem use that have existed for more than four decades. It's not adequately visible to users or applications. The fact that it solves certain problems doesn't change that. Sometimes it may even be the best of a set of poor solutions (though frankly I'm not convinced your example is such a case). That, too, does not mean it's not a bad idea. Obviously "bad idea" is a largely subjective assessment. Characterizing it as FUD, however, is unjustified. Of course, the real problem is excessive coupling between dynamically-bound code in the first place, caused by inadequate naming and versioning conventions, and even more so by poor backward and forward compatibility. OpenSSL is not a particular offender in this area, relatively speaking; the problem is widespread (and many attempts to resolve it are misguided aggravations, like Microsoft's SxS mess). Regardless: Clearly there is no consensus that it's a *good* idea, and therefore having the OpenSSL build set RPATH by default (as has been suggested by some people in this thread) would be undesirable. Michael Wojcik Distinguished Engineer, Micro Focus From wouter.verhelst at fedict.be Wed May 31 15:16:29 2017 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 31 May 2017 17:16:29 +0200 Subject: [openssl-users] OpenSSL and RPATH's In-Reply-To: <48ec6a61-7134-f3a8-128f-26c25d3eaa93@gmail.com> References: <913e4bd9-2a48-8a51-ecd9-e0acec94c38d@fedict.be> <39d06505-29b0-3446-080f-f1c5e090b902@gmail.com> <342d2741-9142-d08b-cfa2-e2fc44a88068@fedict.be> <48ec6a61-7134-f3a8-128f-26c25d3eaa93@gmail.com> Message-ID: <508cc1d0-4c8b-4fa5-6fc0-47835d91d8bb@fedict.be> On 31-05-17 17:11, PGNet Dev wrote: > On 5/31/17 3:16 AM, Wouter Verhelst wrote: >> On 30-05-17 18:12, PGNet Dev wrote: >> [...] >>> with lots of apps still not at all v110 >>> compatible, or at best broken in their attempts, having local builds of >>> both v110x and v102x is extremely useful -- and RPATH'ing makes that >>> trivially manageable. >> >> That's exactly my point -- you don't need to use RPATH to handle that >> (very common) case. You just need to link against the correct .so file >> at compile time (which can be handled by installing them in separate >> directories and using -L to specify which one to link to); the runtime >> dynamic linker will then find a v1.1 version of OpenSSL for applications >> compiled against 1.1.0x, or a v1.0.2 version for applications compiled >> against 1.0.2x. It's that simple. >> >> RPATH is useful if the SONAME is the same but the libraries aren't, for >> whatever reason (e.g., local patches). Other than that, you don't need >> it, [...example...] >> and it's generally a bad idea. > > And, IMO, that's just bad advice. RPATH is perfectly fine, and this^ is exactly what it exists for. Feel free to use it or not, but don't FUD perfectly legitimate functionality as a 'bad idea'. You're quoting me out of context. I said "Other than that, [...] it's generally a bad idea". I didn't say "it's always a bad idea", nor did I imply that. I also said "RPATH is useful if the SONAME is the same but the libraries aren't". Your example (snipped for brevity) is an example of exactly that. So we're in agreement? -- Wouter Verhelst From xiangsiyuan at gmail.com Wed May 31 20:22:41 2017 From: xiangsiyuan at gmail.com (Siyuan Xiang) Date: Wed, 31 May 2017 13:22:41 -0700 Subject: [openssl-users] enable TLS_RSA_WITH_RC4_128_MD5 in openssl 1.1.0e? Message-ID: Hi all, I have a legacy server only accept TLS_RSA_WITH_RC4_128_MD5 cipher. I have a client using openssl 1.1.0e. It doesn't include TLS_RSA_WITH_RC4_128_MD5. I have recompiled the openssl using enable-weak-ssl-ciphers, but it doesn't work but TLS_RSA_WITH_RC4_128_SHA is in client hello message. It looks like all MD5 related ciphers are removed. I tried to use SSL_CTX_set_security_level to set level to 0. but it doesn't work. Do you have any idea how to enable TLS_RSA_WITH_RC4_128_MD5? Regards, Siyuan --- -------------- next part -------------- An HTML attachment was scrubbed... URL: