From sugu.ece28 at gmail.com Fri Jan 1 09:29:56 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Fri, 1 Jan 2016 02:29:56 -0700 (MST) Subject: [openssl-users] Convert RSA key string to PEM file. Message-ID: <1451640596033-61971.post@n7.nabble.com> Hi, I have a RSA Public key as string type. I need to convert this string to PEM file. Please help me to create PEM file from string type. If u have any sample programs pls post it also for better understanding. -- View this message in context: http://openssl.6102.n7.nabble.com/Convert-RSA-key-string-to-PEM-file-tp61971.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From sugu.ece28 at gmail.com Fri Jan 1 10:24:25 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Fri, 1 Jan 2016 03:24:25 -0700 (MST) Subject: [openssl-users] Difference between BIO and Normal openssl functions Message-ID: <1451643865421-61972.post@n7.nabble.com> Hi, I have seen both BIO and normal openssl functions. Actually what is the difference between both the functions. Example: We have PEM_read_BIO_RSAPrivatekey and PEM_read_RSAPrivatekey functions, What makes these functions different from each other???? -- View this message in context: http://openssl.6102.n7.nabble.com/Difference-between-BIO-and-Normal-openssl-functions-tp61972.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From noloader at gmail.com Fri Jan 1 13:48:51 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 1 Jan 2016 08:48:51 -0500 Subject: [openssl-users] Which Coverity project to subscribe to? Message-ID: I see there are two OpenSSL projects listed at https://scan.coverity.com/projects?utf8=%E2%9C%93&search=openssl : * OpenSSL * OpenSSL_release I'm guessing OpenSSL_release is the results from the sources in the release tarball. Is that correct? Is there a list covering, say, daily builds? Would that be the vanilla OpenSSL? Thanks in advance. From kgoldman at us.ibm.com Fri Jan 1 19:40:49 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 1 Jan 2016 14:40:49 -0500 Subject: [openssl-users] Convert RSA key string to PEM file. In-Reply-To: <1451640596033-61971.post@n7.nabble.com> References: <1451640596033-61971.post@n7.nabble.com> Message-ID: On 1/1/2016 4:29 AM, Sugumar wrote: > Hi, > > I have a RSA Public key as string type. > I need to convert this string to PEM file. Please help me to create PEM file > from string type. Convert the string to a binary array. Convert the array n and e to bignum *bn = BN_bin2bn(bin, bytes, *bn); Create an RSA structure and assign n and e to the bignums rsa_pub_key = RSA_new(); (rsa_pub_key)->n = n; (rsa_pub_key)->e = e; (rsa_pub_key)->d = NULL; RSA *rsa_pub_key EVP_PKEY *pkey = NULL; pkey = EVP_PKEY_new(); irc = EVP_PKEY_assign_RSA(pkey, rsa_pub_key); pemFile = fopen(pemFilename, "wb"); irc = PEM_write_PUBKEY(pemFile, pkey); fclose(pemFile); From sugu.ece28 at gmail.com Sat Jan 2 04:36:54 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Fri, 1 Jan 2016 21:36:54 -0700 (MST) Subject: [openssl-users] Convert RSA key string to PEM file. In-Reply-To: References: <1451640596033-61971.post@n7.nabble.com> Message-ID: <1451709414779-61977.post@n7.nabble.com> Ya your example looks good. Thanks. And i have another method, i have created BIO by passing that key to BIO_new_mem_buf function then from that BIO i got a RSA structure using PEM_read_bio_RSAPublicKey function. Is that will work for me??? Code: RSA* CreateRSAStruct(void* data, GetKey type) { RSA *rsa= NULL; BIO *rsaKeyBio; rsaKeyBio = BIO_new_mem_buf(data, -1); //creates read only memory BIO if (rsaKeyBio==NULL) { std::cout<< "Failed to create key BIO" < References: <2580476.uZjsrlHnGz@polaris> <20151230130819.GA9243@roeckx.be> Message-ID: <42701497.nvJzjvrLV7@polaris> And Kurt... you were right. When setting a pixelserver to do DNS-level ad-blocking, I set up a loopback interfaces 192.0.0.2 (It should have been 127.0.0.2) So... yes as github is 192.30... everything was directed to loopback iface, and my apache server was the one answering :S Thank you for making me think! Felix On Wednesday, 30 December 2015 14:08:19 CET Kurt Roeckx wrote: > On Tue, Dec 29, 2015 at 08:35:49PM +0100, Felix Rubio Dalmau wrote: > > Hi all, > > > > I have been searching for some time for a solution and I can not manage to > > solve my problem. I have a computer that can not connect to some sites, e.g. > > github, by using openssl. I am running a debian testing with all the updates > > available as of today, and libssl used is v1.0.2. If I execute: > > > > > openssl s_client -connect github.com:443 > > The trace file you attached, which claims to go github.com:443, > did send a Client Hello. However the reply is a plain text > "400 Bad Request". It looks like you connected to port 80 and not > 443 for some reason. I suspect something is broken in your network. > > > Kurt > > From marcosbontempo at hotmail.com Sun Jan 3 14:30:27 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 3 Jan 2016 12:30:27 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) In-Reply-To: References: Message-ID: I'm searching but I cannot find nothing about the error:00000000:lib(0):func(0):reason(0) when enabling FIPS mode. From: marcosbontempo at hotmail.com To: openssl-users at openssl.org Date: Sun, 27 Dec 2015 17:30:25 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) Hello, I'm trying to enable FIPS mode with this code:__________________________________________________________________#include #include #include int main ( int argc, char *argv[] ){#ifdef OPENSSL_FIPS int mode, result; // Get FIPS mode if(strcmp("get",argv[1]) == 0) { mode = FIPS_mode(); if(mode == 0) { printf("*** FIPS module is disabled. ***\n"); } if(mode == 1) { printf("*** FIPS module is enabled. ***\n"); } } // Set FIPS mode else if(strcmp("set",argv[1]) == 0) { if(strcmp("0",argv[2]) == 0) { printf("*** Disabling FIPS module. ***\n"); result = FIPS_mode_set(0); if(result != 1) { ERR_load_crypto_strings(); printf("*** Failed to disable FIPS module. ***\n"); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); return 1; } } else if (strcmp("1",argv[2]) == 0) { printf("*** Enabling FIPS module. ***\n"); result = FIPS_mode_set(1); if(result != 1) { ERR_load_crypto_strings(); printf("*** Failed to enable FIPS module. ***\n"); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); return 1; } } else { printf("*** Error: unsupported option. ***\n"); return 1; } } // Unsupported option else { printf("*** Error: unsupported option. ***\n"); return 1; } return 0; #else printf("OPENSSL_FIPS is not defined"); #endif //OPENSSL_FIPS } __________________________________________________________________ And with this Makefile: __________________________________________________________________CC=gccOPENSSLDIR=/usr/local/sslLIBS=$(OPENSSLDIR)/lib/libcrypto.a $(OPENSSLDIR)/lib/libssl.a -ldl INCLUDES=-I$(OPENSSLDIR)/includeCMD=fipsctl OBJS=$(CMD).o $(CMD): $(OBJS) FIPSLD_CC=$(CC) $(OPENSSLDIR)/bin/fipsld -o $(CMD) $(OBJS) -ldl \ $(LIBS) $(OBJS): $(CMD).c $(CC) -c $(CMD).c $(INCLUDES) clean: rm -Rf *.o $(CMD)__________________________________________________________________ It compiles without errors. When I try to enable FIPS mode, I get this output: arm:~/nitere/new$ ./fipsctl set 1*** Enabling FIPS module. ****** Failed to enable FIPS module. ***error:00000000:lib(0):func(0):reason(0) But FIPS is still disabled: arm:~/nitere/new$ ./fipsctl get*** FIPS module is disabled. *** Does somebody knows what is wrong? Any tip will be very helpful,Thanks. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Sun Jan 3 15:27:15 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 3 Jan 2016 10:27:15 -0500 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) In-Reply-To: References: Message-ID: > It compiles without errors. When I try to enable FIPS mode, I get this > output: > > arm:~/nitere/new$ ./fipsctl set 1 > *** Enabling FIPS module. *** > *** Failed to enable FIPS module. *** > error:00000000:lib(0):func(0):reason(0) > > But FIPS is still disabled: > > arm:~/nitere/new$ ./fipsctl get > *** FIPS module is disabled. *** > > Does somebody knows what is wrong? Just a guess, but it looks like ERR_get_error() is returning the result of loading the error strings. If FIPS_mode_set fails, then grab ERR_get_error() immediately and ouput it in hex. With the hex error code, you can: $ openssl errstr 0x060800A3 error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips Jeff From marcosbontempo at hotmail.com Sun Jan 3 15:49:26 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 3 Jan 2016 13:49:26 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) In-Reply-To: References: , , Message-ID: Thanks for the answer! The function ERR_get_error() is returning 0x00000000. Do you know what it means?I used the command you suggested:arm:~/nitere/new$ openssl errstr 0x00000000error:00000000:lib(0):func(0):reason(0) > Date: Sun, 3 Jan 2016 10:27:15 -0500 > From: noloader at gmail.com > To: openssl-users at openssl.org > Subject: Re: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) > > > It compiles without errors. When I try to enable FIPS mode, I get this > > output: > > > > arm:~/nitere/new$ ./fipsctl set 1 > > *** Enabling FIPS module. *** > > *** Failed to enable FIPS module. *** > > error:00000000:lib(0):func(0):reason(0) > > > > But FIPS is still disabled: > > > > arm:~/nitere/new$ ./fipsctl get > > *** FIPS module is disabled. *** > > > > Does somebody knows what is wrong? > > Just a guess, but it looks like ERR_get_error() is returning the > result of loading the error strings. > > If FIPS_mode_set fails, then grab ERR_get_error() immediately and > ouput it in hex. With the hex error code, you can: > > $ openssl errstr 0x060800A3 > error:060800A3:digital envelope routines:EVP_DigestInit_ex:disabled for fips > > Jeff > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Sun Jan 3 16:24:45 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Sun, 3 Jan 2016 14:24:45 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) In-Reply-To: References: , , , , Message-ID: I'm getting the code 0 but the FIPS mode still is disabled.#include #include #include int main ( int argc, char *argv[] ){ int rc, mode; mode = FIPS_mode(); if(mode == 0) { rc = FIPS_mode_set(1); ERR_load_crypto_strings(); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); } else { printf("Already in FIPS mode\n"); } return 0;} Every time I run it I get error:00000000:lib(0):func(0):reason(0). > Date: Sun, 3 Jan 2016 10:54:19 -0500 > Subject: Re: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) > From: noloader at gmail.com > To: marcosbontempo at hotmail.com > > On Sun, Jan 3, 2016 at 10:48 AM, Marcos Bontempo > wrote: > > Thanks for the answer! The function ERR_get_error() is returning 0x00000000. > > Do you know what it means? > > I believe it means success. > > > I used the command you suggested: > > > > arm:~/nitere/new$ openssl errstr 0x00000000 > > error:00000000:lib(0):func(0):reason(0) > > You should run the command on the error code you receive immediately > after calling FIPS_mode_set. > > Or, use ERR_print_errors() to print the entire error stack. > > You should probably reduce your testing to something simpler until you > figure out what's going on. Maybe somethin glike > https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B#The_C.2B.2B_Program > . > > Jeff -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Mon Jan 4 07:47:29 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 4 Jan 2016 00:47:29 -0700 (MST) Subject: [openssl-users] OpenSSL 1.0.1q build fails on RS6000, SunSparc and HPIA Message-ID: <1451893649972-62001.post@n7.nabble.com> Hi, I need to build OpenSSL 1.0.1q on various platforms. At first I could only build 1.0.1q on windows. After reading the following post, I could build it on various Linux platforms. http://openssl.6102.n7.nabble.com/OpenSSL-version-1-0-1q-released-corrected-download-td61415.html However building 1.0.1q on RS6000, SunSparc and HPIA still fails becasue 'make depend' doesn't work on these platforms at all. Take RS6000 as an example, the following is the output of 'make depend'. $ pwd /rahav_ocsdev/qun/OpenSSL/openssl-1.0.1q $ make depend making depend in crypto... make[1]: Entering directory `/rahav_ocsdev/qun/OpenSSL/openssl-1.0.1q/crypto' ../util/domd[30]: makedepend: not found mv: cannot rename Makefile.new to Makefile: No such file or directory make[1]: *** [local_depend] Error 127 make[1]: Leaving directory `/rahav_ocsdev/qun/OpenSSL/openssl-1.0.1q/crypto' make: *** [depend] Error 1 Anyone knows how to solve this issue? Any suggestion is appreciated. Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1q-build-fails-on-RS6000-SunSparc-and-HPIA-tp62001.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From kaushalshriyan at gmail.com Mon Jan 4 10:11:46 2016 From: kaushalshriyan at gmail.com (Kaushal Shriyan) Date: Mon, 4 Jan 2016 15:41:46 +0530 Subject: [openssl-users] letter 's' in s_client in openssl Message-ID: Hi, what does the letter 's' signify in *s_client* in the command "openssl s_client -servername test.example.com -connect test.example.com:443 -showcerts" ? Regards, Kaushal -------------- next part -------------- An HTML attachment was scrubbed... URL: From wouter.verhelst at fedict.be Mon Jan 4 10:15:10 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Mon, 4 Jan 2016 11:15:10 +0100 Subject: [openssl-users] letter 's' in s_client in openssl In-Reply-To: References: Message-ID: <568A462E.6080804@fedict.be> On 04-01-16 11:11, Kaushal Shriyan wrote: > Hi, > > what does the letter 's' signify in *s_client* in the command "openssl > s_client -servername test.example.com -connect > test.example.com:443 -showcerts" ? The man page starts with: S_CLIENT(1SSL) OpenSSL S_CLIENT(1SSL) NAME s_client - SSL/TLS client program So, I'd guess it stands for "SSL". What else? ;-) -- Wouter Verhelst From marcosbontempo at hotmail.com Mon Jan 4 12:40:59 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Mon, 4 Jan 2016 10:40:59 -0200 Subject: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) In-Reply-To: References: , , , , , , , , , Message-ID: I read about FIPS kernel support. It is necessary? My system doesn't have the /proc/sys/crypto/fips_enabled file. From: marcosbontempo at hotmail.com To: openssl-users at openssl.org Date: Sun, 3 Jan 2016 14:24:45 -0200 Subject: Re: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) I'm getting the code 0 but the FIPS mode still is disabled.#include #include #include int main ( int argc, char *argv[] ){ int rc, mode; mode = FIPS_mode(); if(mode == 0) { rc = FIPS_mode_set(1); ERR_load_crypto_strings(); printf("%s\n", ERR_error_string(ERR_get_error(), NULL)); } else { printf("Already in FIPS mode\n"); } return 0;} Every time I run it I get error:00000000:lib(0):func(0):reason(0). > Date: Sun, 3 Jan 2016 10:54:19 -0500 > Subject: Re: [openssl-users] FIPS_mode_set(1) error:00000000:lib(0):func(0):reason(0) > From: noloader at gmail.com > To: marcosbontempo at hotmail.com > > On Sun, Jan 3, 2016 at 10:48 AM, Marcos Bontempo > wrote: > > Thanks for the answer! The function ERR_get_error() is returning 0x00000000. > > Do you know what it means? > > I believe it means success. > > > I used the command you suggested: > > > > arm:~/nitere/new$ openssl errstr 0x00000000 > > error:00000000:lib(0):func(0):reason(0) > > You should run the command on the error code you receive immediately > after calling FIPS_mode_set. > > Or, use ERR_print_errors() to print the entire error stack. > > You should probably reduce your testing to something simpler until you > figure out what's going on. Maybe somethin glike > https://wiki.openssl.org/index.php/Fipsld_and_C%2B%2B#The_C.2B.2B_Program > . > > Jeff _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Mon Jan 4 14:39:01 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Mon, 4 Jan 2016 14:39:01 +0000 Subject: [openssl-users] OpenSSL 1.0.1q build fails on RS6000, SunSparc and HPIA In-Reply-To: <1451893649972-62001.post@n7.nabble.com> References: <1451893649972-62001.post@n7.nabble.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Aaron > Sent: Monday, January 04, 2016 02:47 > > However building 1.0.1q on RS6000, SunSparc and HPIA still fails becasue > 'make depend' doesn't work on these platforms at all. > > Take RS6000 as an example, the following is the output of 'make depend'. > $ pwd > /rahav_ocsdev/qun/OpenSSL/openssl-1.0.1q > $ make depend > making depend in crypto... > make[1]: Entering directory > `/rahav_ocsdev/qun/OpenSSL/openssl-1.0.1q/crypto' > ../util/domd[30]: makedepend: not found makedepend is a prerequisite for building OpenSSL. Yes, it would be nice if the INSTALL file, or the README, or the FAQ, mentioned this. But makedepend is widely used by open-source software (and by a lot of proprietary software as well). It's readily available, as a simple Google search will show. Are you sure your systems don't already have it installed? A typical AIX 6.1 system, for example, will have it in /usr/lpp/X11/bin, as part of the X11.adt.imake LPP, if that LPP is installed. (It's an optional LPP that's included in the AIX installation media, if memory serves.) /usr/bin/X11 is a symlink to /usr/lpp/X11/bin. Is /usr/bin/X11 in your path? -- Michael Wojcik Technology Specialist, Micro Focus From doctor at doctor.nl2k.ab.ca Mon Jan 4 16:08:31 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 09:08:31 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh Message-ID: <20160104160831.GA4457@doctor.nl2k.ab.ca> This might be a croosmail, but necessary. I did us openssl-SNAP-20160104 minorss erros and installed. I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found In the openssh configuration file I see # Determine OpenSSL library version { $as_echo "$as_me:${as_lineno-$LINENO}: checking OpenSSL library versi on" >&5 $as_echo_n "checking OpenSSL library version... " >&6; } if test "$cross_compiling" = yes; then : { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cross compiling: not checking" >&5 $as_echo "$as_me: WARNING: cross compiling: not checking" >&2;} else cat confdefs.h - <<_ACEOF >conftest.$ac_ext /* end confdefs.h. */ #include #include #include #include #define DATA "conftest.ssllibver" int main () { FILE *fd; int rc; fd = fopen(DATA,"w"); if(fd == NULL) exit(1); if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), SSLeay_version(SSLEAY_VERSION))) <0) exit(1); exit(0); ; return 0; } _ACEOF if ac_fn_c_try_run "$LINENO"; then : ssl_library_ver=`cat conftest.ssllibver` # Check version is supported. case "$ssl_library_ver" in 0090[0-7]*|009080[0-5]*) as_fn_error $? "OpenSSL >= 0.9.8f requi red (have \"$ssl_library_ver\")" "$LINENO" 5 ;; *) ;; esac { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ssl_l ibrary_ver" >&5 $as_echo "$ssl_library_ver" >&6; } else { $as_echo "$as_me:${as_lineno-$LINENO}: result: not fo und" >&5 $as_echo "not found" >&6; } as_fn_error $? "OpenSSL library not found." "$LINENO" 5 fi rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \ conftest.$ac_objext conftest.beam conftest.$ac_ext fi Could there be anything that is causing openssh not to see the new openssl 1.1 and are any other dependent serverware affacted? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Happy Christmas 2015 and Merry New Year 2016 From openssl-users at dukhovni.org Mon Jan 4 19:22:04 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 4 Jan 2016 19:22:04 +0000 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104160831.GA4457@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> Message-ID: <20160104192204.GL18704@mournblade.imrryr.org> On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > SSLeay_version(SSLEAY_VERSION))) <0) > > Could there be anything that is causing openssh not to see the new openssl 1.1 The above. The SSLeay names are gone. The new way is: if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), OpenSSL_version(OPENSSL_VERSION))) <0) I think it is likely prudent at this time to restore source- backwards-compatible behaviour, by adding to : #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L # include # define SSLeay OpenSSL_version_num # define SSLeay_version OpenSSL_version # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER # define SSLEAY_VERSION OPENSSL_VERSION # define SSLEAY_CFLAGS OPENSSL_CFLAGS # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON # define SSLEAY_PLATFORM OPENSSL_PLATFORM # define SSLEAY_DIR OPENSSL_DIR #endif /* OPENSSL_API_COMPAT */ Users who want to make sure they are avoiding interfaces that are deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or higher as appropriate. -- Viktor. From doctor at doctor.nl2k.ab.ca Mon Jan 4 20:29:56 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 13:29:56 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160104202956.GA24447@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. That is one way. Can we get developers to come on baord so that we can launch a new era without incident? > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Tue Jan 5 00:28:13 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 Jan 2016 17:28:13 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: References: <20160104160831.GA4457@doctor.nl2k.ab.ca> Message-ID: <20160105002812.GA1019@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 11:21:37AM +1100, Darren Tucker wrote: > On Tue, Jan 5, 2016 at 3:08 AM, The Doctor wrote: > > This might be a croosmail, but necessary. > > > > I did us openssl-SNAP-20160104 minorss erros and installed. > > installed onto what kind of system and where? > > > I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found > > OpenSSH's config.log will have the details about what failed. > > My guess is that you built only a dynamic libcrypto.so and installed > it somewhere that your runtime linker can't find. Exactly how to fix > that will depend on what kind of system you have (eg /etc/ld.so.conf > on Linuxes). > Both libssl and libcrypto were build. In openssl , it was discovered that an old code was being used to find the libraries. > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From wangqun at alumni.nus.edu.sg Tue Jan 5 02:17:43 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Mon, 4 Jan 2016 19:17:43 -0700 (MST) Subject: [openssl-users] OpenSSL 1.0.1q build fails on RS6000, SunSparc and HPIA In-Reply-To: References: <1451893649972-62001.post@n7.nabble.com> Message-ID: <1451960263297-62018.post@n7.nabble.com> Thank you very much, Michael. It works. Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/OpenSSL-1-0-1q-build-fails-on-RS6000-SunSparc-and-HPIA-tp62001p62018.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From doctor at doctor.nl2k.ab.ca Tue Jan 5 16:19:32 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 09:19:32 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160105161932.GA22085@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. Tip of the iceberg. Number of changes are needed to be committed before launching. >From inn: tls.o: In function `tmp_dh_cb': /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' tls.o: In function `tls_init_serverengine': /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' gmake[1]: *** [nnrpd] Error 1 so 219 and that area gives us default: /* We should check current keylength vs. requested keylength * also, this is an extremely expensive operation! */ dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU LL); r = dh; I just comment these 2 lines out for now line 498 is CTX = SSL_CTX_new(SSLv23_server_method()); I just replace as follows CTX = SSL_CTX_new(TLS_server_method()); A better fix is neeeded. And there is Apache 2.4 Making all in support /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm ab.o: In function `test': /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' and this piece of code is set_conn_state(c, STATE_CONNECTED); #ifdef USE_SSL if (c->ssl) ssl_proceed_handshake(c); else #endif write_request(c); Looks like a lots of rewriting to do. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rosect190 at yahoo.com Tue Jan 5 20:23:28 2016 From: rosect190 at yahoo.com (rosect190 at yahoo.com) Date: Tue, 5 Jan 2016 20:23:28 +0000 (UTC) Subject: [openssl-users] OCSP_response_status References: <1192495381.566474.1452025408123.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1192495381.566474.1452025408123.JavaMail.yahoo@mail.yahoo.com> Hi, I am using OCSP_response_status(..) to check the OCSP result. My openssl is of version 1.0.1h. It is noticed that if the response has some issue, for example, the ocsp server can not be contacted and thus the request is timed out (this can be handled separately.) or if the Responder URL path is not correct, the call to OCSP_response_status(..) will generate a Segmentation fault. Do we know if this is a known issue or if it has been fixed in a newer version of openssl? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Tue Jan 5 22:33:50 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 15:33:50 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105161932.GA22085@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> Message-ID: <20160105223350.GB19904@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 09:19:32AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > Tip of the iceberg. > > Number of changes are needed to be committed before launching. > > >From inn: > > tls.o: In function `tmp_dh_cb': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' > tls.o: In function `tls_init_serverengine': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' > gmake[1]: *** [nnrpd] Error 1 > > so 219 and that area gives us > > default: > /* We should check current keylength vs. requested keylength > * also, this is an extremely expensive operation! */ > dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU > LL); > r = dh; > > I just comment these 2 lines out for now > > line 498 is > > CTX = SSL_CTX_new(SSLv23_server_method()); > > I just replace as follows > > CTX = SSL_CTX_new(TLS_server_method()); > > A better fix is neeeded. > > And there is Apache 2.4 > > Making all in support > /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm > ab.o: In function `test': > /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' > > and this piece of code is > > set_conn_state(c, STATE_CONNECTED); > #ifdef USE_SSL > if (c->ssl) > ssl_proceed_handshake(c); > else > #endif > write_request(c); > > Looks like a lots of rewriting to do. > > Here is one from bind-9.6-ESV-R11 (Yes this branch is no longer supported) libtool: link: /usr/bin/gcc -g -O2 -Wall -I/usr/contrib/include/libxml2 -o named builtin.o client.o config.o control.o controlconf.o interfacemgr.o listenlist.o log.o logconf.o main.o notify.o query.o server.o sortlist.o statschannel.o tkeyconf.o tsigconf.o update.o xfrout.o zoneconf.o lwaddr.o lwresd.o lwdclient.o lwderror.o lwdgabn.o lwdgnba.o lwdgrbn.o lwdnoop.o lwsearch.o unix/os.o ../../lib/lwres/.libs/liblwres.a -L/usr/contrib/lib -L/usr/lib ../../lib/dns/.libs/libdns.a ../../lib/bind9/.libs/libbind9.a /usr/source/bind-9.6-ESV-R11/lib/isccfg/.libs/libisccfg.a ../../lib/isccfg/.libs/libisccfg.a /usr/source/bind-9.6-ESV-R11/lib/dns/.libs/libdns.a /usr/source/bind-9.6-ESV-R11/lib/isccc/.libs/libisccc.a -lcrypto ../../lib/isccc/.libs/libisccc.a /usr/source/bind-9.6-ESV-R11/lib/isc/.libs/libisc.a ../../lib/isc/.libs/libisc.a /usr/contrib/lib/libxml2.so /usr/contrib/lib/liblzma.so -lz -lpthread /usr/lib/libiconv.so -lm -ldl -Wl,-rpath -Wl,/usr/contrib/lib -Wl,-rpath -Wl,/usr/contrib/lib ../../lib/dns/.libs/libdns.a(openssl_link.o): In function `dst__openssl_init': /usr/source/bind-9.6-ESV-R11/lib/dns/openssl_link.c:171: undefined reference to `CRYPTO_set_id_callback' ../../lib/dns/.libs/libdns.a(openssl_link.o): In function `dst__openssl_destroy': /usr/source/bind-9.6-ESV-R11/lib/dns/openssl_link.c:304: undefined reference to `ERR_remove_state' ../../lib/dns/.libs/libdns.a(openssldh_link.o): In function `dst__openssldh_init': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:624: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:625: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:626: undefined reference to `BN_init' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldh_link.c:627: undefined reference to `BN_init' ../../lib/dns/.libs/libdns.a(openssldsa_link.o): In function `openssldsa_createctx': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:65: undefined reference to `EVP_MD_CTX_create' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:69: undefined reference to `EVP_dss1' /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:70: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(openssldsa_link.o): In function `openssldsa_destroyctx': /usr/source/bind-9.6-ESV-R11/lib/dns/openssldsa_link.c:95: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(opensslrsa_link.o): In function `opensslrsa_createctx': /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:130: undefined reference to `EVP_MD_CTX_create' /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:157: undefined reference to `EVP_MD_CTX_destroy' ../../lib/dns/.libs/libdns.a(opensslrsa_link.o): In function `opensslrsa_destroyctx': /usr/source/bind-9.6-ESV-R11/lib/dns/opensslrsa_link.c:234: undefined reference to `EVP_MD_CTX_destroy' *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. > > > > > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Tue Jan 5 22:40:03 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 5 Jan 2016 15:40:03 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105161932.GA22085@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> Message-ID: <20160105224002.GB20729@doctor.nl2k.ab.ca> On Tue, Jan 05, 2016 at 09:19:32AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > Tip of the iceberg. > > Number of changes are needed to be committed before launching. > > >From inn: > > tls.o: In function `tmp_dh_cb': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:219: undefined reference to `DH_generate_parameters' > tls.o: In function `tls_init_serverengine': > /usr/source/inn-CURRENT-20160105/nnrpd/tls.c:498: undefined reference to `SSLv23_server_method' > gmake[1]: *** [nnrpd] Error 1 > > so 219 and that area gives us > > default: > /* We should check current keylength vs. requested keylength > * also, this is an extremely expensive operation! */ > dh = DH_generate_parameters(keylength, DH_GENERATOR_2, NULL, NU > LL); > r = dh; > > I just comment these 2 lines out for now > > line 498 is > > CTX = SSL_CTX_new(SSLv23_server_method()); > > I just replace as follows > > CTX = SSL_CTX_new(TLS_server_method()); > > A better fix is neeeded. > > And there is Apache 2.4 > > Making all in support > /usr/source/httpd-2.4.18/srclib/apr/libtool --silent --mode=link /usr/bin/gcc -std=gnu99 -Wmissing-prototypes -Wstrict-prototypes -Wmissing-declarations -Wpointer-arith -Wformat -Wformat-security -Wall -g -O2 -L/usr/contrib/lib -lssl -lcrypto -lpthread -o ab -static ab.lo -L/usr/lib -lc -lm -ldl -liconv -lintl -lutil -ldb -levent /usr/source/httpd-2.4.18/srclib/apr-util/libaprutil-1.la -lexpat /usr/source/httpd-2.4.18/srclib/apr/libapr-1.la -lpthread -lm > ab.o: In function `test': > /usr/source/httpd-2.4.18/support/ab.c:1863: undefined reference to `SSL_state' > > and this piece of code is > > set_conn_state(c, STATE_CONNECTED); > #ifdef USE_SSL > if (c->ssl) > ssl_proceed_handshake(c); > else > #endif > write_request(c); > > Looks like a lots of rewriting to do. > > > In exim we get gcc -o exim tls.o: In function `rsa_callback': tls.o(.text+0x19a): undefined reference to `RSA_generate_key' tls.o: In function `tls_servername_cb': tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' tls.o: In function `tls_init': tls.o(.text+0x1654): undefined reference to `SSLv23_server_method' tls.o(.text+0x165e): undefined reference to `SSLv23_client_method' tls.o(.text+0x18d2): undefined reference to `SSL_CTX_set_tmp_rsa_callback' tls.o: In function `tls_validate_require_cipher': tls.o(.text+0x2a6d): undefined reference to `SSLv23_server_method' tls.o: In function `tls_version_report': tls.o(.text+0x2b29): undefined reference to `SSLeay_version' tls.o(.text+0x2b36): undefined reference to `SSLeay_version' tls.o: In function `vaguely_random_number': tls.o(.text+0x2bf0): undefined reference to `RAND_pseudo_bytes' Do we need more examples? > > > > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From kurt at roeckx.be Wed Jan 6 06:14:38 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 6 Jan 2016 07:14:38 +0100 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160105224002.GB20729@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160105161932.GA22085@doctor.nl2k.ab.ca> <20160105224002.GB20729@doctor.nl2k.ab.ca> Message-ID: <20160106061437.GA19399@roeckx.be> On Tue, Jan 05, 2016 at 03:40:03PM -0700, The Doctor wrote: > tls.o(.text+0xf32): undefined reference to `SSLv23_server_method' Are you sure it's finding the correct headers? Kurt From wouter.verhelst at fedict.be Wed Jan 6 10:57:00 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 6 Jan 2016 11:57:00 +0100 Subject: [openssl-users] OCSP_response_status In-Reply-To: <1192495381.566474.1452025408123.JavaMail.yahoo@mail.yahoo.com> References: <1192495381.566474.1452025408123.JavaMail.yahoo.ref@mail.yahoo.com> <1192495381.566474.1452025408123.JavaMail.yahoo@mail.yahoo.com> Message-ID: <568CF2FC.5010403@fedict.be> On 05-01-16 21:23, rosect190 at yahoo.com wrote: > Hi, I am using OCSP_response_status(..) to check the OCSP result. My > openssl is of version 1.0.1h. > > It is noticed that if the response has some issue, for example, the ocsp > server can not be contacted and thus the request is timed out (this can > be handled separately.) or if the Responder URL path is not correct, the > call to OCSP_response_status(..) will generate a Segmentation fault. If you pass incorrect data to OCSP_response_status(), things may go wrong. So don't do that, then :-) Instead, the HTTP library which you use should be able to inform you if the HTTP request failed for some reason. When it does, don't call OCSP_response_status()... (also, make sure to call OCSP_basic_verify() before accepting the result of OCSP_response_status() at fact value, because the latter checks the signature while the former does not). -- Wouter Verhelst From wouter.verhelst at fedict.be Wed Jan 6 11:08:09 2016 From: wouter.verhelst at fedict.be (Wouter Verhelst) Date: Wed, 6 Jan 2016 12:08:09 +0100 Subject: [openssl-users] OCSP signature verification In-Reply-To: <314AD38167954C4BBE91263CA425506D577EFDB231@MAIL2K7CL.yourict.net> References: <314AD38167954C4BBE91263CA425506D577EFDB231@MAIL2K7CL.yourict.net> Message-ID: <568CF599.4090503@fedict.be> Hi, (that other mail on OCSP on this list reminded me of this...) I've found the answer in the mean time by using a debugger and single-stepping through the library... On 01-12-15 14:58, Verhelst Wouter (Consultant) wrote: > Hi folks, > > I'm trying to write an application that needs to verify the validity of data on a smartcard. That data is signed with an RSA key for which a certificate exists on the card; but if the card is stolen or lost, the certificate will be revoked, so I want to ensure that the certificate is valid. I'm doing an OCSP request to take care of that. > > Since OpenSSL's own OCSP_sendreq_* functions don't support HTTP proxies, I'm currently using libcurl to send the request to the OCSP endpoint. This seems to work; when I get the reply and use d2i_OCSP_RESPONSE(), then with things like OCSP_response_status() and OCSP_resp_find_status() and friends I can manage to get the status of the request and a given certificate. > > However, that doesn't do signature verification. I believe that I should use OCSP_basic_verify() for that, but I'm not entirely sure whether that is the case, and if so whether I would need to do some additional checks beforehand. Unfortunately, I can't find any documentation on OCSP_basic_verify(). > > I should note that due to the nature of my needs, I have a rather huge set of valid intermediate CAs, but a fairly limited set of root CAs that can be used for valid cards (that is, if the signature validates but it wasn't signed by any of the CAs under one of my limited set of roots, the card is a forgery and should be rejected as invalid). > > A few questions: > - Am I right in assuming that OCSP_basic_verify will check the signature on the OCSP request? Answer: yes (verified this by modifying some data in the OCSP response data, which caused signature verification to fail) > - In "OCSP_basic_verify(OCSP_BASICRESP *bs, STACK_OF(X509) *certs, X509_STORE *st, unsigned long flags)", I'm not entirely certain of what the "st" argument is meant to contain, and can't figure out the "certs" one. Pouring over the code, I believe the "st" argument should allow me to limit validation to my set of root certificates, but I could be mistaken. As for the "certs" one, I can't understand that one at all. The only thing I can think of is that maybe it should contain the issuer certificate that I used for the original request, but then why is it a STACK_OF(X509)* and not just an X509*? What am I missing? Answers: - The "STACK_OF(X509) *certs" argument should just be bs->certs (i.e., the certificates which were sent along with the OCSP response, and which contain all certificates required to be able to verify the signature on the response as well as its certificate chain). I assume this is done so as to retain API compatibility with other certificate verification methods (e.g., using CRLs), even though the *certs argument really is superfluous (OCSP_basic_verify could just as easily pluck those certificates out of the *bs argument). - The "X509_STORE *st" argument indeed allows me to limit the root certificates allowed for valid signatures. By not including the default certificate store, I can reject cards that are signed by a different root. -- Wouter Verhelst From doctor at doctor.nl2k.ab.ca Wed Jan 6 14:33:27 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 07:33:27 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104192204.GL18704@mournblade.imrryr.org> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> Message-ID: <20160106143327.GA20190@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > The above. The SSLeay names are gone. The new way is: > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > OpenSSL_version(OPENSSL_VERSION))) <0) > > I think it is likely prudent at this time to restore source- > backwards-compatible behaviour, by adding to : > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > # include > # define SSLeay OpenSSL_version_num > # define SSLeay_version OpenSSL_version > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > # define SSLEAY_VERSION OPENSSL_VERSION > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > # define SSLEAY_DIR OPENSSL_DIR > #endif /* OPENSSL_API_COMPAT */ > > Users who want to make sure they are avoiding interfaces that are > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > higher as appropriate. > With all the other issues (DEPREACTED) identified, let me test the above out. > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From doctor at doctor.nl2k.ab.ca Wed Jan 6 15:28:12 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 6 Jan 2016 08:28:12 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160106143327.GA20190@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160106143327.GA20190@doctor.nl2k.ab.ca> Message-ID: <20160106152812.GA20405@doctor.nl2k.ab.ca> On Wed, Jan 06, 2016 at 07:33:27AM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > > > With all the other issues (DEPREACTED) identified, let > me test the above out. > Still a few bumps, but I recommend that this be committed to openssl 1.1 branch. > > -- > > Viktor. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca > God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! > http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism > Birthdate 29 Jan 1969 Redhill, Surrey, UK > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From sanumesh at in.ibm.com Thu Jan 7 11:41:34 2016 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Thu, 7 Jan 2016 17:11:34 +0530 Subject: [openssl-users] openSSL and SLOTH attack Message-ID: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Hello users, Is there any fixes available from openSSL community for the SLOTH attack - http://www.mitls.org/pages/attacks/SLOTH or what are the possible mitigation points? Thanks Sandeep -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Jan 7 14:52:20 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 7 Jan 2016 14:52:20 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: The proposed change: ------ static inline unsigned int constant_time_msb(unsigned int a) { - return 0 - (a >> (sizeof(a) * 8 - 1)); + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); } ----- produces an implementation-defined value in C99. See the final sentence of ISO 9899-1999 6.5.7 #5: The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type or if E1 has a signed type and a nonnegative value, the value of the result is the integral part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative value, the resulting value is implementation-defined. Some implementations fill with the sign bit in this case; some fill with 0. It's possible the standard allows some other behavior. Ignoring the CHAR_BITS issue, the shift portion of the original version looks correct to me, assuming no padding bits. (The latter assumption might as well be made, because it's unlikely the other bit-fiddling constant-time functions work under an implementation with padding bits, and such implementations are uncommon.) For an unsigned left operand, that right-shift should produce either 0 or 1, corresponding to the value of the MSB. That leaves us (in the original code) with the "0 -" part. The intent here is to have the function return either 0 (if the shift operation results in 0) or high-values (i.e., an unsigned int with all bits set). Your new code could return 1 under some implementations for values with the MSB set, so it's not equivalent. Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8 #1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned int have the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U. The result of the latter is -1, which is outside the range of unsigned int; so the resulting value is computed by adding UINT_MAX+1 to it (notionally - this addition is per the normal rules of arithmetic, not constrained by the C implementation). The result is UINT_MAX, which is within the range of unsigned integer. So if you see incorrect values from the original code, that looks like another compiler bug, unless I'm missing something in the standard, or your implementation doesn't conform to C99. (I don't think the relevant sections where changed by C11, but I could be wrong.) Unfortunately, while your alternative might work around it for some cases, it isn't guaranteed to produce the correct result on all implementations. Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each unsigned integer type has the same width as the corresponding integer type. That change just makes the code longer and more fragile if the type of "a" is changed later. (And the parentheses around "a" in the original are unnecessary - sizeof is an operator, not a function.) -- Michael Wojcik Technology Specialist, Micro Focus From jb-openssl at wisemo.com Thu Jan 7 15:18:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 7 Jan 2016 16:18:46 +0100 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <568E81D6.4050806@wisemo.com> On 07/01/2016 15:52, Michael Wojcik wrote: > The proposed change: > > ------ > static inline unsigned int constant_time_msb(unsigned int a) > { > - return 0 - (a >> (sizeof(a) * 8 - 1)); > + return (((unsigned)((int)(a) >> (sizeof(int) * 8 - 1)))); > } > ----- > > produces an implementation-defined value in C99. See the final sentence of ISO 9899-1999 6.5.7 #5: > > The result of E1 >> E2 is E1 right-shifted E2 bit positions. If E1 has an unsigned type > or if E1 has a signed type and a nonnegative value, the value of the result is the integral > part of the quotient of E1 / 2**E2. If E1 has a signed type and a negative value, the > resulting value is implementation-defined. > > Some implementations fill with the sign bit in this case; some fill with 0. It's possible the standard allows some other behavior. > > Ignoring the CHAR_BITS issue, the shift portion of the original version looks correct to me, assuming no padding bits. (The latter assumption might as well be made, because it's unlikely the other bit-fiddling constant-time functions work under an implementation with padding bits, and such implementations are uncommon.) For an unsigned left operand, that right-shift should produce either 0 or 1, corresponding to the value of the MSB. > > That leaves us (in the original code) with the "0 -" part. The intent here is to have the function return either 0 (if the shift operation results in 0) or high-values (i.e., an unsigned int with all bits set). Your new code could return 1 under some implementations for values with the MSB set, so it's not equivalent. > > Should the "0 -" part work correctly? The usual arithmetic conversions (6.3.1.8 #1) convert the 0 to 0U (i.e., 0 as an unsigned int), because int and unsigned int have the same rank. So we either 0U - 0U, which is trivially 0, or 0U - 1U. The result of the latter is -1, which is outside the range of unsigned int; so the resulting value is computed by adding UINT_MAX+1 to it (notionally - this addition is per the normal rules of arithmetic, not constrained by the C implementation). The result is UINT_MAX, which is within the range of unsigned integer. > > So if you see incorrect values from the original code, that looks like another compiler bug, unless I'm missing something in the standard, or your implementation doesn't conform to C99. (I don't think the relevant sections where changed by C11, but I could be wrong.) Unfortunately, while your alternative might work around it for some cases, it isn't guaranteed to produce the correct result on all implementations. > > Note also that changing "sizeof(a)" to "sizeof(int)" has no effect. Each unsigned integer type has the same width as the corresponding integer type. That change just makes the code longer and more fragile if the type of "a" is changed later. (And the parentheses around "a" in the original are unnecessary - sizeof is an operator, not a function.) > This has all been discussed to death. On the compiler in question, *both* versions work, but some particular invocations of this function inlined into certain other inline functions several levels deep triggers a compiler bug where the compiler in question throws away a different arithmetic operation elsewhere in the code and ends up producing the wrong result. Changing from the portable implementation to the old non-portable implementation happens to avoid that compiler bug, by pure chance. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Jan 7 15:46:53 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 7 Jan 2016 15:46:53 +0000 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: As described on that web page, use OpenSSL 1.0.1f or later. That prevents the currently-practical SLOTH attack against RSA-MD5 client authentication. If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not your biggest problem. The authors recommend discontinuing use of MD5 and SHA-1 in general. So does nearly everyone else. Really the risk of continuing to support MD5 and SHA-1 can only meaningfully be evaluated in the context of your own threat model; but either you already know that, or you don't know what your threat model is, in which case the safe move is to drop support for MD5 and SHA-1 as soon as you can. -- Michael Wojcik Technology Specialist, Micro Focus From jeremy.farrell at oracle.com Thu Jan 7 18:04:03 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Thu, 7 Jan 2016 18:04:03 +0000 Subject: [openssl-users] mailing list issues? Re: CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> Message-ID: <568EA893.30909@oracle.com> A few zombie messages today: Received: from mta.openssl.org (localhost [127.0.0.1]) by mta.openssl.org (Postfix) with ESMTP id 14CB4201BB; Thu, 7 Jan 2016 12:13:22 +0000 (UTC) X-Original-To: openssl-users at mta.openssl.org Delivered-To: openssl-users at mta.openssl.org Received: by mta.openssl.org (Postfix, from userid 106) id 0F2632725F; Thu, 10 Dec 2015 11:50:15 +0000 (UTC) On 10/12/2015 11:50, Jayalakshmi bhat wrote: > Hi Matt > > Thanks for the patch. Unfortunately patch did not work. ... -- J. J. Farrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Jan 7 18:05:51 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 7 Jan 2016 18:05:51 +0000 Subject: [openssl-users] mailing list issues? Re: CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <568EA893.30909@oracle.com> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <568EA893.30909@oracle.com> Message-ID: <5e5c67c3f6d2476490945b94242e660b@usma1ex-dag1mb1.msg.corp.akamai.com> > A few zombie messages today: There were some that had been held up on the queue because of things like size limits. From allan at physics.umn.edu Thu Jan 7 18:12:49 2016 From: allan at physics.umn.edu (Graham Allan) Date: Thu, 7 Jan 2016 12:12:49 -0600 Subject: [openssl-users] Troubleshooting failed TLS negotiation Message-ID: <568EAAA1.3040003@physics.umn.edu> I'm moving samba service between a couple of FreeBSD systems (9.3 to 10.2), and I'm stuck on getting samba on the new machine to connect to our openldap server over ssl - frustrating since I've been running samba+ldap for 15 years or so; feel sure I'm missing something basic! The smbd-to-ldap connection works fine with no encryption, but I get errors when using either TLS to port 389 ("Failed to issue the StartTLS instruction: Connect error"), or for SSL to 636 I get: failed to bind to server ldaps://ldap-fqdn with dn="cn=admin,dc=..." Error: Can't contact LDAP server error:0D0C5006:asn1 encoding routines:ASN1_item_verify:EVP lib I'm pretty certain it's not a certificate or CA validation issue. All my other ldap clients on that server are working as expected, including a simple "ldapsearch -ZZ"; and openssl s_client is happy connecting to the ldaps port. I tested different settings in openldap's ldap.conf, eg using TLS_CACERTDIR vs TLS_CACERT and different values of TLS_REQCERT; all seem to work equally well for ldapsearch (and equally badly for smbd). Capturing the packet exchange between smbd and slapd, I'm seeing the (smbd) client sends a "decrypt error" (TLS alert code 51) to the ldap server after receiving the certificate, while the working "ldapsearch -ZZ" moves on to client key exchange etc. The biggest difference I can think of between the working and non-working systems is the openssl version (FreeBSD 10.2 uses 1.0.1p while 9.3 uses 0.9.8zd - the ldap server is using the latter). However that doesn't explain all my other 10.x ldap/ssl clients working successfully... It sounds a bit like this posting from couple of years ago (which I unfortunately couldn't see any resolution to): http://comments.gmane.org/gmane.comp.encryption.openssl.user/49142 I'm not sure where to try looking next for the cause, would welcome any suggestions... Thanks, Graham From kgoldman at us.ibm.com Thu Jan 7 18:39:50 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 7 Jan 2016 13:39:50 -0500 Subject: [openssl-users] EVP_PKEY *X509_get0_pubkey(X509 *x); Message-ID: Meta-comment: The documentation is very thin on when objects should or should not be freed. The application developer is forced to chose between [don't free, leak memory] and [free, access freed memory]. ~~ 1 - The documentation here says this API is available, but I don't see it in either the source or the installed header. https://www.openssl.org/docs/manmaster/crypto/X509_get_pubkey.html 2 - The doc also says that X509_get_pubkey() can be used but "the returned key must be freed up after use". It would be nice if it said how to free it. I assume that EVP_PKEY_free() is correct. 3 - I use this sequence: x509 = PEM_read_bio_X509 EVP_PKEY = X509_get_pubkey RSA = EVP_PKEY_get1_RSA What should be freed? All three structures or just a subset? From openssl-users at dukhovni.org Thu Jan 7 18:41:45 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 Jan 2016 13:41:45 -0500 Subject: [openssl-users] EVP_PKEY *X509_get0_pubkey(X509 *x); In-Reply-To: References: Message-ID: > On Jan 7, 2016, at 1:39 PM, Ken Goldman wrote: > > 3 - I use this sequence: > > x509 = PEM_read_bio_X509 > EVP_PKEY = X509_get_pubkey > RSA = EVP_PKEY_get1_RSA > > What should be freed? All three structures or just a subset? All three. -- Viktor. From Michael.Wojcik at microfocus.com Thu Jan 7 19:18:58 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 7 Jan 2016 19:18:58 +0000 Subject: [openssl-users] CBC ciphers + TLS 1.0 protocol does not work in OpenSSL 1.0.2d In-Reply-To: <568E81D6.4050806@wisemo.com> References: <56615D97.7050306@openssl.org> <56619669.2020403@openssl.org> <5666B794.2080304@openssl.org> <566712E4.4010503@wisemo.com> <5667670D.2040402@openssl.org> <5668B383.1060100@openssl.org> <5668B59C.60106@akamai.com> <56694A58.4060006@openssl.org> <568E81D6.4050806@wisemo.com> Message-ID: Sorry - I thought this topic had come up again (or that this was a new continuation of the older discussion). Now I see it was an old message that had been delayed. Apologies for the noise. -- Michael Wojcik Technology Specialist, Micro Focus From mceli at us.ibm.com Thu Jan 7 20:15:37 2016 From: mceli at us.ibm.com (Miriam Celi) Date: Thu, 7 Jan 2016 20:15:37 +0000 (UTC) Subject: [openssl-users] openSSL and SLOTH attack References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: Michael Wojcik writes: > > As described on that web page, use OpenSSL 1.0.1f or later. That prevents the currently-practical SLOTH > attack against RSA-MD5 client authentication. > > If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not your biggest problem. > > The authors recommend discontinuing use of MD5 and SHA-1 in general. So does nearly everyone else. Really > the risk of continuing to support MD5 and SHA-1 can only meaningfully be evaluated in the context of your > own threat model; but either you already know that, or you don't know what your threat model is, in which > case the safe move is to drop support for MD5 and SHA-1 as soon as you can. > Are the 1.0.0 and 1.0.2 branches also affected? The article states that the issue is present in openssl versions prior to 1.0.1f. If the issue is also present in the 1.0.0 and 1.0.2 branches, will fixes be provided on those branches to address the issue? Thanks very much for your feedback. Best regards, Miriam From jb-openssl at wisemo.com Thu Jan 7 21:32:23 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 7 Jan 2016 22:32:23 +0100 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: <568ED967.9020806@wisemo.com> On 07/01/2016 16:46, Michael Wojcik wrote: > As described on that web page, use OpenSSL 1.0.1f or later. That prevents the currently-practical SLOTH attack against RSA-MD5 client authentication. > > If you're using an OpenSSL release earlier than 1.0.1f, SLOTH is probably not your biggest problem. > > The authors recommend discontinuing use of MD5 and SHA-1 in general. So does nearly everyone else. Really the risk of continuing to support MD5 and SHA-1 can only meaningfully be evaluated in the context of your own threat model; but either you already know that, or you don't know what your threat model is, in which case the safe move is to drop support for MD5 and SHA-1 as soon as you can. > The above is not a very accurate summary. In particular, the following would be a clearer summary: 1. Whenever possible, configure both servers and clients to avoid using MD5 or SHA-1 alone. 2. My suggestion: If it is necessary to retain SHA-1 support due to some correspondents stuck with older weak algorithms (looking at you Microsoft!), then isolate it as much as possible, e.g. with different certificates etc. 3. If possible, configure servers and clients to not choose encryption modes where the TLS handshake is confirmed using only 96 bits of the relevant HMAC. 4. Do not use the "official" tls-unique token to bind something to a TLS handshake, it is unsuited to purpose, even with the recent extension of its format. My suggestion: Instead do a strong hash (SHA-256 or better) of the complete handshake (all handshake messages in both directions, including record headers). 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 jonetsu at teksavvy.com Thu Jan 7 22:06:54 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Thu, 7 Jan 2016 15:06:54 -0700 (MST) Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <568ED967.9020806@wisemo.com> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> <568ED967.9020806@wisemo.com> Message-ID: <1452204414669-62074.post@n7.nabble.com> Does this mean that running 1.01e in FIPS mode is protected regarding this SLOTH attack ? -- View this message in context: http://openssl.6102.n7.nabble.com/openSSL-and-SLOTH-attack-tp62055p62074.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jb-openssl at wisemo.com Fri Jan 8 00:25:29 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 8 Jan 2016 01:25:29 +0100 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <1452204414669-62074.post@n7.nabble.com> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> <568ED967.9020806@wisemo.com> <1452204414669-62074.post@n7.nabble.com> Message-ID: <568F01F9.1050800@wisemo.com> On 07/01/2016 23:06, jonetsu wrote: > Does this mean that running 1.01e in FIPS mode is protected regarding this > SLOTH attack ? Does FIPS mode prevent use of MD5: Yes. Does FIPS mode prevent insecure uses of SHA-1 (a FIPS algorithm): No. Does FIPS mode prevent the SSL/TLS handshake from using 96 bit truncated HMAC values: Probably not. Does FIPS mode prevent use of the insecurely designed 'tls-unique' feature: Probably not. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kamalkishor.Pal at Polycom.com Fri Jan 8 09:44:14 2016 From: Kamalkishor.Pal at Polycom.com (Pal, Kamal Kishor) Date: Fri, 8 Jan 2016 17:44:14 +0800 Subject: [openssl-users] New opensssl sources with some missing files released on 2015-Dec-03 Message-ID: <127B29E8B6805A43BC4E5BEB41D0BB146A0A80DB19@HKGMBOXPRD01.polycom.com> Hi, Any update on packaging errors mentioned in my previous mail.. Further we notice the extracted openssl source "include" directory does not have the header files as well. Any plan from Openssl team to re-package and release again? Regards, Kamal From: Pal, Kamal Kishor Sent: Tuesday, December 29, 2015 1:20 PM To: 'openssl-users at openssl.org' Cc: Pal, Kamal Kishor Subject: [openssl-users] New opensssl sources with some missing files released on 2015-Dec-03 Hi, It seems the new openssl version source tar files released on 2015-Dec-03 has some missing files giving errors while untarring and compiling our application code. We tried using "openssl-0.9.8zh" and "openssl-1.0.1q" version and observed following: A. openssl-0.9.8zh.tar.gz * Untarring the source tar with Winrar in Windows7 gives 88 errors for 44 missing files. * Untarring on Linus also shows symbolic links of same 44 missing files. * Our Application build fails with new source files. B. openssl-1.0.1q.tar.gz * Untarring the source tar with Winrar in Windows7 gives 76 errors for 38 missing files. Please refer the attachments for error details. Links used for downloads are as under: https://www.openssl.org/source/ ftp://ftp.openssl.org/source/ We are actually blocked with openssl upgrade to "openssl-0.9.8zh" due to erroneous packages released. Could you please check the new openssl version packages of "openssl-0.9.8zh.tar.gz" and update the packages or suggest us alternatives, if any. Regards, Kamal -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Fri Jan 8 14:26:43 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 8 Jan 2016 14:26:43 +0000 Subject: [openssl-users] openSSL and SLOTH attack Message-ID: <20160108142651.17780804.64884.44139@ll.mit.edu> What is the problem with truncated 96-bit HMAC value? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. From: Jakob Bohm Sent: Thursday, January 7, 2016 19:25 To: openssl-users at openssl.org Reply To: openssl-users at openssl.org Subject: Re: [openssl-users] openSSL and SLOTH attack On 07/01/2016 23:06, jonetsu wrote: Does this mean that running 1.01e in FIPS mode is protected regarding this SLOTH attack ? Does FIPS mode prevent use of MD5: Yes. Does FIPS mode prevent insecure uses of SHA-1 (a FIPS algorithm): No. Does FIPS mode prevent the SSL/TLS handshake from using 96 bit truncated HMAC values: Probably not. Does FIPS mode prevent use of the insecurely designed 'tls-unique' feature: Probably not. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From jonetsu at teksavvy.com Fri Jan 8 14:09:51 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 8 Jan 2016 07:09:51 -0700 (MST) Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <568F01F9.1050800@wisemo.com> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> <568ED967.9020806@wisemo.com> <1452204414669-62074.post@n7.nabble.com> <568F01F9.1050800@wisemo.com> Message-ID: <1452262191821-62080.post@n7.nabble.com> > Does FIPS mode prevent use of MD5: Yes. > Does FIPS mode prevent insecure uses of SHA-1 (a FIPS > algorithm): No. > Does FIPS mode prevent the SSL/TLS handshake from using 96 bit > truncated HMAC values: Probably not. > Does FIPS mode prevent use of the insecurely designed > 'tls-unique' feature: Probably not. This is what I read so far, thanks for the confirmation. 1.01f though, will be good, will it, FIPS mode or not ? -- View this message in context: http://openssl.6102.n7.nabble.com/openSSL-and-SLOTH-attack-tp62055p62080.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From mceli at us.ibm.com Fri Jan 8 15:50:42 2016 From: mceli at us.ibm.com (Miriam Celi) Date: Fri, 8 Jan 2016 15:50:42 +0000 (UTC) Subject: [openssl-users] openSSL and SLOTH attack References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: Hello again OpenSSL users, I'm still trying to find out if the 1.0.2 and 1.0.0 branches are affected, and if so which versions and if there are versions with fixes available. Based on the changelog for the 1.0.2 branch (http://openssl.org/news/cl102.txt), version 1.0.1f which contains the fix was released (Jan 2014) prior to OpenSSL 1.0.2 (Jan 2015), so 1.0.2d should contain the fix for this, but we are not sure about this and would like confirmation on this. Based on the changelog for the 1.0.1 (https://www.openssl.org/news/cl101.txt) and 1.0.0 (http://openssl.org/news/cl100.txt) branches, version 1.0.1f was released prior to 1.0.0r (Mar 2015), so 1.0.0r should contain the fix for this, but again we are not sure and would like confirmation. The detailed?technical?paper (http://www.mitls.org/downloads/transcript-collisions.pdf) that was published with the attack disclosure, describes a vector for an MD5 based attack against TLS 1.0 and TLS 1.1. So, there's a possibility for an OpenSSL 1.0.0 version to be vulnerable. Thanks for any additional information you can provide on this. Regards, Miriam From xerces9+osl at gmail.com Fri Jan 8 16:02:43 2016 From: xerces9+osl at gmail.com (=?UTF-8?Q?David_Bala=C5=BEic?=) Date: Fri, 8 Jan 2016 17:02:43 +0100 Subject: [openssl-users] Firefox problems with two way SSL auth Message-ID: Hi! I encounter this issue when using Firefox to access tomcat (that is using openssl) with client cert authentication. After a certain timeout, the web application does not "see" the clients certificate in requests. The problem happens on different operating systems (Window,s Linux) and browsers. I reported it to tomcat and Firefox, with not much response. There is a simple test case in comment 1 of the tomcat bug (see below). Could someone assist in finding the cause of the problem? I also have pcap traces (somewhere) of working and non working network traffic. Latest tested configuration: tomcat 8.0.30, using OpenSSL 1.0.1m 19 Mar 2015 Firefox 43.0.4 OS: Windows 7 Pro SP1 64bit The tomcat bug with much details: https://bz.apache.org/bugzilla/show_bug.cgi?id=58244 Firefox bug report (not much details): https://bugzilla.mozilla.org/show_bug.cgi?id=1231406 Regards, David Bala?ic From rsalz at akamai.com Fri Jan 8 17:43:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 8 Jan 2016 17:43:30 +0000 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: Are you going to keep posting and posting until you get a response? :( Master branch, 1.1, is not released but will not be vulnerable (may already be fixed) 1.0.2 is not vulnerable. 1.0.1f and later are not vulnerable. 1.0.0 might be, and is end of life anyway so you should move of that. 0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From kudzu at tenebras.com Fri Jan 8 19:00:14 2016 From: kudzu at tenebras.com (Michael Sierchio) Date: Fri, 8 Jan 2016 11:00:14 -0800 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <20160108142651.17780804.64884.44139@ll.mit.edu> References: <20160108142651.17780804.64884.44139@ll.mit.edu> Message-ID: "Since the HMAC is only 96 bits long, even a generic collision requires only about 248 HMAC computations" But a sequence/call-flow diagram is on the page Sandeep referenced: http://www.mitls.org/pages/attacks/SLOTH - M -------------- next part -------------- An HTML attachment was scrubbed... URL: From kudzu at tenebras.com Fri Jan 8 19:00:46 2016 From: kudzu at tenebras.com (Michael Sierchio) Date: Fri, 8 Jan 2016 11:00:46 -0800 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: References: <20160108142651.17780804.64884.44139@ll.mit.edu> Message-ID: 2^48. Which is larger than 248, which was a cut-and-paste error. ;-) On Fri, Jan 8, 2016 at 11:00 AM, Michael Sierchio wrote: > "Since the HMAC is only 96 bits long, even a generic collision requires > only about 248 HMAC computations" > > But a sequence/call-flow diagram is on the page Sandeep referenced: > http://www.mitls.org/pages/attacks/SLOTH > > - M > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Fri Jan 8 18:57:35 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 8 Jan 2016 11:57:35 -0700 (MST) Subject: [openssl-users] Difference in the methods for listing the FIPS ciphers Message-ID: <1452279454999-62089.post@n7.nabble.com> Hello, Using 1.0.1e running FIPS module 2.0.9, the following two commands for querying the ciphers do not yield the same results. There are more ciphers declared in the 'string' version. The 'environment variable' version: % OPENSSL_FIPS=1 openssl ciphers -v | The 'string' version: % openssl ciphers -v 'FIPS' In the 'string' version only: Is the 'environment variable' usage broken ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/Difference-in-the-methods-for-listing-the-FIPS-ciphers-tp62089.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From Michal.Trojnara at stunnel.org Sat Jan 9 00:17:30 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Sat, 9 Jan 2016 01:17:30 +0100 Subject: [openssl-users] stunnel 5.29 released Message-ID: <5690519A.2070404@stunnel.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.29 of stunnel. The ChangeLog entry: Version 5.29, 2016.01.08, urgency: LOW * New features - New WIN32 icons. - Performance improvement: rwlocks used for locking with pthreads. * Bugfixes - Compilation fix for *BSD. - Fixed configuration file reload for relative stunnel.conf path on Unix. - Fixed ignoring CRLfile unless CAfile was also specified (thx to Strukov Petr). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 43909625403ea634fa7cb8399d58faf8e7f11c1b7b29097491469951f56df551 stunnel-5.29.tar.gz c92ccc98cc9eb0c5d95d9550af39ab502e7ea45ed4d9ccc821aa261856f958b1 stunnel-5.29-installer.exe f9db8676e8e2ec6db355bae41eb625eb8ebd45a836ad8cbf06ce60a3c305fde2 stunnel-5.29-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJWkFGaAAoJEC78f/DUFuAUGocQAMgblKTHppSpRurlkCZtjNDh p/M7IqxzfqCczIUuG1zdPVyk7lcW3jhFHXsfjTcch56YH6FtMcezUv8Wa8LojNjY iY1uSbWyAmdsV5ye+Z4SWybwOfS53i5IK9Fnb3UE1CmcETxsI56AWzVLG0w8jsGH HwRB3+J/aVS+VqOeNO4VW53yzvT73k3tvPDAKu7NFRrmhvJ9vk7BkgL/WJ/1oK5D 480eLHoT0phe/Xl2cMaOJDXBnU0dAfDieM5IWwL+jAqWhsEeTgK8n92FbAqFB6T6 GkhJGfgc0olSlQkCo7Iz3Q8mh65NpEYNoZGIT2VelalXOM2lyeL4vuwfbGiomalW N3Mt1xNXuneX77E0rOM2rlnzoaG9FulcDHp/Ie9plOyO6OyimFMKU1Xg9lJSCU2B iTu6F0FvptduPU3e6rE1FSxMII0lzMo6oDHFggK5YlitJJKPOoGLfW2T4SjYlsmw BirrEO9j/OvOqLT5ovMCJUVLXZrrjKkoCQoZI7p8r1rPJlsdC4QeRb0p9wJAGdAJ pS3w1HEgcXMUf/xS130nM2euftu0Td3Qi1tqXnDgtbSkwEN1T0tP3xiD1D++BzMf TzMivlWyerjOEuBMCRwcKMsrIr8+seSdLzUIISJ8EwCGWUq0p1l4KXYs5EofNJKI gIZdYXEX46WlR+dl7aZC =IchS -----END PGP SIGNATURE----- From noloader at gmail.com Sat Jan 9 00:38:10 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 8 Jan 2016 19:38:10 -0500 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: References: <20160108142651.17780804.64884.44139@ll.mit.edu> Message-ID: On Fri, Jan 8, 2016 at 2:00 PM, Michael Sierchio wrote: > 2^48. Which is larger than 248, which was a cut-and-paste error. ;-) Right.... The bad guy should *not* be able to compute a MAC to perform the forgery within TCP's 2MSL bound and TLS timers. However, there's a keep alive the authors used in the past to basically make their attack windows unbounded in time. From the earlier paper on Logjam (http://weakdh.org/imperfect-forward-secrecy-ccs15.pdf): TLS warning alerts. Web browsers tend to have shorter timeouts, but we can keep their connections alive by sending TLS warning alerts, which are ignored by the browser but reset the handshake timer. As far as I know, there's no interest in fixing it in the TLS working group. Jeff From matt at openssl.org Sat Jan 9 03:56:49 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 9 Jan 2016 03:56:49 +0000 Subject: [openssl-users] New opensssl sources with some missing files released on 2015-Dec-03 In-Reply-To: <127B29E8B6805A43BC4E5BEB41D0BB146A0A80DB19@HKGMBOXPRD01.polycom.com> References: <127B29E8B6805A43BC4E5BEB41D0BB146A0A80DB19@HKGMBOXPRD01.polycom.com> Message-ID: <56908501.9080308@openssl.org> On 08/01/16 09:44, Pal, Kamal Kishor wrote: > Hi, > > Any update on packaging errors mentioned in my previous mail.. > > > > Further we notice the extracted openssl source ?include? directory does > not have the header files as well. > > > > Any plan from Openssl team to re-package and release again? There is no plan to re-package. The missing files and links are not necessary to successfully compile and install OpenSSL. They are recreated when running "Configure" and "make depend". Matt From doctor at doctor.nl2k.ab.ca Sat Jan 9 13:54:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 9 Jan 2016 06:54:47 -0700 Subject: [openssl-users] openssl-SNAP-20160109 issue Message-ID: <20160109135447.GA22497@doctor.nl2k.ab.ca> In a amke && make test I got making all in engines/ccgost... gcc -I.. -I../include -I../crypto/include -I../fips -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -march=i486 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c jpaketest.c jpaketest.c: In function `main': jpaketest.c:119: warning: implicit declaration of function `CRYPTO_set_mem_debug_functions' jpaketest.c:120: parse error before "CRYPTO_mem_ctrl" jpaketest.c:179: warning: implicit declaration of function `CRYPTO_mem_leaks' *** Error code 1 Stop. *** Error code 1 Stop. Please fix. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From steve at openssl.org Sun Jan 10 01:24:52 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 10 Jan 2016 01:24:52 +0000 Subject: [openssl-users] Difference in the methods for listing the FIPS ciphers In-Reply-To: <1452279454999-62089.post@n7.nabble.com> References: <1452279454999-62089.post@n7.nabble.com> Message-ID: <20160110012452.GA27566@openssl.org> On Fri, Jan 08, 2016, jonetsu wrote: > Hello, > > Using 1.0.1e running FIPS module 2.0.9, the following two > commands for querying the ciphers do not yield the same results. > There are more ciphers declared in the 'string' version. > > The 'environment variable' version: > > % OPENSSL_FIPS=1 openssl ciphers -v | > > The 'string' version: > > % openssl ciphers -v 'FIPS' > > In the 'string' version only: > > > Is the 'environment variable' usage broken ? > No: the two are not equivalent. The environment variable version lists the default ciphers with the non-FIPS ciphers filtered out. When you specify FIPS as the cipher string it specifies all ciphers which can be used in FIPS mode including those not in the default list. Specifically the default cipher string omits anonymous cipher suites. If you do: OPENSSL_FIPS=1 openssl ciphers -v ALL you should get the same result as the FIPS cipher string. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From anilmathew001 at gmail.com Sun Jan 10 04:15:48 2016 From: anilmathew001 at gmail.com (Anil Mathew) Date: Sun, 10 Jan 2016 08:15:48 +0400 Subject: [openssl-users] Jks converted to Pem error in veirfying Message-ID: I am a novice in terms of ssl and hence have limited knowledge in this. Please help I have been a given a jks file that has server certificate, client certificate and a key for the client certificate. I need to convert it to pem to use it in my application. I have converted a jks file to p12 and then to pem. However when i try to verify i get the following error. echo |openssl verify -verbose -purpose sslclient -issuer_checks -CApath C:\Data\Openssl\demoCA\certs -CAfile client.pem client.pem client.pem: /CN=cn/O=o/L=L/ST=il/C= c error 29 at 0 depth lookup:subject issuer mismatch /CN=cn/O=o/L=L/ST=il/C= c error 29 at 0 depth lookup:subject issuer mismatch /CN=cn/O=o/L=L/ST=il/C= c error 29 at 0 depth lookup:subject issuer mismatch /CN=cn/O=o/L=L/ST=il/C= c error 29 at 0 depth lookup:subject issuer mismatch /CN=cn/O=o/L=L/ST=il/C= c error 20 at 0 depth lookup:unable to get local issuer certificate Regards Anil Sent with MailTrack -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Sun Jan 10 22:18:11 2016 From: karl at denninger.net (Karl Denninger) Date: Sun, 10 Jan 2016 16:18:11 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question Message-ID: <5692D8A3.5010402@denninger.net> I'm sure this is a function of my lack of understanding of the documentation, but here it is... I have an application that implements SSL-encrypted transport between two or more devices. For those that are clients without certificates (e.g. someone connecting with a web browser) it is working fine. However, I also want certain "things" to connect *with* a certificate. Toward that end I have set up a separate context for said connections, with (simplified a bit): master_method = (SSL_METHOD *) SSLv23_server_method(); /* Create instance */ master_context = SSL_CTX_new(master_method); /* Get SSL context for later */ Then I set up the CA that is going to verify the client certificates that are presented, with: sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR); if (!SSL_CTX_load_verify_locations(master_context, tmp, NULL)) { syslog(LOG_ERR, "Cannot load verification; MASTER will not validate"); } and then load the server-side certificate and key, plus tell it to verify the peer. sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert); if (SSL_CTX_use_certificate_file(master_context, tmp, SSL_FILETYPE_PEM) < 0) { syslog(LOG_WARNING, "Cannot load SSL Certificate - SSL MASTER DISABLED"); } else { sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey); if (SSL_CTX_use_PrivateKey_file(master_context, tmp, SSL_FILETYPE_PEM) < 0) { syslog(LOG_WARNING, "Cannot load SSL Key - SSL MASTER DISABLED"); } else { SSL_CTX_set_verify(master_context, SSL_VERIFY_PEER, verify_callback); master_ssl_possible = 1; /* Enable */ syslog(LOG_INFO, "SSL MASTER capability initalized."); } } verify_callback just returns the preverify_ok flag back; I don't care WHY the verification failed, just whether it did or not. In other words looking at the "last reason" is good enough (which I can get once the accept fails, if it does.) Now the client has a very similar set of code in it and when it connects it gets the verification (with the callback set to NULL) and, provided the certificate verifies against the CA file provided, all is well and it works. The client's certificate and key are loaded and the same basic code as up above is used to load the cert and key without errors being thrown (except, of course, that I call SSLv23_client_method() to get the method structure.) It also connects *and* properly verifies the server's certificate. However, on the server side I never get a client certificate back despite having loaded one into the context on the client and asking for it with SSL_VERIFY_PEER on the server. If I INSIST on a client certificate by adding the SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at SSL_accept() with an error indicating that no client certificate was provided. If not, however, the accept succeeds, the verification callback routine is never called (!) and when I attempt to get the peer certificate with SSL_get_peer_certificate() so I can walk through it and check the returned attributes (I wish to use the subjectAltName field among others) I get back a NULL. This has to be something stupid on my part, because I should get the verify_callback in any event, I believe -- but I never do. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From wilson.judson at gmail.com Sun Jan 10 23:07:49 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 10 Jan 2016 15:07:49 -0800 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <5692D8A3.5010402@denninger.net> References: <5692D8A3.5010402@denninger.net> Message-ID: On the client side, double check that you are creating the SSL object from the context AFTER you set the client cert for the context, and not the other way around. On Sun, Jan 10, 2016 at 2:18 PM, Karl Denninger wrote: > I'm sure this is a function of my lack of understanding of the > documentation, but here it is... > > I have an application that implements SSL-encrypted transport between two > or more devices. For those that are clients without certificates (e.g. > someone connecting with a web browser) it is working fine. > > However, I also want certain "things" to connect *with* a certificate. > Toward that end I have set up a separate context for said connections, with > (simplified a bit): > > master_method = (SSL_METHOD *) SSLv23_server_method(); > /* Create instance */ > master_context = SSL_CTX_new(master_method); /* Get SSL > context for later */ > > Then I set up the CA that is going to verify the client certificates that > are presented, with: > > sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR); > if (!SSL_CTX_load_verify_locations(master_context, tmp, > NULL)) { > syslog(LOG_ERR, "Cannot load verification; MASTER > will not validate"); > } > > and then load the server-side certificate and key, plus tell it to verify > the peer. > > sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert); > if (SSL_CTX_use_certificate_file(master_context, tmp, > SSL_FILETYPE_PEM) < 0) { > syslog(LOG_WARNING, "Cannot load SSL Certificate - > SSL MASTER DISABLED"); > } else { > sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey); > if (SSL_CTX_use_PrivateKey_file(master_context, > tmp, SSL_FILETYPE_PEM) < 0) { > syslog(LOG_WARNING, "Cannot load SSL Key - > SSL MASTER DISABLED"); > } else { > SSL_CTX_set_verify(master_context, > SSL_VERIFY_PEER, verify_callback); > master_ssl_possible = 1; /* Enable */ > syslog(LOG_INFO, "SSL MASTER capability > initalized."); > } > } > > verify_callback just returns the preverify_ok flag back; I don't care WHY > the verification failed, just whether it did or not. In other words > looking at the "last reason" is good enough (which I can get once the > accept fails, if it does.) > > Now the client has a very similar set of code in it and when it connects > it gets the verification (with the callback set to NULL) and, provided the > certificate verifies against the CA file provided, all is well and it > works. The client's certificate and key are loaded and the same basic code > as up above is used to load the cert and key without errors being thrown > (except, of course, that I call SSLv23_client_method() to get the method > structure.) It also connects *and* properly verifies the server's > certificate. > > However, on the server side I never get a client certificate back despite > having loaded one into the context on the client and asking for it with > SSL_VERIFY_PEER on the server. > > If I INSIST on a client certificate by adding the > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at > SSL_accept() with an error indicating that no client certificate was > provided. > > If not, however, the accept succeeds, the verification callback routine is > never called (!) and when I attempt to get the peer certificate with > SSL_get_peer_certificate() so I can walk through it and check the returned > attributes (I wish to use the subjectAltName field among others) I get back > a NULL. > > This has to be something stupid on my part, because I should get the > verify_callback in any event, I believe -- but I never do. > > -- > Karl Denninger > karl at denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Mon Jan 11 02:20:41 2016 From: karl at denninger.net (Karl Denninger) Date: Sun, 10 Jan 2016 20:20:41 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: References: <5692D8A3.5010402@denninger.net> Message-ID: <56931179.5030204@denninger.net> I found the problem... for an unexplained reason either the certificate or key were corrupt; I have added checking to make sure they're coherent, as apparently OpenSSL is perfectly happy to load a bogus cert (or key) without throwing an error, but won't present them. On 1/10/2016 17:07, Judson Wilson wrote: > On the client side, double check that you are creating the SSL object > from the context AFTER you set the client cert for the context, and > not the other way around. > > On Sun, Jan 10, 2016 at 2:18 PM, Karl Denninger > wrote: > > I'm sure this is a function of my lack of understanding of the > documentation, but here it is... > > I have an application that implements SSL-encrypted transport > between two or more devices. For those that are clients without > certificates (e.g. someone connecting with a web browser) it is > working fine. > > However, I also want certain "things" to connect *with* a > certificate. Toward that end I have set up a separate context for > said connections, with (simplified a bit): > > master_method = (SSL_METHOD *) > SSLv23_server_method(); /* Create instance */ > master_context = SSL_CTX_new(master_method); /* > Get SSL context for later */ > > Then I set up the CA that is going to verify the client > certificates that are presented, with: > > sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR); > if (!SSL_CTX_load_verify_locations(master_context, > tmp, NULL)) { > syslog(LOG_ERR, "Cannot load verification; > MASTER will not validate"); > } > > and then load the server-side certificate and key, plus tell it to > verify the peer. > > sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert); > if (SSL_CTX_use_certificate_file(master_context, > tmp, SSL_FILETYPE_PEM) < 0) { > syslog(LOG_WARNING, "Cannot load SSL > Certificate - SSL MASTER DISABLED"); > } else { > sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey); > if > (SSL_CTX_use_PrivateKey_file(master_context, tmp, > SSL_FILETYPE_PEM) < 0) { > syslog(LOG_WARNING, "Cannot load > SSL Key - SSL MASTER DISABLED"); > } else { > SSL_CTX_set_verify(master_context, > SSL_VERIFY_PEER, verify_callback); > master_ssl_possible = 1; /* > Enable */ > syslog(LOG_INFO, "SSL MASTER > capability initalized."); > } > } > > verify_callback just returns the preverify_ok flag back; I don't > care WHY the verification failed, just whether it did or not. In > other words looking at the "last reason" is good enough (which I > can get once the accept fails, if it does.) > > Now the client has a very similar set of code in it and when it > connects it gets the verification (with the callback set to NULL) > and, provided the certificate verifies against the CA file > provided, all is well and it works. The client's certificate and > key are loaded and the same basic code as up above is used to load > the cert and key without errors being thrown (except, of course, > that I call SSLv23_client_method() to get the method structure.) > It also connects *and* properly verifies the server's certificate. > > However, on the server side I never get a client certificate back > despite having loaded one into the context on the client and > asking for it with SSL_VERIFY_PEER on the server. > > If I INSIST on a client certificate by adding the > SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at > SSL_accept() with an error indicating that no client certificate > was provided. > > If not, however, the accept succeeds, the verification callback > routine is never called (!) and when I attempt to get the peer > certificate with SSL_get_peer_certificate() so I can walk through > it and check the returned attributes (I wish to use the > subjectAltName field among others) I get back a NULL. > > This has to be something stupid on my part, because I should get > the verify_callback in any event, I believe -- but I never do. > > -- > Karl Denninger > karl at denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > > _______________________________________________ > 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 -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From wilson.judson at gmail.com Mon Jan 11 03:04:25 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 10 Jan 2016 19:04:25 -0800 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <56931179.5030204@denninger.net> References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> Message-ID: It's always good to start with the s_client and s_server programs for incrementally verifying compatibility in your new programs. Those would have failed on your certificates, alerting you it's not a program problem. On Sun, Jan 10, 2016 at 6:20 PM, Karl Denninger wrote: > I found the problem... for an unexplained reason either the certificate or > key were corrupt; I have added checking to make sure they're coherent, as > apparently OpenSSL is perfectly happy to load a bogus cert (or key) without > throwing an error, but won't present them. > > > On 1/10/2016 17:07, Judson Wilson wrote: > > On the client side, double check that you are creating the SSL object from > the context AFTER you set the client cert for the context, and not the > other way around. > > On Sun, Jan 10, 2016 at 2:18 PM, Karl Denninger > wrote: > >> I'm sure this is a function of my lack of understanding of the >> documentation, but here it is... >> >> I have an application that implements SSL-encrypted transport between two >> or more devices. For those that are clients without certificates (e.g. >> someone connecting with a web browser) it is working fine. >> >> However, I also want certain "things" to connect *with* a certificate. >> Toward that end I have set up a separate context for said connections, with >> (simplified a bit): >> >> master_method = (SSL_METHOD *) SSLv23_server_method(); >> /* Create instance */ >> master_context = SSL_CTX_new(master_method); /* Get SSL >> context for later */ >> >> Then I set up the CA that is going to verify the client certificates that >> are presented, with: >> >> sprintf(tmp, "%s/ssl/ca.pem", CONFIG_DIR); >> if (!SSL_CTX_load_verify_locations(master_context, tmp, >> NULL)) { >> syslog(LOG_ERR, "Cannot load verification; MASTER >> will not validate"); >> } >> >> and then load the server-side certificate and key, plus tell it to verify >> the peer. >> >> sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, cert); >> if (SSL_CTX_use_certificate_file(master_context, tmp, >> SSL_FILETYPE_PEM) < 0) { >> syslog(LOG_WARNING, "Cannot load SSL Certificate >> - SSL MASTER DISABLED"); >> } else { >> sprintf(tmp, "%s/ssl/%s", CONFIG_DIR, pkey); >> if (SSL_CTX_use_PrivateKey_file(master_context, >> tmp, SSL_FILETYPE_PEM) < 0) { >> syslog(LOG_WARNING, "Cannot load SSL Key >> - SSL MASTER DISABLED"); >> } else { >> SSL_CTX_set_verify(master_context, >> SSL_VERIFY_PEER, verify_callback); >> master_ssl_possible = 1; /* Enable */ >> syslog(LOG_INFO, "SSL MASTER capability >> initalized."); >> } >> } >> >> verify_callback just returns the preverify_ok flag back; I don't care WHY >> the verification failed, just whether it did or not. In other words >> looking at the "last reason" is good enough (which I can get once the >> accept fails, if it does.) >> >> Now the client has a very similar set of code in it and when it connects >> it gets the verification (with the callback set to NULL) and, provided the >> certificate verifies against the CA file provided, all is well and it >> works. The client's certificate and key are loaded and the same basic code >> as up above is used to load the cert and key without errors being thrown >> (except, of course, that I call SSLv23_client_method() to get the method >> structure.) It also connects *and* properly verifies the server's >> certificate. >> >> However, on the server side I never get a client certificate back despite >> having loaded one into the context on the client and asking for it with >> SSL_VERIFY_PEER on the server. >> >> If I INSIST on a client certificate by adding the >> SSL_VERIFY_FAIL_IF_NO_PEER_CERT, the connections always fail at >> SSL_accept() with an error indicating that no client certificate was >> provided. >> >> If not, however, the accept succeeds, the verification callback routine >> is never called (!) and when I attempt to get the peer certificate with >> SSL_get_peer_certificate() so I can walk through it and check the returned >> attributes (I wish to use the subjectAltName field among others) I get back >> a NULL. >> >> This has to be something stupid on my part, because I should get the >> verify_callback in any event, I believe -- but I never do. >> >> -- >> Karl Denninger >> karl at denninger.net >> *The Market Ticker* >> *[S/MIME encrypted email preferred]* >> >> _______________________________________________ >> 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 > > > -- > Karl Denninger > karl at denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Mon Jan 11 03:07:58 2016 From: karl at denninger.net (Karl Denninger) Date: Sun, 10 Jan 2016 21:07:58 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> Message-ID: <56931C8E.3030505@denninger.net> Yeah, now I just have to figure out how to parse the X509 Extension data from the certificate to pull out the SubjectAltName information.... :-) There wouldn't be a snippet of code laying around somewhere that does that given a X509 cert as input would there? It looks a bit arcane.... On 1/10/2016 21:04, Judson Wilson wrote: > It's always good to start with the s_client and s_server programs for > incrementally verifying compatibility in your new programs. Those > would have failed on your certificates, alerting you it's not a > program problem. > > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From wilson.judson at gmail.com Mon Jan 11 03:19:44 2016 From: wilson.judson at gmail.com (Judson Wilson) Date: Sun, 10 Jan 2016 19:19:44 -0800 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <56931C8E.3030505@denninger.net> References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> <56931C8E.3030505@denninger.net> Message-ID: I think what you want might be found in the book "Network Security with OpenSSL" from the year 2002, and the same code snippit can be found here: http://www.cs.odu.edu/~cs772/ssl/c-examples/NSopenssl/common.c look for "post_connection_check". This is just something I remember from reading. I have no experience with it. On Sun, Jan 10, 2016 at 7:07 PM, Karl Denninger wrote: > Yeah, now I just have to figure out how to parse the X509 Extension data > from the certificate to pull out the SubjectAltName information.... :-) > > There wouldn't be a snippet of code laying around somewhere that does that > given a X509 cert as input would there? It looks a bit arcane.... > > On 1/10/2016 21:04, Judson Wilson wrote: > > It's always good to start with the s_client and s_server programs for > incrementally verifying compatibility in your new programs. Those would > have failed on your certificates, alerting you it's not a program problem. > > >> >> > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > Karl Denninger > karl at denninger.net > *The Market Ticker* > *[S/MIME encrypted email preferred]* > > _______________________________________________ > 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 Mon Jan 11 03:43:29 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 Jan 2016 03:43:29 +0000 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <56931179.5030204@denninger.net> References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> Message-ID: <20160111034329.GA18704@mournblade.imrryr.org> On Sun, Jan 10, 2016 at 08:20:41PM -0600, Karl Denninger wrote: > I found the problem... for an unexplained reason either the certificate > or key were corrupt; I have added checking to make sure they're > coherent, as apparently OpenSSL is perfectly happy to load a bogus cert > (or key) without throwing an error, but won't present them. You forgot the validate the loaded cert/key combination via: SSL_CTX_check_private_key(ctx); which should be called after loading the key and certificate. -- Viktor. From karl at denninger.net Mon Jan 11 03:47:44 2016 From: karl at denninger.net (Karl Denninger) Date: Sun, 10 Jan 2016 21:47:44 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> <56931C8E.3030505@denninger.net> Message-ID: <569325E0.6090304@denninger.net> I got that book.... that's what I've been working with. It looks like there have been some internal changes in OpenSSL and this is no longer "appropriate" to use as null dereferences may occur (well, ok, maybe a bit more than "may") :-) Got some ideas here, thanks... I think I'm pointed in the right direction. On 1/10/2016 21:19, Judson Wilson wrote: > I think what you want might be found in the book "Network Security > with OpenSSL" from the year 2002, and the same code snippit can be > found here: > > http://www.cs.odu.edu/~cs772/ssl/c-examples/NSopenssl/common.c > > > look for "post_connection_check". > > This is just something I remember from reading. I have no experience > with it. > > On Sun, Jan 10, 2016 at 7:07 PM, Karl Denninger > wrote: > > Yeah, now I just have to figure out how to parse the X509 > Extension data from the certificate to pull out the SubjectAltName > information.... :-) > > There wouldn't be a snippet of code laying around somewhere that > does that given a X509 cert as input would there? It looks a bit > arcane.... > > On 1/10/2016 21:04, Judson Wilson wrote: >> It's always good to start with the s_client and s_server programs >> for incrementally verifying compatibility in your new programs. >> Those would have failed on your certificates, alerting you it's >> not a program problem. >> >> >> >> >> >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > Karl Denninger > karl at denninger.net > /The Market Ticker/ > /[S/MIME encrypted email preferred]/ > > _______________________________________________ > 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 -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From karl at denninger.net Mon Jan 11 03:53:03 2016 From: karl at denninger.net (Karl Denninger) Date: Sun, 10 Jan 2016 21:53:03 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <20160111034329.GA18704@mournblade.imrryr.org> References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> <20160111034329.GA18704@mournblade.imrryr.org> Message-ID: <5693271F.4020505@denninger.net> On 1/10/2016 21:43, Viktor Dukhovni wrote: > On Sun, Jan 10, 2016 at 08:20:41PM -0600, Karl Denninger wrote: > >> I found the problem... for an unexplained reason either the certificate >> or key were corrupt; I have added checking to make sure they're >> coherent, as apparently OpenSSL is perfectly happy to load a bogus cert >> (or key) without throwing an error, but won't present them. > You forgot the validate the loaded cert/key combination via: > > SSL_CTX_check_private_key(ctx); > > which should be called after loading the key and certificate. > Yep. Fixed that, and then found out that the old recipes for walking through the subjectAltName data is no longer workable (apparently the published "book" work on that went rooting around in internal data structures that one should not be playing with)..... there's a resolution for that too though (just had to dig around a bit), so it's all good now. Thanks... -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From mail-list-users at materna.de Mon Jan 11 13:04:02 2016 From: mail-list-users at materna.de (Mail Lists) Date: Mon, 11 Jan 2016 14:04:02 +0100 Subject: [openssl-users] Mistake in buildprocess Message-ID: <5693A842.2000903@materna.de> Hello, there is a 'bug', more a mistake, in the buildprocess from openssl. If you set another destination with --prefix and compile openssl, than c_rehash tries to do it's job before the destination is created and generates warnings near the end: WARNING: can't open config file: /opt/openssl_101q/ssl/openssl.cnf ca-cert.pem => 3f77a2b5.0 WARNING: can't open config file: /opt/openssl_101q/ssl/openssl.cnf dsa-ca.pem => cbdbd8bc.0 WARNING: can't open config file: /opt/openssl_101q/ssl/openssl.cnf dsa-pca.pem => de4fa23b.0 WARNING: can't open config file: /opt/openssl_101q/ssl/openssl.cnf pca-cert.pem => e83ef475.0 The following patch modifies Makefile.org and moves the line, which invokes c_rehash, to install section: --- Makefile.orig 2016-01-11 10:43:57.336033819 +0100 +++ Makefile.orig.fix 2016-01-11 10:43:44.008078666 +0100 @@ -448,8 +448,7 @@ (OPENSSL="`pwd`/util/opensslwrap.sh"; \ [ -x "apps/openssl.exe" ] && OPENSSL="apps/openssl.exe" || :; \ OPENSSL_DEBUG_MEMORY=on; \ - export OPENSSL OPENSSL_DEBUG_MEMORY; \ - $(PERL) tools/c_rehash certs/demo) && \ + export OPENSSL OPENSSL_DEBUG_MEMORY) && \ touch rehash.time; \ else :; fi @@ -590,6 +589,7 @@ fi; \ fi; \ done; \ + $(PERL) tools/c_rehash certs/demo ; \ ( here="`pwd`"; \ cd $(INSTALL_PREFIX)$(INSTALLTOP)/$(LIBDIR); \ $(MAKE) -f $$here/Makefile HERE="$$here" link-shared ); \ Please apply the fix. Sincerly From rsalz at akamai.com Mon Jan 11 15:06:05 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 15:06:05 +0000 Subject: [openssl-users] Do you need EGD support? Message-ID: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> We are considering removing EGD support in 1.1 If your platform still needs it, please reply soon. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Mon Jan 11 16:02:04 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 11 Jan 2016 16:02:04 +0000 Subject: [openssl-users] Do you need EGD support? In-Reply-To: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Will you still support PRNGD? I need PRNGD, as I'm on a platform without a built-in random device or cpu instructions. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Monday, January 11, 2016 7:06 AM To: openssl-dev at openssl.org; openssl-users at openssl.org Subject: [openssl-users] Do you need EGD support? We are considering removing EGD support in 1.1 If your platform still needs it, please reply soon. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Jan 11 18:15:22 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 Jan 2016 13:15:22 -0500 Subject: [openssl-users] Mistake in buildprocess In-Reply-To: <5693A842.2000903@materna.de> References: <5693A842.2000903@materna.de> Message-ID: > On Jan 11, 2016, at 8:04 AM, Mail Lists wrote: > > Hello, > > there is a 'bug', more a mistake, in the buildprocess from openssl. > If you set another destination with --prefix and compile openssl, than c_rehash tries to do it's job before > the destination is created and generates warnings near the end: Thanks for the report, but the patch is not right. These certificates are not installed (and not supposed to be installed), and testing is not supposed to happen during "make install". The solution is to either suppress the warnings when the configuration file is missing, or to explicitly specify a non-default .cnf file from the build tree. -- Viktor. From lutz at lutz-jaenicke.de Mon Jan 11 20:25:35 2016 From: lutz at lutz-jaenicke.de (=?UTF-8?Q?Lutz_J=c3=a4nicke?=) Date: Mon, 11 Jan 2016 21:25:35 +0100 Subject: [openssl-users] Do you need EGD support? In-Reply-To: References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <56940FBF.8040603@lutz-jaenicke.de> On 11.01.2016 17:02, Scott Neugroschl wrote: > > Will you still support PRNGD? I need PRNGD, as I?m on a platform > without a built-in random device or cpu instructions. > PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. Best regards, Lutz > > > *From:*openssl-users [mailto:openssl-users-bounces at openssl.org] *On > Behalf Of *Salz, Rich > *Sent:* Monday, January 11, 2016 7:06 AM > *To:* openssl-dev at openssl.org; openssl-users at openssl.org > *Subject:* [openssl-users] Do you need EGD support? > > > > We are considering removing EGD support in 1.1 If your platform still > needs it, please reply soon. > > > > -- > > Senior Architect, Akamai Technologies > > IM: richsalz at jabber.at Twitter: RichSalz > > > > > > _______________________________________________ > 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 Mon Jan 11 20:32:42 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 11 Jan 2016 20:32:42 +0000 Subject: [openssl-users] [openssl-dev] Do you need EGD support? In-Reply-To: <56940FBF.8040603@lutz-jaenicke.de> References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> <56940FBF.8040603@lutz-jaenicke.de> Message-ID: >>Will you still support PRNGD?? I need PRNGD, as I?m on a platform without a built-in random device or cpu instructions. > PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. Thanks. That means we should not remove it right away. (Although perhaps we need only use it in the library, not the command-line?) From jb-openssl at wisemo.com Mon Jan 11 20:38:05 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 11 Jan 2016 21:38:05 +0100 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> Message-ID: <569412AD.1010002@wisemo.com> On 08/01/2016 18:43, Salz, Rich wrote: > Are you going to keep posting and posting until you get a response? :( > > Master branch, 1.1, is not released but will not be vulnerable (may already be fixed) > 1.0.2 is not vulnerable. > 1.0.1f and later are not vulnerable. > 1.0.0 might be, and is end of life anyway so you should move of that. > 0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable. If you read the description of SLOTH (linked in the OP), you will see that it is not limited to TLS 1.2 and probably affects the TLS/SSL versions implemented by older (end of life) OpenSSL versions such as 0.9.8. Basically, it is a laundry list of ways that backward compatible hash uses in the SSL/TLS protocols are weaker than some people assume. Their summary list doesn't even consider the possibility that some people still need to use TLS 1.1 or older, so barely mentions those. This also means that completely protecting an implementation against SLOTH is not possible without breaking interoperability with implementations that are not or cannot be updated to the latest protocol versions and features (This happens to include some widely deployed embedded operating systems). Now it so happens that SLOTH also includes an attack on implementation bugs that can be tricked into using/accepting MD5-based signatures when they shouldn't. That *particular* aspect of SLOTH was apparently fixed in 1.0.1f and 1.0.2. The entire discussion would have been easier if the SLOTH team at INRIA had given specific names and CVE ids for each of the issues in their report, such that one might say "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3: hypothetical for now, can be fixed with a cipher string setting, etc. etc." But no such names exist. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lutz at lutz-jaenicke.de Mon Jan 11 21:12:54 2016 From: lutz at lutz-jaenicke.de (=?UTF-8?Q?Lutz_J=c3=a4nicke?=) Date: Mon, 11 Jan 2016 22:12:54 +0100 Subject: [openssl-users] [openssl-dev] Do you need EGD support? In-Reply-To: References: <11d84bf7c4d847a0b9e03f9a3ea16b44@usma1ex-dag1mb1.msg.corp.akamai.com> <56940FBF.8040603@lutz-jaenicke.de> Message-ID: <56941AD6.7030401@lutz-jaenicke.de> On 11.01.2016 21:32, Salz, Rich wrote: >>> Will you still support PRNGD? I need PRNGD, as I?m on a platform without a built-in random device or cpu instructions. >> PRNGD is a direct replacement for EGD, so if the interface to EGD is removed from OpenSSL, PRNGD stops to work for it as well. > Thanks. That means we should not remove it right away. (Although perhaps we need only use it in the library, not the command-line?) Removing it from the command line tools would make the apps with random number requirements useless... Best regards, Lutz From janjust at nikhef.nl Mon Jan 11 22:02:42 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Mon, 11 Jan 2016 23:02:42 +0100 Subject: [openssl-users] Jks converted to Pem error in veirfying In-Reply-To: References: Message-ID: <56942682.6060002@nikhef.nl> Hi, On 10/01/16 05:15, Anil Mathew wrote: > I am a novice in terms of ssl and hence have limited knowledge in this. > Please help > > I have been a given a jks file that has server certificate, client > certificate and a key for the client certificate. I need to convert it to > pem to use it in my application. > > I have converted a jks file to p12 and then to pem. > However when i try to verify i get the following error. > > echo |openssl verify -verbose -purpose sslclient -issuer_checks -CApath > C:\Data\Openssl\demoCA\certs -CAfile client.pem client.pem > client.pem: /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 20 at 0 depth lookup:unable to get local issuer certificate this could be a PRINTABLE_STRING / UTF8_STRING mismatch - can you send me the certificates (not the key!) via private email and I will have a look. There are some funky options you can add to openssl to see how the certificate is composed. Also, it would help to list the exact version of openssl that you are using (run 'openssl version'). HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Mon Jan 11 22:58:19 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 11 Jan 2016 23:58:19 +0100 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <569412AD.1010002@wisemo.com> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> <569412AD.1010002@wisemo.com> Message-ID: <20160111225819.GA11720@roeckx.be> On Mon, Jan 11, 2016 at 09:38:05PM +0100, Jakob Bohm wrote: > On 08/01/2016 18:43, Salz, Rich wrote: > >Are you going to keep posting and posting until you get a response? :( > > > >Master branch, 1.1, is not released but will not be vulnerable (may already be fixed) > >1.0.2 is not vulnerable. > >1.0.1f and later are not vulnerable. > >1.0.0 might be, and is end of life anyway so you should move of that. > >0.9.8 is also end of life, but does not do TLS 1.2 so is not vulnerable. > If you read the description of SLOTH (linked in the OP), you > will see that it is not limited to TLS 1.2 and probably > affects the TLS/SSL versions implemented by older (end of > life) OpenSSL versions such as 0.9.8. > > Basically, it is a laundry list of ways that backward > compatible hash uses in the SSL/TLS protocols are weaker > than some people assume. Their summary list doesn't even > consider the possibility that some people still need to use > TLS 1.1 or older, so barely mentions those. > > This also means that completely protecting an > implementation against SLOTH is not possible without > breaking interoperability with implementations that > are not or cannot be updated to the latest protocol > versions and features (This happens to include some > widely deployed embedded operating systems). > > Now it so happens that SLOTH also includes an attack on > implementation bugs that can be tricked into > using/accepting MD5-based signatures when they shouldn't. > That *particular* aspect of SLOTH was apparently fixed > in 1.0.1f and 1.0.2. > > The entire discussion would have been easier if the SLOTH > team at INRIA had given specific names and CVE ids for > each of the issues in their report, such that one might say > "SLOTH-1: Never vulnerable, SLOTH-2: Fixed in 1.0.1f, SLOTH-3: > hypothetical for now, can be fixed with a cipher string > setting, etc. etc." But no such names exist. So here are the things mentioned in the paper: 1) Some things that were believed to require preimage resistance need collision resistance. This by itself reduces security bits of the hashes by a factor 2. Assuming MD5 and SHA1 didn't have any problem with collision resistance it would be reduced from 128 and 160 bit to 64 and 80. But they have a problem with collision resistance and so it's worse, specially for MD5. 2) Some implementations support MD5 based signatures in TLS 1.2 3) Some implementations accept the MD5 based signatures in TLS 1.2 while it would appear they didn't. SLOTH really is just about 1). It says that you should stop using MD5 and really look at stopping to use SHA1. And so 2) and 3) are just 2 cases where MD5 is used. But just fixing 2) and 3) is just fixing the problem with MD5, while we should also look at stopping SHA1. TLS 1.0 and 1.1 use MD5 + SHA1, so while those are enabled we're stuck at the level of SHA1. Kurt From noloader at gmail.com Mon Jan 11 23:15:06 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 11 Jan 2016 18:15:06 -0500 Subject: [openssl-users] openSSL and SLOTH attack In-Reply-To: <20160111225819.GA11720@roeckx.be> References: <201601071141.u07BfeqV024162@d28av01.in.ibm.com> <569412AD.1010002@wisemo.com> <20160111225819.GA11720@roeckx.be> Message-ID: > So here are the things mentioned in the paper: > 1) Some things that were believed to require preimage resistance > need collision resistance. This by itself reduces security bits > of the hashes by a factor 2. Assuming MD5 and SHA1 didn't have > any problem with collision resistance it would be reduced from > 128 and 160 bit to 64 and 80. But they have a problem with > collision resistance and so it's worse, specially for MD5. > 2) Some implementations support MD5 based signatures in TLS 1.2 > 3) Some implementations accept the MD5 based signatures in TLS 1.2 > while it would appear they didn't. > > SLOTH really is just about 1). It says that you should stop using > MD5 and really look at stopping to use SHA1. And so 2) and 3) are > just 2 cases where MD5 is used. > > But just fixing 2) and 3) is just fixing the problem with MD5, > while we should also look at stopping SHA1. TLS 1.0 and 1.1 use > MD5 + SHA1, so while those are enabled we're stuck at the level of > SHA1. Forgive my ignorance... Aren't these two different application of the hash? The latter, TLS 1.0 and 1.1, is approved when they are used as the PRF. Is the PRF in danger? (I only skimmed the paper, but I did not get the impression the PRF was in jeopardy). Jeff From Michal.Trojnara at stunnel.org Tue Jan 12 09:05:42 2016 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Tue, 12 Jan 2016 10:05:42 +0100 Subject: [openssl-users] SSL_COMP Message-ID: <5694C1E6.6070303@stunnel.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi Guys, Any idea how to properly use: STACK_OF(SSL_COMP) *SSL_COMP_get_compression_methods(void); STACK_OF(SSL_COMP) *SSL_COMP_set0_compression_methods(STACK_OF(SSL_COMP) *meths); in the latest OpenSSL 1.1 git, which no longer declares SSL_COMP? I guess openssl/ssl.h should be modified to include: typedef struct ssl_comp_st SSL_COMP; DEFINE_STACK_OF(SSL_COMP) Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWlMHlAAoJEC78f/DUFuAU3JMQAMtCTOp6fK45IPWwJf+wQ89M J6Le/KtsVN1IHqnubJF8OUcAxJCMRf0u75irRukuhil8SQ5SgVmham8IhD2oeQ2F EAbLAZC1GRBBD5q2E+1XcXGB520PKiSjHjz0cEAr7GmLkzUggw1d1/cDKsjiKpnx CMdCCQ1cTZ/tWt4m2dHnqh4lDpjnKN8AhTsMo8NZjqf3w4gZPtQbUhoIDhR18OUt xiiaDtKXlYUu+aGtI5lLC2FoU1cFJ8t5ovynsfzB5lLaB5kKKxx7JbjyhtbW1Nxa UCjzkgJCrpFkeWKx38ddWpf9gCjPMUJ+1rirlukuVs5mitqf8jsiqOIk8qW+E0KJ ANlWfMNRkk/vLqw4tO9TfPn3WUzmuGbFt3TFUrF8Wj8AtgGYatHdB88m2UzQqdz/ mMaCYZq6B60BnMsHFTKoqdpYRVyTaAde/kAYTBp5CcXbYN/hWx63EtYgtxxtl++2 ts06xj3xze6cy9L9Q4d1qsPf8GtBRiQgkwU7qFjvI4ZE1P5YdJDejNOjOpO7yP8x S+oFjX0DiaxHFEkoo2GTMj4dBMTBmZ58h7BTZY6PH72JibH1juDe/WWTwSUqWYzJ zrRkDqiU8cVxonEvVTrppK/jd5gCYmF0b1jlaBZrvrPCEBOCRpYGxI7AIdInk5tv YeMSmqRugknjQ88AQYxT =BCDL -----END PGP SIGNATURE----- From anilmathew001 at gmail.com Tue Jan 12 09:15:11 2016 From: anilmathew001 at gmail.com (Anil Mathew) Date: Tue, 12 Jan 2016 13:15:11 +0400 Subject: [openssl-users] Jks converted to Pem error in veirfying In-Reply-To: <56942682.6060002@nikhef.nl> References: <56942682.6060002@nikhef.nl> Message-ID: Hi Jan, Thanks for you reply. I have sent you the mail with the certificates. The version is. OpenSSL 0.9.8k 25 Mar 2009 ?Regards Anil? Sent with MailTrack On Tue, Jan 12, 2016 at 2:02 AM, Jan Just Keijser wrote: > Hi, > > On 10/01/16 05:15, Anil Mathew wrote: > > I am a novice in terms of ssl and hence have limited knowledge in this. > Please help > > I have been a given a jks file that has server certificate, client > certificate and a key for the client certificate. I need to convert it to > pem to use it in my application. > > I have converted a jks file to p12 and then to pem. > However when i try to verify i get the following error. > > echo |openssl verify -verbose -purpose sslclient -issuer_checks -CApath > C:\Data\Openssl\demoCA\certs -CAfile client.pem client.pem > client.pem: /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 29 at 0 depth lookup:subject issuer mismatch > /CN=cn/O=o/L=L/ST=il/C= c > error 20 at 0 depth lookup:unable to get local issuer certificate > > > this could be a PRINTABLE_STRING / UTF8_STRING mismatch - can you send me > the certificates (not the key!) via private email and I will have a look. > There are some funky options you can add to openssl to see how the > certificate is composed. > > Also, it would help to list the exact version of openssl that you are > using (run 'openssl version'). > > HTH, > > JJK > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Best Regards Anil Mathew -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Jan 12 19:01:47 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jan 2016 14:01:47 -0500 Subject: [openssl-users] SSL_COMP In-Reply-To: <5694C1E6.6070303@stunnel.org> References: <5694C1E6.6070303@stunnel.org> Message-ID: > typedef struct ssl_comp_st SSL_COMP; Yes, that needs to be visible. Thanks. Patch below: openssl base64 -d < ssl_comp.diff H4sIANFMlVYAA42SwW7iMBCG736KkfYCZJ3QNEArLkU0FLQUEM5hb1awHWIpJFFs tKyqffe1SygtpFUjRbZn/vnl8XxcJglgvJUaYk/mLNtz4RWlyJXKPPO7KWya40jm XBxg09/EvfuN6woWxJwFcNPt9oMAYYw/c0SO43zq+vAA+Nbv/bwDxy43XTAR/bcU XCSgdLVnGoySMlmmoqJKAyFzOp6tpuF6iJqUSigli/wkJSEhs+XiWqszRZXcxtlW WW00J5TMnkbzJ9Lsy4o8oUwf3u6wXEzoOPo9RE6jeleelc8r44ngMZzMFiEl0Wj8 iy4n1oJErXNDbeRcSFqn+rat9zpA1tEKyqrQgmnTpd0mMhMKkqKCvRLwR+oUdCrs gapKlyAO2ry4FbfWkzH0Bv2g3fGuezRaenamtbNt4gXx99zU06NZwY7AfAzUpMTB fZfxW9dlvu/HA/6RlIuSIyIXQctG/85A0QPndfWb4KjK01Re7Bv9AJGb25ot/tZY MGrKGyv7yVyD5MPjwQBgMiyNK+jk8U7UYWtDn8NounyEzk7otLAF/+zA8RfTrFPz 6YhMT6ma1fYrLOg/L07Oi6wDAAA= EOF -- Viktor. From openssl-users at dukhovni.org Tue Jan 12 19:18:11 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 Jan 2016 14:18:11 -0500 Subject: [openssl-users] SSL_COMP In-Reply-To: <5694C1E6.6070303@stunnel.org> References: <5694C1E6.6070303@stunnel.org> Message-ID: <0FA97769-EA66-4142-A079-9BF136DF2CF6@dukhovni.org> > On Jan 12, 2016, at 4:05 AM, Michal Trojnara wrote: > > Any idea how to properly use: > STACK_OF(SSL_COMP) *SSL_COMP_get_compression_methods(void); > STACK_OF(SSL_COMP) *SSL_COMP_set0_compression_methods(STACK_OF(SSL_COMP) > *meths); > in the latest OpenSSL 1.1 git, which no longer declares SSL_COMP? > > I guess openssl/ssl.h should be modified to include: > typedef struct ssl_comp_st SSL_COMP; > DEFINE_STACK_OF(SSL_COMP) Try a more recent git commit. This should be fixed now. -- Viktor. From Michal.Trojnara at stunnel.org Tue Jan 12 19:43:14 2016 From: Michal.Trojnara at stunnel.org (=?UTF-8?Q?Micha=c5=82_Trojnara?=) Date: Tue, 12 Jan 2016 20:43:14 +0100 Subject: [openssl-users] SSL_COMP In-Reply-To: <0FA97769-EA66-4142-A079-9BF136DF2CF6@dukhovni.org> References: <5694C1E6.6070303@stunnel.org> <0FA97769-EA66-4142-A079-9BF136DF2CF6@dukhovni.org> Message-ID: <56955752.90508@stunnel.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 12.01.2016 20:18, Viktor Dukhovni wrote: >> On Jan 12, 2016, at 4:05 AM, Michal Trojnara >> wrote: I guess openssl/ssl.h should >> be modified to include: typedef struct ssl_comp_st SSL_COMP; >> DEFINE_STACK_OF(SSL_COMP) > > Try a more recent git commit. This should be fixed now. It works. Thank you. Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJWlVdRAAoJEC78f/DUFuAUbfIQAMrWPpm37y3/qajjOmvN+ZX4 uke0FFWyMY94DrsSFcL6GjdLa6T1/LvuyDELVn+lujPlMMGq8zApSyQ5Qnsz3Vbq oosKVga1jpCgJasx8aas4kk6faiggNrk+THjIC5GZtMlqLN/o/cC5SDQgYKQ0UBA PZRaywTbS37Sdu8gldu0mL46SqGhwyeUV/dNeAvKiB1Bimb4HZMYM3cqs6dabBfr pw7ymJIa99rSKx4DureWZ+vIrtHyfFm34QT9JB0A+3qqj8m0B8DG71ljsUSbAu7p YIz1QJ3Aj1qOqWC76JEVtw/754/YKOnWFtapt1A09C9Cxo3DxFFHEwhmiJYHjPu/ 0WZbnw91PU9KjEqJ+f6ELxyTT315WjxT2pypgDKw/E1EIetQoaOGukMW1UnTTVJY UKSsotkNoDT5mrFcfW355KorvXmguKcd3rKT+6gC6zW0CO1pGmCunyp9hSm7K5l1 +pb1cRNDGYIn6jDPJuqCameTFsYx2YGYYGK41k6Bu9kyF8xzWnys26U+aIs4Ib6k IXToIjDF52gVGS1UQYrz08QsVV3XnI47Q/+FIOlY9oOEMHISQvytIJp7kVaUNZ1Z 0g6g7xEQgn53LMai45htTkzR4Sv15rQDYvXr6IU9KmiCKWUhVmJVa1hTaVAeO8ZX 6i+qE6WzyHUC8qLnuoaL =4EYu -----END PGP SIGNATURE----- From jeffarcher7 at gmail.com Tue Jan 12 21:03:42 2016 From: jeffarcher7 at gmail.com (Jeff Archer) Date: Tue, 12 Jan 2016 16:03:42 -0500 Subject: [openssl-users] libssl.so.1.0.0 Message-ID: I am building from source that came from openssl-1.0.2e.tar.gz but it appears to be producing output of libssl.so.1.0.0. Is this what I should expect? Jeff Archer jeffarcher7 at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From kurt at roeckx.be Tue Jan 12 21:51:55 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 12 Jan 2016 22:51:55 +0100 Subject: [openssl-users] libssl.so.1.0.0 In-Reply-To: References: Message-ID: <20160112215154.GA26943@roeckx.be> On Tue, Jan 12, 2016 at 04:03:42PM -0500, Jeff Archer wrote: > I am building from source that came from openssl-1.0.2e.tar.gz but it > appears to be producing output of libssl.so.1.0.0. Is this what I should > expect? Yes. That is the correct soname for all 1.0.X releases. Kurt From joe.flowers at nofreewill.com Tue Jan 12 22:43:58 2016 From: joe.flowers at nofreewill.com (Joe Flowers) Date: Tue, 12 Jan 2016 17:43:58 -0500 Subject: [openssl-users] OpenSSL 0.9.8 - No more security fixes, nor updates and support, But NO CVEs listed either? Message-ID: Hello OpenSSL Developers, I understand through your previous announcements that OpenSSL 0.9.8 is no longer "supported", and no more "security fixes", nor "security updates" will be provided by OpenSSL.org. Does this mean that we can expect no more CVEs to be generated or listed for OpenSSL 0.9.8 also? Thanks! Joe ------------------------ "NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS." "As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade." per http://openssl.org/news/secadv/20151203.txt. ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From flowers.joseph at gmail.com Tue Jan 12 23:05:00 2016 From: flowers.joseph at gmail.com (Joe Flowers) Date: Tue, 12 Jan 2016 18:05:00 -0500 Subject: [openssl-users] OpenSSL 0.9.8 - No more security fixes, nor updates and support, But NO CVEs listed either? Message-ID: Hello OpenSSL Developers, I understand through your previous announcements that OpenSSL 0.9.8 is no longer "supported", and no more "security fixes", nor "security updates" will be provided by OpenSSL.org. Does this mean that we can expect no more CVEs to be generated or listed for OpenSSL 0.9.8 also? Thanks! Joe ------------------------ "NOTE: WE ANTICIPATE THAT 1.0.0t AND 0.9.8zh WILL BE THE LAST RELEASES FOR THE 0.9.8 AND 1.0.0 VERSIONS AND THAT NO MORE SECURITY FIXES WILL BE PROVIDED (AS PER PREVIOUS ANNOUNCEMENTS). USERS ARE ADVISED TO UPGRADE TO LATER VERSIONS." "As per our previous announcements and our Release Strategy (https://www.openssl.org/about/releasestrat.html), support for OpenSSL versions 1.0.0 and 0.9.8 will cease on 31st December 2015. No security updates for these versions will be provided after that date. In the absence of significant security issues being identified prior to that date, the 1.0.0t and 0.9.8zh releases will be the last for those versions. Users of these versions are advised to upgrade." per http://openssl.org/news/secadv/20151203.txt. ------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Jan 13 00:01:54 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 Jan 2016 00:01:54 +0000 Subject: [openssl-users] OpenSSL 0.9.8 - No more security fixes, nor updates and support, But NO CVEs listed either? In-Reply-To: References: Message-ID: <569593F2.1020809@openssl.org> On 12/01/16 22:43, Joe Flowers wrote: > Hello OpenSSL Developers, > > > I understand through your previous announcements that OpenSSL 0.9.8 is no longer "supported", and no more "security fixes", nor "security updates" will be provided by OpenSSL.org. > > > Does this mean that we can expect no more CVEs to be generated or listed for OpenSSL 0.9.8 also? Not supported means we will no longer being doing work on the 0.9.8 or 1.0.0 branches. This includes any analysis which may lead to a CVE assignment. Matt From flowers.joseph at gmail.com Wed Jan 13 02:29:34 2016 From: flowers.joseph at gmail.com (Joe Flowers) Date: Tue, 12 Jan 2016 21:29:34 -0500 Subject: [openssl-users] OpenSSL 0.9.8 - No more security fixes, nor updates and support, But NO CVEs listed either? In-Reply-To: References: Message-ID: Thanks, Matt! I did not know that OpenSSL.org is the only organization that creates CVEs for OpenSSL. Thanks for clearing this up for me! Joe ------------------ On 12/01/16 22:43, Joe Flowers wrote: >* Hello OpenSSL Developers, *> > >* I understand through your previous announcements that OpenSSL 0.9.8 is no longer "supported", and no more "security fixes", nor "security updates" will be provided by OpenSSL.org. *> > >* Does this mean that we can expect no more CVEs to be generated or listed for OpenSSL 0.9.8 also? * Not supported means we will no longer being doing work on the 0.9.8 or 1.0.0 branches. This includes any analysis which may lead to a CVE assignment. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From michel.sales at free.fr Wed Jan 13 12:50:54 2016 From: michel.sales at free.fr (Michel) Date: Wed, 13 Jan 2016 13:50:54 +0100 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> <56931C8E.3030505@denninger.net> Message-ID: <001201d14e01$0a94c1f0$1fbe45d0$@sales@free.fr> Hi Karl, I believe it could be helpful to have a look at the 509_check_host() and do_x509_check() source code in crypto\x509v3\v3_utl.c. Also, if you want to parse the SAN just for certificate validation, it is now easier to use : https://www.openssl.org/docs/manmaster/crypto/X509_VERIFY_PARAM_set_flags.html Hope this helps, Regards, Michel. De : openssl-users [mailto:openssl-users-bounces at openssl.org] De la part de Karl Denninger Envoy? : lundi 11 janvier 2016 04:08 ? : openssl-users at openssl.org Objet : Re: [openssl-users] (Probably) Silly Application Programming Question Yeah, now I just have to figure out how to parse the X509 Extension data from the certificate to pull out the SubjectAltName information.... :-) There wouldn't be a snippet of code laying around somewhere that does that given a X509 cert as input would there? It looks a bit arcane.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From karl at denninger.net Wed Jan 13 16:19:11 2016 From: karl at denninger.net (Karl Denninger) Date: Wed, 13 Jan 2016 10:19:11 -0600 Subject: [openssl-users] (Probably) Silly Application Programming Question In-Reply-To: <001201d14e01$0a94c1f0$1fbe45d0$@sales@free.fr> References: <5692D8A3.5010402@denninger.net> <56931179.5030204@denninger.net> <56931C8E.3030505@denninger.net> <001201d14e01$0a94c1f0$1fbe45d0$@sales@free.fr> Message-ID: <569678FF.50200@denninger.net> Unfortunately I need a bit more than that. I have two things I'm trying to accomplish, both in the context of checking a client that is connecting to the server: 1. The OpenSSL code by default does not check the OCSP revocation servers when validating a certificate, and I haven't found a "built in" way to do that. Thus, I need to pull out the OCSP responder location from the certificate and check it myself. In this particular application the certificates all come from a private CA which has an OCSP server associated with it, and if a certificate is revoked it's important that it be immediately invalidated. I also wish to have the server operator be given the choice of either allowing the connection to proceed if the OCSP server fails to respond (e.g. is offline temporarily) or to drop the connection. 2. The server has both a "name" (which is usually a shorter version of the hostname; a short "nickname" is nice from a user interface perspective) it expects to connect and a password. While I could simply rely on the presentation of that from the client theft of that tuple would allow any valid certificate-bearing client to impersonate a different client. I can significantly harden against that risk by adding the SAN hostname to the database of names and passwords; now to be considered when the credential is presented the cert associated with that peer has to contain a SAN extension containing the expected DNS name as well. Thus, if you manage to steal a set of login credentials unless you *also* steal the certificate and key associated with it what you managed to get your hands on is worthless. I've got #2 working and am working on #1; it doesn't look all that awful to implement. On 1/13/2016 06:50, Michel wrote: > > Hi Karl, > > > > I believe it could be helpful to have a look at the 509_check_host() > and do_x509_check() source code in crypto\x509v3\v3_utl.c. > > Also, if you want to parse the SAN just for certificate validation, it > is now easier to use : > > https://www.openssl.org/docs/manmaster/crypto/X509_VERIFY_PARAM_set_flags.html > > > > Hope this helps, > > > > Regards, > > > > Michel. > > > > *De :*openssl-users [mailto:openssl-users-bounces at openssl.org] *De la > part de* Karl Denninger > *Envoy? :* lundi 11 janvier 2016 04:08 > *? :* openssl-users at openssl.org > *Objet :* Re: [openssl-users] (Probably) Silly Application Programming > Question > > > > Yeah, now I just have to figure out how to parse the X509 Extension > data from the certificate to pull out the SubjectAltName > information.... :-) > > There wouldn't be a snippet of code laying around somewhere that does > that given a X509 cert as input would there? It looks a bit arcane.... > > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From trajber at gmail.com Wed Jan 13 17:37:10 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Wed, 13 Jan 2016 15:37:10 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command Message-ID: Hi, I created a CSR with subjectAlternativeNames: $ openssl req -noout -in my.csr -text .... Requested Extensions: X509v3 Subject Alternative Name: IP Address:1.1.1.1, DNS:www.example.com ... But when I try to sign it using my own CA using the x509 command this data is removed $ openssl x509 -req -in my.csr -CA my-ca.cert -CAkey my-ca.key -CAcreateserial -out my.cert -days 3650 Do you know how can I preserve this data on my certificate? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jan 13 17:42:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 Jan 2016 17:42:15 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: Message-ID: >But when I try to sign it using my own CA using the x509 command this data is removed? You need to make sure that subjectAltName is marked as copy in your config file. From trajber at gmail.com Wed Jan 13 18:22:10 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Wed, 13 Jan 2016 16:22:10 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: Message-ID: In which section? On section [CA_default] I have 'copy_extensions = copy' Can I do this using only command line options? On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich wrote: > >But when I try to sign it using my own CA using the x509 command this > data is removed > > You need to make sure that subjectAltName is marked as copy in your config > file. > _______________________________________________ > 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 Wed Jan 13 18:25:36 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 13 Jan 2016 18:25:36 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: Message-ID: <70ba4671735c40efa4a846469fbcb89d@usma1ex-dag1mb1.msg.corp.akamai.com> In your ca_defualt you should have a x509_extensions field that references another stanza. That other stanza needs the copy. I don?t know if copy_extensions copies everything. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 13 18:46:17 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 13 Jan 2016 13:46:17 -0500 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: Message-ID: <42A91DBB-E5AA-4513-8828-1013AB7A45F1@dukhovni.org> > On Jan 13, 2016, at 1:22 PM, Mauro Romano Trajber wrote: > > In which section? > > On section [CA_default] I have 'copy_extensions = copy' In case you find it useful, I am attaching a bash script I use to generate certificate chains for various automated tests. This does not use any customized .cnf files, and bypasses the ca(1) utility, just signs directly via "openssl x509 -req" and extension settings created on the fly via "-extfile <(printf ...)". -------------- next part -------------- A non-text attachment was scrubbed... Name: mkcert Type: application/octet-stream Size: 2872 bytes Desc: not available URL: -------------- next part -------------- The keys created are always EC P-256 keys, but you can change that part of the script if you want RSA instead. $ ./mkcert genroot "Root CA" rootkey rootcert $ ./mkcert genca "Issuer CA" cakey cacert rootkey rootcert $ ./mkcert genee "$(uname -n)" eekey eecert cakey cacert $ openssl x509 -in eecert.pem -text -noout | egrep 'DNS:|Subject|Issuer' Issuer: CN = Issuer CA Subject: CN = vpro.lan Subject Public Key Info: X509v3 Subject Key Identifier: X509v3 Subject Alternative Name: DNS:vpro.lan -- Viktor. From trajber at gmail.com Wed Jan 13 19:23:36 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Wed, 13 Jan 2016 17:23:36 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: <42A91DBB-E5AA-4513-8828-1013AB7A45F1@dukhovni.org> References: <42A91DBB-E5AA-4513-8828-1013AB7A45F1@dukhovni.org> Message-ID: Thanks, I could not make subjectAltName copy at all. I try several ways without success - subjectAltName=IP:copy its not a valid option like subjectAltName=email:copy. What works for me (but doesn't seems to be the correct solution) is pass the extfile to x509 command with subjectAltName data again - although the CSR file already contain this information Here goes what I did: # creating the CA $ openssl genrsa -out ca.key 2048 $ openssl req -new -x509 -nodes -days 3650 -key ca.key -out ca.cert -subj '/C=xx/ST=xx/L=xx/CN=catest' # creating the peer certificate $ openssl genrsa -out server.key 2048 $ openssl req -new -key server.key -out server.csr -subj '/C=xx/ST=xx/L=xx/CN=server/' -reqexts SAN -config <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=IP:1.1.1.1,DNS: www.example.com")) At this point we can see that the CSR file contains the v3ext data: $ openssl req -noout -text -in server.csr .... Requested Extensions: X509v3 Subject Alternative Name: IP Address:1.1.1.1, DNS:www.example.com ... But to subjectAltName data be included in the certificate I must pass all info again to x509 command: $ openssl x509 -req -in server.csr -CA ca.cert -CAkey ca.key -CAcreateserial -out server.cert -days 3650 -extfile <(cat /etc/ssl/openssl.cnf <(printf "[SAN]\nsubjectAltName=IP:1.1.1.1,DNS: www.example.com")) -extensions SAN $ openssl x509 -noout -text -in server.cert .... Requested Extensions: X509v3 Subject Alternative Name: IP Address:1.1.1.1, DNS:www.example.com ... On Wed, Jan 13, 2016 at 4:46 PM, Viktor Dukhovni wrote: > > > On Jan 13, 2016, at 1:22 PM, Mauro Romano Trajber > wrote: > > > > In which section? > > > > On section [CA_default] I have 'copy_extensions = copy' > > In case you find it useful, I am attaching a bash script I use to > generate certificate chains for various automated tests. > > This does not use any customized .cnf files, and bypasses the ca(1) > utility, just signs directly via "openssl x509 -req" and extension > settings created on the fly via "-extfile <(printf ...)". > > > > > The keys created are always EC P-256 keys, but you can change > that part of the script if you want RSA instead. > > $ ./mkcert genroot "Root CA" rootkey rootcert > $ ./mkcert genca "Issuer CA" cakey cacert rootkey rootcert > $ ./mkcert genee "$(uname -n)" eekey eecert cakey cacert > $ openssl x509 -in eecert.pem -text -noout | egrep 'DNS:|Subject|Issuer' > Issuer: CN = Issuer CA > Subject: CN = vpro.lan > Subject Public Key Info: > X509v3 Subject Key Identifier: > X509v3 Subject Alternative Name: > DNS:vpro.lan > > -- > Viktor. > > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Jan 13 19:29:27 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 13 Jan 2016 19:29:27 +0000 Subject: [openssl-users] pkeyutl does not invoke hash? Message-ID: I?m not sure whether this is a bug (as I suspect ? hence sending to openssl-dev), or a poorly-documented ?feature? (so copying to openssl-users). I am trying to use ?openssl pkeyutl? to digitally sign (and verify) a file. When the file size matches the size of the specified digest (32 bytes for SHA256, 48 bytes for SHA384, etc), everything seems fine: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha384 -out t384.ecdsa.sig -in t384.dat engine "pkcs11" set. PKCS#11 token PIN: $ openssl pkeyutl -engine pkcs11 -keyform engine -verify -pubin -inkey "pkcs11:object=SIGN%20pubkey;object-type=public" -sigfile t384.ecdsa.sig -in t384.dat engine "pkcs11" set. Signature Verified Successfully $ However, if I try to feed it a larger file, it complains regardless of whether I specify a hash-function to digest the file: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha1 -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -pkeyopt digest:sha384 -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ openssl pkeyutl -engine pkcs11 -keyform engine -sign -inkey "pkcs11:object=SIGN%20key;object-type=private" -out t2570.ecdsa.sig -in t2570.dat engine "pkcs11" set. PKCS#11 token PIN: Public Key operation error 140735120921424:error:80029001:PKCS11 library:func(41):Cancel:p11_ops.c:61: $ If the input to "pkeyutl ?sign? is supposed to be digest output only ? then what?s the point of having command line arguments specifying the digest to use? And if the input can be an arbitrary file (like for ?dgst?), then why it doesn?t seem to work? I?d appreciate comments, guidance, etc. Thanks! -- Regards, Uri Blumenthal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From steve at openssl.org Wed Jan 13 21:19:14 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 13 Jan 2016 21:19:14 +0000 Subject: [openssl-users] pkeyutl does not invoke hash? In-Reply-To: References: Message-ID: <20160113211914.GA29513@openssl.org> On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote: > > > If the input to "pkeyutl ???sign??? is supposed to be digest output only ??? then > what???s the point of having command line arguments specifying the digest to > use? And if the input can be an arbitrary file (like for ???dgst???), then why > it doesn???t seem to work? > > I???d appreciate comments, guidance, etc. > The dgst utility performs hash+sign the pkeyutl utility is supplied with the data to sign (which is usually but not always a hash). The reason you can specify which hash the digest is for is that without that the utility just sees binary data of a certain length. By specifying the digest it can sanity check the length and in some schemes (e.g. RSA) include the digest algorithm in the data being signed (PKCS#1 DigestInfo structure for some RSA padding modes). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From uri at ll.mit.edu Wed Jan 13 21:32:47 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 13 Jan 2016 21:32:47 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: <20160113211914.GA29513@openssl.org> References: <20160113211914.GA29513@openssl.org> Message-ID: On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" wrote: >On Wed, Jan 13, 2016, Blumenthal, Uri - 0553 - MITLL wrote: >> >> >> If the input to "pkeyutl -sign" is supposed to be digest output only - >>then >> what?s the point of having command line arguments specifying the digest >>to >> use? And if the input can be an arbitrary file (like for ?dgst"), then >>why >> it doesn?t seem to work? >> >> I?d appreciate comments, guidance, etc. >> > >The dgst utility performs hash+sign; the pkeyutl utility is supplied with >the >data to sign (which is usually but not always a hash). I see. Thank you for explaining! >The reason you can specify which hash the digest is for is that without >that >the utility just sees binary data of a certain length. By specifying the >digest it can sanity check the length and in some schemes (e.g. RSA) >include >the digest algorithm in the data being signed (PKCS#1 DigestInfo structure >for some RSA padding modes). Can I suggest and ask that all of the above explanation is added to/included in the pkeyutl man page? I?m sure it would save some grief to other users. Thanks! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Thu Jan 14 04:00:48 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 04:00:48 +0000 Subject: [openssl-users] simplifying rand_egd API Message-ID: There are currently three functions related to the EGD: int RAND_egd(const char *path); int RAND_egd_bytes(const char *path, int bytes); int RAND_query_egd_bytes(const char *path, unsigned char *buf, int bytes); I would like to just have a single function Int RAND_add_egd(const char* path) Does anyone use those three functions? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From gareth at garethwilliams.me.uk Thu Jan 14 08:07:18 2016 From: gareth at garethwilliams.me.uk (Gareth Williams) Date: Thu, 14 Jan 2016 08:07:18 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: Message-ID: <1901202.QIKCmWRJdQ@localhost.localdomain> On Wednesday 13 January 2016 16:22:10 Mauro Romano Trajber wrote: > In which section? > > On section [CA_default] I have 'copy_extensions = copy' Is that the issue? You have copy_extensions in the CA_default section, which is no doubt referenced to by the default_ca = ... stanza earlier in the config file. My understanding is that this is only read when you use the openssl ca command. As you stated you're using the openssl x509 command to sign your request, then this isn't being read. Any reason you're not signing with the openssl ca command? I've just checked and it works as you expected when using this command. Kind regards, Gareth > > Can I do this using only command line options? > > On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich wrote: > > >But when I try to sign it using my own CA using the x509 command this > > > > data is removed > > > > You need to make sure that subjectAltName is marked as copy in your config > > file. > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From trajber at gmail.com Thu Jan 14 12:59:01 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Thu, 14 Jan 2016 10:59:01 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: <1901202.QIKCmWRJdQ@localhost.localdomain> References: <1901202.QIKCmWRJdQ@localhost.localdomain> Message-ID: Could you send me the ca command line? There's any way to run it without creating a .cnf - using only <(print notation? On Thu, Jan 14, 2016 at 6:07 AM, Gareth Williams < gareth at garethwilliams.me.uk> wrote: > On Wednesday 13 January 2016 16:22:10 Mauro Romano Trajber > wrote: > > In which section? > > > > On section [CA_default] I have 'copy_extensions = copy' > > Is that the issue? You have copy_extensions in the CA_default > section, which is no doubt referenced to by the default_ca = ... stanza > earlier in the config file. > > My understanding is that this is only read when you use the openssl > ca command. As you stated you're using the openssl x509 command > to sign your request, then this isn't being read. > > Any reason you're not signing with the openssl ca command? I've just > checked and it works as you expected when using this command. > > Kind regards, > > Gareth > > > > > Can I do this using only command line options? > > > > On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich > wrote: > > > >But when I try to sign it using my own CA using the x509 > command this > > > > > > data is removed > > > > > > You need to make sure that subjectAltName is marked as copy in > your config > > > file. > > > _______________________________________________ > > > 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 gareth at garethwilliams.me.uk Thu Jan 14 13:08:02 2016 From: gareth at garethwilliams.me.uk (Gareth Williams) Date: Thu, 14 Jan 2016 13:08:02 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: <1901202.QIKCmWRJdQ@localhost.localdomain> Message-ID: <1697169.YAZF59DhWY@localhost.localdomain> On Thursday 14 January 2016 10:59:01 Mauro Romano Trajber wrote: > Could you send me the ca command line? There's any way to run it without > creating a .cnf - using only <(print notation? To be honest, I don't know whether you could run it purely from the command line without a config file as there are many configuration options needed to operate openssl as a CA. Saying that, defaults values may work for many of those. Instead, I use a simple bash script (which I don't have to hand I'm afraid - at work) which uses a heredoc to echo a configuration to a temp file which is then used with the openssl ca command, before being deleted afterwards. If you're interested, I can dig it out later. > > On Thu, Jan 14, 2016 at 6:07 AM, Gareth Williams < > > gareth at garethwilliams.me.uk> wrote: > > On Wednesday 13 January 2016 16:22:10 Mauro Romano Trajber > > > > wrote: > > > In which section? > > > > > > On section [CA_default] I have 'copy_extensions = copy' > > > > Is that the issue? You have copy_extensions in the CA_default > > section, which is no doubt referenced to by the default_ca = ... stanza > > earlier in the config file. > > > > My understanding is that this is only read when you use the openssl > > ca command. As you stated you're using the openssl x509 command > > to sign your request, then this isn't being read. > > > > Any reason you're not signing with the openssl ca command? I've just > > checked and it works as you expected when using this command. > > > > Kind regards, > > > > Gareth > > > > > Can I do this using only command line options? > > > > > > On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich > > > > wrote: > > > > >But when I try to sign it using my own CA using the x509 > > > > command this > > > > > > data is removed > > > > > > > > You need to make sure that subjectAltName is marked as copy in > > > > your config > > > > > > file. > > > > _______________________________________________ > > > > 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 trajber at gmail.com Thu Jan 14 13:17:48 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Thu, 14 Jan 2016 11:17:48 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: <1697169.YAZF59DhWY@localhost.localdomain> References: <1901202.QIKCmWRJdQ@localhost.localdomain> <1697169.YAZF59DhWY@localhost.localdomain> Message-ID: There's any advantage to use ca command instead x509 command? Why there's two different ways to sign a certificate request? On Thu, Jan 14, 2016 at 11:08 AM, Gareth Williams < gareth at garethwilliams.me.uk> wrote: > On Thursday 14 January 2016 10:59:01 Mauro Romano Trajber wrote: > > Could you send me the ca command line? There's any way to run it without > > creating a .cnf - using only <(print notation? > > To be honest, I don't know whether you could run it purely from the command > line without a config file as there are many configuration options needed > to > operate openssl as a CA. Saying that, defaults values may work for many of > those. > > Instead, I use a simple bash script (which I don't have to hand I'm afraid > - > at work) which uses a heredoc to echo a configuration to a temp file which > is > then used with the openssl ca command, before being deleted afterwards. > > If you're interested, I can dig it out later. > > > > > On Thu, Jan 14, 2016 at 6:07 AM, Gareth Williams < > > > > gareth at garethwilliams.me.uk> wrote: > > > On Wednesday 13 January 2016 16:22:10 Mauro Romano Trajber > > > > > > wrote: > > > > In which section? > > > > > > > > On section [CA_default] I have 'copy_extensions = copy' > > > > > > Is that the issue? You have copy_extensions in the CA_default > > > section, which is no doubt referenced to by the default_ca = ... stanza > > > earlier in the config file. > > > > > > My understanding is that this is only read when you use the openssl > > > ca command. As you stated you're using the openssl x509 command > > > to sign your request, then this isn't being read. > > > > > > Any reason you're not signing with the openssl ca command? I've just > > > checked and it works as you expected when using this command. > > > > > > Kind regards, > > > > > > Gareth > > > > > > > Can I do this using only command line options? > > > > > > > > On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich > > > > > > wrote: > > > > > >But when I try to sign it using my own CA using the x509 > > > > > > command this > > > > > > > > data is removed > > > > > > > > > > You need to make sure that subjectAltName is marked as copy in > > > > > > your config > > > > > > > > file. > > > > > _______________________________________________ > > > > > 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 gareth at garethwilliams.me.uk Thu Jan 14 13:30:29 2016 From: gareth at garethwilliams.me.uk (Gareth Williams) Date: Thu, 14 Jan 2016 13:30:29 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: References: <1697169.YAZF59DhWY@localhost.localdomain> Message-ID: <2628891.OVIcUavG0B@localhost.localdomain> On Thursday 14 January 2016 11:17:48 Mauro Romano Trajber wrote: > There's any advantage to use ca command instead x509 command? Why there's > two different ways to sign a certificate request? The x509 command is simply there to generate/manipulate X.509 format certificates. The ca command operates as a very basic CA and does things like keep track of issued certificates (for revocation at a later date) and manages certificate serial numbers (increments them by one), manages which extensions are applied to the signed certificate (such as SAN extension). There is more to operating a CA than signing certificates. The openssl ca command attempts to operate as a very basic CA but even the documentation admits that it is only for testing/development/experimenting and not for real world use where the trust derived from certificates has some real value. > > On Thu, Jan 14, 2016 at 11:08 AM, Gareth Williams < > > gareth at garethwilliams.me.uk> wrote: > > On Thursday 14 January 2016 10:59:01 Mauro Romano Trajber wrote: > > > Could you send me the ca command line? There's any way to run it without > > > creating a .cnf - using only <(print notation? > > > > To be honest, I don't know whether you could run it purely from the > > command > > line without a config file as there are many configuration options needed > > to > > operate openssl as a CA. Saying that, defaults values may work for many > > of > > those. > > > > Instead, I use a simple bash script (which I don't have to hand I'm afraid > > - > > at work) which uses a heredoc to echo a configuration to a temp file which > > is > > then used with the openssl ca command, before being deleted afterwards. > > > > If you're interested, I can dig it out later. > > > > > On Thu, Jan 14, 2016 at 6:07 AM, Gareth Williams < > > > > > > gareth at garethwilliams.me.uk> wrote: > > > > On Wednesday 13 January 2016 16:22:10 Mauro Romano Trajber > > > > > > > > wrote: > > > > > In which section? > > > > > > > > > > On section [CA_default] I have 'copy_extensions = copy' > > > > > > > > Is that the issue? You have copy_extensions in the CA_default > > > > section, which is no doubt referenced to by the default_ca = ... > > > > stanza > > > > earlier in the config file. > > > > > > > > My understanding is that this is only read when you use the openssl > > > > ca command. As you stated you're using the openssl x509 command > > > > to sign your request, then this isn't being read. > > > > > > > > Any reason you're not signing with the openssl ca command? I've just > > > > checked and it works as you expected when using this command. > > > > > > > > Kind regards, > > > > > > > > Gareth > > > > > > > > > Can I do this using only command line options? > > > > > > > > > > On Wed, Jan 13, 2016 at 3:42 PM, Salz, Rich > > > > > > > > wrote: > > > > > > >But when I try to sign it using my own CA using the x509 > > > > > > > > command this > > > > > > > > > > data is removed > > > > > > > > > > > > You need to make sure that subjectAltName is marked as copy in > > > > > > > > your config > > > > > > > > > > file. > > > > > > _______________________________________________ > > > > > > 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 rsalz at akamai.com Thu Jan 14 13:31:09 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 13:31:09 +0000 Subject: [openssl-users] [openssl-dev] simplifying rand_egd API In-Reply-To: <20160114102614.lkgKEqOJx%steffen@sdaoden.eu> References: <20160114102614.lkgKEqOJx%steffen@sdaoden.eu> Message-ID: <5fbd19b87cbf4b5792b857d0af375637@usma1ex-dag1mb1.msg.corp.akamai.com> > truly think that saying "please keep this interface" isn't backed by noone, > wether they speak up or not today.) Yes, I know. It is however the best we can do. My issue with the other two API's is that they are really EGD functions, not OpenSSL functions. > P.S.: i like the new website; i had Matt Caswell's message laying around for > many weeks but a reply never made it. Not that it matters, anyway. Always nice to hear a kind word. Thanks! From uri at ll.mit.edu Thu Jan 14 14:41:20 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 14:41:20 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? Message-ID: <20160114144128.17780804.28529.45238@ll.mit.edu> If you already know what Dr. Henson explained in the quoted emails - then the man page is crystal clear. However, if you don't - then it is very easy (it was to me) to make an erroneous assumption (that is not explicitly contradicted) that the digest you specify would be applied to the data you are signing by pkeyutl itself.? This is why I'm asking to include a statement (taking the relevant paragraph from Steve's email seems the best and the simplest way to me) somewhere in the beginning of the Notes section. That added statement/paragraph would makeit unambiguously clear that specified or implied digest and it's parameters are used by pkeyutl ONLY for sanity checks and inclusion into the signature structure, but are NOT applied to the input data by pkeyutl (which instead the user must himself perform prior to invoking pkeyutl). Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hubert Kario Sent: Thursday, January 14, 2016 07:34 To: openssl-dev at openssl.org; openssl-users at openssl.org Reply To: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Wednesday 13 January 2016 21:32:47 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/13/16, 16:19 , "openssl-dev on behalf of Dr. Stephen Henson" > > wrote: > >The reason you can specify which hash the digest is for is that > >without that > >the utility just sees binary data of a certain length. By specifying > >the digest it can sanity check the length and in some schemes (e.g. > >RSA) include > >the digest algorithm in the data being signed (PKCS#1 DigestInfo > >structure for some RSA padding modes). > > Can I suggest and ask that all of the above explanation is added > to/included in the pkeyutl man page? I?m sure it would save some grief > to other users. from pkeyutl(1ssl) in OpenSSL 1.0.1: ----->8------ Unless otherwise mentioned all algorithms support the digest:alg option which specifies the digest in use for sign, verify and verifyrecover operations. The value alg should represent a digest name as used in the EVP_get_digestbyname() function for example sha1. (...) -rsa_padding_mode:mode (...) In PKCS#1 padding if the message digest is not set then the supplied data is signed or verified directly instead of using a DigestInfo structure. If a digest is set then the a DigestInfo structure is used and its the length must correspond to the digest type. (...) EXAMPLES (...) Sign data using a message digest value (this is currently only valid for RSA): openssl pkeyutl -sign -in file -inkey key.pem -out sig -pkeyopt digest:sha256 ----->8------ So it looks documented to me. What is missing in your opinion? -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4350 bytes Desc: not available URL: From levitte at openssl.org Thu Jan 14 14:44:18 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 14 Jan 2016 15:44:18 +0100 (CET) Subject: [openssl-users] OpenSSL version 1.1.0 pre release 2 published Message-ID: <20160114.154418.799119456171028604.levitte@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 2 (alpha) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ OpenSSL 1.1.0 is currently in alpha. OpenSSL 1.1.0 pre release 2 has now been made available. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.1.0-notes.html Note: This OpenSSL pre-release has been provided for testing ONLY. It should NOT be used for security critical purposes. The alpha release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre2.tar.gz Size: 4948288 SHA1 checksum: d7a26cce5d4cc2b491996489d5385e0640bb92ef SHA256 checksum: 09e7470462e263ae853bc7a8fdb07fa439651c5f70aab4573c1a87ee2537a7ac The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre2.tar.gz openssl sha256 openssl-1.1.0-pre2.tar.gz Please download and check this alpha release as soon as possible. Bug reports should go to rt at openssl.org. Please check the release notes and mailing lists to avoid duplicate reports of known issues. Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJWl7A8AAoJENXp5D99+e6MB2kQAJU5fn49JZ7YPx1VByhn873B UptNfbXozRn7ceLoDxMuZlwhbZEV/2BVc37bocagTsuU2gu2RedCE4WS/Kdk9j7q 9IK7pgInLgK2gTMXuPzKFz2qxAxtSi5QJC7BRqq88gR03dl0qXuJ+eCW2Y+zKiDt 2WgAFKrbTW9reDZs2a6WLJEY2lQdsc4eKMkVfCPZTPNpwMUsXipv7egJYC5XchBG ZM1nq8KbmwtVn1EIjH3pUxKbRIPhfza3OCwKQqWsx1XHga7fA4Cz/u+NiswcubGv fC+Aei30Ygi3oR8QG2tdEYMWQaa54hvn06/1bh6tVi8GcXGhFXj+gUTr6dw4TlGx wB/H3bII9slNkGC3w5kcVbSdCmH7ThTDKqeHbqPTVooOJMXMKj5EBXGKkkJ/O8Xg P3cDhqw48LgTW6BtM0ItZE7yHrApPaJr4MWTBQj4uqUIQz0SSUnxCE7xpSJS5UPE A/oi0p+Mzr3bJG+39lzDEqhFWxR/WP5cU9mWo68b002qwSzcOPm8RpMfqGfNJDyg P5OVJnykeI0JU8rR85fTdJFvcGgESOfv1HnSa9sGIMLhEA6Y4GwDhM804AV9xQ3+ trLd1Y5WYTcgc8yx181psw541N1Hsxl15Jm2sPcMMYdiK5YVbi1y+K3NGfnmKnYT /79DbTCo0r02h0k1X8JI =It+h -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Thu Jan 14 16:28:46 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 16:28:46 +0000 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: <1697169.YAZF59DhWY@localhost.localdomain> References: <1901202.QIKCmWRJdQ@localhost.localdomain> <1697169.YAZF59DhWY@localhost.localdomain> Message-ID: <20160114162846.GC646@mournblade.imrryr.org> On Thu, Jan 14, 2016 at 01:08:02PM +0000, Gareth Williams wrote: > On Thursday 14 January 2016 10:59:01 Mauro Romano Trajber wrote: > > Could you send me the ca command line? There's any way to run it without > > creating a .cnf - using only <(print notation? > > To be honest, I don't know whether you could run it purely from the command > line without a config file as there are many configuration options needed to > operate openssl as a CA. Saying that, defaults values may work for many of > those. That's what the script I posted does, it bypasses all the bagage of .cnf files and a stateful CA, by constructing miniature ".cnf" files on the fly via <(printf ....). So yes, this can be done. -- Viktor. From trajber at gmail.com Thu Jan 14 16:39:04 2016 From: trajber at gmail.com (Mauro Romano Trajber) Date: Thu, 14 Jan 2016 14:39:04 -0200 Subject: [openssl-users] Signing a csr with subjectAltName using x509 command In-Reply-To: <20160114162846.GC646@mournblade.imrryr.org> References: <1901202.QIKCmWRJdQ@localhost.localdomain> <1697169.YAZF59DhWY@localhost.localdomain> <20160114162846.GC646@mournblade.imrryr.org> Message-ID: Correct me if I'm wrong, but your script uses x509 command. I was asking if it is possible to do this using the "ca" command. On Thu, Jan 14, 2016 at 2:28 PM, Viktor Dukhovni wrote: > On Thu, Jan 14, 2016 at 01:08:02PM +0000, Gareth Williams wrote: > > > On Thursday 14 January 2016 10:59:01 Mauro Romano Trajber wrote: > > > Could you send me the ca command line? There's any way to run it > without > > > creating a .cnf - using only <(print notation? > > > > To be honest, I don't know whether you could run it purely from the > command > > line without a config file as there are many configuration options > needed to > > operate openssl as a CA. Saying that, defaults values may work for many > of > > those. > > That's what the script I posted does, it bypasses all the bagage > of .cnf files and a stateful CA, by constructing miniature ".cnf" > files on the fly via <(printf ....). So yes, this can be done. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Jan 14 19:11:54 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 19:11:54 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: On 1/14/16, 13:56 , "Hubert Kario" wrote: >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: >> If you already know what Dr. Henson explained in the quoted emails - >> then the man page is crystal clear. However, if you don't - then it >> is very easy (it was to me) to make an erroneous assumption (that is >> not explicitly contradicted) that the digest you specify would be >> applied to the data you are signing by pkeyutl itself. >> >> This is why I'm asking to include a statement (taking the relevant >> paragraph from Steve's email seems the best and the simplest way to >> me) somewhere in the beginning of the Notes section. That added >> statement/paragraph would make it unambiguously clear that specified >> or implied digest and it's parameters are used by pkeyutl ONLY for >> sanity checks and inclusion into the signature structure, but are NOT >> applied to the input data by pkeyutl (which instead the user must >> himself perform prior to invoking pkeyutl). >How about such change?: >--------->8---------- > >While the man page of pkeyutl mentions usage of hashes of data, >it is not explicit in that the data should be passed in >is the result of hashing and that the function will no perform >any hashing on the input data. I must admit that the above confuses me, even though now I *know* what it should mean. I would prefer something much simpler, like: Pkeyutl will not perform any hashing of the input data. The input data to be signed may or may not be a result of Hashing. Its size must be either equal to the digest output size if digest is specified or implied, or not greater than the size of the public key field or modulus otherwise. >This patch adds a note that makes this explicit. >--- > doc/apps/pkeyutl.pod | 4 ++++ > 1 file changed, 4 insertions(+) > >diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod >index 27be9a9..b6f9e40 100644 >--- a/doc/apps/pkeyutl.pod >+++ b/doc/apps/pkeyutl.pod >@@ -135,6 +135,10 @@ and its implementation. The OpenSSL operations and >options are indicated below. > > Unless otherwise mentioned all algorithms support the B >option > which specifies the digest in use for sign, verify and verifyrecover >operations. >+This value is used only for sanity-checking the lengths of passed in >data and +This value and that of the corresponding parameters if specified, is used +only for sanity-checking the lengths of passed in data and >+setting the values of signature structures (e.g. B) of the >+generated signature. In other words, if the value of digest is B >the >+input should be 20 bytes long binary encoding of SHA-1 hash function. > The value B should represent a digest name as used in the > EVP_get_digestbyname() function for example B. +If the digest is neither specified nor implied, the length of the +passed in data must be no greater than the public key modulus or +field size. > >-- >2.4.3 What do you think of the above? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From rsalz at akamai.com Thu Jan 14 19:52:17 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 14 Jan 2016 19:52:17 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: Okay, how about this. First, remove the NOTES subhead. Add this to the end of the first paragraph: This program does not hash the input data and requires the input data to be of the proper size, and must not be greater than the size of the public key field or modulus. See dgst(1) for a unified Interace. From openssl-users at dukhovni.org Thu Jan 14 19:54:46 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 14:54:46 -0500 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: > On Jan 14, 2016, at 2:52 PM, Salz, Rich wrote: > > Okay, how about this. First, remove the NOTES subhead. Add this to the end of the first paragraph: > > This program does not hash the input data and requires the input data > to be of the proper size, and must not be greater than the size of > the public key field or modulus. See dgst(1) for a unified > Interace. Sounds good, s/Interace/interface/ -- Viktor. From uri at ll.mit.edu Thu Jan 14 20:00:09 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 14 Jan 2016 20:00:09 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: On 1/14/16, 14:54 , "openssl-users on behalf of Viktor Dukhovni" wrote: >>On Jan 14, 2016, at 2:52 PM, Salz, Rich wrote: >> >> Okay, how about this. First, remove the NOTES subhead. Add this to >>the end of the first paragraph: >> >> This program does not hash the input data and requires the input data >> to be of the proper size, and must not be greater than the size of >> the public key field or modulus. See dgst(1) for a unified >> Interace. > >Sounds good, s/Interace/interface/ It?s shorter than I?d prefer (so maybe you?d agree to add some words about WHY the digest is specified even though it is not invoked, to make it less puzzling to the uninitiated :), but it covers the essentials. :-) -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4308 bytes Desc: not available URL: From jb-openssl at wisemo.com Thu Jan 14 20:37:24 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 14 Jan 2016 21:37:24 +0100 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> Message-ID: <56980704.2020809@wisemo.com> On 14/01/2016 20:52, Salz, Rich wrote: > Okay, how about this. First, remove the NOTES subhead. Add this to the end of the first paragraph: > > This program does not hash the input data and requires the input data > to be of the proper size, and must not be greater than the size of > the public key field or modulus. See dgst(1) for a unified > Interace. A unified interface to what. I don't think the dgst command does any signing. Also, I agree there should be words like "the digest parameter specifies that the signature should be formatted as if the input was a digest of this type, e.g. by putting the OID of the digest in the signature (for RSA PKCS#1 v1.5) or by using that digest algorithm to do further formatting (for RSA PKCS#1 v2.1). Not specifying a digest allows using this command to perform the raw private key operation on arbitrary data." Adapt as applicable (e.g. if this only applies to some modes of the pkeyutl command etc.). 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Jan 14 21:03:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 14 Jan 2016 16:03:20 -0500 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: <56980704.2020809@wisemo.com> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> <56980704.2020809@wisemo.com> Message-ID: <8C6B25F7-B575-40DA-A961-382274DFCA9C@dukhovni.org> > On Jan 14, 2016, at 3:37 PM, Jakob Bohm wrote: > > A unified interface to what. I don't think the dgst command > does any signing. NAME dgst, sha, sha1, mdc2, ripemd160, sha224, sha256, sha384, sha512, md4, md5 - message digests SYNOPSIS openssl dgst [-sha|-sha1|-mdc2|-ripemd160|-sha224|-sha256|-sha384|-sha512|-md4|-md5] [-c] [-d] [-hex] [-binary] [-r] [-out filename] [-sign filename] [-keyform arg] [-passin arg] [-verify filename] [-prverify filename] [-signature filename] [-hmac key] [-fips-fingerprint] [file...] openssl [digest] [...] DESCRIPTION The digest functions output the message digest of a supplied file or files in hexadecimal. The digest functions also generate and verify digital signatures using message digests. -- Viktor. From wangqun at alumni.nus.edu.sg Fri Jan 15 02:35:48 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Thu, 14 Jan 2016 19:35:48 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? Message-ID: <1452825348480-62289.post@n7.nabble.com> Hi Steve, I encountered a Windows OpenSSL build issue when upgrading the OpenSSL used in our product to version 1.0.1q. The error message is as follows. NMAKE : fatal error U1073: don't know how to make 'tmp32\applink.obj' I searched related articles in this forum and found the following post. http://openssl.6102.n7.nabble.com/Windows-x86-64-build-broken-RE-openssl-users-OpenSSL-version-1-0-1q-released-corrected-download-td61450.html However I was not allowed to ask my question there, so I post my question here. Hopefully you could see my question here. While I have already upgrraded OpenSSL on all our support platforms, this issue blocks me from upgrading on Windows. Under this circumstance, I could not wait for next OpenSSL release in which you have fixed the issue. I would need to put your fix into OpenEEL 1.0.1q to complete my upgrading. Would you please let me know how to fix the issue? Thanks a lot in advance, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From wangqun at alumni.nus.edu.sg Fri Jan 15 08:31:51 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Fri, 15 Jan 2016 01:31:51 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <1452825348480-62289.post@n7.nabble.com> References: <1452825348480-62289.post@n7.nabble.com> Message-ID: <1452846711633-62291.post@n7.nabble.com> Hi, Anyone knows how to check what is updated in commit 544058202be49a6 ? Thanks, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289p62291.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From uri at ll.mit.edu Fri Jan 15 14:03:33 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 15 Jan 2016 14:03:33 +0000 Subject: [openssl-users] [openssl-dev] pkeyutl does not invoke hash? In-Reply-To: <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> References: <20160114144128.17780804.28529.45238@ll.mit.edu> <16513294.pb9p7bj2dx@pintsize.usersys.redhat.com> <1777847.88KJYcgRvU@pintsize.usersys.redhat.com> Message-ID: <20160115140342.17789001.711.45471@ll.mit.edu> Yes, and I can live with this update.? I still think it would be nice to inform the user of ?what to expect in the (unlikely but possible) case when his data is not an output of some cryptographic hash function.? Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network. ? Original Message ? From: Hubert Kario Sent: Friday, January 15, 2016 07:00 To: Blumenthal, Uri - 0553 - MITLL Cc: openssl-dev at openssl.org; openssl-users at openssl.org Subject: Re: [openssl-dev] [openssl-users] pkeyutl does not invoke hash? On Thursday 14 January 2016 19:11:54 Blumenthal, Uri - 0553 - MITLL wrote: > On 1/14/16, 13:56 , "Hubert Kario" wrote: > >On Thursday 14 January 2016 14:41:20 Blumenthal, Uri - 0553 - MITLL wrote: > >> If you already know what Dr. Henson explained in the quoted emails > >> - > >> then the man page is crystal clear. However, if you don't - then it > >> is very easy (it was to me) to make an erroneous assumption (that > >> is > >> not explicitly contradicted) that the digest you specify would be > >> applied to the data you are signing by pkeyutl itself. > >> > >> This is why I'm asking to include a statement (taking the relevant > >> paragraph from Steve's email seems the best and the simplest way to > >> me) somewhere in the beginning of the Notes section. That added > >> statement/paragraph would make it unambiguously clear that > >> specified > >> or implied digest and it's parameters are used by pkeyutl ONLY for > >> sanity checks and inclusion into the signature structure, but are > >> NOT > >> applied to the input data by pkeyutl (which instead the user must > >> himself perform prior to invoking pkeyutl). > > > >How about such change?: > >--------->8---------- > > > >While the man page of pkeyutl mentions usage of hashes of data, > >it is not explicit in that the data should be passed in > >is the result of hashing and that the function will no perform > >any hashing on the input data. > > I must admit that the above confuses me, even though now I *know* what > it should mean. I would prefer something much simpler, like: > > Pkeyutl will not perform any hashing of the input data. > The input data to be signed may or may not be a result of > Hashing. Its size must be either equal to the digest > output size if digest is specified or implied, or not > greater than the size of the public key field or modulus > otherwise. The above was just a a comment to the patch, it needs to be understandable only by the developers :), but yes, the wording was quite clumsy. What was below it is what matters as that's what ends up in the man page. Second try: ------------->8------------- >From a4f4971fc3bcc03c5aaead6844beded7f92ab01c Mon Sep 17 00:00:00 2001 From: Hubert Kario Date: Fri, 15 Jan 2016 12:58:22 +0100 Subject: [PATCH] clarify pkeyutl man page Because pkeyutl does not perform hashing of any inputs but the man page mentions data hashes, it's not obvious whether the inputs to this function should be results of hashing or the data itself. This patch adds a note that makes this behaviour explicit. --- doc/apps/pkeyutl.pod | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/doc/apps/pkeyutl.pod b/doc/apps/pkeyutl.pod index 27be9a9..e885474 100644 --- a/doc/apps/pkeyutl.pod +++ b/doc/apps/pkeyutl.pod @@ -135,6 +135,13 @@ and its implementation. The OpenSSL operations and options are indicated below. Unless otherwise mentioned all algorithms support the B option which specifies the digest in use for sign, verify and verifyrecover operations. +This value is used only for sanity-checking the lengths of data passed in to +the B and for setting the values of the structures making up the +signature (e.g. B). In other words, if the value of digest is +B the input should be 20 bytes long binary encoding of SHA-1 hash +function output. In case the digest algorithm is not specified and is not +implied by the key type and/or padding mode, the length of data must not be +bigger than the key's modulus or field size (depending on key type). The value B should represent a digest name as used in the EVP_get_digestbyname() function for example B. -- 2.4.3 ------------->8------------- -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 455 bytes Desc: not available URL: From noloader at gmail.com Fri Jan 15 15:04:06 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 15 Jan 2016 10:04:06 -0500 Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <1452846711633-62291.post@n7.nabble.com> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> Message-ID: On Fri, Jan 15, 2016 at 3:31 AM, Aaron wrote: > Hi, > > Anyone knows how to check what is updated in commit 544058202be49a6 ? > According to http://git.openssl.org/?p=openssl.git&a=search&st=commit&s=544058202be49a6 , there is no commit by that number. Jeff From p_levesque555 at hotmail.com Fri Jan 15 15:05:09 2016 From: p_levesque555 at hotmail.com (Philippe Levesque) Date: Fri, 15 Jan 2016 15:05:09 +0000 Subject: [openssl-users] BN_exp Message-ID: Hi I wanted some input on a problem. I need to use bn_exp for some big calculation but I hit a limit where it take age to get a result (after two day I stopped the process). I tried for fun to run a bn_mod_exp and it took 2 seconds. The manpage state that; BN_exp() raises a to the p-th power and places the result in r ("r=a^p"). This function is faster than repeated applications of BN_mul(). BN_mod_exp() computes a to the p-th power modulo m ("r=a^p % m"). This function uses less time and space than BN_exp(). Is there a tip there to get the exp result from bn_mod_exp ? or to optimize bn_exp ? Thanks Philippe nb. Sorry if the question might have been answered in the past, I didn't find any way to search the mailing-list's archive. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Fri Jan 15 15:15:50 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 15 Jan 2016 10:15:50 -0500 Subject: [openssl-users] BN_exp In-Reply-To: References: Message-ID: On Fri, Jan 15, 2016 at 10:05 AM, Philippe Levesque wrote: > Hi > > I wanted some input on a problem. I need to use bn_exp for some big > calculation but I hit a limit where it take age to get a result (after two > day I stopped the process). Pure exponentiations without a modular reduction can quickly spill into the page file. It brings a machine to its knees because of memory growth, > I tried for fun to run a bn_mod_exp and it took > 2 seconds. Yes, usually a much better choice. > Is there a tip there to get the exp result from bn_mod_exp ? or to optimize > bn_exp ? bn_mod_exp computes r = a^p mod n. You already have the exponent (p) and you get the result (r). What are you trying to accomplish? Can you sketch the pseudo-code? Jeff From doctor at doctor.nl2k.ab.ca Fri Jan 15 17:11:09 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 15 Jan 2016 10:11:09 -0700 Subject: [openssl-users] OPenssl and dependencies such as openssh In-Reply-To: <20160104202956.GA24447@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160104202956.GA24447@doctor.nl2k.ab.ca> Message-ID: <20160115171109.GA22842@doctor.nl2k.ab.ca> On Mon, Jan 04, 2016 at 01:29:56PM -0700, The Doctor wrote: > On Mon, Jan 04, 2016 at 07:22:04PM +0000, Viktor Dukhovni wrote: > > On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote: > > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(), > > > SSLeay_version(SSLEAY_VERSION))) <0) > > > > > > Could there be anything that is causing openssh not to see the new openssl 1.1 > > > > The above. The SSLeay names are gone. The new way is: > > > > if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(), > > OpenSSL_version(OPENSSL_VERSION))) <0) > > > > I think it is likely prudent at this time to restore source- > > backwards-compatible behaviour, by adding to : > > > > #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L > > # include > > # define SSLeay OpenSSL_version_num > > # define SSLeay_version OpenSSL_version > > # define SSLEAY_VERSION_NUMBER OPENSSL_VERSION_NUMBER > > # define SSLEAY_VERSION OPENSSL_VERSION > > # define SSLEAY_CFLAGS OPENSSL_CFLAGS > > # define SSLEAY_BUILT_ON OPENSSL_BUILT_ON > > # define SSLEAY_PLATFORM OPENSSL_PLATFORM > > # define SSLEAY_DIR OPENSSL_DIR > > #endif /* OPENSSL_API_COMPAT */ > > > > Users who want to make sure they are avoiding interfaces that are > > deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or > > higher as appropriate. > > That is one way. > > Can we get developers to come on baord so that > we can launch a new era without incident? All right, can the above be committed and any other source-backwards-compatible behaviour ? This will help API developers a lot. BTW, I got openssl-SNAP-20160115 to behave nicely. -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From rsalz at akamai.com Fri Jan 15 17:21:56 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 15 Jan 2016 17:21:56 +0000 Subject: [openssl-users] [openssl-dev] OPenssl and dependencies such as openssh In-Reply-To: <20160115171109.GA22842@doctor.nl2k.ab.ca> References: <20160104160831.GA4457@doctor.nl2k.ab.ca> <20160104192204.GL18704@mournblade.imrryr.org> <20160104202956.GA24447@doctor.nl2k.ab.ca> <20160115171109.GA22842@doctor.nl2k.ab.ca> Message-ID: <0cb2942f10ef4a8c93abf96b5786b4d1@usma1ex-dag1mb1.msg.corp.akamai.com> > All right, can the above be committed and any other source-backwards- > compatible behaviour ? > > This will help API developers a lot. It was done and is part of the yesterday's alpha release. From wangqun at alumni.nus.edu.sg Sat Jan 16 01:06:21 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Fri, 15 Jan 2016 18:06:21 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> Message-ID: <1452906381295-62326.post@n7.nabble.com> Hi Jeff, Thank you for your response. I got the commit number from here: http://openssl.6102.n7.nabble.com/Windows-x86-64-build-broken-RE-openssl-users-OpenSSL-version-1-0-1q-released-corrected-download-td61450.html The commit number was provided by Steve (Dr Stephen N. Henson. OpenSSL project core developer). Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289p62326.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From openssl-users at dukhovni.org Sat Jan 16 02:00:03 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 15 Jan 2016 21:00:03 -0500 Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <1452906381295-62326.post@n7.nabble.com> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> <1452906381295-62326.post@n7.nabble.com> Message-ID: <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> > On Jan 15, 2016, at 8:06 PM, Aaron wrote: > > I got the commit number from here: > http://openssl.6102.n7.nabble.com/Windows-x86-64-build-broken-RE-openssl-users-OpenSSL-version-1-0-1q-released-corrected-download-td61450.html > > The commit number was provided by Steve (Dr Stephen N. Henson. OpenSSL > project core developer). The commit id must have changed by the time it got into the main repo. You were likely looking for: commit 9501418ea2287658d1a11ce888ff97fa49e9164d Author: Dr Stephen Henson Date: Tue Dec 8 19:10:48 2015 +0000 Don't use applink for static builds. -- Viktor. From tkachyov at mailfrom.ru Sat Jan 16 04:11:33 2016 From: tkachyov at mailfrom.ru (vgt) Date: Sat, 16 Jan 2016 07:11:33 +0300 Subject: [openssl-users] Encryption/decryption using parameters obtained via handshake (SSL_accept/SSL_connect) Message-ID: <1452917493.2811.4.camel@vgt-K53SV> Hello, all :) I need to link OpenSSL to a library which makes reads/writes itself and permits only to encrypt data before sending (and decrypt after receiving). Is it possible to initialize connection as follows SSL_load_error_strings(); SSL_library_init(); context = SSL_CTX_new(SSLv23_method()); if(!SSL_CTX_use_certificate_file(context, certFile, SSL_FILETYPE_PEM)) ... if(SSL_CTX_use_PrivateKey_file(context, keyFile, SSL_FILETYPE_PEM)<0 ) ... ssl = SSL_new(context); SSL_set_fd(ssl,fd); /// fd is an open socket descriptor SSL_accept(ssl); // or SSL_connect(ssl); in client and then use encryption/decryption using parameters obtained by the initialization stage above? Thank you in advance, Vladimir P.S. SSL_read/SSL_write then works well, but as I mentioned, the library does reads/writes itself... From wangqun at alumni.nus.edu.sg Sat Jan 16 08:26:56 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Sat, 16 Jan 2016 01:26:56 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> <1452906381295-62326.post@n7.nabble.com> <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> Message-ID: <1452932816272-62336.post@n7.nabble.com> Hello Viktor, Thank you very much for your response. I believe you are right. As I am new to OpenSSL, I don't know how to check what is updated in commit 9501418ea2287658d1a11ce888ff97fa49e9164d. I could not even find the commit in the list: http://git.openssl.org/?p=openssl.git;a=shortlog I wonder if you could show me what is updated in the commit or let me know how to check it? Your help is appreciated. Thanks again, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289p62336.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From diganta.bhattacharjee at sasken.com Sat Jan 16 10:57:46 2016 From: diganta.bhattacharjee at sasken.com (Diganta Bhattacharjee) Date: Sat, 16 Jan 2016 10:57:46 +0000 Subject: [openssl-users] Updating TLS1.1 to TLS1.2 Message-ID: I am looking at (query about) updating a TLS 1.1 solution based on OpenSSL 1.0.1b to TLS 1.2. I understand the latest OpenSSL 1.0.2 supports TLS 1.2. At first look I believe if we replace the OpenSSL 1.0.1 with OpenSSL 1.0.2 it should automatically update the TLS to 1.2 versions. That is there should not be any need to do any code changes in application as there is no major changes in API between OpenSSL version 1.0.1 and 1.0.2. Can anyone please comment on my above understanding? I am new at OpenSSL and do not have hands-on experience on using OpenSSL for TLS hence looking for comments to understand what the risks in such update. Thanks, Diganta ________________________________ SASKEN BUSINESS DISCLAIMER: This message may contain confidential, proprietary or legally privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited ("Sasken") unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email. Read Disclaimer at http://www.sasken.com/extras/mail_disclaimer.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Sat Jan 16 10:58:15 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Sat, 16 Jan 2016 03:58:15 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <1452932816272-62336.post@n7.nabble.com> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> <1452906381295-62326.post@n7.nabble.com> <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> <1452932816272-62336.post@n7.nabble.com> Message-ID: <1452941895229-62344.post@n7.nabble.com> Hello, Anyone knows how to check what is updated in commit 9501418ea2287658d1a11ce888ff97fa49e9164d ? Any help is appreciated. Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289p62344.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From kurt at roeckx.be Sat Jan 16 12:19:00 2016 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 16 Jan 2016 13:19:00 +0100 Subject: [openssl-users] Updating TLS1.1 to TLS1.2 In-Reply-To: References: Message-ID: <20160116121900.GA25136@roeckx.be> On Sat, Jan 16, 2016 at 10:57:46AM +0000, Diganta Bhattacharjee wrote: > > I am looking at (query about) updating a TLS 1.1 solution based on OpenSSL 1.0.1b to TLS 1.2. I understand the latest OpenSSL 1.0.2 supports TLS 1.2. At first look I believe if we replace the OpenSSL 1.0.1 with OpenSSL 1.0.2 it should automatically update the TLS to 1.2 versions. That is there should not be any need to do any code changes in application as there is no major changes in API between OpenSSL version 1.0.1 and 1.0.2. > Can anyone please comment on my above understanding? I am new at OpenSSL and do not have hands-on experience on using OpenSSL for TLS hence looking for comments to understand what the risks in such update. The 1.0.1 versions already supported TLS 1.2. If you're getting TLS 1.1 it might mean that you compiled it with the option not to support TLS 1.2 as client. At the time there were servers that had a problem with clients that supported TLS 1.2, but most of that should have been fixed. Upgrading to the 1.0.2 version should also just work because the API is compatible. I would also recommend that you keep more up to date with OpenSSL versions, the 1.0.1b version has various securities issues in it that were fixed in later versions. Kurt From jeremy.farrell at oracle.com Sat Jan 16 17:30:40 2016 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Sat, 16 Jan 2016 17:30:40 +0000 Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <1452932816272-62336.post@n7.nabble.com> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> <1452906381295-62326.post@n7.nabble.com> <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> <1452932816272-62336.post@n7.nabble.com> Message-ID: <569A7E40.2000304@oracle.com> Go to https://git.openssl.org/?p=openssl.git and scroll down to the 'heads' section. Click 'shortlog' for OpenSSL_1_0_1-stable, scroll down to around the date quoted in Viktor's message, and you'll find a commit with the description he quoted. Clicking on 'commitdiff' takes you to https://git.openssl.org/?p=openssl.git;a=commitdiff;h=d724616f682cb374b613d7fbd57e4c2bf749469c Regards, jjf On 16/01/2016 08:26, Aaron wrote: > Hello Viktor, > > Thank you very much for your response. I believe you are right. > > As I am new to OpenSSL, I don't know how to check what is updated in commit > 9501418ea2287658d1a11ce888ff97fa49e9164d. > > I could not even find the commit in the list: > http://git.openssl.org/?p=openssl.git;a=shortlog > > I wonder if you could show me what is updated in the commit or let me know > how to check it? Your help is appreciated. > > Thanks again, > Aaron -- J. J. Farrell -------------- next part -------------- An HTML attachment was scrubbed... URL: From wangqun at alumni.nus.edu.sg Sun Jan 17 06:56:35 2016 From: wangqun at alumni.nus.edu.sg (Aaron) Date: Sat, 16 Jan 2016 23:56:35 -0700 (MST) Subject: [openssl-users] How to fix OpenSSL 1.0.1q Windows x86_64 build failure? In-Reply-To: <569A7E40.2000304@oracle.com> References: <1452825348480-62289.post@n7.nabble.com> <1452846711633-62291.post@n7.nabble.com> <1452906381295-62326.post@n7.nabble.com> <3D811AE0-DFE9-4631-AFC3-881C30070353@dukhovni.org> <1452932816272-62336.post@n7.nabble.com> <569A7E40.2000304@oracle.com> Message-ID: <1453013795326-62402.post@n7.nabble.com> Thank you very much, jjf. Regards, Aaron -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-fix-OpenSSL-1-0-1q-Windows-x86-64-build-failure-tp62289p62402.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From rfcustodio at gmail.com Mon Jan 18 12:20:21 2016 From: rfcustodio at gmail.com (custodio) Date: Mon, 18 Jan 2016 05:20:21 -0700 (MST) Subject: [openssl-users] possible Bug in OpenSSL - rfc 3161 - TSA service In-Reply-To: <51483F23.1040006@mizera.cz> References: <2d37b54ab51dcc898654c1fe60a342f4@mail2.volny.cz> <1363609662439-44380.post@n7.nabble.com> <51483F23.1040006@mizera.cz> Message-ID: <1453119621021-62434.post@n7.nabble.com> Hi everybody, I do not know if this is the best place to discuss it, but I would like to have your opinions on the best place to include Time Attribute Certificate (TAC) into TST. By defult, the Thales timestamp system puts the hash of TAC in the field signing certificate as discussed here. Here are some questions: a) the insertion of the TAC in signing certificate is against the RFC 3161? b) If so, what would be the best place in TST to include the TAC or a reference to it? c) What do you think of including the TAC or a reference to it in a non critical extension of TSTInfo? Best regards custodio -- View this message in context: http://openssl.6102.n7.nabble.com/possible-Bug-in-OpenSSL-rfc-3161-TSA-service-tp43128p62434.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From nounou.dadoun at avigilon.com Mon Jan 18 20:42:31 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Mon, 18 Jan 2016 20:42:31 +0000 Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm Message-ID: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> Hi folks, I'm trying to do some simple conversions (I need to push some certificate data across a soap interface). I'm trying to do an ASN1 time conversion to tm (and eventually time_t but tm would be fine). Earlier mailing list entries said that this was not available but I've now found: https://github.com/openssl/openssl/blob/master/crypto/asn1/a_time.c? which contains asn1_time_to_tm which also refers to https://github.com/openssl/openssl/blob/master/crypto/asn1/a_gentm.c? for asn1_generalizedtime_to_tm I could just copy and paste them but no sense in duplicating the wheel if there's a header file which exposes them, is there one?? Which releases of openssl have them? The other conversions I need to do are key usage (I have a first cut at this) and extended key usage as a usage string and critical (boolean) flag; any similar openssl apis to retrieve those? Or pointers to sample code? Thanks in advance for any pointers . N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. From nounou.dadoun at avigilon.com Mon Jan 18 21:01:23 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Mon, 18 Jan 2016 21:01:23 +0000 Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E04620@mbx027-w1-ca-4.exch027.domain.local> Upon further investigation I've discovered that they're declared in asn1_locl.h but marked as: /* Internal ASN1 structures and functions: not for application use */ They seem to be generally useful and making them available would keep people's hands out of opaque data structures, any reason why they're not exposed? Nou Dadoun Senior Firmware Developer, Security Specialist -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Nounou Dadoun Sent: Monday, January 18, 2016 12:43 PM To: openssl-users at openssl.org Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm Hi folks, I'm trying to do some simple conversions (I need to push some certificate data across a soap interface). I'm trying to do an ASN1 time conversion to tm (and eventually time_t but tm would be fine). Earlier mailing list entries said that this was not available but I've now found: https://github.com/openssl/openssl/blob/master/crypto/asn1/a_time.c? which contains asn1_time_to_tm which also refers to https://github.com/openssl/openssl/blob/master/crypto/asn1/a_gentm.c? for asn1_generalizedtime_to_tm I could just copy and paste them but no sense in duplicating the wheel if there's a header file which exposes them, is there one?? Which releases of openssl have them? The other conversions I need to do are key usage (I have a first cut at this) and extended key usage as a usage string and critical (boolean) flag; any similar openssl apis to retrieve those? Or pointers to sample code? Thanks in advance for any pointers . N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn This email, including any files attached hereto (the "email"), contains privileged and confidential information and is only for the intended addressee(s). If this email has been sent to you in error, such sending does not constitute waiver of privilege and we request that you kindly delete the email and notify the sender. Any unauthorized use or disclosure of this email is prohibited. Avigilon and certain other trade names used herein are the registered and/or unregistered trademarks of Avigilon Corporation and/or its affiliates in Canada and other jurisdictions worldwide. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From steve at openssl.org Mon Jan 18 22:51:04 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 18 Jan 2016 22:51:04 +0000 Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20160118225104.GA17296@openssl.org> On Mon, Jan 18, 2016, Nounou Dadoun wrote: > Hi folks, > > I'm trying to do some simple conversions (I need to push some certificate data across a soap interface). > > I'm trying to do an ASN1 time conversion to tm (and eventually time_t but tm would be fine). > The equivalent of time_t is easier. If you use the function ASN1_TIME_diff you can find the difference in days and seconds between two ASN1_TIME structures so if you set one to the epoch you can then convert the result to time_t. You have to be careful the result doesn't overflow the local time_t. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From marcosbontempo at hotmail.com Tue Jan 19 00:43:12 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Mon, 18 Jan 2016 22:43:12 -0200 Subject: [openssl-users] Digest MD5 forbidden in FIPS mode Message-ID: Hello, I wrote a C code which enter in FIPS mode with fips_mod_set(1). But, when I call MD5 functions after setting FIPS mode, I get this error: md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API call to digest MD5 forbidden in FIPS mode! Aborted. Does anybody know what is wrong? How can I correct it? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Tue Jan 19 01:04:01 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 18 Jan 2016 20:04:01 -0500 Subject: [openssl-users] Digest MD5 forbidden in FIPS mode In-Reply-To: References: Message-ID: > I wrote a C code which enter in FIPS mode with fips_mod_set(1). > > But, when I call MD5 functions after setting FIPS mode, I get this error: > > md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API call > to digest MD5 forbidden in FIPS mode! Aborted. > > Does anybody know what is wrong? How can I correct it? Nothing is going wrong; everything is working as expected. MD5 is essentially forbidden in US Federal except under a few exemptions. The exemptions include the PRF in TLS. But I've never seen a library expose MD5 even if its using it under the hood. Also see FIPS 140-2 and http://www.nsrl.nist.gov/collision.html. Jeff From ethan.rahn at gmail.com Tue Jan 19 01:04:18 2016 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Mon, 18 Jan 2016 17:04:18 -0800 Subject: [openssl-users] Digest MD5 forbidden in FIPS mode In-Reply-To: References: Message-ID: MD5 is not considered a safe function to use hence it is forbidden in FIPS mode. Can you use a different hash function ( such as SHA-something ) for your use case? On Mon, Jan 18, 2016 at 4:43 PM, Marcos Bontempo wrote: > Hello, > > I wrote a C code which enter in FIPS mode with fips_mod_set(1). > > But, when I call MD5 functions after setting FIPS mode, I get this error: > > md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API > call to digest MD5 forbidden in FIPS mode! Aborted. > > Does anybody know what is wrong? How can I correct it? > > Any tip will be very helpful, > Thanks. > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nounou.dadoun at avigilon.com Tue Jan 19 01:28:30 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Tue, 19 Jan 2016 01:28:30 +0000 Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm In-Reply-To: <20160118225104.GA17296@openssl.org> References: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> <20160118225104.GA17296@openssl.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E04686@mbx027-w1-ca-4.exch027.domain.local> That actually worked reasonably smoothly, the only thing that I have to fix now is that it's obviously taking the time zone into account - is there a way of telling it to do everything in UTC? And I still don't see any programmatic way of accessing whether a key usage is "critical" or not. Thanks .... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 ?|? avigilon.com Follow?Twitter ?|? Follow?LinkedIn -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Dr. Stephen Henson Sent: Monday, January 18, 2016 2:51 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm On Mon, Jan 18, 2016, Nounou Dadoun wrote: > Hi folks, > > I'm trying to do some simple conversions (I need to push some certificate data across a soap interface). > > I'm trying to do an ASN1 time conversion to tm (and eventually time_t but tm would be fine). > The equivalent of time_t is easier. If you use the function ASN1_TIME_diff you can find the difference in days and seconds between two ASN1_TIME structures so if you set one to the epoch you can then convert the result to time_t. You have to be careful the result doesn't overflow the local time_t. 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 security.veteran at gmail.com Tue Jan 19 02:21:18 2016 From: security.veteran at gmail.com (security veteran) Date: Mon, 18 Jan 2016 18:21:18 -0800 Subject: [openssl-users] Apache (2.x) server and OpenSSL FIPS modules Message-ID: Hi, We will be using OpenSSL FIPS modules on our Linux server and was wondering if we need to do any work on the Apache server in order to make it working seamlessly with OpenSSL when the FIPS mode is enabled. My questions are: 1) How to make Apache server enable the FIPS mode on OpenSSL? My understanding is, for each application which need use OpenSSL FIPS mode, the application need to invoke the FIPS_mode_set () API. In that case how do we make Apache to invoke this API? Is that a configuration changes or does it require to rebuild Apache server? 2) If Apache is enabled with FIPS module, does it mean all the Apache processes (when invoking crypto functions from OpenSSL) will be operating with the OpenSSL FIPS mode? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Tue Jan 19 02:31:18 2016 From: security.veteran at gmail.com (security veteran) Date: Mon, 18 Jan 2016 18:31:18 -0800 Subject: [openssl-users] Integrating OpenSSL FIPS modules with languages like Python and PHP Message-ID: Hi All: We will be using OpenSSL FIPS modules on our Linux appliances and we have some Python and PHP applications which need to invoke crypto related functionalities provided by OpenSSL. I was wondering has anyone integrated Python and PHP with OpenSSL FIPS modules? Since for each application which need to use OpenSSL FIPS modules, the application need to invoke the FIPS_mode_set () API in its process space. To me it sounds like the FIPS_mode_set function needs to be invoked from within the Python and PHP interpreter processes, which means we need to modify the Python or PHP interpreter make make them invoke the FIPS_mode_set() API when needed. Does that sound like the right thing to do, or is there any better way for doing this? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Jan 19 03:05:07 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 19 Jan 2016 03:05:07 +0000 Subject: [openssl-users] How to access some simple conversion functions - asn1_time_to_tm In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E04686@mbx027-w1-ca-4.exch027.domain.local> References: <8149AB08BCB1F54F92680ED6104891A0E045F9@mbx027-w1-ca-4.exch027.domain.local> <20160118225104.GA17296@openssl.org> <8149AB08BCB1F54F92680ED6104891A0E04686@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20160119030507.GA22130@openssl.org> On Tue, Jan 19, 2016, Nounou Dadoun wrote: > That actually worked reasonably smoothly, the only thing that I have to fix now is that it's obviously taking the time zone into account - is there a way of telling it to do everything in UTC? > The routines don't take any account of local timezone: if the ASN1_TIME structure contains a timezone (which is rare becasue it is forbidden in DER but a few certificates do it anyway) that will be adjusted. > And I still don't see any programmatic way of accessing whether a key usage is "critical" or not. > There are several ways to retrieve that. The function X509_get_ext_d2i() decodes an extension and retrieves the criticality flags in one call. You can use X509_EXTENSION_get_critical too if you've retrieved the X509_EXTENSION structure. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Tue Jan 19 03:07:44 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 19 Jan 2016 03:07:44 +0000 Subject: [openssl-users] Digest MD5 forbidden in FIPS mode In-Reply-To: References: Message-ID: <20160119030744.GA22484@openssl.org> On Mon, Jan 18, 2016, Marcos Bontempo wrote: > Hello, > I wrote a C code which enter in FIPS mode with fips_mod_set(1). > But, when I call MD5 functions after setting FIPS mode, I get this error: > md5_dgst.c(75): OpenSSL internal error, assertion failed: Low level API call to digest MD5 forbidden in FIPS mode! Aborted. > Does anybody know what is wrong? How can I correct it? > Any tip will be very helpful,Thanks. As well as the fact that MD5 is forbidden in FIPS mode you also have to use the EVP API for digests. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From security.veteran at gmail.com Tue Jan 19 09:33:16 2016 From: security.veteran at gmail.com (security veteran) Date: Tue, 19 Jan 2016 01:33:16 -0800 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so Message-ID: Hi, I am trying to build a system with both the non-FIPS OpenSSL and the OpenSSL with FIPS modules, and was wondering does OpenSSL FIPS modules actually only affect libcrypto.so? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Jan 19 14:44:49 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 19 Jan 2016 09:44:49 -0500 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: References: Message-ID: <569E4BE1.9040307@openssl.com> On 01/19/2016 04:33 AM, security veteran wrote: > Hi, > > I am trying to build a system with both the non-FIPS OpenSSL and the > OpenSSL with FIPS modules, and was wondering does OpenSSL FIPS modules > actually only affect libcrypto.so? Yes and no. The "FIPS enabled" OpenSSL consists of OpenSSL 1.0.N built with the "fips" option, in the presence of an OpenSSL FIPS module. That module (which is basically the fipscanister.o file) is embedded within the libcrypto shared library. If you don't enable FIPS mode (no FIPS_mode_set() call) then that libcrypto behaves just like the usual libcrypto from a non-FIPS enabled OpenSSL build; the FIPS module is just dead weight. But once you enable FIPS mode then the cryptographic operations that are not allowed by FIPS 140-2 (which is many of the algorithms supported by OpenSSL) are automagically disabled. Those cryptographic operations which are allowed are routed to the FIPS module. Note that those separate crypto implementations in the FIPS module will always necessarily be "behind" the ones on OpenSSL proper (in terms of performance, security, general robustness). Note we designed the "FIPS enabled" mechanism just so that vendors would not need to ship two different sets of binaries to their customers who do and don't care about FIPS 140-2. Ship the "FIPS enabled" OpenSSL libraries to all your customers, and those who don't explicitly enable FIPS mode won't see the FIPS part. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Suman.Patro-TRN at lntebg.com Tue Jan 19 15:52:25 2016 From: Suman.Patro-TRN at lntebg.com (Suman.Patro-TRN) Date: Tue, 19 Jan 2016 15:52:25 +0000 Subject: [openssl-users] regarding openssl 1.0.2e Message-ID: <1453218765733.59815@lntebg.com> Hello, I am trying with SSL handshake mechanism with ECDSA-ECDHE-AES-SHA and have generated certificates following the below link. http://this.is.thoughtcrime.org.nz/elliptic-curve-ca-guide But have certain issues regarding the same. 1. The generated certificates show "The certificate has an invalid signature " and the public key length shown is ECC (0 bits ) . Upon exploring some websites, I understood, it is related to key length restrictions of windows. I am working on windows. But creating ECC keys and signing it by RSA works fine, the problem prevails with ECDSA, how do I resolve the same? 2. The s_server and s_client of openssl are implemented for ECDSA_ECDHE_AES_GCM_SHA384 but the same s_server and s_client work with my ECDHE-RSA certificates as well , How is that possible?The ECDHE-RSA certificates should work invalid. But that's not the case, it works fine. Please explain the underlying reason. 3. The s_server and s_client behave quite uncertain at times i.e the same cipher suite that I input is recognized at one instance and at other instance the same suite is not recognized and I am provided with an error of "no shared cipher error" from the server side. Please explain. Kindly answer. Any help is highly appreciated. Thanks and regards, Suman [http://www.lntebg.com/images/Digital_Signature_Elecrama_2016.jpg] Larsen & Toubro Limited www.larsentoubro.com This Email may contain confidential or privileged information for the intended recipient (s). If you are not the intended recipient, please do not use or disseminate the information, notify the sender and delete it from your system. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Suman.Patro-TRN at lntebg.com Tue Jan 19 15:19:20 2016 From: Suman.Patro-TRN at lntebg.com (R-D intern) Date: Tue, 19 Jan 2016 08:19:20 -0700 (MST) Subject: [openssl-users] regarding openssl 1.0.2e Message-ID: <1453216760152-62472.post@n7.nabble.com> Hello, I am trying with SSL handshake mechanism with ECDSA-ECDHE-AES-SHA and have generated certificates following the below link. http://this.is.thoughtcrime.org.nz/elliptic-curve-ca-guide But have certain issues regarding the same. 1. The generated certificates show "The certificate has an invalid signature " and the public key length shown is ECC (0 bits ) . Upon exploring some websites, I understood, it is related to key length restrictions of windows. I am working on windows. But creating ECC keys and signing it by RSA works fine, the problem prevails with ECDSA, how do I resolve the same? 2. The s_server and s_client of openssl are implemented for ECDSA_ECDHE_AES_GCM_SHA384 but the same s_server and s_client work with my ECDHE-RSA certificates as well , How is that possible?The ECDHE-RSA certificates should work invalid. But that's not the case, it works fine. Please explain the underlying reason. 3. The s_server and s_client behave quite uncertain at times i.e the same cipher suite that I input is recognized at one instance and at other instance the same suite is not recognized and I am provided with an error of "no shared cipher error" from the server side. Please explain. Kindly answer. Any help is highly appreciated. Thanks and regards, Suman -- View this message in context: http://openssl.6102.n7.nabble.com/regarding-openssl-1-0-2e-tp62472.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From security.veteran at gmail.com Tue Jan 19 18:41:43 2016 From: security.veteran at gmail.com (security veteran) Date: Tue, 19 Jan 2016 10:41:43 -0800 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: <569E4BE1.9040307@openssl.com> References: <569E4BE1.9040307@openssl.com> Message-ID: Thanks Steve. So basically the idea is to allow companies build the OpenSSL with FIPS modules in their product and ship only this version of OpenSSL to all their customers. For the customers who don't need FIPS, then just simply keep the FIPS mode disabled and then the OpenSSL will behave just like there's no FIPS module exist. Is that correct? One question I have is, in the above case should the openssl commands also remain FIPS disabled unless we explicitly enable FIPS mode? I built a OpenSSL lib with FIPS modules, and what I found was, when I run the following command to create non-FIPS compliant checksum (i.e. MD5 in this case), it failed with some MD5 algorithm not permitted errors. openssl dgst -md5 FILE_NAME To me it looks like the openssl commands are always run with FIPS enabled in this case. Is that the expected behavior? Thanks. On Tue, Jan 19, 2016 at 6:44 AM, Steve Marquess wrote: > On 01/19/2016 04:33 AM, security veteran wrote: > > Hi, > > > > I am trying to build a system with both the non-FIPS OpenSSL and the > > OpenSSL with FIPS modules, and was wondering does OpenSSL FIPS modules > > actually only affect libcrypto.so? > > Yes and no. > > The "FIPS enabled" OpenSSL consists of OpenSSL 1.0.N built with the > "fips" option, in the presence of an OpenSSL FIPS module. That module > (which is basically the fipscanister.o file) is embedded within the > libcrypto shared library. > > If you don't enable FIPS mode (no FIPS_mode_set() call) then that > libcrypto behaves just like the usual libcrypto from a non-FIPS enabled > OpenSSL build; the FIPS module is just dead weight. > > But once you enable FIPS mode then the cryptographic operations that are > not allowed by FIPS 140-2 (which is many of the algorithms supported by > OpenSSL) are automagically disabled. Those cryptographic operations > which are allowed are routed to the FIPS module. Note that those > separate crypto implementations in the FIPS module will always > necessarily be "behind" the ones on OpenSSL proper (in terms of > performance, security, general robustness). > > Note we designed the "FIPS enabled" mechanism just so that vendors would > not need to ship two different sets of binaries to their customers who > do and don't care about FIPS 140-2. Ship the "FIPS enabled" OpenSSL > libraries to all your customers, and those who don't explicitly enable > FIPS mode won't see the FIPS part. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Tue Jan 19 18:52:45 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 19 Jan 2016 18:52:45 +0000 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: References: <569E4BE1.9040307@openssl.com> Message-ID: <20160119185245.GA8853@openssl.org> On Tue, Jan 19, 2016, security veteran wrote: > > openssl dgst -md5 FILE_NAME > > To me it looks like the openssl commands are always run with FIPS enabled > in this case. Is that the expected behavior? > Ihe openssl command enters FIPS mode if the environmant variable OPENSSL_FIPS is set. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From security.veteran at gmail.com Tue Jan 19 18:54:33 2016 From: security.veteran at gmail.com (security veteran) Date: Tue, 19 Jan 2016 10:54:33 -0800 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? Message-ID: Hi All: What version of OpenSSL source can be built with FIPS modules? We are using Ubuntu, and we noticed that the Ubuntu 12.04 and 14.04 packaged their openssl .deb from different version of openssl source. e.g. Ubuntu 12.04 uses openssl_1.0.1 and Ubuntu 14.04 uses openssl_1.0.1f Can the OpenSSL FIPS modules be built with both of these two different version of OpenSSL? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Tue Jan 19 19:02:33 2016 From: security.veteran at gmail.com (security veteran) Date: Tue, 19 Jan 2016 11:02:33 -0800 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: <20160119185245.GA8853@openssl.org> References: <569E4BE1.9040307@openssl.com> <20160119185245.GA8853@openssl.org> Message-ID: Thanks Steve. When the environment variable OPENSSL_FIPS is set, does it enable FIPS mode globally, so that any applications which use OpenSSL also enter FIPS mode? On Tue, Jan 19, 2016 at 10:52 AM, Dr. Stephen Henson wrote: > On Tue, Jan 19, 2016, security veteran wrote: > > > > > openssl dgst -md5 FILE_NAME > > > > To me it looks like the openssl commands are always run with FIPS enabled > > in this case. Is that the expected behavior? > > > > Ihe openssl command enters FIPS mode if the environmant variable > OPENSSL_FIPS > is set. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Jan 19 19:11:59 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 19 Jan 2016 14:11:59 -0500 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: References: <569E4BE1.9040307@openssl.com> Message-ID: <569E8A7F.7090203@openssl.com> On 01/19/2016 01:41 PM, security veteran wrote: > Thanks Steve. > > So basically the idea is to allow companies build the OpenSSL with FIPS > modules in their product and ship only this version of OpenSSL to all > their customers. For the customers who don't need FIPS, then just simply > keep the FIPS mode disabled and then the OpenSSL will behave just like > there's no FIPS module exist. Is that correct? > > ... That is correct. After the #1747 validation was approved the CMVP introduced a new requirement that the POST be unconditional, which would conflict with that objective (to some extent anyway, by forcing the POST to even in the more common case where FIPS 140-2 was not desired). So that design objective will not be fully achievable in future validations. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Tue Jan 19 19:17:14 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 19 Jan 2016 14:17:14 -0500 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? In-Reply-To: References: Message-ID: <569E8BBA.2060503@openssl.com> On 01/19/2016 01:54 PM, security veteran wrote: > Hi All: > > What version of OpenSSL source can be built with FIPS modules? Stock OpenSSL 0.9.8 is compatible with the 1.2 module only (openssl-fips-1.2.N.tar.gz). Note the 1.2 module will die at the end of this month. Stock OpenSSL 1.0.N is compatible with the 2.0 module only (openssl-fips-2.0.N.tar.gz). OpenSSL 1.1 is not compatible with any FIPS module. > We are using Ubuntu, and we noticed that the Ubuntu 12.04 and 14.04 > packaged their openssl .deb from different version of openssl source. > > e.g. Ubuntu 12.04 uses openssl_1.0.1 > and > Ubuntu 14.04 uses openssl_1.0.1f > > > Can the OpenSSL FIPS modules be built with both of these two different > version of OpenSSL? Keep in mind that the OpenSSL bundled with Ubuntu isn't stock OpenSSL, and isn't built as a "FIPS capable" OpenSSL. I don't know how feasible it will be to rebuild those Ubuntu sources with the "fips" option to make a "FIPS capable" OpenSSL, as I haven't looked at the Ubuntu modifications. Try it and see. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From security.veteran at gmail.com Tue Jan 19 19:30:37 2016 From: security.veteran at gmail.com (security veteran) Date: Tue, 19 Jan 2016 11:30:37 -0800 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? In-Reply-To: <569E8BBA.2060503@openssl.com> References: <569E8BBA.2060503@openssl.com> Message-ID: Thanks Steve. I believe the OpenSSL bundled with Ubuntu basically just added some Ubuntu packaging stuffs such as the package installation scripts, the dependency information, etc. The main source code should be pretty much the same and all the patches should still come from the OpenSSL community. Another option I was thinking was, build the FIPS modules with the openssl source in Ubuntu package, and then just replace the original Ubuntu libcrypto.so file with the libcrypto.so which integrated with the FIPS modules. Ideally this should work, or do you see any possible issues of doing this way? Thanks. On Tue, Jan 19, 2016 at 11:17 AM, Steve Marquess wrote: > On 01/19/2016 01:54 PM, security veteran wrote: > > Hi All: > > > > What version of OpenSSL source can be built with FIPS modules? > > Stock OpenSSL 0.9.8 is compatible with the 1.2 module only > (openssl-fips-1.2.N.tar.gz). Note the 1.2 module will die at the end of > this month. > > Stock OpenSSL 1.0.N is compatible with the 2.0 module only > (openssl-fips-2.0.N.tar.gz). > > OpenSSL 1.1 is not compatible with any FIPS module. > > > We are using Ubuntu, and we noticed that the Ubuntu 12.04 and 14.04 > > packaged their openssl .deb from different version of openssl source. > > > > e.g. Ubuntu 12.04 uses openssl_1.0.1 > > < > http://archive.ubuntu.com/ubuntu/pool/main/o/openssl/openssl_1.0.1.orig.tar.gz> > and > > Ubuntu 14.04 uses openssl_1.0.1f > > < > https://launchpad.net/ubuntu/+archive/primary/+files/openssl_1.0.1f.orig.tar.gz > > > > > > Can the OpenSSL FIPS modules be built with both of these two different > > version of OpenSSL? > > Keep in mind that the OpenSSL bundled with Ubuntu isn't stock OpenSSL, > and isn't built as a "FIPS capable" OpenSSL. I don't know how feasible > it will be to rebuild those Ubuntu sources with the "fips" option to > make a "FIPS capable" OpenSSL, as I haven't looked at the Ubuntu > modifications. Try it and see. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Jan 19 19:43:07 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 19 Jan 2016 14:43:07 -0500 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? In-Reply-To: References: <569E8BBA.2060503@openssl.com> Message-ID: <569E91CB.7050900@openssl.com> On 01/19/2016 02:30 PM, security veteran wrote: > Thanks Steve. > > I believe the OpenSSL bundled with Ubuntu basically just added some > Ubuntu packaging stuffs such as the package installation scripts, the > dependency information, etc. The main source code should be pretty much > the same and all the patches should still come from the OpenSSL community. > > Another option I was thinking was, build the FIPS modules with the > openssl source in Ubuntu package, and then just replace the original > Ubuntu libcrypto.so file with the libcrypto.so which integrated with the > FIPS modules. Ideally this should work, or do you see any possible > issues of doing this way? If the Ubuntu mods are metadata only, and all the operational source code is intact, then that *should* work. FWiW I once spent a lot of time hacking OSS packages for DoD in multiple distros, and generally found it more trouble than it was worth to try try replacing bundled vendor packages, as opposed to installing a new OpenSSL along with new versions of the OSS products that used it (such as OpenSSH, Apache httpd, Stunnel, etc.). -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Tue Jan 19 19:56:07 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 19 Jan 2016 20:56:07 +0100 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? In-Reply-To: References: <569E8BBA.2060503@openssl.com> Message-ID: <569E94D7.3030108@wisemo.com> If, as I suspect, the Ubuntu and Debian OpenSSL packages share the packaging work and patches, then the situation is a bit different. At least for Debian, the OpenSSL packages: - Freeze the visible patch level letter at whatever it was on some freeze date prior to release (for instance it may say "1.0.1e") - Include backports of all relevant security patches in Debian packages versioned e.g. 1.0.1e-2+deb7u18 (meaning the 18th patch release since version 2 of the 1.0.1e packaging was included in Debian 7.0). - Include additional patches to do "symbol versioning" wherever the 1.0.x libraries contain ABI differences that would otherwise break running software compiled to run against shared libraries built from the 1.0.0 tree against shared libraries compiled from the 1.0.1 tree (etc.). Basically, they fix bugs in the binary compatibility within the 1.0.x upstream releases. - An unknown number of truly custom patches, one of which used to accidentally criple key generation so badly they were actually able to release a blacklist of all the public keys it could possibly generate (after they found the bug). On 19/01/2016 20:30, security veteran wrote: > Thanks Steve. > > I believe the OpenSSL bundled with Ubuntu basically just added some > Ubuntu packaging stuffs such as the package installation scripts, the > dependency information, etc. The main source code should be pretty > much the same and all the patches should still come from the OpenSSL > community. > > Another option I was thinking was, build the FIPS modules with the > openssl source in Ubuntu package, and then just replace the original > Ubuntu libcrypto.so file with the libcrypto.so which integrated with > the FIPS modules. Ideally this should work, or do you see any possible > issues of doing this way? > > Thanks. > > On Tue, Jan 19, 2016 at 11:17 AM, Steve Marquess > wrote: > > On 01/19/2016 01:54 PM, security veteran wrote: > > Hi All: > > > > What version of OpenSSL source can be built with FIPS modules? > > Stock OpenSSL 0.9.8 is compatible with the 1.2 module only > (openssl-fips-1.2.N.tar.gz). Note the 1.2 module will die at the > end of > this month. > > Stock OpenSSL 1.0.N is compatible with the 2.0 module only > (openssl-fips-2.0.N.tar.gz). > > OpenSSL 1.1 is not compatible with any FIPS module. > > > We are using Ubuntu, and we noticed that the Ubuntu 12.04 and 14.04 > > packaged their openssl .deb from different version of openssl > source. > > > > e.g. Ubuntu 12.04 uses openssl_1.0.1 > > > > and > > Ubuntu 14.04 uses openssl_1.0.1f > > > > > > > Can the OpenSSL FIPS modules be built with both of these two > different > > version of OpenSSL? > > Keep in mind that the OpenSSL bundled with Ubuntu isn't stock OpenSSL, > and isn't built as a "FIPS capable" OpenSSL. I don't know how feasible > it will be to rebuild those Ubuntu sources with the "fips" option to > make a "FIPS capable" OpenSSL, as I haven't looked at the Ubuntu > modifications. Try it and see. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > 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 Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Jan 19 20:06:20 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 19 Jan 2016 15:06:20 -0500 Subject: [openssl-users] What version of OpenSSL source can be built with FIPS modules? In-Reply-To: <569E94D7.3030108@wisemo.com> References: <569E8BBA.2060503@openssl.com> <569E94D7.3030108@wisemo.com> Message-ID: > On Jan 19, 2016, at 2:56 PM, Jakob Bohm wrote: > > - Include additional patches to do "symbol versioning" > wherever the 1.0.x libraries contain ABI differences > that would otherwise break running software compiled > to run against shared libraries built from the 1.0.0 > tree against shared libraries compiled from the 1.0.1 > tree (etc.). Basically, they fix bugs in the binary > compatibility within the 1.0.x upstream releases. My reading of the symbol versioning in Debian is that no effort is made to preserve the ABI. Rather the symbol versioning enables Debian to more accurately determine minimum OpenSSL version dependencies when building other packages that depend on OpenSSL. And they allow the same application to dynamically load, for example, both the 0.9.8 and 1.0.0 (ABI so 1.0.0/1.0.1/1.0.2) shared libraries. The Debian libraries do not AFAIK contain backwards-ABI-compatible versions of obsoleted interfaces. -- Viktor. From steve at openssl.org Tue Jan 19 22:42:41 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 19 Jan 2016 22:42:41 +0000 Subject: [openssl-users] Does OpenSSL FIPS modules only affect libcrypto.so In-Reply-To: References: <569E4BE1.9040307@openssl.com> <20160119185245.GA8853@openssl.org> Message-ID: <20160119224241.GA1738@openssl.org> On Tue, Jan 19, 2016, security veteran wrote: > > When the environment variable OPENSSL_FIPS is set, does it enable FIPS mode > globally, so that any applications which use OpenSSL also enter FIPS mode? > No it only applies to the "openssl" application. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From doctor at doctor.nl2k.ab.ca Tue Jan 19 23:37:24 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 19 Jan 2016 16:37:24 -0700 Subject: [openssl-users] Openssl 1.1 and Bind 9.6 ESV R11 Message-ID: <20160119233724.GA9102@doctor.nl2k.ab.ca> Tried to compile an old bind and ran into /bin/bash /usr/source/bind-9.6-ESV-R11/libtool --mode=compile /usr/bin/gcc -I/usr/source/bind-9.6-ESV-R11 -I. -Iinclude -I/usr/source/bind-9.6-ESV-R11/lib/dns/include -I../../lib/dns/include -I/usr/source/bind-9.6-ESV-R11/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include -I/usr/contrib/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_MD5 -DOPENSSL -g -O2 -Wall -I/usr/contrib/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c openssldh_link.c libtool: compile: /usr/bin/gcc -I/usr/source/bind-9.6-ESV-R11 -I. -Iinclude -I/usr/source/bind-9.6-ESV-R11/lib/dns/include -I../../lib/dns/include -I/usr/source/bind-9.6-ESV-R11/lib/isc/include -I../../lib/isc -I../../lib/isc/include -I../../lib/isc/unix/include -I../../lib/isc/nothreads/include -I../../lib/isc/x86_32/include -I/usr/contrib/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DUSE_MD5 -DOPENSSL -g -O2 -Wall -I/usr/contrib/include/libxml2 -W -Wall -Wmissing-prototypes -Wcast-qual -Wwrite-strings -Wformat -Wpointer-arith -fno-strict-aliasing -c openssldh_link.c -o openssldh_link.o openssldh_link.c: In function `openssldh_generate': openssldh_link.c:155: storage size of `cb' isn't known openssldh_link.c:155: warning: unused variable `cb' openssldh_link.c: In function `dst__openssldh_init': openssldh_link.c:623: warning: implicit declaration of function `BN_init' /usr/contrib/include/openssl/conf.h: At top level: openssldh_link.c:73: storage size of `bn2' isn't known openssldh_link.c:73: storage size of `bn768' isn't known openssldh_link.c:73: storage size of `bn1024' isn't known openssldh_link.c:73: storage size of `bn1536' isn't known *** Error code 1 Stop. *** Error code 1 Stop. *** Error code 1 Stop. Line 73 reads static BIGNUM bn2, bn768, bn1024, bn1536; line 155 reads #if OPENSSL_VERSION_NUMBER > 0x00908000L BN_GENCB cb; #endif and line 623 reads isc_result_t dst__openssldh_init(dst_func_t **funcp) { REQUIRE(funcp != NULL); if (*funcp == NULL) { BN_init(&bn2); BN_init(&bn768); BN_init(&bn1024); BN_init(&bn1536); BN_set_word(&bn2, 2); BN_fromhex(&bn768, PRIME768); BN_fromhex(&bn1024, PRIME1024); BN_fromhex(&bn1536, PRIME1536); *funcp = &openssldh_functions; } return (ISC_R_SUCCESS); } What needs to be adjusted? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From bkaduk at akamai.com Wed Jan 20 02:53:49 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 19 Jan 2016 20:53:49 -0600 Subject: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160119233724.GA9102@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> Message-ID: <569EF6BD.9000804@akamai.com> On 01/19/2016 05:37 PM, The Doctor wrote: > Tried to compile an old bind and ran into Why? > What needs to be adjusted? > > The bind code is what needs to be adjusted, given that openssl 1.1 is intentionally introducing API changes and removing direct access to many structures. It seems quite unlikely that an EoL version of a third-party software is going to magically receive a new release allowing it to build against a version of openssl that did not exist when it was released. -Ben From cloud.force858 at gmail.com Wed Jan 20 07:00:47 2016 From: cloud.force858 at gmail.com (cloud force) Date: Tue, 19 Jan 2016 23:00:47 -0800 Subject: [openssl-users] Questions regarding the openssl FIPS self-tests Message-ID: Hi everyone, >From the openssl tips doc it said the power-on self-tests need to be run when the system comes up. If I have multiple applications which uses the openssl crypto functions (under fips mode), does each of this application need to run the power-on self-tests? Also if the openssl fips modules are installed on a Linux server, what is the best way to run the power-on self-tests (e.g. run within init.d script or upstart scripts or run by a daemon)? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jan 20 12:22:37 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 20 Jan 2016 07:22:37 -0500 Subject: [openssl-users] Questions regarding the openssl FIPS self-tests In-Reply-To: References: Message-ID: <569F7C0D.4060708@openssl.com> On 01/20/2016 02:00 AM, cloud force wrote: > Hi everyone, > > From the openssl tips doc it said the power-on self-tests need to be run > when the system comes up. > > If I have multiple applications which uses the openssl crypto functions > (under fips mode), does each of this application need to run the > power-on self-tests? > > Also if the openssl fips modules are installed on a Linux server, what > is the best way to run the power-on self-tests (e.g. run within init.d > script or upstart scripts or run by a daemon)? The POST is run automagically when your application code calls FIPS_mode_SET(). For most platforms including Linux the shared library has non-writable code/data area(s) shared among all calling processes, and writable data area(s) private to each such process. The library state information resides in the private writable areas, of course, so each such process will need to independently call FIPS_mode_set(). Keep in mind that the POST doesn't really do anything useful, it is an ideological requirement from the dim mists of history. As such you cannot enable FIPS mode without also invoking the POST. Note this means that one set of shared libraries can be used for all processes, both those that care about FIPS 140-2 and those that don't. The OpenSSL + OpenSSL FIPS module combination (the "FIPS capable" OpenSSL) was designed for such dual use so that the FIPS behavior wouldn't be seen *unless* FIPS_mode_set() was called. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From sara at sinodun.com Wed Jan 20 14:27:25 2016 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 20 Jan 2016 14:27:25 +0000 Subject: [openssl-users] Using TCP Fast Open with OpenSSL References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> Message-ID: <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> Hi, I have recently been adding support for TLS using OpenSSL to a client application. When using TCP the application uses TCP Fast Open (TFO) as described in this RFC: https://tools.ietf.org/html/rfc7413 . TFO is currently available for clients on both Linux and OS X, however the socket API changes for TFO are different on the 2 platforms. I have TFO + TLS (using OpenSSL) working on OS X. However, because of the specifics of the TFO implementation on Linux, I can?t see how to get that working with OpenSSL. On Linux using TFO requires that - the connect() call is skipped entirely - the first data sent on the connection must be sent using the sendto() function passing in the MSG_FASTOPEN flag. This sendto() call takes care of both the TCP handshake, and sending the data as payload in the SYN. I may well be missing something, but I can?t see anyway to use this in combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() functions rely on the underlying socket already being setup and ready to accept a 'write'. Does anyone know of a solution/workaround, or a plan to add support for client TFO to OpenSSL? Regards Sara. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Jan 20 16:55:17 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jan 2016 11:55:17 -0500 Subject: [openssl-users] Using TCP Fast Open with OpenSSL In-Reply-To: <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> Message-ID: <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> > On Jan 20, 2016, at 9:27 AM, Sara Dickinson wrote: > > I have TFO + TLS (using OpenSSL) working on OS X. However, because of the specifics of the TFO implementation on Linux, I can?t see how to get that working with OpenSSL. On Linux using TFO requires that > - the connect() call is skipped entirely > - the first data sent on the connection must be sent using the sendto() function passing in the MSG_FASTOPEN flag. This sendto() call takes care of both the TCP handshake, and sending the data as payload in the SYN. > > I may well be missing something, but I can?t see anyway to use this in combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() functions rely on the underlying socket already being setup and ready to accept a 'write'. Does anyone know of a solution/workaround, or a plan to add support for client TFO to OpenSSL? Well, I am not shy to say that the Linux Kernel API for this is poorly designed. However, we can perhaps work around this. This could be done via an enhancement of BIO_s_socket() to support completing the connection on the first write. Then you just configure the modified BIO as the network BIO of the SSL handle. The construction of the BIO could be made transparent to users of SSL_set_fd() via a suitable new control operation that's passed through to the underlying BIO. SSL_set_fd(ssl, sock); SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen); (Or some variant of these types for Windows, ...) But of course the feature itself would not initially be available on all platforms. -- Viktor. From nounou.dadoun at avigilon.com Wed Jan 20 18:01:00 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Wed, 20 Jan 2016 18:01:00 +0000 Subject: [openssl-users] Using TCP Fast Open with OpenSSL In-Reply-To: <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E04B92@mbx027-w1-ca-4.exch027.domain.local> -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Viktor Dukhovni Sent: Wednesday, January 20, 2016 8:55 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] Using TCP Fast Open with OpenSSL > On Jan 20, 2016, at 9:27 AM, Sara Dickinson wrote: > > I have TFO + TLS (using OpenSSL) working on OS X. However, because of > the specifics of the TFO implementation on Linux, I can?t see how to > get that working with OpenSSL. On Linux using TFO requires that > - the connect() call is skipped entirely > - the first data sent on the connection must be sent using the sendto() function passing in the MSG_FASTOPEN flag. This sendto() call takes care of both the TCP handshake, and sending the data as payload in the SYN. > > I may well be missing something, but I can?t see anyway to use this in combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() functions rely on the underlying socket already being setup and ready to accept a 'write'. Does anyone know of a solution/workaround, or a plan to add support for client TFO to OpenSSL? Well, I am not shy to say that the Linux Kernel API for this is poorly designed. However, we can perhaps work around this. This could be done via an enhancement of BIO_s_socket() to support completing the connection on the first write. Then you just configure the modified BIO as the network BIO of the SSL handle. The construction of the BIO could be made transparent to users of SSL_set_fd() via a suitable new control operation that's passed through to the underlying BIO. SSL_set_fd(ssl, sock); SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen); (Or some variant of these types for Windows, ...) But of course the feature itself would not initially be available on all platforms. -- Viktor. ---------------------------- But if the TFO data payload is in the first SYN how can it be encrypted (etc) even before the TCP handshake is complete (let alone the SSL handshake) unless the calls are unbundled and serialized somehow. Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn From doctor at doctor.nl2k.ab.ca Wed Jan 20 18:05:58 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 20 Jan 2016 11:05:58 -0700 Subject: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <569EF6BD.9000804@akamai.com> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> Message-ID: <20160120180558.GB13198@doctor.nl2k.ab.ca> On Tue, Jan 19, 2016 at 08:53:49PM -0600, Benjamin Kaduk wrote: > On 01/19/2016 05:37 PM, The Doctor wrote: > > Tried to compile an old bind and ran into > > Why? > > > What needs to be adjusted? > > > > > > The bind code is what needs to be adjusted, given that openssl 1.1 is > intentionally introducing API changes and removing direct access to many > structures. It seems quite unlikely that an EoL version of a > third-party software is going to magically receive a new release > allowing it to build against a version of openssl that did not exist > when it was released. That's my issue. I cannot get a more recent bind version to stay to stable on one box. > > -Ben > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From openssl-users at dukhovni.org Wed Jan 20 18:11:04 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jan 2016 18:11:04 +0000 Subject: [openssl-users] Using TCP Fast Open with OpenSSL In-Reply-To: <8149AB08BCB1F54F92680ED6104891A0E04B92@mbx027-w1-ca-4.exch027.domain.local> References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> <8149AB08BCB1F54F92680ED6104891A0E04B92@mbx027-w1-ca-4.exch027.domain.local> Message-ID: <20160120181104.GT646@mournblade.imrryr.org> On Wed, Jan 20, 2016 at 06:01:00PM +0000, Nounou Dadoun wrote: > But if the TFO data payload is in the first SYN how can it be encrypted > (etc) even before the TCP handshake is complete (let alone the SSL > handshake) unless the calls are unbundled and serialized somehow. The TCP first-flight data will be the TLS ClientHello message. This saves one round-trip on repeat visits: C: SYN + TFO-COOKIE + TLS ClientHello S: SYN-ACK S: ACK + TLS Server Hello ... ... -- Viktor. From rsalz at akamai.com Wed Jan 20 18:11:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 18:11:16 +0000 Subject: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160120180558.GB13198@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> Message-ID: <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> > That's my issue. I cannot get a more recent bind version to stay to stable on > one box. Then I think that's going to be a tough issue, and you'll either have to modify that source or stay at 1.0.2 From openssl-users at dukhovni.org Wed Jan 20 18:20:07 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jan 2016 18:20:07 +0000 Subject: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <20160120180558.GB13198@doctor.nl2k.ab.ca> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> Message-ID: <20160120182007.GU646@mournblade.imrryr.org> On Wed, Jan 20, 2016 at 11:05:58AM -0700, The Doctor wrote: > > The bind code is what needs to be adjusted, given that openssl 1.1 is > > intentionally introducing API changes and removing direct access to many > > structures. It seems quite unlikely that an EoL version of a > > third-party software is going to magically receive a new release > > allowing it to build against a version of openssl that did not exist > > when it was released. > > That's my issue. I cannot get a more recent bind version to stay > to stable on one box. Bind 9.10 works fine for me, but I use it only as an authoritative server. My recursive resolver is "unbound". And I make sure to build both without GOST support. If BIND is not reliable enough for you, consider some combination "unbound" and/or "nsd". -- Viktor. From Eric.Erhardt at microsoft.com Wed Jan 20 18:13:05 2016 From: Eric.Erhardt at microsoft.com (Eric Erhardt) Date: Wed, 20 Jan 2016 18:13:05 +0000 Subject: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER Message-ID: What is the most appropriate way to programmatically get the following information about an SSL_CIPHER? Currently, we need to read: * Which cipher algorithm is being used * Which key exchange algorithm is being used * Which MAC hash algorithm is being used The way we've currently been doing this is by looking at the SSL_CIPHER's algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is no public header that contains the enum values, we've copied the values out of ssl/ssl_locl.h into our own code. This is problematic, since these values have recently changed with https://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb For example: -# define SSL_kDHE 0x00000008U +# define SSL_kDHE 0x00000002U One option we've discussed is to compare strings returned from SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than ideal. Is there a better way to programmatically get this information? Thanks in advance, Eric Erhardt -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Jan 20 18:39:29 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 Jan 2016 18:39:29 +0000 Subject: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER In-Reply-To: References: Message-ID: The most portable, and longest-lasting, way is probably to get the name and then use that as a key to look up things in your own table of characteristics. A PR that adds API's (and doc) for extracting various things, and returning them as nid's or oid's or something, would be helpful. From sara at sinodun.com Wed Jan 20 18:43:34 2016 From: sara at sinodun.com (Sara Dickinson) Date: Wed, 20 Jan 2016 18:43:34 +0000 Subject: [openssl-users] Using TCP Fast Open with OpenSSL In-Reply-To: <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> Message-ID: <9EAAE059-2470-4F18-B125-E9F52A103035@sinodun.com> > On 20 Jan 2016, at 16:55, Viktor Dukhovni wrote: >> On Jan 20, 2016, at 9:27 AM, Sara Dickinson wrote: >> >> I have TFO + TLS (using OpenSSL) working on OS X. However, because of the specifics of the TFO implementation on Linux, I can?t see how to get that working with OpenSSL. On Linux using TFO requires that >> - the connect() call is skipped entirely >> - the first data sent on the connection must be sent using the sendto() function passing in the MSG_FASTOPEN flag. This sendto() call takes care of both the TCP handshake, and sending the data as payload in the SYN. >> >> I may well be missing something, but I can?t see anyway to use this in combination with the OpenSSL API, because the SSL_connect()/SSL_do_handshake() functions rely on the underlying socket already being setup and ready to accept a 'write'. Does anyone know of a solution/workaround, or a plan to add support for client TFO to OpenSSL? > > Well, I am not shy to say that the Linux Kernel API for this is > poorly designed. However, we can perhaps work around this. Indeed. The OS X implementation is nicer since a connectx() call with the correct flags sets the socket up as needed and then the first write() call performs the TFO. > > This could be done via an enhancement of BIO_s_socket() > to support completing the connection on the first write. > Then you just configure the modified BIO as the network > BIO of the SSL handle. > > The construction of the BIO could be made transparent to > users of SSL_set_fd() via a suitable new control operation > that's passed through to the underlying BIO. > > SSL_set_fd(ssl, sock); > SSL_set_tfo_addr(ssl, struct sockaddr *sa, int salen); Yes, that sounds like it would do the job! > > (Or some variant of these types for Windows, ...) > > But of course the feature itself would not initially be > available on all platforms. As of today TFO isn?t implemented on Windows at all AFAIK and only server side support is currently implemented on FreeBSD. Regards Sara. From nounou.dadoun at avigilon.com Wed Jan 20 18:45:42 2016 From: nounou.dadoun at avigilon.com (Nounou Dadoun) Date: Wed, 20 Jan 2016 18:45:42 +0000 Subject: [openssl-users] Using TCP Fast Open with OpenSSL In-Reply-To: <20160120181104.GT646@mournblade.imrryr.org> References: <16B5EA04-4BC4-4CCC-AF54-541093350AA6@sinodun.com> <73F7D165-4B4B-42B7-9B4B-7B822D89DEB5@sinodun.com> <1FA6D39C-888F-4392-A858-8B5E1F733A8A@dukhovni.org> <8149AB08BCB1F54F92680ED6104891A0E04B92@mbx027-w1-ca-4.exch027.domain.local> <20160120181104.GT646@mournblade.imrryr.org> Message-ID: <8149AB08BCB1F54F92680ED6104891A0E04C0C@mbx027-w1-ca-4.exch027.domain.local> The TCP first-flight data will be the TLS ClientHello message. This saves one round-trip on repeat visits: C: SYN + TFO-COOKIE + TLS ClientHello S: SYN-ACK S: ACK + TLS Server Hello ... ... -- Viktor. ======== That makes sense, thanks ... N Nou Dadoun Senior Firmware Developer, Security Specialist Office: 604.629.5182 ext 2632 Support: 888.281.5182 | avigilon.com Follow Twitter | Follow LinkedIn From steve at openssl.org Wed Jan 20 19:09:49 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 20 Jan 2016 19:09:49 +0000 Subject: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER In-Reply-To: References: Message-ID: <20160120190949.GA23214@openssl.org> On Wed, Jan 20, 2016, Eric Erhardt wrote: > What is the most appropriate way to programmatically get the following information about an SSL_CIPHER? > > Currently, we need to read: > > > * Which cipher algorithm is being used > > * Which key exchange algorithm is being used > > * Which MAC hash algorithm is being used > > The way we've currently been doing this is by looking at the SSL_CIPHER's algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is no public header that contains the enum values, we've copied the values out of ssl/ssl_locl.h into our own code. > > This is problematic, since these values have recently changed with https://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb > > For example: > -# define SSL_kDHE 0x00000008U > +# define SSL_kDHE 0x00000002U > > > One option we've discussed is to compare strings returned from SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than ideal. > > Is there a better way to programmatically get this information? > There are several functions that can extract some of the information. SSL_CIPHER_get_cipher_nid and SSL_CIPHER_get_digest_nid for example. Currently there isn't a function to extract the key exchange or signing algorithm though. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From openssl-users at dukhovni.org Wed Jan 20 19:23:53 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 20 Jan 2016 14:23:53 -0500 Subject: [openssl-users] Getting the current key exchange algorithm mode from an SSL_CIPHER In-Reply-To: References: Message-ID: > On Jan 20, 2016, at 1:13 PM, Eric Erhardt wrote: > > What is the most appropriate way to programmatically get the following information about an SSL_CIPHER? > > Currently, we need to read: > > ? Which cipher algorithm is being used > ? Which key exchange algorithm is being used > ? Which MAC hash algorithm is being used > > The way we?ve currently been doing this is by looking at the SSL_CIPHER?s algorithm_enc, algorithm_mkey, and algorithm_mac fields. But since there is no public header that contains the enum values, we?ve copied the values out of ssl/ssl_locl.h into our own code. > > This is problematic, since these values have recently changed withhttps://github.com/openssl/openssl/commit/bc71f91064a3eec10310fa4cc14fe2a3fd9bc7bb > > For example: > -# define SSL_kDHE 0x00000008U > +# define SSL_kDHE 0x00000002U > > > One option we?ve discussed is to compare strings returned from SSL_CIPHER_get_name, or SSL_CIPHER_description, but this seems less than ideal. > > Is there a better way to programmatically get this information? At present, you can get: SSL_CIPHER_get_cipher_nid() SSL_CIPHER_get_digest_nid() SSL_CIPHER_get_id() The last of these returns 0x0300NNMM with {NN,MM} found at the IANA registry http://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4 There are at present no stable nids for the key exchange, so it may be best to apply your own mappings. Another option is to create an SSL handle with the given cipher name as the first cipher-list element and "!kDHE", "!kECDHE", "!kRSA", ... as the second and last. Whichever of these fails with an empty cipherlist was the actual key exchange method. -- Viktor. From doctor at doctor.nl2k.ab.ca Wed Jan 20 21:52:47 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Wed, 20 Jan 2016 14:52:47 -0700 Subject: [openssl-users] [openssl-dev] Openssl 1.1 and Bind 9.6 ESV R11 In-Reply-To: <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160119233724.GA9102@doctor.nl2k.ab.ca> <569EF6BD.9000804@akamai.com> <20160120180558.GB13198@doctor.nl2k.ab.ca> <79e519af478e4b32abe06f2f65480c42@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160120215246.GA18819@doctor.nl2k.ab.ca> On Wed, Jan 20, 2016 at 06:11:16PM +0000, Salz, Rich wrote: > > That's my issue. I cannot get a more recent bind version to stay to stable on > > one box. > > Then I think that's going to be a tough issue, and you'll either have to modify that source or stay at 1.0.2 > Source modification it is. BTW we are more interested in Bind 9.9 and Bind 9.10 ? > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! http://www.fullyfollow.me/rootnl2k Look at Psalms 14 and 53 on Atheism Birthdate 29 Jan 1969 Redhill, Surrey, UK From Imran.Ali at enghouse.com Wed Jan 20 22:07:05 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Wed, 20 Jan 2016 22:07:05 +0000 Subject: [openssl-users] OpenSSL FIPS Object Module v2.0 Message-ID: Hi Steve, Is there any update on the submissions for the OpenSSL FIPS Object Module v2.0, validation(s) #1747/#2398/#2474 Regards, Imran -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Thu Jan 21 01:27:55 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 20 Jan 2016 20:27:55 -0500 Subject: [openssl-users] OpenSSL FIPS Object Module v2.0 In-Reply-To: References: Message-ID: <56A0341B.3030302@openssl.com> On 01/20/2016 05:07 PM, Imran Ali wrote: > Hi Steve, > > > > Is there any update on the submissions for the OpenSSL FIPS Object > Module v2.0, validation(s) #1747/#2398/#2474 > Still waiting on the CMVP. The paperwork for all three validations was submitted on December 20. I'm not even going to try and guess how long they'll take to review it; we've had to wait over six months for similar (no new platforms) change letters. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From kirubak at zadarastorage.com Thu Jan 21 08:58:24 2016 From: kirubak at zadarastorage.com (Kirubakaran Kaliannan) Date: Thu, 21 Jan 2016 14:28:24 +0530 Subject: [openssl-users] compiling stud proxy with the latest SSL Message-ID: <1920626c75c8279b36d401fe1656dc26@mail.gmail.com> Hi All, I am using stud proxy (https://*github*.com/bumptech/*stud)*, which is on the TLSv1, and want to recompile it with new openssl to support TLS1.2. Also, by default the CIPHER suite it include is AES256-SHA. I want to include more CIPHER suites to the stud proxy. My I know, the procedure to include more cipher suites? Can I get some help with this stud compiled on latest openssl and include large set of CIPHER suites? Thanks, -kiru -------------- next part -------------- An HTML attachment was scrubbed... URL: From swall at redcom.com Thu Jan 21 13:26:05 2016 From: swall at redcom.com (Wall, Stephen) Date: Thu, 21 Jan 2016 08:26:05 -0500 Subject: [openssl-users] Apache (2.x) server and OpenSSL FIPS modules In-Reply-To: References: Message-ID: <401084E5E73F4241A44F3C9E6FD7942803667C18E9@exch-01> See http://httpd.apache.org/docs/2.4/mod/mod_ssl.html#sslfips for using the OpenSSL fipscontainer with apache. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of security veteran Sent: Monday, January 18, 2016 9:21 PM To: openssl-users at openssl.org Subject: [openssl-users] Apache (2.x) server and OpenSSL FIPS modules Hi, We will be using OpenSSL FIPS modules on our Linux server and was wondering if we need to do any work on the Apache server in order to make it working seamlessly with OpenSSL when the FIPS mode is enabled. My questions are: 1) How to make Apache server enable the FIPS mode on OpenSSL? My understanding is, for each application which need use OpenSSL FIPS mode, the application need to invoke the FIPS_mode_set () API. In that case how do we make Apache to invoke this API? Is that a configuration changes or does it require to rebuild Apache server? 2) If Apache is enabled with FIPS module, does it mean all the Apache processes (when invoking crypto functions from OpenSSL) will be operating with the OpenSSL FIPS mode? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Fri Jan 22 21:28:49 2016 From: security.veteran at gmail.com (security veteran) Date: Fri, 22 Jan 2016 13:28:49 -0800 Subject: [openssl-users] OpenSSL FIPS modules license Message-ID: Hi All, What type of license does OpenSSL FIPS modules have? Is it the same as the OpenSSL license, or is it a different license? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Jan 22 22:03:34 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 22 Jan 2016 17:03:34 -0500 Subject: [openssl-users] OpenSSL FIPS modules license In-Reply-To: References: Message-ID: <56A2A736.4030009@openssl.com> On 01/22/2016 04:28 PM, security veteran wrote: > Hi All, > > What type of license does OpenSSL FIPS modules have? Is it the same as > the OpenSSL license, or is it a different license? > > Thanks. Same license. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From ranshalit at gmail.com Sun Jan 24 10:53:57 2016 From: ranshalit at gmail.com (Ran Shalit) Date: Sun, 24 Jan 2016 12:53:57 +0200 Subject: [openssl-users] libcrypto.so is missing in build Message-ID: Hello, I've cross compiled openssh, openssl, and zlib But on trying to run stfp-server (openssh) I get: /libexec/sftp-server: error while loading shared libraries: libcrypto.so.1.0.0: cannot open shared object file: No such file or directory Checking openssl installed files, I see that it created /lib/libcrypto.a but not libcrypto.so This is the configure I used: ./Configure shared dist --prefix=/home/ubuntu/openssh/openssl Trying to add "shared" option did not help. Is there any idea ? Thank you! Ran From mark at openssl.org Mon Jan 25 11:17:05 2016 From: mark at openssl.org (Mark J Cox) Date: Mon, 25 Jan 2016 11:17:05 +0000 Subject: [openssl-users] Forthcoming OpenSSL releases Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Forthcoming OpenSSL releases ============================ The OpenSSL project team would like to announce the forthcoming release of OpenSSL versions 1.0.2f, 1.0.1r. These releases will be made available on 28th January between approx. 1pm and 5pm (UTC). They will fix two security defects, one of "high" severity affecting 1.0.2 releases, and one "low" severity affecting all releases. Please see the following page for further details of severity levels: https://www.openssl.org/policies/secpolicy.html Please also note that, as per our previous announcements, support for 1.0.0 and 0.9.8 releases ended on 31st December 2015 and are no longer receiving security updates. Support for 1.0.1 will end on 31st December 2016. Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBCAAGBQJWpgNkAAoJEAEKUEB8TIy9QcwH/3C7y700FjGjDBcNMcVO++GU 81cs87VqsoziuMSU9Sx8XlDWA8tH5JWXpES4+p9iWdKbks+2E0EahVZVaS5yDaLM LY6MaUM2Pucmrd/I7mvQ02AzzMWEUrFlbk1GtFVjU7IkYc1/ZOZLhjM6H0X8M8lO 5kvqpgWTGV5lMCJdOQLr/eIGIdGTy5Xqerm3Qz/nzvhbwaOu5pjvq0eub8AWbPb3 wwdB4GIKW4XaU7YAJl61o8jNeVoy/kMTfZmZYEefQzXf/1JYO2p8oqCMTIEUrSoN P7sT2d2DpjQvrK3j8MsIPMYUHLhxZt+MJ2+wuOLyznkPTdEIV+ylr6q0I74Wv1Q= =gzHe -----END PGP SIGNATURE----- From Owen.Wieck at ricardo.com Mon Jan 25 20:02:03 2016 From: Owen.Wieck at ricardo.com (Wieck, Owen) Date: Mon, 25 Jan 2016 20:02:03 +0000 Subject: [openssl-users] parse tlsext error in response to client hello Message-ID: Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 0000 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW P.S.: Apologies for the enormous footer that gets tacked on below here. -------------------------------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --------------------------------------------------------------------------------------------------------------------------------------------------------------'. From Owen.Wieck at ricardo.com Mon Jan 25 19:44:46 2016 From: Owen.Wieck at ricardo.com (Wieck, Owen) Date: Mon, 25 Jan 2016 19:44:46 +0000 Subject: [openssl-users] parse tlsext error in response to client hello Message-ID: Dear all -- Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. The example in RFC 4492 (section 5.1.2) is: A client that can parse only the uncompressed point format (value 0) includes an extension consisting of the following octets; note that the first two octets indicate the extension type (Supported Point Formats Extension): 00 0B 00 02 01 00 And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." For reference, here is the complete "SSL record" of the client hello taken from a packet capture: 0000 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 0060 00 Many Thanks! --OLW -------------------------------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --------------------------------------------------------------------------------------------------------------------------------------------------------------'. From matt at openssl.org Mon Jan 25 23:42:13 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 25 Jan 2016 23:42:13 +0000 Subject: [openssl-users] parse tlsext error in response to client hello In-Reply-To: References: Message-ID: <56A6B2D5.8090005@openssl.org> On 25/01/16 20:02, Wieck, Owen wrote: > Dear all -- > > Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? Yes. I copied your record below and pushed it through OpenSSL to recreate the error. It is indeed failing on the parsing of the supported point formats extension for precisely the reason you have specified. OpenSSL automatically rejects a zero length point formats extension. Matt > > 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. > > The example in RFC 4492 (section 5.1.2) is: > > A client that can parse only the uncompressed point format (value 0) > includes an extension consisting of the following octets; note that > the first two octets indicate the extension type (Supported Point > Formats Extension): > > 00 0B 00 02 01 00 > > And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." > > For reference, here is the complete "SSL record" of the client hello taken from a packet capture: > > 0000 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 > 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 > 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f > 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 > 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 > 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 > 0060 00 > > Many Thanks! > > --OLW > > P.S.: Apologies for the enormous footer that gets tacked on below here. > -------------------------------------------------------------------------------------------------------------------------------------------------------------- > This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are > addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. > Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those > of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's > authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and > other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and > any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. > "Ricardo" means Ricardo Inc. and its affiliated companies. > --------------------------------------------------------------------------------------------------------------------------------------------------------------'. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From marquess at openssl.com Tue Jan 26 14:07:06 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 26 Jan 2016 09:07:06 -0500 Subject: [openssl-users] FIPS 140-2 X9.31 RNG transition partially done Message-ID: <56A77D8A.4040105@openssl.com> If you don't know or care what FIPS 140-2 is then bail out now. Here be dragons. The CMVP has approved the mandated "X9.31 RNG transition"[1] update for two-thirds of the OpenSSL FIPS Object Module v2.0. That "transition" consists of editorial changes to the Security Policy document(s) and did not involve any changes to the OpenSSL FIPS module software. That module is, for perversely confusing reasons[2], covered by three nominally separate but very similar validations, #1747, #2398, and #2473. Those three validations collectively cover all the formally tested platforms for this OpenSSL FIPS module. As of yesterday our submissions for the #1747 and #2473 validations were approved and posted on the NIST CMVP web site. Those validations will thus presumably be spared the promised fate of de-listing to "not to be used" status on January 31. The documentation for the remaining validation, #2398, was submitted at the same time but is still pending. That delay will only be significant for users of the OpenSSL FIPS module on platforms listed only for the #2398 module. -Steve M. [1] http://csrc.nist.gov/groups/STM/cmvp/notices.html, see the section labeled "X9.31 RNG transition, December 31, 2015". [2] Details for masochists only: http://openssl.com/fips/ransom.html -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Owen.Wieck at ricardo.com Tue Jan 26 15:30:08 2016 From: Owen.Wieck at ricardo.com (Wieck, Owen) Date: Tue, 26 Jan 2016 15:30:08 +0000 Subject: [openssl-users] parse tlsext error in response to client hello In-Reply-To: <56A6B2D5.8090005@openssl.org> References: <56A6B2D5.8090005@openssl.org> Message-ID: Many thanks! I'll chase down the vendor. The device in question is a Canon imagerunner MFP in case anyone was wondering. --OLW -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Monday, January 25, 2016 6:42 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] parse tlsext error in response to client hello On 25/01/16 20:02, Wieck, Owen wrote: > Dear all -- > > Trying to debug a failing TLS negotiation. Is the following (possibly erroneous) "supported point formats extension" the cause of openssl's "parse tlsext" error? Yes. I copied your record below and pushed it through OpenSSL to recreate the error. It is indeed failing on the parsing of the supported point formats extension for precisely the reason you have specified. OpenSSL automatically rejects a zero length point formats extension. Matt > > 00 0b 00 01 00where 000b == the extension type (ec point formats), 0001 == the length (1 byte), and 00 == a zero-length ec point formats list. > > The example in RFC 4492 (section 5.1.2) is: > > A client that can parse only the uncompressed point format (value 0) > includes an extension consisting of the following octets; note that > the first two octets indicate the extension type (Supported Point > Formats Extension): > > 00 0B 00 02 01 00 > > And further, section 5.1 of the same RFC explicitly states "if the Supported Point Formats Extension is indeed sent, it MUST contain the value 0 (uncompressed) as one of the items in the list of point formats." > > For reference, here is the complete "SSL record" of the client hello taken from a packet capture: > > 0000 16 03 01 00 5c 01 00 00 58 03 01 56 a6 52 fa a0 > 0010 7e e3 1d 40 16 89 dd 23 2a 92 dd b5 77 c5 d3 19 > 0020 10 82 07 9a 4f de 54 1e 69 c7 c4 00 00 1e 00 2f > 0030 00 35 00 04 00 05 00 09 00 0a 00 03 00 08 c0 13 > 0040 c0 14 c0 09 c0 0a 00 33 00 39 00 16 01 00 00 11 > 0050 00 0a 00 08 00 06 00 17 00 18 00 19 00 0b 00 01 > 0060 00 > > Many Thanks! > > --OLW > > P.S.: Apologies for the enormous footer that gets tacked on below here. > ---------------------------------------------------------------------- > ---------------------------------------------------------------------- > ------------------ This e-mail and any files transmitted with it are > confidential and intended solely for the use of the individual or > entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. > Please note that any views or opinions presented in this e-mail are > solely those of the author and do not necessarily represent those of > Ricardo (save for reports and other documentation formally approved > and signed for release to the intended recipient). Only Ricardo's > authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. > "Ricardo" means Ricardo Inc. and its affiliated companies. > --------------------------------------------------------------------------------------------------------------------------------------------------------------'. > _______________________________________________ > 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 -------------------------------------------------------------------------------------------------------------------------------------------------------------- This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender immediately and delete this e-mail from your system. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Ricardo (save for reports and other documentation formally approved and signed for release to the intended recipient). Only Ricardo's authorized representatives may enter into legally binding obligations on behalf of Ricardo. Ricardo may monitor outgoing and incoming e-mails and other telecommunications systems. By replying to this e-mail you give consent to such monitoring. The recipient should check e-mail and any attachments for the presence of viruses. Ricardo accepts no liability for any damage caused by any virus transmitted by this e-mail. "Ricardo" means Ricardo Inc. and its affiliated companies. --------------------------------------------------------------------------------------------------------------------------------------------------------------'. From secaficionado at gmail.com Tue Jan 26 18:38:05 2016 From: secaficionado at gmail.com (Sec_Aficiondado) Date: Tue, 26 Jan 2016 13:38:05 -0500 Subject: [openssl-users] A path for feature obsolescence Message-ID: Hello, This occurred to me the other day after reading a thread about the possibility of removing some functions in OpenSSL. No matter how arcane or obscure, any existing feature is bound to have very loyal and probably vocal users. So my idea is along these lines: 1. Announce the potential removal (same as today) and wait for comments. 2. If there are no compelling reasons (the Internet won't catch on fire) and no resources are available to keep this in the code, move the feature to something that will require an explicit configure option (i. e. --with-arcane-function). OpenSSL will build without it from that point on by default. 3. Move the code to a "place" where it can stay untouched and announce that the feature is no longer maintained and not even guaranteed to build. Anyone who needs it is still welcome to include it in their build or tinker with it. I know not everything is modular enough to work well in this scenario but it eases users into other solutions. It also empowers users to take portions of code and modify them according to their needs. If something is truly as important as people claim, someone will fork and update the feature to keep it working with the latest OpenSSL. Most likely, though, everyone will find an alternate solution and move on. A path to obsolescence will be more work for OpenSSL devs at first, but hopefully less drama overall. Just my 2?. From yesprabhu at gmail.com Wed Jan 27 07:17:06 2016 From: yesprabhu at gmail.com (Prabhu S) Date: Wed, 27 Jan 2016 12:47:06 +0530 Subject: [openssl-users] SSL_accept appears to be stuck Message-ID: I have an SSL server, which has, suddenly stopped processing client requests. I see the following error. >> SSL_GET_NEW_SESSION:ssl session id callback failed. Exactly after 15 seconds of calling SSL_accept, the error is seen. The socket is non-blocking. The application was running fine for about 10 days. The problem started suddenly and thereafter, each and every call fails with the above error. And each time it is 15 seconds. The application has 20 worker threads and one epoll thread which handles data and hands it over to worker threads for processing. The epoll thread gets client-hello, notifies the worker thread which calls SSL_accept. Any thoughts on why SSL_accept would not return even if socket is non-blocking. -Prabhu.S -------------- next part -------------- An HTML attachment was scrubbed... URL: From nuliknol at gmail.com Wed Jan 27 13:56:53 2016 From: nuliknol at gmail.com (Nulik Nol) Date: Wed, 27 Jan 2016 07:56:53 -0600 Subject: [openssl-users] SSL version status Message-ID: Hi, I have to implement SSL/TLS in a proprietary web server daemon. I am only familiar with SSL as a user, not as developer, so my question is. What versions of SSL should I support for best compatibility and optimal development time? How much old browsers are out there that still use older SSL versions? Because, Wikipedia says SSL 3.0 was deprecated by Jun 2015 but if I only implement TLS, I may lose many visitors with old browsers, right ? Please advise. TIA Nulik From Imran.Ali at enghouse.com Wed Jan 27 15:24:47 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Wed, 27 Jan 2016 15:24:47 +0000 Subject: [openssl-users] FIPS Certification Message-ID: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> All, Looking at the website http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm There is a new date of 01/25/2016 under Validation against OpenSSL Software Foundation (2473). Does that mean that we now have a FIPS compliant Open SSL again? Regards, Imran -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jan 27 15:44:57 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 27 Jan 2016 10:44:57 -0500 Subject: [openssl-users] FIPS Certification In-Reply-To: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> Message-ID: <56A8E5F9.1090306@openssl.com> On 01/27/2016 10:24 AM, Imran Ali wrote: > All, > > > > Looking at the website > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm > > > > There is a new date of 01/25/2016 under Validation against OpenSSL > Software Foundation (2473). Does that mean that we > now have a FIPS compliant Open SSL again?** You missed my post yesterday: https://mta.openssl.org/pipermail/openssl-users/2016-January/002858.html Note it's not a simple yes/no kind of answer. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Wed Jan 27 15:54:27 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 27 Jan 2016 16:54:27 +0100 Subject: [openssl-users] FIPS Certification In-Reply-To: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> Message-ID: <56A8E833.2010001@wisemo.com> On 27/01/2016 16:24, Imran Ali wrote: > > All, > > Looking at the website > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm > > There is a new date of 01/25/2016 under Validation against OpenSSL > Software Foundation (2473). Does that mean that > we now have a FIPS compliant Open SSL again?** > > ** > According to yesterday's post by Steve Marquess, the platforms listed under validation #1747 and #2473 are OK (for now), but the platforms listed under validation #2398 are still at risk unless #2398 too gets updated before January 31. 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 Imran.Ali at enghouse.com Wed Jan 27 16:34:46 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Wed, 27 Jan 2016 16:34:46 +0000 Subject: [openssl-users] FIPS Certification In-Reply-To: <56A8E833.2010001@wisemo.com> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> Message-ID: <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> I might be asking asking a very basic question so do apologies upfront but I need to have a clear understanding on this. The platforms mentioned under #1747 and #2473 does not contain the latest versions of Operating System e.g. Windows 2012 R2 and Windows 10. Does this have any impact on the certification or these libraries can now be used on any OS. Regards, Imran -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm Sent: 27 January 2016 15:54 To: openssl-users at openssl.org Subject: Re: [openssl-users] FIPS Certification On 27/01/2016 16:24, Imran Ali wrote: > > All, > > Looking at the website > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm > > There is a new date of 01/25/2016 under Validation against OpenSSL > Software Foundation (2473). Does that mean that > we now have a FIPS compliant Open SSL again?** > > ** > According to yesterday's post by Steve Marquess, the platforms listed under validation #1747 and #2473 are OK (for now), but the platforms listed under validation #2398 are still at risk unless #2398 too gets updated before January 31. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jb-openssl at wisemo.com Wed Jan 27 16:54:21 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 27 Jan 2016 17:54:21 +0100 Subject: [openssl-users] FIPS Certification In-Reply-To: <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> Message-ID: <56A8F63D.3040209@wisemo.com> The unfortunate people who are legally required to use FIPS-validated crypto are legally restricted to use *only* the crypto sw/hw on the FIPS validated list and *only* in the specific configurations (OS etc.) listed for each on that list. Everybody else is better off not trying to use FIPS- restricted modes and setups. Those who make software for use by the unfortunate people obviously have to stay within the limits of what they are allowed to use, but only in software for them. On 27/01/2016 17:34, Imran Ali wrote: > I might be asking asking a very basic question so do apologies upfront but I need to have a clear understanding on this. > The platforms mentioned under #1747 and #2473 does not contain the latest versions of Operating System e.g. Windows 2012 R2 and Windows 10. Does this have any impact on the certification or these libraries can now be used on any OS. > Regards, > Imran > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jakob Bohm > Sent: 27 January 2016 15:54 > To: openssl-users at openssl.org > Subject: Re: [openssl-users] FIPS Certification > On 27/01/2016 16:24, Imran Ali wrote: >> All, >> Looking at the website >> http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm >> There is a new date of 01/25/2016 under Validation against OpenSSL >> Software Foundation (2473). Does that mean that >> we now have a FIPS compliant Open SSL again?** >> ** > According to yesterday's post by Steve Marquess, the platforms listed under validation #1747 and > #2473 are OK (for now), but the platforms listed under validation #2398 are still at risk unless > #2398 too gets updated before January 31. > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jan 27 16:55:19 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 27 Jan 2016 11:55:19 -0500 Subject: [openssl-users] FIPS Certification In-Reply-To: <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> Message-ID: <56A8F677.1020901@openssl.com> On 01/27/2016 11:34 AM, Imran Ali wrote: > I might be asking asking a very basic question so do apologies > upfront but I need to have a clear understanding on this. > > The platforms mentioned under #1747 and #2473 does not contain the > latest versions of Operating System e.g. Windows 2012 R2 and Windows > 10. Does this have any impact on the certification or these libraries > can now be used on any OS. That's actually a rather tricky question. First off, the one OpenSSL FIPS module (for a significant overlap of revisions) is covered by three validations; #1747, #2398, and #2473. The set of formally tested platforms (Operational Environments or "OEs") for that module is the union of the platforms listed for each of those three validations. Roughly speaking, your platform of interest matches one of those "OEs" if: 1) The OS name matches to the first two "dot-rev" levels of the revision number. For instance, "AcmeOS 1.2", "AcmeOS 1.2.3", "AcmeOS 1.2.3.4" are all the same OS. 2) ...and the virtualization environment (ESXi, Hyper-V, Xenserver, etc.), if any, matches to two dot-rev levels. 3) ...and the "processor architecture" is the same. Roughly speaking, that means the binary FIPS module built for the specific OE processor runs as-is on our platform, with the same "code path". So for instance all x86 processors without AES-NI are equivalent to one another, as are all x86 processors with AES-NI. Ditto ARMv7 with/without NEON. Lacking such a direct match, you still have "user affirmation" per FIPS 140-2 scripture (section G.5 of the Implementation Guidance document). That basically says that you as a vendor can "affirm" the use of the FIPS module on your platform of interest assuming you can build it per the mandated process (which in particular means *no* source code tweaks). As with everything FIPS 140-2, there are no "bright line" rules here. My usual advice is that you ask your customers what their expectations are. Some customers don't like user affirmation, and some (in DoD for instance) impose additional requirements. On the other hand, some customers are fine with liberal use of user affirmation. As a last resort, if you determine that an important customer requires a specific "OE" match (or if source code tweaks are necessary), you can fund addition of your platform(s) of interest to one of the validations. That is how the list of formally tested platforms has over time grown to more than 120 "OEs", more than any other validated module. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Wed Jan 27 16:59:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jan 2016 16:59:15 +0000 Subject: [openssl-users] FIPS Certification In-Reply-To: <56A8F63D.3040209@wisemo.com> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> <56A8F63D.3040209@wisemo.com> Message-ID: >Everybody else is better off not trying to use FIPS-restricted modes and setups. Strongly agree!! From marquess at openssl.com Wed Jan 27 17:02:56 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 27 Jan 2016 12:02:56 -0500 Subject: [openssl-users] FIPS Certification In-Reply-To: <56A8F63D.3040209@wisemo.com> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> <56A8F63D.3040209@wisemo.com> Message-ID: <56A8F840.7030605@openssl.com> On 01/27/2016 11:54 AM, Jakob Bohm wrote: > The unfortunate people who are legally required to use > FIPS-validated crypto are legally restricted to use > *only* the crypto sw/hw on the FIPS validated list and > *only* in the specific configurations (OS etc.) listed > for each on that list. Well, there is I.G. G.5, a perfectly legitimate though often under-utilized tactic. As noted in my last message it's generally accepted that "on the list" doesn't necessarily mean a literal string match, though even then there will always be a huge number of platforms that are not formally tested OEs. > Everybody else is better off not trying to use FIPS- > restricted modes and setups. > > ... This is a good point worth repeating: use FIPS 140-2 validated cryptography only because you must, not because you think it is somehow "better". It isn't; the validated crypto is necessarily inferior to its unvalidated equivalent (e.g. stock OpenSSL in the case of the OpenSSL FIPS Object Module) by every real world metric (security, performance, maintainability). -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Imran.Ali at enghouse.com Wed Jan 27 18:19:36 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Wed, 27 Jan 2016 18:19:36 +0000 Subject: [openssl-users] FIPS Certification In-Reply-To: <56A8F677.1020901@openssl.com> References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> <56A8F677.1020901@openssl.com> Message-ID: Thanks Steve - for the explanation. We are using these libraries for Windows 2012 R2 which is 6.3 and certificate #1747 mentions Windows 7 which is 6.1. I am hoping based on below that we are OK to use it under Windows 2012 R2 https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx Regards, Imran -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess Sent: 27 January 2016 16:55 To: openssl-users at openssl.org Subject: Re: [openssl-users] FIPS Certification On 01/27/2016 11:34 AM, Imran Ali wrote: > I might be asking asking a very basic question so do apologies upfront > but I need to have a clear understanding on this. > > The platforms mentioned under #1747 and #2473 does not contain the > latest versions of Operating System e.g. Windows 2012 R2 and Windows > 10. Does this have any impact on the certification or these libraries > can now be used on any OS. That's actually a rather tricky question. First off, the one OpenSSL FIPS module (for a significant overlap of revisions) is covered by three validations; #1747, #2398, and #2473. The set of formally tested platforms (Operational Environments or "OEs") for that module is the union of the platforms listed for each of those three validations. Roughly speaking, your platform of interest matches one of those "OEs" if: 1) The OS name matches to the first two "dot-rev" levels of the revision number. For instance, "AcmeOS 1.2", "AcmeOS 1.2.3", "AcmeOS 1.2.3.4" are all the same OS. 2) ...and the virtualization environment (ESXi, Hyper-V, Xenserver, etc.), if any, matches to two dot-rev levels. 3) ...and the "processor architecture" is the same. Roughly speaking, that means the binary FIPS module built for the specific OE processor runs as-is on our platform, with the same "code path". So for instance all x86 processors without AES-NI are equivalent to one another, as are all x86 processors with AES-NI. Ditto ARMv7 with/without NEON. Lacking such a direct match, you still have "user affirmation" per FIPS 140-2 scripture (section G.5 of the Implementation Guidance document). That basically says that you as a vendor can "affirm" the use of the FIPS module on your platform of interest assuming you can build it per the mandated process (which in particular means *no* source code tweaks). As with everything FIPS 140-2, there are no "bright line" rules here. My usual advice is that you ask your customers what their expectations are. Some customers don't like user affirmation, and some (in DoD for instance) impose additional requirements. On the other hand, some customers are fine with liberal use of user affirmation. As a last resort, if you determine that an important customer requires a specific "OE" match (or if source code tweaks are necessary), you can fund addition of your platform(s) of interest to one of the validations. That is how the list of formally tested platforms has over time grown to more than 120 "OEs", more than any other validated module. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From marquess at openssl.com Wed Jan 27 19:31:55 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 27 Jan 2016 14:31:55 -0500 Subject: [openssl-users] FIPS Certification In-Reply-To: References: <9afe9f3623dc4dc48f13d0d3b80f3931@UK-MAIL-001.edge.local> <56A8E833.2010001@wisemo.com> <760295c23ed44fd594f27d5e2aec59a8@UK-MAIL-001.edge.local> <56A8F677.1020901@openssl.com> Message-ID: <56A91B2B.8070705@openssl.com> On 01/27/2016 01:19 PM, Imran Ali wrote: > Thanks Steve - for the explanation. > > We are using these libraries for Windows 2012 R2 which is 6.3 and certificate #1747 mentions Windows 7 which is 6.1. I am hoping based on below that we are OK to use it under Windows 2012 R2 > > https://msdn.microsoft.com/en-gb/library/windows/desktop/ms724832(v=vs.85).aspx "Windows 2012 R2" and "Windows 7" are different OEs in FIPS-land. The CMVP goes by nominal OS branding and doesn't pay any attention to the actual underlying software. For instance, if you roll your own "white box" system from a Linux kernel then your OS is (say) "Linux 3.10". When you upgrade that kernel to 3.13, then you no longer have a match with the "Linux 3.10" OE. But, if you instead used an "Ubuntu 14.04" system and the OS vendor (Canonical) upgraded the kernel from 3.10 to 3.13, then you'd still have a match because it is still called "Ubuntu 14.04". So what to a software engineer is superficial branding becomes significant in FIPS-land. Note for that reason many vendors with "white box" systems choose to give their customized OS a distinctive brand name (e.g. "AcmeOS 1.0") so that the same formally tested OE will cover multiple Linux kernels under that OS brand name and unchanged OS version number. It would be a bit of a stretch to re-brand Microsoft Windows, though. Your options are to leverage I.G. G.5 "user affirmation", or to sponsor addition of a Windows 2012 R2 platform. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From openssl-users at dukhovni.org Wed Jan 27 19:52:06 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 27 Jan 2016 14:52:06 -0500 Subject: [openssl-users] SSL version status In-Reply-To: References: Message-ID: <6F9805F1-5EB1-477A-B51B-20F0113FA9C5@dukhovni.org> > On Jan 27, 2016, at 8:56 AM, Nulik Nol wrote: > > How much old browsers are out there that > still use older SSL versions? Because, Wikipedia says SSL 3.0 was > deprecated by Jun 2015 but if I only implement TLS, I may lose many > visitors with old browsers, right ? You do not have to enable SSLv3. It is use is exceedingly rare these days. You will not lose interoperability with a non-negligible number of clients. Make sure SSLv2 and SSLv3 are both disabled. See https://tools.ietf.org/html/rfc7525 for guidelines. -- Viktor. From nuliknol at gmail.com Wed Jan 27 21:00:32 2016 From: nuliknol at gmail.com (Nulik Nol) Date: Wed, 27 Jan 2016 15:00:32 -0600 Subject: [openssl-users] SSL version status In-Reply-To: <6F9805F1-5EB1-477A-B51B-20F0113FA9C5@dukhovni.org> References: <6F9805F1-5EB1-477A-B51B-20F0113FA9C5@dukhovni.org> Message-ID: Thanks for the link! This says it all: " o Implementations MUST NOT negotiate SSL version 2. Rationale: Today, SSLv2 is considered insecure [RFC6176]. o Implementations MUST NOT negotiate SSL version 3. Rationale: SSLv3 [RFC6101] was an improvement over SSLv2 and plugged some significant security holes but did not support strong cipher suites. " On Wed, Jan 27, 2016 at 1:52 PM, Viktor Dukhovni wrote: > >> On Jan 27, 2016, at 8:56 AM, Nulik Nol wrote: >> >> How much old browsers are out there that >> still use older SSL versions? Because, Wikipedia says SSL 3.0 was >> deprecated by Jun 2015 but if I only implement TLS, I may lose many >> visitors with old browsers, right ? > > You do not have to enable SSLv3. It is use is exceedingly rare > these days. You will not lose interoperability with a non-negligible > number of clients. Make sure SSLv2 and SSLv3 are both disabled. > > See https://tools.ietf.org/html/rfc7525 for guidelines. > > -- > Viktor. > > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From cloud.force858 at gmail.com Wed Jan 27 22:33:23 2016 From: cloud.force858 at gmail.com (cloud force) Date: Wed, 27 Jan 2016 14:33:23 -0800 Subject: [openssl-users] OpenSSL FIPS modules and APIs compatibility Message-ID: Hi everyone, Does OpenSSL FIPS modules keep all the OpenSSL APIs intact? i.e. If we use the OpenSSL FIPS modules, we don't need to make any API invocation changes on our applications side (in addition to invoking the FIPS_mode_set API). Is that correct? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Jan 27 22:54:27 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 27 Jan 2016 17:54:27 -0500 Subject: [openssl-users] OpenSSL FIPS modules and APIs compatibility In-Reply-To: References: Message-ID: <56A94AA3.20607@openssl.com> On 01/27/2016 05:33 PM, cloud force wrote: > Hi everyone, > > Does OpenSSL FIPS modules keep all the OpenSSL APIs intact? > i.e. If we use the OpenSSL FIPS modules, we don't need to make any API > invocation changes on our applications side (in addition to invoking the > FIPS_mode_set API). Is that correct? OpenSSL and the OpenSSL FIPS module (technically the "OpenSSL FIPS Object Module v2.0") are separate and distinct software products. The OpenSSL FIPS module doesn't replace OpenSSL. The "FIPS capable" OpenSSL (OpenSSL built with the "fips" option in the presence of the FIPS module) will behave just like stock OpenSSL until the FIPS mode of operation is enabled. At that point many cryptographic operations are automagically disabled; but that's not the same thing as changing the API. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Wed Jan 27 23:40:22 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 27 Jan 2016 23:40:22 +0000 Subject: [openssl-users] OpenSSL FIPS modules and APIs compatibility In-Reply-To: References: Message-ID: > Does OpenSSL FIPS modules keep all the OpenSSL APIs intact? No. For example, only the EVP interface to crypto. From cloud.force858 at gmail.com Thu Jan 28 00:21:52 2016 From: cloud.force858 at gmail.com (cloud force) Date: Wed, 27 Jan 2016 16:21:52 -0800 Subject: [openssl-users] SSL keys and certificates for FIPS and non-FIPS mode Message-ID: Hi everyone, If I have a HTTPS client and server both using OpenSSL with FIPS modules, and supporting both FIPS and non-FIPS mode, will the SSL server and client keys and certificates need to be changed between operating on FIPS and non-FIPS mode? Thanks, Rich -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Thu Jan 28 11:02:11 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Thu, 28 Jan 2016 09:02:11 -0200 Subject: [openssl-users] Acessing a proxy with OpenSSL Message-ID: Hello, I'm using this example to make a SSL connection: http://fm4dd.com/openssl/sslconnect.htm.Now I want to also acess a HTTPS proxy. Is there a way to acess a HTTPS proxy with the OpenSSL library? Any tip will be very helpful,Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at convey.de Thu Jan 28 11:47:48 2016 From: ted at convey.de (=?UTF-8?Q?Bernhard_Fr=c3=b6hlich?=) Date: Thu, 28 Jan 2016 12:47:48 +0100 Subject: [openssl-users] Acessing a proxy with OpenSSL In-Reply-To: References: Message-ID: <56A9FFE4.1060205@convey.de> Am 28.01.2016 um 12:02 schrieb Marcos Bontempo: > Hello, > > I'm using this example to make a SSL connection: > http://fm4dd.com/openssl/sslconnect.htm. > Now I want to also acess a HTTPS proxy. Is there a way to acess a > HTTPS proxy with the OpenSSL library? > > Any tip will be very helpful, > Thanks. See http://wiki.squid-cache.org/Features/HTTPS and http://tools.ietf.org/rfc/rfc2817. AFAIK OpenSSL does not provide specific support for SSL via proxy, but you can set up a SSL connection using the CONNECT request to the proxy. Using a proxy for SSL connection does not make sense if you want to take advantage of a proxy's caching feature, since these CONNECT requests cannot be cached. This is by design. Using a proxy for SSL can be useful if you want to avoid NAT, or want to log, or filter, the connection targets. Hope this helps, Ted ;) -- PGP Public Key Information Key ID = 7AFB8D26 Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcosbontempo at hotmail.com Thu Jan 28 12:55:49 2016 From: marcosbontempo at hotmail.com (Marcos Bontempo) Date: Thu, 28 Jan 2016 10:55:49 -0200 Subject: [openssl-users] Acessing a proxy with OpenSSL In-Reply-To: <56A9FFE4.1060205@convey.de> References: , <56A9FFE4.1060205@convey.de> Message-ID: Thanks for your answer! Have you got a C example using the CONNECT request to the proxy?In this case I want to avoid NAT. It helped a lot!Thanks. To: openssl-users at openssl.org From: ted at convey.de Date: Thu, 28 Jan 2016 12:47:48 +0100 Subject: Re: [openssl-users] Acessing a proxy with OpenSSL Am 28.01.2016 um 12:02 schrieb Marcos Bontempo: Hello, I'm using this example to make a SSL connection: http://fm4dd.com/openssl/sslconnect.htm. Now I want to also acess a HTTPS proxy. Is there a way to acess a HTTPS proxy with the OpenSSL library? Any tip will be very helpful, Thanks. See http://wiki.squid-cache.org/Features/HTTPS and http://tools.ietf.org/rfc/rfc2817. AFAIK OpenSSL does not provide specific support for SSL via proxy, but you can set up a SSL connection using the CONNECT request to the proxy. Using a proxy for SSL connection does not make sense if you want to take advantage of a proxy's caching feature, since these CONNECT requests cannot be cached. This is by design. Using a proxy for SSL can be useful if you want to avoid NAT, or want to log, or filter, the connection targets. Hope this helps, Ted ;) -- PGP Public Key Information Key ID = 7AFB8D26 Key fingerprint = 31B0 E029 BCF9 6605 DAC1 B2E1 0CC8 70F4 7AFB 8D26 _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Jan 28 15:03:27 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:03:27 +0000 Subject: [openssl-users] OpenSSL version 1.0.1r published Message-ID: <20160128150327.GA23362@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1r released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1r of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1r is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1r.tar.gz Size: 4547786 SHA1 checksum: d2cfa980ef4548da6079fa1e51fe1fb2e5a53e99 SHA256 checksum: 784bd8d355ed01ce98b812f873f8b2313da61df7c7b5677fcf2e57b0863a3346 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.1r.tar.gz openssl sha256 openssl-1.0.1r.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqiPkAAoJENnE0m0OYESRcmgIAJidxSVl5K1TE23gWxVrj75z tYY1YGGi+DjyYMJCxuXaKKZ/Yidhj8w3d+b0HnUs8r2YJNRjDQmh+BvGtA4FIgcq WQlypzUL/hmyicdvhTz/Y0r3O0DNOpYFIrjkWGkJFiYYm2bZIwDqkx4UAImOM3r1 qh0SfUuILDsHhwsi/EMexmTNKOuqcXWc/UVy2a5q074Va7BRJnUvAApD/jBpZgdh fIWOlVs1BnVE87wPddyXHK6UlyUd+5Zuc91ytvxYQayqx9D/t0AZ73isfzoE1jj9 dDS9H2+SJyN+WwJI1UUxZ8QthmPbnWwKpR733xtMUZ5r0M2e+V92eOgTNfcVvEI= =AYwY -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 28 15:03:37 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:03:37 +0000 Subject: [openssl-users] OpenSSL version 1.0.2f published Message-ID: <20160128150337.GA23585@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2f released =============================== OpenSSL - The Open Source toolkit for SSL/TLS http://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2f of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: http://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2f is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under http://www.openssl.org/source/mirror.html): * http://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2f.tar.gz Size: 5258384 SHA1 checksum: 2047c592a6e5a42bd37970bdb4a931428110a927 SHA256 checksum: 932b4ee4def2b434f85435d9e3e19ca8ba99ce9a065a61524b429a9d5e9b2e9c The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2f.tar.gz openssl sha256 openssl-1.0.2f.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqh5GAAoJENnE0m0OYESRsd8IALq/rtH2LTBSva5EahcoHWbp wa/bcqnk84tWhBtFdsPY6bc842I7KUuajdlb/O/tKket/7XDBtO8Ud+xwajCDjUR 0Ui56bWUD6KzDCKOuarTQ2zSdrnbBvO20x4WZlpNQ67ZsEQ3DuSouTetFGRmNgfb Te2BNteBZ//OGsqfvzuegbMbAuaePwwOO8XurNqwm4O1F1dphz7BuBx9IiCsHypa ISmmx27WzGYUS30nQuseFTHj8wd++zaJVRX8xM/alqoDdOT6qkavqpVku8RhwKuZ gnmeIXPRPzktYagQ1w+Py5ZGEIEZhvJpf/UQktuGw6xJ+D8PXC3D3i1Rth9UHIA= =ITZs -----END PGP SIGNATURE----- From openssl at openssl.org Thu Jan 28 15:05:47 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 28 Jan 2016 15:05:47 +0000 Subject: [openssl-users] OpenSSL Security Advisory Message-ID: <20160128150547.GA26799@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [28th Jan 2016] ========================================= NOTE: SUPPORT FOR VERSION 1.0.1 WILL BE ENDING ON 31ST DECEMBER 2016. NO SECURITY FIXES WILL BE PROVIDED AFTER THAT DATE. UNTIL THAT TIME SECURITY FIXES ONLY ARE BEING APPLIED. DH small subgroups (CVE-2016-0701) ================================== Severity: High Historically OpenSSL usually only ever generated DH parameters based on "safe" primes. More recently (in version 1.0.2) support was provided for generating X9.42 style parameter files such as those required for RFC 5114 support. The primes used in such files may not be "safe". Where an application is using DH configured with parameters based on primes that are not "safe" then an attacker could use this fact to find a peer's private DH exponent. This attack requires that the attacker complete multiple handshakes in which the peer uses the same private DH exponent. For example this could be used to discover a TLS server's private DH exponent if it's reusing the private DH exponent or it's using a static DH ciphersuite. OpenSSL provides the option SSL_OP_SINGLE_DH_USE for ephemeral DH (DHE) in TLS. It is not on by default. If the option is not set then the server reuses the same private DH exponent for the life of the server process and would be vulnerable to this attack. It is believed that many popular applications do set this option and would therefore not be at risk. OpenSSL before 1.0.2f will reuse the key if: - - SSL_CTX_set_tmp_dh()/SSL_set_tmp_dh() is used and SSL_OP_SINGLE_DH_USE is not set. - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used, and both the parameters and the key are set and SSL_OP_SINGLE_DH_USE is not used. This is an undocumted feature and parameter files don't contain the key. - - Static DH ciphersuites are used. The key is part of the certificate and so it will always reuse it. This is only supported in 1.0.2. It will not reuse the key for DHE ciphers suites if: - - SSL_OP_SINGLE_DH_USE is set - - SSL_CTX_set_tmp_dh_callback()/SSL_set_tmp_dh_callback() is used and the callback does not provide the key, only the parameters. The callback is almost always used like this. Non-safe primes are generated by OpenSSL when using: - - genpkey with the dh_rfc5114 option. This will write an X9.42 style file including the prime-order subgroup size "q". This is supported since the 1.0.2 version. Older versions can't read files generated in this way. - - dhparam with the -dsaparam option. This has always been documented as requiring the single use. The fix for this issue adds an additional check where a "q" parameter is available (as is the case in X9.42 based parameters). This detects the only known attack, and is the only possible defense for static DH ciphersuites. This could have some performance impact. Additionally the SSL_OP_SINGLE_DH_USE option has been switched on by default and cannot be disabled. This could have some performance impact. This issue affects OpenSSL version 1.0.2. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 is not affected by this CVE because it does not support X9.42 based parameters. It is possible to generate parameters using non "safe" primes, but this option has always been documented as requiring single use and is not the default or believed to be common. However, as a precaution, the SSL_OP_SINGLE_DH_USE change has also been backported to 1.0.1r. This issue was reported to OpenSSL on 12 January 2016 by Antonio Sanso (Adobe). The fix was developed by Matt Caswell of the OpenSSL development team (incorporating some work originally written by Stephen Henson of the OpenSSL core team). SSLv2 doesn't block disabled ciphers (CVE-2015-3197) ==================================================== Severity: Low A malicious client can negotiate SSLv2 ciphers that have been disabled on the server and complete SSLv2 handshakes even if all SSLv2 ciphers have been disabled, provided that the SSLv2 protocol was not also disabled via SSL_OP_NO_SSLv2. This issue affects OpenSSL versions 1.0.2 and 1.0.1. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 users should upgrade to 1.0.1r This issue was reported to OpenSSL on 26th December 2015 by Nimrod Aviram and Sebastian Schinzel. The fix was developed by Nimrod Aviram with further development by Viktor Dukhovni of the OpenSSL development team. An update on DHE man-in-the-middle protection (Logjam) ==================================================================== A previously published vulnerability in the TLS protocol allows a man-in-the-middle attacker to downgrade vulnerable TLS connections using ephemeral Diffie-Hellman key exchange to 512-bit export-grade cryptography. This vulnerability is known as Logjam (CVE-2015-4000). OpenSSL added Logjam mitigation for TLS clients by rejecting handshakes with DH parameters shorter than 768 bits in releases 1.0.2b and 1.0.1n. This limit has been increased to 1024 bits in this release, to offer stronger cryptographic assurance for all TLS connections using ephemeral Diffie-Hellman key exchange. OpenSSL 1.0.2 users should upgrade to 1.0.2f OpenSSL 1.0.1 users should upgrade to 1.0.1r The fix was developed by Kurt Roeckx of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160128.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJWqiT1AAoJENnE0m0OYESR07gIAJ65FdP2oFR9pspmLh+iZ978 Q+1R8vShqUjkpE14gUOHaidgsU8l7HoR7v3mWFtv+XqBUp94ISOFeyt4B4jlDsHE SSgO60zlnYha0KaOeRv/aH1quiWhx8bxNZ1HJbbwlxPclqmEplhXqoSEbVvOZKFZ VPu8gmJg3fzdQpQT0eAZ/5ez6SMvIM1FO47FlqtstWgHSs0iq1scIr1LKNmH3uMZ tmNmq5U/tTX/51eKYqFIrWXIeyHSiOTXRBUjnw4ybCiobklLH1qiEApJW6iPkOob 9WthtiyBVBxCpYpF8h4mQc3h77J/q4rLcL/b56sqMsHTV4ULhbN2VIUnzcuzIUI= =Dfuh -----END PGP SIGNATURE----- From karl at denninger.net Thu Jan 28 16:49:54 2016 From: karl at denninger.net (Karl Denninger) Date: Thu, 28 Jan 2016 10:49:54 -0600 Subject: [openssl-users] SSL version status In-Reply-To: References: Message-ID: <56AA46B2.9010108@denninger.net> On 1/27/2016 07:56, Nulik Nol wrote: > Hi, > I have to implement SSL/TLS in a proprietary web server daemon. I am > only familiar with SSL as a user, not as developer, so my question is. > What versions of SSL should I support for best compatibility and > optimal development time? How much old browsers are out there that > still use older SSL versions? Because, Wikipedia says SSL 3.0 was > deprecated by Jun 2015 but if I only implement TLS, I may lose many > visitors with old browsers, right ? > > Please advise. > TIA > Nulik Some, to use a single word. Not many though. The notable problems come from very old mobile handsets (e.g. Froyo and similar Android). I have about 3% of my users on systems I manage still hitting them from XP machines as an example of "old", which are potential issues in this regard, BUT TLS1.0 is supportable by XP -- so shutting off SSL3 won't kill those users. There are a smattering of machines that still hit my sites running Windows 98, however (well under 1%), believe it or not. Be aware that the OpenSSL defaults when you define a server context are inappropriate for most purposes and thus you have to do a bit more work when programming a server to get a reasonably-secure environment than when connecting using OpenSSL as a client. Specifically, be aware of issues surrounding client renegotiation requests (which can turn into a denial-of-service problem) and how you handle Diffie-Hellman (if you choose to load said keys) along with the ECDH cipher set. For a server you also have to consider whether you're going to multiplex or multithread as OpenSSL requires some additional attention at the programming level (for locking) in a threaded application. -- Karl Denninger karl at denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2996 bytes Desc: S/MIME Cryptographic Signature URL: From Michal.Trojnara at stunnel.org Thu Jan 28 16:57:00 2016 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Thu, 28 Jan 2016 17:57:00 +0100 Subject: [openssl-users] stunnel 5.30 released Message-ID: <56AA485C.6070806@stunnel.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Dear Users, I have released version 5.30 of stunnel. The ChangeLog entry: Version 5.30, 2016.01.28, urgency: HIGH * Security bugfixes - OpenSSL DLLs updated to version 1.0.2f. https://www.openssl.org/news/secadv_20160128.txt * New features - Improved compatibility with the current OpenSSL 1.1.0-dev tree. - Added OpenSSL autodetection for the recent versions of Xcode. * Bugfixes - Fixed references to /etc removed from stunnel.init.in. - Stopped even trying -fstack-protector on unsupported platforms (thx to Rob Lockhart). Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 7d6eb389f6a1954b3bcf6c71d4ae3c5f9dde1990dd0b9e0cb1c7caf138d60570 stunnel-5.30.tar.gz cf13a881d2f19b8db5e70fafac6e5dad31f041ee6b9c0316dbd8f9f425c16418 stunnel-5.30-installer.exe 102c54d0f58937fc3c3de2a6fb6295622222e48eae200123d6357889defa45c1 stunnel-5.30-android.zip Best regards, Mike -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWqkhcAAoJEC78f/DUFuAUbZoP/iH+4dndQdh5SSpSH8NR2dUf Nx10nPHP9WXZIVF9C0pISDGpRcpRi6k+4p3NU8SblGsTRm78zCpWYmeEso46Q9ve IHCrUrmQntygZ5xL5Igij9rvN8s6VeucxiMX1pZBJWAvtV5Mj2XDWFEgGiUc+sPC leCJIhj+2G6hNZJzl5whptW48+smqQvh8LC5jEtFaAUp5C0ptjrmz/vebEDlVKOs qZOZMwLmNojP3WGWWrt5fkBCLZXKvkDipgI4ln3aro/fCYQZ5fikGYbW7dTOvNCT lFmCS2vXg1hqFNM3qBWp8HKqiyYR9nVYNesW5vQW/INp6wRSqul9QSJQwsVge37N wbl19KLZL0bqXYV5a5OTovi5X1X+wRbKkcGE8yozptifV4n1AgZL4rbLkKqFu/BF zHHUmOi1m5SkRAoN8pmaTmNFe/Zp72o6unN1kfrXyvJj6NCiDKXMqTmYw4bfoSBM UUg6uKtc7k7XGPvgca/HrdEu8DJPQIWcRqNVqQ5AxVnub9gBFsJC15XdgutHJK97 XuLhZhHBdm10Frf2u/nk2Q2GpPdHAPK67QgERzO2Nr35KGOxwMXahyxKK0jI5ue5 bekTLYjZYUKS94Lt/uUgxaVmwG0x1qjurfhdXoUemuYKUAzv2tZlNF1NiGme3feP WqLyTnuGhYIxEbltnFif =gYXk -----END PGP SIGNATURE----- From security.veteran at gmail.com Fri Jan 29 00:11:28 2016 From: security.veteran at gmail.com (security veteran) Date: Thu, 28 Jan 2016 16:11:28 -0800 Subject: [openssl-users] How to enable FIPS mode system-wide for the FIPS capable OpenSSL? Message-ID: Hi All: Is there a way to enable FIPS mode globally, instead of having to explicitly invoke the FIPS_mode_set() API from each application, for enabling the FIPS mode? The reason I ask is, it will be much easier to enable FIPS mode if there're many applications which rely on OpenSSL for crypto work, and making changes to all of these applications to allow then invoking FIPS_mode_set() will be too much of the work. Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sugu.ece28 at gmail.com Fri Jan 29 06:58:26 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Thu, 28 Jan 2016 23:58:26 -0700 (MST) Subject: [openssl-users] Problem in RSA encrypt and Decrypt using EVP Message-ID: <1454050706450-62759.post@n7.nabble.com> Hi, I have problem in RSA encrypt and decrypt using EVP methods. My below program is some times working fine and some times it fails to decrypt the message. That means when i executing the below code 2 times working fine 3rd time it fails to decrypt. Please point out the error. Code: #include #include #include #include #include #include EVP_PKEY *pkey = EVP_PKEY_new(); EVP_PKEY_CTX *ctx2; unsigned char *out1; size_t outlen1; EVP_PKEY_CTX *ctx; ENGINE *eng; RSA *rsakey =RSA_new(); bool GenerateRsaKeyPair() { BIGNUM *bnexp = NULL; unsigned long exp = RSA_F4; bnexp = BN_new(); if(!BN_set_word(bnexp,exp)) { std::cout <<"Failed to set exponent word in BIO."< References: <1454050706450-62759.post@n7.nabble.com> Message-ID: <56AB3373.6050102@thincast.com> Hi, I'm currently experimenting with OpenSSL 1.1 android build with shared libraries. Since android is not (properly) supporting shared library versioning, is there a easy way to turn versioning off? From marquess at openssl.com Fri Jan 29 14:31:00 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 29 Jan 2016 09:31:00 -0500 Subject: [openssl-users] How to enable FIPS mode system-wide for the FIPS capable OpenSSL? In-Reply-To: References: Message-ID: <56AB77A4.6020308@openssl.com> On 01/28/2016 07:11 PM, security veteran wrote: > Hi All: > > Is there a way to enable FIPS mode globally, instead of having to > explicitly invoke the FIPS_mode_set() API from each application, for > enabling the FIPS mode? > > ... Kinda-sorta, via OPENSSL_config() and openssl.conf. See the FIPS user guide, https://openssl.org/docs/fips/UserGuide-2.0.pdf, section 5.2. -Steve M. -- Steve Marquess OpenSSL Software Foundation 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From BYan at visa.com Fri Jan 29 18:40:45 2016 From: BYan at visa.com (Yan, Bob) Date: Fri, 29 Jan 2016 18:40:45 +0000 Subject: [openssl-users] Certificate verification failure Message-ID: Dear Sir/Madam, I have an application which acting as SSL server. When the application loads the root and intermediate CA files from a CA path, the handshake between my application and openssl client was failed at the point when my application was authenticating the client's certificate. But when I bound the root CA and intermediate CA into a single pem file and reload it from my application, the handshake is successful. Could anybody help me resolve this issue? Below is the sample of my application code for loading the CA certificates: if (SSL_CTX_load_verify_locations(ctx, caFile, caPath) != 1) { exit; } if (SSL_CTX_set_default_verify_paths(ctx) != 1) { exit; } if (SSL_CTX_use_certificate_chain_file(ctx, certFile) != 1) { exit; } if (SSL_CTX_use_PrivateKey_file(ctx, keyFile, SSL_FILETYPE_PEM) != 1) { exit; } SSL_CTX_set_verify_depth(ctx, chainDepths); SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER | SSL_VERIFY_FAIL_IF_NO_PEER_CERT, callback); SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2); Thank you very much! Bob -------------- next part -------------- An HTML attachment was scrubbed... URL: From axel.luttgens at skynet.be Sat Jan 30 16:34:18 2016 From: axel.luttgens at skynet.be (Axel Luttgens) Date: Sat, 30 Jan 2016 17:34:18 +0100 Subject: [openssl-users] Configure with both options "no-comp" and "zlib" Message-ID: <1DD2171D-7A83-4BF2-97B2-ECE562F44D47@skynet.be> Hello, According to this thread: http://openssl.6102.n7.nabble.com/config-and-no-zlib-td42924.html it would make sense to execute Configure with both "no-comp" and "zlib" options. If I understand correctly, this would avoid to have the openssl library to use compression for SSL/TLS by default while still having compression available for command line tools. However, using both options leads to a failure here (please see details for openssl-1.0.2f at the end of this message). So, first of all, does it really make sense to configure with both options? Or am I just plain wrong with my understanding of, for example, the INSTALL file, the comments at the beginning of Configure, the reasonings in above thread? Otherwise, perhaps am I missing an important step in my configure/build attempts? TIA, Axel Configuring for darwin64-x86_64-cc no-comp [option] OPENSSL_NO_COMP (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-libunbound [experimental] OPENSSL_NO_LIBUNBOUND (skip dir) no-md2 [default] OPENSSL_NO_MD2 (skip dir) no-rc5 [default] OPENSSL_NO_RC5 (skip dir) no-rfc3779 [default] OPENSSL_NO_RFC3779 (skip dir) no-sctp [default] OPENSSL_NO_SCTP (skip dir) no-shared [default] no-ssl-trace [default] OPENSSL_NO_SSL_TRACE (skip dir) no-ssl2 [option] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-zlib-dynamic [default] [?] cc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o cms_cd.o cms_cd.c cms_cd.c:131:20: warning: implicit declaration of function 'BIO_f_zlib' is invalid in C99 [-Wimplicit-function-declaration] return BIO_new(BIO_f_zlib()); ^ [?] cc -DMONOLITH -I.. -I../include -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o enc.o enc.c enc.c:468:28: warning: implicit declaration of function 'BIO_f_zlib' is invalid in C99 [-Wimplicit-function-declaration] if ((bzl = BIO_new(BIO_f_zlib())) == NULL) ^ [?] Undefined symbols for architecture x86_64: "_BIO_f_zlib", referenced from: _enc_main in enc.o _cms_CompressedData_init_bio in libcrypto.a(cms_cd.o) ld: symbol(s) not found for architecture x86_64 [?] And indeed, file openssl.conf is built with: # define OPENSSL_NO_COMP Moreover, both files cms_cd.c and enc.c have: #ifndef OPENSSL_NO_COMP # include #endif so that the definition of BIO_f_zlib() can?t be found. And it appears that "comp" is removed from the SDIRS variable. Playing very dangerously, that is: manually adding comp to SDIRS replacing #ifndef OPENSSL_NO_COMP with #if defined ZLIB || not defined OPENSSL_NO_COMP it seems that make succeeds. Dangerously, because I just don?t know what I am doing, what side-effects I am very likely introducing. ;-) From scott_n at xypro.com Thu Jan 7 17:56:43 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 07 Jan 2016 17:56:43 -0000 Subject: [openssl-users] Trouble compiling in version 0.9.8h In-Reply-To: References: Message-ID: 0.9.8h?. REALLY???? The latest is 0.9.8zh. And on top of that 0.9.8 got EOL?ed as of the beginning of the year. Can you update to 1.0.1? (Latest is 1.0.1q). From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Luiz Laranjeira Sent: Sunday, December 27, 2015 7:02 AM To: openssl-users at openssl.org Subject: [openssl-users] Trouble compiling in version 0.9.8h I am getting the errors below. Anyone can help? Line 282 of file pkcs7.h = DECLARE_ASN1_FUNCTIONS(PKCS7_ISSUER_AND_SERIAL) 1>------ Build started: Project: OpenSSL, Configuration: Debug Win32 ------ 1> tls_srp.c 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2055: expected formal parameter list, not a type list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'd2i_PKCS7_ISSUER_AND_SERIAL' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'i2d_PKCS7_ISSUER_AND_SERIAL' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(282): error C2085: 'PKCS7_ISSUER_AND_SERIAL_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(286): error C2085: 'PKCS7_ISSUER_AND_SERIAL_digest' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(288): error C2085: 'd2i_PKCS7_fp' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\...\include\openssl\pkcs7.h(289): error C2085: 'i2d_PKCS7_fp' : not in formal parameter list ...... 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(291): error C2085: 'PKCS7_dup' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(292): error C2085: 'd2i_PKCS7_bio' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(293): error C2085: 'i2d_PKCS7_bio' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'd2i_PKCS7_SIGNER_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'i2d_PKCS7_SIGNER_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(296): error C2085: 'PKCS7_SIGNER_INFO_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'd2i_PKCS7_RECIP_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'i2d_PKCS7_RECIP_INFO' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(297): error C2085: 'PKCS7_RECIP_INFO_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'd2i_PKCS7_SIGNED' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'i2d_PKCS7_SIGNED' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(298): error C2085: 'PKCS7_SIGNED_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'd2i_PKCS7_ENC_CONTENT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'i2d_PKCS7_ENC_CONTENT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(299): error C2085: 'PKCS7_ENC_CONTENT_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'd2i_PKCS7_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'i2d_PKCS7_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(300): error C2085: 'PKCS7_ENVELOPE_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'd2i_PKCS7_SIGN_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'i2d_PKCS7_SIGN_ENVELOPE' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(301): error C2085: 'PKCS7_SIGN_ENVELOPE_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'd2i_PKCS7_DIGEST' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'i2d_PKCS7_DIGEST' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(302): error C2085: 'PKCS7_DIGEST_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'd2i_PKCS7_ENCRYPT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'i2d_PKCS7_ENCRYPT' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(303): error C2085: 'PKCS7_ENCRYPT_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_free' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'd2i_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'i2d_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(304): error C2085: 'PKCS7_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(306): error C2085: 'PKCS7_ATTR_SIGN_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(307): error C2085: 'PKCS7_ATTR_VERIFY_it' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(309): error C2085: 'i2d_PKCS7_NDEF' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(311): error C2085: 'PKCS7_ctrl' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(313): error C2085: 'PKCS7_set_type' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(314): error C2085: 'PKCS7_set0_type_other' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(315): error C2085: 'PKCS7_set_content' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(317): error C2085: 'PKCS7_SIGNER_INFO_set' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(318): error C2085: 'PKCS7_add_signer' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(319): error C2085: 'PKCS7_add_certificate' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(320): error C2085: 'PKCS7_add_crl' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(321): error C2085: 'PKCS7_content_new' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(323): error C2085: 'PKCS7_dataVerify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(325): error C2085: 'PKCS7_signatureVerify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(327): error C2085: 'PKCS7_dataInit' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(328): error C2085: 'PKCS7_dataFinal' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(329): error C2085: 'PKCS7_dataDecode' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(333): error C2085: 'PKCS7_add_signature' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(334): error C2085: 'PKCS7_cert_from_signer_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(335): error C2085: 'PKCS7_set_digest' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(336): error C2085: 'PKCS7_get_signer_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(338): error C2085: 'PKCS7_add_recipient' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(339): error C2085: 'PKCS7_add_recipient_info' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(340): error C2085: 'PKCS7_RECIP_INFO_set' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(341): error C2085: 'PKCS7_set_cipher' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(343): error C2085: 'PKCS7_get_issuer_and_serial' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(344): error C2085: 'PKCS7_digest_from_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(346): error C2085: 'PKCS7_add_signed_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(348): error C2085: 'PKCS7_add_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(349): error C2085: 'PKCS7_get_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(350): error C2085: 'PKCS7_get_signed_attribute' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(352): error C2085: 'PKCS7_set_signed_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(353): error C2085: 'PKCS7_set_attributes' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(357): error C2085: 'PKCS7_sign' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(359): error C2085: 'PKCS7_verify' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(360): error C2085: 'PKCS7_get0_signers' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(362): error C2085: 'PKCS7_encrypt' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(363): error C2085: 'PKCS7_decrypt' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(366): error C2085: 'PKCS7_add_attrib_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(367): error C2085: 'PKCS7_get_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(368): error C2085: 'PKCS7_simple_smimecap' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(370): error C2085: 'SMIME_write_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(371): error C2085: 'SMIME_read_PKCS7' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(372): error C2085: 'SMIME_crlf_copy' : not in formal parameter list 1>c:\users\luiz\dropbox\luiz\profissional\projetos\sadap3-assinaturadigital-iti\development\pdfsignature\openssl\include\openssl\pkcs7.h(372): fatal error C1003: error count exceeds 100; stopping compilation On Sun, Dec 27, 2015 at 12:41 AM, David Boulding > wrote: v1.1.0-pre1 on linux (1) Compiling with "no-threads " gives error on lines 173 and 379 in async.c. possible cause: async_fibre_makecontext() function async_posix.h @ line 57: #if defined(OPENSSL_SYS_UNIX) && defined(OPENSSL_THREADS) seems threads is required? (2) Compiling with no-psk and no-srp gives error on line 1692 in statem_clnt.c possible cause: with no-psk and no-srp nop'd out by #ifndef's above, line 1692 starts with "else if" instead of "if" Neither of these errors occurred in 1.0.2e. _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: