From pratyush.parimal at gmail.com Mon Aug 1 04:09:23 2016 From: pratyush.parimal at gmail.com (pratyush parimal) Date: Mon, 1 Aug 2016 00:09:23 -0400 Subject: [openssl-users] Recommended sequence for FIPS_mode_set(), RAND_load_file() and SSL_library_init() Message-ID: Hi everyone, I'm writing an application which can operate in FIPS mode, for which I'm calling FIPS_mode_set(). At one point, I'm also seeding the PRNG using RAND_load_file() so I can generate random bytes later. What I'm unsure about is that for FIPS mode operation, am I required to do the seeding after calling FIPS_mode_set() or is it OK for me to call it before as well? Also, what about the calls to initialization functions like SSL_library_init() ? I'd really appreciate if someone could help me understand the proper sequence of these function calls from a FIPS 140-2 compliance perspective. Thanks in advance! Pratyush -------------- next part -------------- An HTML attachment was scrubbed... URL: From Prabhat.Puroshottam at outlook.com Mon Aug 1 04:39:45 2016 From: Prabhat.Puroshottam at outlook.com (Prabhat Puroshottam) Date: Mon, 1 Aug 2016 04:39:45 +0000 Subject: [openssl-users] SSL session resumption from different TLS version In-Reply-To: <37a73a8b-f947-83a0-5444-d2e8896c7a39@openssl.org> References: , <37a73a8b-f947-83a0-5444-d2e8896c7a39@openssl.org> Message-ID: > IIRC the behaviour is different in the forthcoming OpenSSL 1.1.0. In > that version the client does not fix its version to the session version. > The client remains version flexible - if the server does not wish to use > the same version as was in the session then they can still negotiate a > different one and the session simply does not get used. Thanks Matt, for that detailed and helpful reply. Is it at all possible to merge these changes being done in OpenSSL 1.1.0 to older version of OpenSSL (as we build and ship our own version of OpenSSL)? Or is the nature of changes very complex in nature? Thanks, Prabhat -------------- next part -------------- An HTML attachment was scrubbed... URL: From git.syedelec at gmail.com Mon Aug 1 06:09:30 2016 From: git.syedelec at gmail.com (Syed Elec) Date: Mon, 1 Aug 2016 08:09:30 +0200 Subject: [openssl-users] overload engine for openssl dgst -sign Message-ID: Hi everyone, I'm currently working on an engine and I have a question about 'overload' the openssl dgst -sign ... command line using this engine. I can overload the openssl dgst only (for digests) using ENGINE_set_digests but how overload the whole command openssl dgst -sign for example : openssl dgst -md5 -binary -engine myengine -keyform engine -sign key.pem -out dgst.sig file Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nithin.cs.coorg at gmail.com Mon Aug 1 07:51:20 2016 From: nithin.cs.coorg at gmail.com (Nitz Malikarjun) Date: Mon, 1 Aug 2016 13:21:20 +0530 Subject: [openssl-users] Android javax.net.ssl and FIPS compliance openSSL. (In Application vs Android Stack). Message-ID: Hi folks, AFAIK Android javax.net.ssl classes uses openSSL/BoringSSL library at C/Low level for any SSL/TLS. https://developer.android.com/reference/javax/net/ssl/package-summary.html. /** - Provides the Java side of our JNI glue for OpenSSL. */ https://android.googlesource.com/platform/external/conscrypt/+/f087968/src/main/java/org/conscrypt/OpenSSLSocketImpl.java https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt/NativeCrypto.java https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/java/org/conscrypt C++ https://android.googlesource.com/platform/external/conscrypt/+/master/src/main/native/org_conscrypt_NativeCrypto.cpp org_conscrypt_NativeCrypto.cpp https://android.googlesource.com/platform/external/conscrypt/+/master/Android.mk (Build OpenSSL or BoringSSL). Intention: Load FIPS compliance openSSL libaray in my application and make javax.net.ssl(okhttp) classes use the that library hence my application become fips complaince. https://wiki.openssl.org/index.php/FIPS_Library_and_Android http://square.github.io/okhttp/ Simlilar to WolfSSL provider but its at firrware level or aosp, also its not JSSE compatible. http://www.linuxjournal.com/article/10896 is this feasible to load FIPS openSSL .OS and link it , what are configuration at android java level ? Thanks Nithin -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 1 08:51:21 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 1 Aug 2016 09:51:21 +0100 Subject: [openssl-users] SSL session resumption from different TLS version In-Reply-To: References: <37a73a8b-f947-83a0-5444-d2e8896c7a39@openssl.org> Message-ID: On 01/08/16 05:39, Prabhat Puroshottam wrote: > >> IIRC the behaviour is different in the forthcoming OpenSSL 1.1.0. In >> that version the client does not fix its version to the session version. >> The client remains version flexible - if the server does not wish to use >> the same version as was in the session then they can still negotiate a >> different one and the session simply does not get used. > > > > Thanks Matt, for that detailed and helpful reply. > > Is it at all possible to merge these changes being done in OpenSSL 1.1.0 > to older version of OpenSSL (as we build and ship our own version of > OpenSSL)? Or is the nature of changes very complex in nature? Unfortunately the version negotiation logic (which this change relies on) has been completely rewritten for 1.1.0 so this would not be suitable for backporting to 1.0.2. Matt From steve at openssl.org Mon Aug 1 14:05:59 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 1 Aug 2016 14:05:59 +0000 Subject: [openssl-users] overload engine for openssl dgst -sign In-Reply-To: References: Message-ID: <20160801140559.GA25079@openssl.org> On Mon, Aug 01, 2016, Syed Elec wrote: > Hi everyone, > > I'm currently working on an engine and I have a question about 'overload' > the openssl dgst -sign ... command line using this engine. > > I can overload the openssl dgst only (for digests) using ENGINE_set_digests > but how overload the whole command openssl dgst -sign > > for example : > openssl dgst -md5 -binary -engine myengine -keyform engine -sign key.pem > -out dgst.sig file > You need to provide support for the appropriate public key algorithm e.g. an RSA_METHOD. This can either be for general purpose acceleration of a key specific method which is used only for keys loaded from that ENGINE. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jonetsu at teksavvy.com Tue Aug 2 15:38:09 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 2 Aug 2016 08:38:09 -0700 (MST) Subject: [openssl-users] linker input file unused/linking not done gcc warning Message-ID: <1470152289481-67693.post@n7.nabble.com> Hello, Is it normal to get a 'linker imput file unused because linking not done' warning when compiling C code that uses OpenSSL in FIPS mode, hence using fipsld ? The object file is actually generated,a s well as the executable, and it does execute in a meaningful manner. The warning: [...] gcc: warning: /usr/include/openssl/: linker input file unused because linking not done FIPSLD_CC=gcc /usr/lib/ssl/fips-2.0/bin/fipsld -o fips_hmac-errCode fips_hmac-errCode.o /usr/lib/arm-li nux-gnueabihf/libcrypto.a -ldl -lz The simple Makefile: OPENSSLDIR = /usr/lib/ssl LIBCRYPTO = /usr/lib/arm-linux-gnueabihf/libcrypto.a INCLUDES = /usr/include/openssl/ CMD = fips_hmac-errCode OBJS = $(CMD).o $(CMD): $(OBJS) FIPSLD_CC=$(CC) $(OPENSSLDIR)/fips-2.0/bin/fipsld -o $(CMD) $(OBJS) $(LIBCRYPTO) -ldl -lz $(OBJS): $(CMD).c $(CC) -c $(CMD).c $(INCLUDES) clean: rm $(OBJS) Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/linker-input-file-unused-linking-not-done-gcc-warning-tp67693.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From jonetsu at teksavvy.com Tue Aug 2 17:59:43 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 2 Aug 2016 10:59:43 -0700 (MST) Subject: [openssl-users] FIPS: using libcrypto.so ? Message-ID: <1470160783316-67694.post@n7.nabble.com> The current FIPS User Guide mentions: "3.3 Creation of Shared Libraries The FIPS Object Module is not directly usable as a shared library, but it can be linked into an application that is a shared library. A ?FIPS compatible? OpenSSL distribution will automatically incorporate an available FIPS Object Module into the libcrypto shared library when built using the fips option (see ?4.2.3)." Does the first sentence mean that there should be an intermediate, user created, .so that itself uses libcrypto.a ? What does the second part mean ? The FOM will be included in the shared library (assuming the libcrypto.so file) ? If so, then why wouldn't it be available directly ? A clarification in perhaps simpler terms over what seems to be an explanation in the User Guide would be much appreciated. In practical terms, is it possible for an application to link against a libcrypto.so that provides all needed FIPS symbols ? If it's not, can you give an example overview in which an application already using OpenSSL (libcrypto.so) but now supporting FIPS, can still use libcrypto.so with full FIPS support ? Is the only answer to now have the application linked against libcrypto.a ? Thanks ! -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From bkaduk at akamai.com Tue Aug 2 19:15:53 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 2 Aug 2016 14:15:53 -0500 Subject: [openssl-users] linker input file unused/linking not done gcc warning In-Reply-To: <1470152289481-67693.post@n7.nabble.com> References: <1470152289481-67693.post@n7.nabble.com> Message-ID: <36047a5b-7ab2-9705-6e03-a9dce789189d@akamai.com> On 08/02/2016 10:38 AM, jonetsu wrote: > Hello, > > Is it normal to get a 'linker imput file unused because linking > not done' warning when compiling C code that uses OpenSSL in FIPS > mode, hence using fipsld ? > > The object file is actually generated,a s well as the executable, > and it does execute in a meaningful manner. > > The warning: > > [...] > > gcc: warning: /usr/include/openssl/: linker input file unused > because linking not done > > FIPSLD_CC=gcc /usr/lib/ssl/fips-2.0/bin/fipsld -o > fips_hmac-errCode fips_hmac-errCode.o /usr/lib/arm-li > nux-gnueabihf/libcrypto.a -ldl -lz > > > The simple Makefile: > > OPENSSLDIR = /usr/lib/ssl > LIBCRYPTO = /usr/lib/arm-linux-gnueabihf/libcrypto.a > INCLUDES = /usr/include/openssl/ The later usage makes it seem like this should be -I/usr/include/openssl/ , including the "-I". -Ben > CMD = fips_hmac-errCode > OBJS = $(CMD).o > $(CMD): $(OBJS) > FIPSLD_CC=$(CC) $(OPENSSLDIR)/fips-2.0/bin/fipsld -o $(CMD) > $(OBJS) $(LIBCRYPTO) -ldl -lz > > $(OBJS): $(CMD).c > $(CC) -c $(CMD).c $(INCLUDES) > clean: > rm $(OBJS) > > > Thanks. > > > > > -- > View this message in context: http://openssl.6102.n7.nabble.com/linker-input-file-unused-linking-not-done-gcc-warning-tp67693.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Tue Aug 2 19:45:01 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Tue, 2 Aug 2016 12:45:01 -0700 (MST) Subject: [openssl-users] FIPS mode: Need to use FIPS versions of (EVP) methods ? Message-ID: <1470167101379-67696.post@n7.nabble.com> FIPS: Need to use FIPS versions of (EVP) methods ? In FIPS mode, is there a need to use the FIPS_* methods instead of the regular ones once FIPS_mode_set(1) was successfully executed ? For instance, is there a need to use FIPS_evp_sha1() instead of EVP_sha1() ? Wouldn't the FIPS version of EVP_sha1() be used automatically when in FIPS mode ? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-mode-Need-to-use-FIPS-versions-of-EVP-methods-tp67696.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From steve at openssl.org Tue Aug 2 23:30:59 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 2 Aug 2016 23:30:59 +0000 Subject: [openssl-users] FIPS mode: Need to use FIPS versions of (EVP) methods ? In-Reply-To: <1470167101379-67696.post@n7.nabble.com> References: <1470167101379-67696.post@n7.nabble.com> Message-ID: <20160802233059.GA21911@openssl.org> On Tue, Aug 02, 2016, jonetsu wrote: > FIPS: Need to use FIPS versions of (EVP) methods ? > > In FIPS mode, is there a need to use the FIPS_* methods instead of the > regular ones once FIPS_mode_set(1) was successfully executed ? For > instance, is there a need to use FIPS_evp_sha1() instead of EVP_sha1() > ? Wouldn't the FIPS version of EVP_sha1() be used automatically when > in FIPS mode ? > The FIPS implementation of sha1 is automatically used in FIPS mode yes. You shouldn't use FIPS_evp_sha1() etc. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From thomas.francis.jr at pobox.com Wed Aug 3 15:32:13 2016 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Wed, 3 Aug 2016 11:32:13 -0400 Subject: [openssl-users] FIPS: using libcrypto.so ? In-Reply-To: <1470160783316-67694.post@n7.nabble.com> References: <1470160783316-67694.post@n7.nabble.com> Message-ID: <6D8251BC-2190-48BB-89D8-719A53373E9A@pobox.com> > On Aug 2, 2016, at 1:59 PM, jonetsu wrote: > > The current FIPS User Guide mentions: > > "3.3 Creation of Shared Libraries > > The FIPS Object Module is not directly usable as a shared > library, but it can be linked into an application that is a > shared library. A ?FIPS compatible? OpenSSL distribution will > automatically incorporate an available FIPS Object Module into > the libcrypto shared library when built using the fips > option (see ?4.2.3)." > > Does the first sentence mean that there should be an intermediate, user > created, .so that itself uses libcrypto.a ? I think you?re confusing the FIPS Object Module with libcrypto. You might also be confusing the libcrypto produced from your FIPS build, and the libcrypto produced by a FIPS capable OpenSSL. The former is what you get when you compile the software found in, e.g., openssl-fips-2.0.11.tar.gz, while the latter is produced when you compile from a regular OpenSSL release (e.g. openssl-1.0.2g.tar.gz). These are three different things. The libcrypto from the FIPS build isn?t used in any of your link steps. The FIPS Object Module may be (and on most systems is) compiled as a shared object (not a .so file, but a shared object). Because it?s not a library, you can?t simply link it. Some systems allow shared objects to be accessed via dlopen(), and the warning is to indicate that doing so is inappropriate, even when it?s possible. Noting that you can link it into a shared executable or library indicates that if you have a shared library or executable that you want to link the FIPS Object Module into, that you may do so. The usual way to do this is to link libcrypto.a (from a FIPS capable OpenSSL build) and use the fipsld script. Even if you don?t do it the usual way (e.g. you want to link only the FIPS Object Module), then you may, but you still have to follow all the rules laid out in the security policy (e.g. do everything the fipsld script is doing). This probably not what one wants to do. It?s far more likely that one wants to use the FIPS capable OpenSSL shared library directly. That?s what the second part is about... > What does the second part mean ? The FOM will be included in the shared > library (assuming the libcrypto.so file) ? If so, then why wouldn't it be > available directly ? A clarification in perhaps simpler terms over what > seems to be an explanation in the User Guide would be much appreciated. It means that when you create a FIPS capable OpenSSL, if you compiled libcrypto as a shared library, that libcrypto shared library will incorporate the FIPS Object Module, following the security policy. This means that you can use that shared library as you would any other shared library, and still be able to enable FIPS mode. This is what most people who want to use a shared library will want to do. > In practical terms, is it possible for an application to link against a > libcrypto.so that provides all needed FIPS symbols ? In general, yes. In practice, it depends. Compiling a FIPS capable OpenSSL might not create a shared library on your system. In that case, you must link libcrypto.a, and use the fipsld script (or equivalent) when you link it. I think that the vast majority of systems will compile it as a shared library, though, without any intervention on your part. > If it's not, can you > give an example overview in which an application already using OpenSSL > (libcrypto.so) but now supporting FIPS, can still use libcrypto.so with full > FIPS support ? Just link against the library produced by the FIPS capable OpenSSL build. If, for some reason, that only produced libcrypto.a, then you need to investigate why ? perhaps you passed ?no-shared? when running the config script? > Is the only answer to now have the application linked > against libcrypto.a ? > > Thanks ! > > > > > -- > View this message in context: http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694.html > Sent from the OpenSSL - User mailing list archive at Nabble.com. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jonetsu at teksavvy.com Wed Aug 3 14:27:16 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Wed, 3 Aug 2016 07:27:16 -0700 (MST) Subject: [openssl-users] FIPS: using libcrypto.so ? In-Reply-To: <6D8251BC-2190-48BB-89D8-719A53373E9A@pobox.com> References: <1470160783316-67694.post@n7.nabble.com> <6D8251BC-2190-48BB-89D8-719A53373E9A@pobox.com> Message-ID: <1470234436212-67705.post@n7.nabble.com> Thanks for the explanation. > Just link against the library produced by the FIPS capable > OpenSSL build. If, for some reason, that only produced > libcrypto.a, then you need to investigate why ? perhaps you > passed ?no-shared? when running the config script? The confusion came from trying to use methods such as FIPS_evp_sha1, FIPS_evp_sha224, FIPS_evp_sha256. As Steve replied yesterday, these should not be used (is there any case in which they would ?) as the EVP_sha* methods will automatically use the FIPS enabled ones when FIPS mode is active. For instance doing an 'objdump -T' on libcrypto.so.1.0.0 will show some FIPS* methods, but not the sha* for instance. Which now I see is a normal thing since they are not to be used. Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/FIPS-using-libcrypto-so-tp67694p67705.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From brian at virtru.com Wed Aug 3 17:39:02 2016 From: brian at virtru.com (Brian Jost) Date: Wed, 3 Aug 2016 10:39:02 -0700 Subject: [openssl-users] 755413103 error on fingerprint match Message-ID: I modified a script to get a FIPS compliant iOS library and am having issues with the fingerprint. I had to add a CPU adjustment to the incore_macho but I wouldn't think that would cause a FIPS fingerprint mismatch. https://gist.github.com/jostster/ebbc6925c668b632d8b185293080256c Does anyone have any thoughts how to overcome this error so that I can have a FIPS compliant iOS library for armv7, armv7s and arm64? -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at virtru.com Wed Aug 3 18:56:20 2016 From: brian at virtru.com (Brian Jost) Date: Wed, 3 Aug 2016 11:56:20 -0700 Subject: [openssl-users] 755413103 error on fingerprint match In-Reply-To: References: Message-ID: Update on this. Here is the log from my app. Any idea why my calculated sig is 000000000...? 2016-08-03 11:47:49.988 App[32127:2253410] FIPS_mode_set failed: 755413103 2016-08-03 11:47:49.988 App[32127:2253410] Embedded sig: 7363808352b3d84a797c91df813afcb58bf924b4 2016-08-03 11:47:49.988 App[32127:2253410] Calculated sig: 0000000000000000000000000000000000000000 Here is my code inside of my main.m files for my ios app int mode = FIPS_mode(), ret = 0; unsigned long err = 0; if(mode == 0) { ret = FIPS_mode_set(1 /*on*/); err = ERR_get_error(); } else { ret = FIPS_mode_set(0 /*off*/); err = ERR_get_error(); } if(1 != ret) NSLog(@"FIPS_mode_set failed: %lu", err); NSMutableString* f1 = [NSMutableString stringWithCapacity:MAGIC_20*2 + 8]; for(unsigned int i = 0; i < MAGIC_20; i++) [f1 appendFormat:@"%02x", FIPS_signature[i]]; NSLog(@"Embedded sig: %@", f1); unsigned char calculated[20] = {}; unsigned int ret2 = FIPS_incore_fingerprint(calculated, sizeof(calculated)); if(ret2 != MAGIC_20) { // Failure - wipe it. // Default is 0x00. We use 0xFF to differentiate memset(calculated, 0xFF, sizeof(calculated)); } NSMutableString* f2 = [NSMutableString stringWithCapacity:MAGIC_20*2 + 8]; for(unsigned int j = 0; j < MAGIC_20; j++) [f2 appendFormat:@"%02x", calculated[j]]; NSLog(@"Calculated sig: %@", f2); On Wed, Aug 3, 2016 at 10:39 AM, Brian Jost wrote: > I modified a script to get a FIPS compliant iOS library and am having > issues with the fingerprint. I had to add a CPU adjustment to the > incore_macho but I wouldn't think that would cause a FIPS fingerprint > mismatch. > > https://gist.github.com/jostster/ebbc6925c668b632d8b185293080256c > > Does anyone have any thoughts how to overcome this error so that I can > have a FIPS compliant iOS library for armv7, armv7s and arm64? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at openssl.org Thu Aug 4 14:26:55 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 4 Aug 2016 14:26:55 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published Message-ID: <20160804142655.GA19332@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 pre release 6 (beta) =========================================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ OpenSSL 1.1.0 is currently in beta. OpenSSL 1.1.0 pre release 6 has now been made available. For details of changes and known issues see the release notes at: https://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 beta release is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0-pre6.tar.gz Size: 5100538 SHA1 checksum: b4c4b64c56813a4dd824b9bb2735ac15331845b8 SHA256 checksum: ca869f843b8a947fb64ca7d7bebb2afe47a48d7bb5e9becc54d9c8fe674535c2 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0-pre6.tar.gz openssl sha256 openssl-1.1.0-pre6.tar.gz Please download and check this beta 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 iQEcBAEBAgAGBQJXo0qTAAoJENnE0m0OYESRj8sH/2sBz0vvkdGHZmNIttjbsrXz Xyx+nZHUkpuNwnQXzq7QuHMrUk+DtPOfgjxt7IOwVyzz/yyDMO+txhTRpgQH0y4e bOjsx+xUz1Bz3AioP06tREGkUdrZSkthVypkF1bKdb043rTZhY4EQ8sr+kw8cha6 sr93CFug/M52P0DLEksQQY0JXWkCvZvBbJK4YcC+ToyVhJ2Iz4og8KeN6X2/bNcB h5+RjdQnaLBMZIWe4MNt4flgtw59vt+3DbwPHiu5WDVl/RngUyGf22qxVV+y9XIu DEJ56V5TKvn7/BonIoUdFthx9s9wzzCcnm71LcfFzW1El9oOP3wOwDpCriRDkhY= =q4/S -----END PGP SIGNATURE----- From ohaya at yahoo.com Thu Aug 4 15:00:36 2016 From: ohaya at yahoo.com (o haya) Date: Thu, 4 Aug 2016 15:00:36 +0000 (UTC) Subject: [openssl-users] Question about OpenSSL and FIPS 140-2 module References: <1034280143.9116258.1470322836451.JavaMail.yahoo.ref@mail.yahoo.com> Message-ID: <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> Hi, I've been tasked to look into FIPS 140-2 "compliance" for our systems, overall, and I know that there's a "FIPS 140-2 module" for OpenSSL, that needs to be built from source and then integrated into OpenSSL by building OpenSSL with the FIPS module. The User guide goes into how to integrate the resulting OpenSSL(+FIPS module) with applications, and also has an example of doing that. What I was wondering is: Does that mean that EVERY application that we want to have use the OpenSSL(+FIPS module) would have be (slightly) modified and then rebuilt from source? What about something like Apache? Would we have to modify the Apache source and rebuild that together with the OpenSSL(+FIPS module)? Finally, what about COTS products, e.g., WebLogic, for which we cannot obtain the source? Thanks, Jim From marquess at openssl.com Thu Aug 4 15:48:35 2016 From: marquess at openssl.com (Steve Marquess) Date: Thu, 4 Aug 2016 11:48:35 -0400 Subject: [openssl-users] Question about OpenSSL and FIPS 140-2 module In-Reply-To: <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> References: <1034280143.9116258.1470322836451.JavaMail.yahoo.ref@mail.yahoo.com> <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> Message-ID: On 08/04/2016 11:00 AM, o haya wrote: > Hi, > > I've been tasked to look into FIPS 140-2 "compliance" for our > systems, overall, and I know that there's a "FIPS 140-2 module" for > OpenSSL, that needs to be built from source and then integrated into > OpenSSL by building OpenSSL with the FIPS module. > > The User guide goes into how to integrate the resulting OpenSSL(+FIPS > module) with applications, and also has an example of doing that. > > What I was wondering is: Does that mean that EVERY application that > we want to have use the OpenSSL(+FIPS module) would have be > (slightly) modified and then rebuilt from source? Yes, unless that product already has support for the "FIPS capable" OpenSSL. > What about something like Apache? Would we have to modify the Apache > source and rebuild that together with the OpenSSL(+FIPS module)? Apache httpd is an example of a product that supports the OpenSSL FIPS module natively, if built using the right build-time options. Stunnel, socat are others. Probably quite a few more but I don't try to keep track. OpenSSH is an example of a product not easily adapted for (righteous) use of the OpenSSL FIPS module, as it contains in-lined cryptographic code. > > Finally, what about COTS products, e.g., WebLogic, for which we > cannot obtain the source? You'll need to talk to the vendor(s) of those products. As a general rule any product that is sold into the USG/DoD market will come in a FIPS 140 flavor. If you don't have source you'll not be able to tell if it's readily adaptable for FIPS 140 compliance. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 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 thomas.francis.jr at pobox.com Thu Aug 4 15:53:40 2016 From: thomas.francis.jr at pobox.com (Thomas Francis, Jr.) Date: Thu, 4 Aug 2016 11:53:40 -0400 Subject: [openssl-users] Question about OpenSSL and FIPS 140-2 module In-Reply-To: <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> References: <1034280143.9116258.1470322836451.JavaMail.yahoo.ref@mail.yahoo.com> <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> Message-ID: <897CDA5C-1736-4904-A5AB-15B80C9E5C44@pobox.com> > On Aug 4, 2016, at 11:00 AM, o haya wrote: > > Hi, > > I've been tasked to look into FIPS 140-2 "compliance" for our systems, overall, and I know that there's a "FIPS 140-2 module" for OpenSSL, that needs to be built from source and then integrated into OpenSSL by building OpenSSL with the FIPS module. > > The User guide goes into how to integrate the resulting OpenSSL(+FIPS module) with applications, and also has an example of doing that. > > What I was wondering is: Does that mean that EVERY application that we want to have use the OpenSSL(+FIPS module) would have be (slightly) modified and then rebuilt from source? Potentially, yes. Some may already have such modifications. You can also find unofficial patches for some packages to do this, too. Of course, that doesn?t help you with software that uses some other cryptographic software. You?d probably need to make massive changes to them. :) > What about something like Apache? Would we have to modify the Apache source and rebuild that together with the OpenSSL(+FIPS module)? I believe there are already patches to make apache work with OpenSSL & FIPS. > Finally, what about COTS products, e.g., WebLogic, for which we cannot obtain the source? You would need to ask your vendors about products that provide FIPS compliance. I really should point out three things, though: 1) FIPS 140 compliance (from any software package) is always less secure than non-FIPS 140 compliant packages. By its nature, the validation process places software several months to years out of date, and no changes are allowed, even to address severe security problems. There are known security problems in at least some of the OpenSSL FIPS modules. 2) FIPS 140 compliance is _not_ about security. It?s about proving that specific algorithms are in use, for purposes of government auditing. Nothing in the compliance tests actually prove that, either. The algorithms must simply be able to produce the correct output for well-known inputs (that includes several runtime tests that also only prove it gives the right output for well-known inputs), and there must exist some sort of ?proof? that the module has not been modified from the tested form. There?s nothing in there to prevent FIPS 140 validation of a module that stores all your keys and sends them to someone else, and there?s nothing in there to prevent FIPS 140 validation of a module that contains algorithms that only do the right thing for those well-known inputs. There are even approved algorithms that have been shown to be insecure, even when the software implements the algorithm correctly (see Dual EC DRBG). 3) Unless you?re required by regulation to have FIPS 140 compliance, you should avoid it like the plague it is. It?s less secure, and you?ll never be able to update your software in a timely manner (even if there were no security problems, which is unlikely). Given that you reference COTS instead of GOTS, I suspect you?re not working for a government agency that is required to comply with FIPS 140. Steve Marquess has some excellent posts on his blog about these issues. Here?s one: http://veridicalsystems.com/blog/secure-or-compliant-pick-one/ TOM > Thanks, > Jim > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From jb-openssl at wisemo.com Thu Aug 4 16:26:02 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 4 Aug 2016 18:26:02 +0200 Subject: [openssl-users] Question about OpenSSL and FIPS 140-2 module In-Reply-To: <897CDA5C-1736-4904-A5AB-15B80C9E5C44@pobox.com> References: <1034280143.9116258.1470322836451.JavaMail.yahoo.ref@mail.yahoo.com> <1034280143.9116258.1470322836451.JavaMail.yahoo@mail.yahoo.com> <897CDA5C-1736-4904-A5AB-15B80C9E5C44@pobox.com> Message-ID: <01b7fc41-bda3-7e36-4548-47cc0995f217@wisemo.com> On 04/08/2016 17:53, Thomas Francis, Jr. wrote: > ... > > I really should point out three things, though: > > 1) FIPS 140 compliance (from any software package) is always less secure than non-FIPS 140 compliant packages. By its nature, the validation process places software several months to years out of date, and no changes are allowed, even to address severe security problems. There are known security problems in at least some of the OpenSSL FIPS modules. > > 2) FIPS 140 compliance is _not_ about security. It?s about proving that specific algorithms are in use, for purposes of government auditing. Nothing in the compliance tests actually prove that, either. The algorithms must simply be able to produce the correct output for well-known inputs (that includes several runtime tests that also only prove it gives the right output for well-known inputs), and there must exist some sort of ?proof? that the module has not been modified from the tested form. There?s nothing in there to prevent FIPS 140 validation of a module that stores all your keys and sends them to someone else, and there?s nothing in there to prevent FIPS 140 validation of a module that contains algorithms that only do the right thing for those well-known inputs. There are even approved algorithms that have been shown to be insecure, even when the software implements the algorithm correctly (see Dual EC DRBG). > > 3) Unless you?re required by regulation to have FIPS 140 compliance, you should avoid it like the plague it is. It?s less secure, and you?ll never be able to update your software in a timely manner (even if there were no security problems, which is unlikely). Given that you reference COTS instead of GOTS, I suspect you?re not working for a government agency that is required to comply with FIPS 140. > > At least one public non-gov CA has made the mistake of putting FIPS-140-2 compliance into one of their CP/CPS documents for how non-gov certificate holders should store their private key. Hopefully, this is an outlier, but it shows that FIPS 140-2 requirements sometimes sneak outside the USGOV context. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Thu Aug 4 17:19:41 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 4 Aug 2016 19:19:41 +0200 Subject: [openssl-users] iOS assembler questions Message-ID: <48cb6c60-49e2-055d-d863-21d280ba1b94@wisemo.com> I am trying to build the OpenSSL 1.0.2h ARM optimized assembler routines for Apple iOS (the default build config doesn't do that yet). However the Apple version of the LLVM 7.3.0 ARM assembler seems to reject some of the notation used by the current source code (.type, .size and address subtraction). Is there a known workaround/solution, or should I create my own patch to fix this? 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 julien at trigofacile.com Thu Aug 4 19:25:39 2016 From: julien at trigofacile.com (=?UTF-8?Q?Julien_=c3=89LIE?=) Date: Thu, 4 Aug 2016 21:25:39 +0200 Subject: [openssl-users] Wording in OpenSSL documentation for SSL_CTX_set_options In-Reply-To: <98066b7a-d9c7-537e-e07d-b72414e4d4ab@trigofacile.com> References: <98066b7a-d9c7-537e-e07d-b72414e4d4ab@trigofacile.com> Message-ID: <74802af4-3ac4-497a-c862-da603b943fd5@trigofacile.com> Hi all, Another thing: couldn't SSL_OP_CIPHER_SERVER_PREFERENCE be renamed (or aliased) to SSL_OP_SERVER_PREFERENCE in OpenSSL 1.1.0 because it applies to more objects than only cipher suites? -- Julien -------- Message transf?r? -------- Sujet : Wording in OpenSSL documentation for SSL_CTX_set_options Date : Fri, 29 Jul 2016 21:15:16 +0200 Hi, In a recent discussion in the news.software.nntp newsgroup, we discussed the use of SSL_OP_CIPHER_SERVER_PREFERENCE, and would like to point out a possible improvement in the wording of the documentation of SSL_CTX_set_options. Currently, there is in OpenSSL documentation: https://www.openssl.org/docs/manmaster/ssl/SSL_CONF_cmd.html "-serverpref Use server and not client preference order when determining which cipher suite, signature algorithm or elliptic curve to use for an incoming connection. Equivalent to SSL_OP_CIPHER_SERVER_PREFERENCE. Only used by servers." https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_options.html "When choosing a cipher, use the server's preferences instead of the client preferences. When not set, the SSL server will always follow the clients preferences. When set, the SSL/TLS server will choose following its own preferences." Maybe the documentation of SSL_CTX_set_options should also mention signature algorithms and elliptic curves. Also, Michael B?uerle noted that TLSv1.3 seems to change things a bit because FFDHE groups can now be negotiated too (codes starting at 256): and therefore suggests to mention "(EC)DHE groups" in both the above man pages. Have a nice day, -- Julien ?LIE ? La libertad, Sancho, es uno de los m?s preciosos dones que a los hombres dieron los cielos; con ella no pueden igualarse los tesoros que encierran la tierra y el mar: por la libertad, as? como por la honra, se puede y debe aventurar la vida. ? (Miguel de Cervantes Saavedra) From carl at five-ten-sg.com Thu Aug 4 22:05:00 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 04 Aug 2016 15:05:00 -0700 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <20160804142655.GA19332@openssl.org> References: <20160804142655.GA19332@openssl.org> Message-ID: <1470348300.858.12.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 > OpenSSL version 1.1.0 pre release 6 (beta) Seems to work in my openssl/sendmail/dane test environment. http://www.five-ten-sg.com/mapper/blog/dane -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAleju/sACgkQL6j7milTFsHPcACfYSuc4OxBsPrsclKgrTougmRV uL0Ani5CG7invjJBRGaYNAaaqAy/phWO =9l6k -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Thu Aug 4 22:33:36 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 4 Aug 2016 22:33:36 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <1470348300.858.12.camel@ns.five-ten-sg.com> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> Message-ID: <20160804223336.GH4670@mournblade.imrryr.org> On Thu, Aug 04, 2016 at 03:05:00PM -0700, Carl Byington wrote: > > OpenSSL version 1.1.0 pre release 6 (beta) > > Seems to work in my openssl/sendmail/dane test environment. Thanks for the confirmation. > http://www.five-ten-sg.com/mapper/blog/dane Note, I still firmly hold that the "o DANE=always" mode is largely a bad idea. It is only "useful" when an MX host has its address records in a signed zone, but its TLSA records are CNAMEd into an unsigned zone: ; example.com zone is signed example.com. IN MX 0 smtp.example.com. smtp.example.com. IN A 192.0.2.1 _25._tcp.smtp.example.com. IN CNAME _dane.example.net. ; example.net zone is not signed _dane.example.net. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 Such configurations will be rather rare, and offer minimal incremental MITM protection. The code and documentation to support this use-case and explain it to users are not worth the trouble. -- Viktor. From carl at five-ten-sg.com Thu Aug 4 23:30:39 2016 From: carl at five-ten-sg.com (Carl Byington) Date: Thu, 04 Aug 2016 16:30:39 -0700 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <20160804223336.GH4670@mournblade.imrryr.org> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> <20160804223336.GH4670@mournblade.imrryr.org> Message-ID: <1470353439.858.28.camel@ns.five-ten-sg.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On Thu, 2016-08-04 at 22:33 +0000, Viktor Dukhovni wrote: > Such configurations will be rather rare, and offer minimal incremental > MITM protection. The code and documentation to support this use-case > and explain it to users are not worth the trouble. Have you seen the mta-sts proposal: https://tools.ietf.org/html/draft-brotman-mta-sts-00 That is a mechanism to allow mail receivers that (do not/can not) do DNSSEC, to publish some constraints on the tls keys on their mail servers. Senders can reject connections that violate those constraints. But mta-sts starts with an unauthenticated dns TXT record. If that proposal is worth anything, it indicates there is some use for a mechanism to allow publishing unauthenticated data in dns to be used by mail senders to constrain the acceptable tls keys. I think it is better to publish an unauthenticated TLSA record, rather than to publish an unauthenticated TXT record that then leads to an https url which then delivers the tls key constraints. ; example.com zone is unsigned example.com. IN MX 0 smtp.example.com. smtp.example.com. IN A 192.0.2.1 _25._tcp.smtp.example.com. IN TLSA 3 1 1 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 None of these MX, A, and TLSA records are signed. But mail senders *could* still enforce the constraints implied by that TLSA record. Compared to mta-sts, this is easier for mail senders (a single TLSA record, rather than a TXT record and an entire https infrastructure with its own tls keys and pki certificates). It is also easier for mail receivers, since it is not much code to relax the "must be dnssec signed" constraint in the existing DANE code. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (GNU/Linux) iEYEAREKAAYFAlej0AgACgkQL6j7milTFsG7JwCfQ3FkX2MOdr/pMBneFImyoI/R PXEAnjj6t6HF//susl7XmFZXipsgxT8q =H4FQ -----END PGP SIGNATURE----- From openssl-users at dukhovni.org Thu Aug 4 23:48:07 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 4 Aug 2016 23:48:07 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <1470353439.858.28.camel@ns.five-ten-sg.com> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> <20160804223336.GH4670@mournblade.imrryr.org> <1470353439.858.28.camel@ns.five-ten-sg.com> Message-ID: <20160804234806.GI4670@mournblade.imrryr.org> On Thu, Aug 04, 2016 at 04:30:39PM -0700, Carl Byington wrote: > Have you seen the mta-sts proposal: Of course. > But mta-sts starts with an unauthenticated dns TXT record. Yes, this is but one of its compromises. > If that proposal is worth anything, it indicates there is some use for a > mechanism to allow publishing unauthenticated data in dns to be used by > mail senders to constrain the acceptable tls keys. You misunderstand the role of the DNS record in STS. It is a cache-priming signal, it is not the actual policy, which is always delivered via HTTPS. You're also forgetting that RFC7672-compliant MTAs MUST NOT attempt to retrieve TLSA records when the address records are insecure, so "DANE=always" will almost never happen. > I think it is better to publish an unauthenticated TLSA record, rather > than to publish an unauthenticated TXT record that then leads to an > https url which then delivers the tls key constraints. Except that nobody will use it, when it lies in the same unsigned zone as the host records. > None of these MX, A, and TLSA records are signed. But mail senders > *could* still enforce the constraints implied by that TLSA record. But they MUST NOT look up the TLSA record except when it is (rarely) a CNAME from a signed to an unsigned zone. > Compared to mta-sts, this is easier for mail senders (a single TLSA > record, rather than a TXT record and an entire https infrastructure with > its own tls keys and pki certificates). It is also easier for mail > receivers, since it is not much code to relax the "must be dnssec > signed" constraint in the existing DANE code. I am not an avid fan of STS, but I am helping the authors to avoid needless mistakes. -- Viktor. From jb-openssl at wisemo.com Fri Aug 5 02:33:25 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 5 Aug 2016 04:33:25 +0200 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <20160804234806.GI4670@mournblade.imrryr.org> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> <20160804223336.GH4670@mournblade.imrryr.org> <1470353439.858.28.camel@ns.five-ten-sg.com> <20160804234806.GI4670@mournblade.imrryr.org> Message-ID: <3196357d-9ca3-5997-9622-12a13e1e1693@wisemo.com> On 05/08/2016 01:48, Viktor Dukhovni wrote: > On Thu, Aug 04, 2016 at 04:30:39PM -0700, Carl Byington wrote: > >> Have you seen the mta-sts proposal: > Of course. > >> But mta-sts starts with an unauthenticated dns TXT record. > Yes, this is but one of its compromises. > >> If that proposal is worth anything, it indicates there is some use for a >> mechanism to allow publishing unauthenticated data in dns to be used by >> mail senders to constrain the acceptable tls keys. > You misunderstand the role of the DNS record in STS. It is a > cache-priming signal, it is not the actual policy, which is always > delivered via HTTPS. > > You're also forgetting that RFC7672-compliant MTAs MUST NOT attempt > to retrieve TLSA records when the address records are insecure, so > "DANE=always" will almost never happen. > >> I think it is better to publish an unauthenticated TLSA record, rather >> than to publish an unauthenticated TXT record that then leads to an >> https url which then delivers the tls key constraints. > Except that nobody will use it, when it lies in the same unsigned > zone as the host records. > >> None of these MX, A, and TLSA records are signed. But mail senders >> *could* still enforce the constraints implied by that TLSA record. > But they MUST NOT look up the TLSA record except when it is (rarely) > a CNAME from a signed to an unsigned zone. > >> Compared to mta-sts, this is easier for mail senders (a single TLSA >> record, rather than a TXT record and an entire https infrastructure with >> its own tls keys and pki certificates). It is also easier for mail >> receivers, since it is not much code to relax the "must be dnssec >> signed" constraint in the existing DANE code. > I am not an avid fan of STS, but I am helping the authors to avoid > needless mistakes. > I haven't read that proposal, but if the HTTPS server has to use the same host name as the SMTPS server, then the SMTPS server could just use the certificate directly. Alternatively, if the HTTPS server has to have a specific name relationship to the name of the SMTPS server or the RCPT TO domain, then a rule to allow the weaker name matching directly on the SMTPS certificate could be a simplification. An unauthenticated or weakly authenticated flag to indicate a specific certificate caching or matching discipline might be doable on the SMTP(S) connection e.g. as a capability keyword in the initial EHLO exchange, next to the keywords that indicate other SMTP features, I think there is an IANA registry for those. Just some ideas for those working on this. Note that putting a feature extending proxy in front of an SMTP server is common already, for example many spam-filters operate like that. This can be used to add any needed extensions to an existing SMTP server that can't be modified. 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 Fri Aug 5 02:51:09 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 5 Aug 2016 02:51:09 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <3196357d-9ca3-5997-9622-12a13e1e1693@wisemo.com> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> <20160804223336.GH4670@mournblade.imrryr.org> <1470353439.858.28.camel@ns.five-ten-sg.com> <20160804234806.GI4670@mournblade.imrryr.org> <3196357d-9ca3-5997-9622-12a13e1e1693@wisemo.com> Message-ID: <20160805025109.GJ4670@mournblade.imrryr.org> On Fri, Aug 05, 2016 at 04:33:25AM +0200, Jakob Bohm wrote: > I haven't read that proposal, but if the HTTPS server has to use the > same host name as the SMTPS server, then the SMTPS server could just > use the certificate directly. There is at best a very tenuous analogy between TLS for HTTP and TLS for SMTP. So your suggestions miss the mark, unfortunately. :-( First and forement TLS in SMTP is opportunistic, and compounding that the destination hosts are discovered indirectly via MX records. For a more detailed exposition, see: https://tools.ietf.org/html/rfc7672#section-1.3 [ Or just take my word for it, you are likely busy enough with other things that I know very little about. ] -- Viktor. From jb-openssl at wisemo.com Fri Aug 5 05:35:05 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 5 Aug 2016 07:35:05 +0200 Subject: [openssl-users] OpenSSL version 1.1.0 pre release 6 published In-Reply-To: <20160805025109.GJ4670@mournblade.imrryr.org> References: <20160804142655.GA19332@openssl.org> <1470348300.858.12.camel@ns.five-ten-sg.com> <20160804223336.GH4670@mournblade.imrryr.org> <1470353439.858.28.camel@ns.five-ten-sg.com> <20160804234806.GI4670@mournblade.imrryr.org> <3196357d-9ca3-5997-9622-12a13e1e1693@wisemo.com> <20160805025109.GJ4670@mournblade.imrryr.org> Message-ID: On 05/08/2016 04:51, Viktor Dukhovni wrote: > On Fri, Aug 05, 2016 at 04:33:25AM +0200, Jakob Bohm wrote: > >> I haven't read that proposal, but if the HTTPS server has to use the >> same host name as the SMTPS server, then the SMTPS server could just >> use the certificate directly. > There is at best a very tenuous analogy between TLS for HTTP and TLS > for SMTP. So your suggestions miss the mark, unfortunately. :-( > > First and forement TLS in SMTP is opportunistic, and compounding > that the destination hosts are discovered indirectly via MX records. > For a more detailed exposition, see: Hence my other suggestions about how to incorporate rules based on the RCPT TO domain name matching if that is what said proposal is doing (from what you wrote previously, it couldn't safely connect to any random https server mentioned in an unsigned TXT record). > https://tools.ietf.org/html/rfc7672#section-1.3 > > [ Or just take my word for it, you are likely busy enough with > other things that I know very little about. ] > 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 minfrin at sharp.fm Fri Aug 5 13:08:59 2016 From: minfrin at sharp.fm (Graham Leggett) Date: Fri, 5 Aug 2016 15:08:59 +0200 Subject: [openssl-users] Unknown record type 207: what is it, and why does it cause SSL to fail? Message-ID: <11065662-F526-4754-A5B3-209169954BD2@sharp.fm> Hi all, I am having a problem where an iPhone running iOS v9.3.3 is attempting to connect to httpd+openssl on CentOS7 and suddenly failing when this used to work in the past. The client (iOS) seems to believe the SSL handshake is successful, and so attempts to send some application data. The server (httpd), appears to be offended by this, and returns "unknown record type: 207?. The server then slams the phone down, and the client follows suit directly after. Some questions: - What is record type 207? - Why would openssl believe that record type 207 is not known? The trace from ssldump is below. 1 1 0.0089 (0.0089) C>S V3.1(223) Handshake ClientHello Version 3.3 random[32]= 57 a4 8d b0 4c 85 18 b6 dd e1 1f 10 5a 41 5e 8b 73 5f eb 49 77 6c ee 33 f1 5c 57 a0 c0 d2 95 ab cipher suites TLS_EMPTY_RENEGOTIATION_INFO_SCSV TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA compression methods NULL 1 2 0.0221 (0.0131) S>C V3.3(93) Handshake ServerHello Version 3.3 random[32]= 57 a4 8c 87 8c 6c 8a fc e0 7f 73 64 a9 b2 27 ad 6a e8 fa 46 b4 e1 db dd 7d f2 fd 07 e1 e8 1e ed session_id[32]= 12 7b 6e ad 46 df 9b 20 21 2a 31 e8 b6 cb 4d 75 cf ec 2c af 7b 22 49 8d d9 98 1d fb bf de ca e2 cipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 compressionMethod NULL 1 3 0.0221 (0.0000) S>C V3.3(2790) Handshake [snip server certificate] 1 4 0.0221 (0.0000) S>C Short record: 589 bytes available (expecting: 592) 1 5 0.0221 (0.0000) S>C V215.13(0) unknown record type: 0 1 6 0.1699 (0.1478) C>S V3.3(953) Handshake [snip client certificate] 1 7 0.1700 (0.0000) C>S V3.3(70) Handshake ClientKeyExchange Not enough data. Found 64 bytes (expecting 16384) 1 8 0.1700 (0.0000) C>S V3.3(264) Handshake CertificateVerify Not enough data. Found 258 bytes (expecting 16384) 1 9 0.1700 (0.0000) C>S V3.3(1) ChangeCipherSpec 1 10 0.1700 (0.0000) C>S V3.3(40) Handshake 1 11 0.1820 (0.0119) C>S V3.3(379) application_data 1 12 0.1829 (0.0008) S>C V3.1(576) unknown record type: 207 1 5.1278 (4.9449) S>C TCP FIN 1 5.6138 (0.4859) C>S TCP FIN Regards, Graham ? From CONRAD.GERHART.WELLING at leidos.com Fri Aug 5 20:36:09 2016 From: CONRAD.GERHART.WELLING at leidos.com (Welling, Conrad Gerhart) Date: Fri, 5 Aug 2016 20:36:09 +0000 Subject: [openssl-users] Unexpected SSL23_GET_SERVER_HELLO unsupported protocol Error Message-ID: I am encountering curl-7.44.0+openssl-1.0.2d (FIPS-capable) TLS session-initialization failures like ... * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol on only ONE (HOSTX) of two 2008 R2 IIS 7.5 HTTPS servers (HOSTX, ROOM40) which are supposed to be configured the same. I am using OpenSSL 1.0.2d-fips 9 Jul 2015 curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ROOM40 and HOSTX servers run IIS 7.5 or IIS 8.0, and, the values of the keys (SSL 2.0 - TLS 1.2, Client and Server) in the registry branch HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols are the same (see following). All the OTHER ..\Protocols keys - Ciphers, CipherSuites, Hashes, and KeyExchangeAlgorithms - are the same (all blank). SSL 2.0 Client "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 Server SSL 3.0 Client "Enabled"=dword:00000000 Server "Enabled"=dword:00000000 TLS 1.0 (Does not exist on HOSTX) Client Server TLS 1.1 Client "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Server "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 TLS 1.2 Client "Enabled"=dword:00000001 Server "Enabled"=dword:00000001 I've researched "TLS version intolerance", SNI, ALPN and more, but, haven't figured this out yet. Following are four curl-7.44.0+openssl-1.0.2d (FIPS- capable) attempts to "upload" a file. The 1st attempt to server ROOM40 succeeds, but the subsequent three attempts to server HOSTX all fail. Any hints or insights are very much appreciated ... Note: The following output has been been edited to enhance readability and disguise client and servers. =============================================================================== ==> openssl version OpenSSL 1.0.2d-fips 9 Jul 2015 ==> curl --version curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT TO UPLOAD TO ROOM40 (Successful) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user matahari:18761917 https://ROOM40/datasink/ * Trying 10.11.51.37... * Connected to ROOM40 (10.11. 51.37) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=CA; L=Los Angeles; O=CID; OU=LA DEV; CN=ROOM40 * start date: 2014-05-01 15:44:59 GMT * expire date: 2018-02-05 22:10:46 GMT * common name: ROOM40 (matched) * issuer: CN=DISRAELI * SSL certificate verify ok. * Server auth using Basic with user 'matahari' > PUT /datasink/stuff.dat HTTP/1.1 > Host: ROOM40 > Authorization: Basic ZnRwd2FsbDoxMzRGa3JlVDk1andfMlE= > User-Agent: curl/7.44.0 > Accept: */* > Content-Length: 161 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 201 Created < Location: http://ROOM40/datasink/stuff.dat < Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET < Date: Thu, 04 Aug 2016 01:31:09 GMT < Content-Length: 0 < * Connection #0 to host ROOM40 left intact ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #1 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #2 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to hostx.area51.gov:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to hostx.area51.gov:443 ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #3 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol -------------- next part -------------- An HTML attachment was scrubbed... URL: From CONRAD.GERHART.WELLING at leidos.com Sat Aug 6 00:46:42 2016 From: CONRAD.GERHART.WELLING at leidos.com (Welling, Conrad Gerhart) Date: Sat, 6 Aug 2016 00:46:42 +0000 Subject: [openssl-users] Unexpected SSL23_GET_SERVER_HELLO unsupported protocol Error Message-ID: --- Reformatted and resent --- I am encountering curl-7.44.0+openssl-1.0.2d (FIPS-capable) TLS session-initialization failures like ... * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol on only ONE (HOSTX) of two 2008 R2 IIS 7.5 HTTPS servers (HOSTX, ROOM40) which are supposed to be configured the same. I am using OpenSSL 1.0.2d-fips 9 Jul 2015 curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ROOM40 and HOSTX servers run IIS 7.5 or IIS 8.0, and, the values of the keys (SSL 2.0 - TLS 1.2, Client and Server) in the registry branch HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols are the same (see following). All the OTHER ..\Protocols keys - Ciphers, CipherSuites, Hashes, and KeyExchangeAlgorithms - are the same (all blank). SSL 2.0 Client "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 Server SSL 3.0 Client "Enabled"=dword:00000000 Server "Enabled"=dword:00000000 TLS 1.0 (Does not exist on HOSTX) Client Server TLS 1.1 Client "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Server "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 TLS 1.2 Client "Enabled"=dword:00000001 Server "Enabled"=dword:00000001 I've researched "TLS version intolerance", SNI, ALPN and more, but, haven't figured this out yet. Following are four curl-7.44.0+openssl-1.0.2d (FIPS- capable) attempts to "upload" a file. The 1st attempt to server ROOM40 succeeds, but the subsequent three attempts to server HOSTX all fail. Any hints or insights are very much appreciated ... Note: The following output has been been edited to enhance readability and disguise client and servers. =============================================================================== ==> openssl version OpenSSL 1.0.2d-fips 9 Jul 2015 ==> curl --version curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT TO UPLOAD TO ROOM40 (Successful) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user matahari:18761917 https://ROOM40/datasink/ * Trying 10.11.51.37... * Connected to ROOM40 (10.11. 51.37) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=CA; L=Los Angeles; O=CID; OU=LA DEV; CN=ROOM40 * start date: 2014-05-01 15:44:59 GMT * expire date: 2018-02-05 22:10:46 GMT * common name: ROOM40 (matched) * issuer: CN=DISRAELI * SSL certificate verify ok. * Server auth using Basic with user 'matahari' > PUT /datasink/stuff.dat HTTP/1.1 > Host: ROOM40 > Authorization: Basic ZnRwd2FsbDoxMzRGa3JlVDk1andfMlE= > User-Agent: curl/7.44.0 > Accept: */* > Content-Length: 161 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 201 Created < Location: http://ROOM40/datasink/stuff.dat < Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET < Date: Thu, 04 Aug 2016 01:31:09 GMT < Content-Length: 0 < * Connection #0 to host ROOM40 left intact ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #1 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #2 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to hostx.area51.gov:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to hostx.area51.gov:443 ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #3 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol -------------- next part -------------- An HTML attachment was scrubbed... URL: From jim at carroll.com Sat Aug 6 01:32:38 2016 From: jim at carroll.com (Jim Carroll) Date: Fri, 5 Aug 2016 21:32:38 -0400 Subject: [openssl-users] Trouble with BIO_s_mem() and SSL_new() on OpenSSL-1.1.0-pre7-dev Message-ID: <002301d1ef82$6b2f3d60$418db820$@carroll.com> We have a non-blocking windows app that we are migrating to from OpenSSL 1.0.2i to 1.1.0-pre7-dev. We move data from sockets to SSL via BIO_s_mem() objects. rbio = BIO_new(BIO_s_mem()); wbio = BIO_new(BIO_s_mem()); ssl = SSL_new(ssl_ctx); SSL_set_bio(ssl, rbio, wbio); We move data in via BIO_write(rbio, ...), but later an SSL_read(ssl, ...) returns bytes -1 and SSL_get_error() returns SSL_ERROR(1) Debug stepping through the code, we were surprised to discover that ssl3_read_n() dispatched the SSL_read() into BIO_s_connect(). A detailed study of the code, and I can assure that at no point do we ever associate the windows socket with SSL. Is it possible that that SSL_new() no longer allows the use of memory BIO's? I know that's a long shot question, but we're grasping at straws here. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4722 bytes Desc: not available URL: From matt at openssl.org Sat Aug 6 08:47:32 2016 From: matt at openssl.org (Matt Caswell) Date: Sat, 6 Aug 2016 09:47:32 +0100 Subject: [openssl-users] Trouble with BIO_s_mem() and SSL_new() on OpenSSL-1.1.0-pre7-dev In-Reply-To: <002301d1ef82$6b2f3d60$418db820$@carroll.com> References: <002301d1ef82$6b2f3d60$418db820$@carroll.com> Message-ID: <67ec57ea-b070-d6b9-f60f-c0630233c45c@openssl.org> On 06/08/16 02:32, Jim Carroll wrote: > We have a non-blocking windows app that we are migrating to from OpenSSL > 1.0.2i to 1.1.0-pre7-dev. We move data from sockets to SSL via > BIO_s_mem() objects. > > > > rbio = BIO_new(BIO_s_mem()); > > wbio = BIO_new(BIO_s_mem()); > > > > ssl = SSL_new(ssl_ctx); > > SSL_set_bio(ssl, rbio, wbio); > > > > We move data in via BIO_write(rbio, ...), but later an SSL_read(ssl, > ...) returns bytes -1 and SSL_get_error() returns SSL_ERROR(1) > > > > Debug stepping through the code, we were surprised to discover that > ssl3_read_n() dispatched the SSL_read() into BIO_s_connect(). A detailed > study of the code, and I can assure that at no point do we ever > associate the windows socket with SSL. > > Is it possible that that SSL_new() no longer allows the use of memory > BIO's? I know that's a long shot question, but we're grasping at straws > here. No, the use of memory BIO's is perfectly acceptable - and in fact we do exactly that in our own self-tests. See create_ssl_connection() in test/ssltestlib.c. Matt From jim at carroll.com Sat Aug 6 10:19:48 2016 From: jim at carroll.com (Jim Carroll) Date: Sat, 6 Aug 2016 06:19:48 -0400 Subject: [openssl-users] Trouble with BIO_s_mem() and SSL_new() on OpenSSL-1.1.0-pre7-dev In-Reply-To: <67ec57ea-b070-d6b9-f60f-c0630233c45c@openssl.org> References: <002301d1ef82$6b2f3d60$418db820$@carroll.com> <67ec57ea-b070-d6b9-f60f-c0630233c45c@openssl.org> Message-ID: <00b701d1efcc$0fbf30d0$2f3d9270$@carroll.com> Matt Complete mis-read on my part, there is nothing wrong with SSL_new() and BIO_s_mem(). I neglected to recall I was debugging a unittest with a client thread was using the simpler bio_s_connect() to test our non-blocking server. The debugger was showing us the other thread. -- thanks much. > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf Of Matt Caswell > Sent: Saturday, August 06, 2016 4:48 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Trouble with BIO_s_mem() and SSL_new() on > OpenSSL-1.1.0-pre7-dev > > > > On 06/08/16 02:32, Jim Carroll wrote: > > We have a non-blocking windows app that we are migrating to from > OpenSSL > > 1.0.2i to 1.1.0-pre7-dev. We move data from sockets to SSL via > > BIO_s_mem() objects. > > > > > > > > rbio = BIO_new(BIO_s_mem()); > > > > wbio = BIO_new(BIO_s_mem()); > > > > > > > > ssl = SSL_new(ssl_ctx); > > > > SSL_set_bio(ssl, rbio, wbio); > > > > > > > > We move data in via BIO_write(rbio, ...), but later an SSL_read(ssl, > > ...) returns bytes -1 and SSL_get_error() returns SSL_ERROR(1) > > > > > > > > Debug stepping through the code, we were surprised to discover that > > ssl3_read_n() dispatched the SSL_read() into BIO_s_connect(). A > detailed > > study of the code, and I can assure that at no point do we ever > > associate the windows socket with SSL. > > > > Is it possible that that SSL_new() no longer allows the use of memory > > BIO's? I know that's a long shot question, but we're grasping at > straws > > here. > > No, the use of memory BIO's is perfectly acceptable - and in fact we do > exactly that in our own self-tests. See create_ssl_connection() in > test/ssltestlib.c. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users begin 666 smime.p7s M,( &"2J&2(;W#0$'`J" ,( "`0$Q"S )!@4K#@,"&@4`,( &"2J&2(;W#0$' M`0``H((.$3""!#8P@@,>H ,"`0("`0$P#08)*H9(AO<-`0$%!0`P;S$+, D& M`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T($%",28P) 8#500+$QU!9&14 M'1E%PTP,# U,S Q,#0X,SA:%PTR,# U,S Q,#0X M,SA:,&\Q"S )!@-5! 83`E-%,10P$@8#500*$PM!9&14=,K(D%3IQE\/>)V:0#P.K&&J7A2/GH>A:E#&`JCIJ&DF&)"K3+!/(ZLZ3X38W\Z?X6EON]="UVM$Y,>M[FU! M7W):<0 at WLWEEI%F at E#?W`"\-PI)RVM X DRU0:, L& M`U4=#P0$`P(!!C /!@-5'1,!`?\$!3 #`0'_,(&9!@-5'2,$@9$P at 8Z %*V] MF'HTM";W^L0F5.\#O> DRU0:H7.D<3!O,0LP"08#500&$P)313$4,!(&`U4$ M"A,+061D5')U8'9 M'EL4!R,V98^PV'>[K$%L1V"#4;#Y,CWG_/8F$\> %J6_6OR'SWAYB2&:XDP' M"H8UO/+>4<32EK?L,`E$4+8Z]%N#!WT9UYR2M[/1"M(63:[H<4KPC:^$PWFO6-^>7NG"0U JVK=CXK#]O:, M&D(%4=1%]9^G8B%H%2!#/)GG?+TDV*F1%W.(/U8;,3 at 8M'$/FLW(#IZ.+AOA MC)B#RQ\Q\41,Q at 1S279@#\?XO1> :R[IS$P.6IIY#R *+M6>8R8>59*4V((7 M6GO0O,>/3H8$,(($KS""`Y>@`P(!`@(1`. CRQ42 at U.)K6%N>E1G:R$P#08) M*H9(AO<-`0$+!0`P;S$+, D&`U4$!A,"4T4Q%# 2!@-5! H3"T%D9%1R=7-T M($%",28P) 8#500+$QU!9&14'1E%PTQ-#$R,C(P M,# P,#!:%PTR,# U,S Q,#0X,SA:,(&;,0LP"08#500&$P)'0C$;,!D&`U4$ M"!,21W)E871EE,93G!2';Q6 MI at 8FM[A)X);G4:OQ\%H3216CM(P;8+QZ44*G>8RD(M\784Z1U78C"A332@)_ MMAT)@&ZE!#W9NKL6_J&'J2Y#4D,6?*\R4,BF3UKI"-C/DR6<>XCH,&3FI/A6 M@/TJ)!0S%YFL1.5IBZ-&!DO",]3I0)\&L+&LDT"YM0B3.IPJ4Z,0VST at 83Q5 M`X[93G8E`B$I^J-\<79/[N%?@>G[5(#;PWLU4K>$WB(]+# M,7]9O5(WL#-I M+4/K^M:E\9=W9U&,V>XGZ[RE!SAVC*2I./_?C/4#K$F^RO=SF3H/,JNPP#@8#51T/`0'_! 0#`@&&,!(&`U4=$P$!_P0(, 8!`?\"`0`P'08# M51TE!!8P% 8(*P8!!04'`P(&""L&`04%!P,$,!$&`U4=( 0*, @P!@8$51T@ M`#!$!@-5'1\$/3 [,#F at -Z UAC-H='1P.B\O8W)L+G5S97)T'1EJSMCY=K5<^_LX/M[XJ/_\$(CG,JVC4T^Y$L8`[*H+=38 MNT)+D&F%$-NF-S3H>^ !$*6Y+,KF'$K8F0W!AN*0DOM:0FHC(1#I M913V2A :)OI\BON;,((% M(#""! B@`P(!`@(1`-4+#]T2278FC)\!=Y87SN8P#08)*H9(AO<-`0$+!0`P M at 9LQ"S )!@-5! 83`D=",1LP&08#500($Q)'%PTQ-C Q,3,P,# P,#!:%PTQ-S Q M,3(R,S4Y-3E:," Q'C HV/H^"EPS!W)_L#3<"[3T(BZ3LDTHN"#(\B5A1 M^VO2XN77=+Z\+IU=@1UR!40:,<7&)5,P,O1STRE:UFFYLS65=GVT*:ZY[YK9 M':(_+75)?UCOJQ: M-%=9XH<_VNPXG^;7/:6"2-DDFNH3JMIBVKH$1G/E$ 9 MD8XE<3>#8^@.89*P$#)O+'$"`P$``:."`=SB(9<*/G' MV*_ SS .!@-5'0\!`?\$! ,"!: P# 8#51T3`0'_! (P`# =!@-5'24$%C 4 M!@@K!@$%!0<#! 8(*P8!!04'`P(P1 at 8#51T@!#\P/3 [!@PK!@$$`;(Q`0(! M`P4P*S I!@@K!@$%!0<"`18=:'1T<',Z+R]S96-UDE*'QH34=CM%+[K`1M] M]CL[U/FRY5[^LX>0V\F[3S&JAG>8?S4(\8%YC7"@FZN?&[XNG;*71FB1VC5\ M[C at 1T1/1VFB^.U_DY "31W;:;K"NZ]K)Q3#HO(@&45E,YCJ!NY$AC!C\IGQ: M2/NGP"_K'85*^(.K.&Q*INS)?2E26GN'Y^%BLAID at HA<[DL&']YY*Z 9#&;V MFJ3HYV^Y[HF)FFH-]D/]<5G):'.LJD*"]IJWI4,'-BQ;060E4[7[NKAN!^P\ MBTU&T;&8EQ; '\I'[_^.1-;+K'J.:_]/&2]A0 at L9SC^8NO*8S_4,>"4TRIOH MI'J>$[1$P4TQ@@0C,(($'P(!`3"!L3"!FS$+, D&`U4$!A,"1T(Q&S 9!@-5 M! @3$D=R96%T97(@36%N8VAE6%\[F,('$!@LJADB&]PT!"1 ""S&!M*"!L3"!FS$+, D&`U4$ M!A,"1T(Q&S 9!@-5! @3$D=R96%T97(@36%N8VAE^.6-+0H/W4$1/H93$ M9>YZTBB^DR=4GZ.LS"""+I+P?5?H4V+SVL'.IO>4`G4W_(YML02(75'%O]B! M!@LA8AMJLE12/^(K_FS*?3?5FXEU0T[]1(&[6AWS.I0NK6'"T_U8X>@NW'-;Y>K^$F[[*K7/&:,GTM(@[J6CN MRP#+BAR*<#-Q&]X\L&:3^:G-TL at K"?C&QF(M6],TJ7[+$02-$ZH4=J7F7>95 JZX&5`NC9^ UQW1-_Q1E4 at RH9/(>&-5RV78I4*DRCETTZ")%<```````` ` end From jim at carroll.com Sat Aug 6 10:58:42 2016 From: jim at carroll.com (Jim Carroll) Date: Sat, 6 Aug 2016 06:58:42 -0400 Subject: [openssl-users] 'no shared cipher', TLS_method on OpenSSL-1-1-0-pre7-dev Message-ID: <00d301d1efd1$7ef984a0$7cec8de0$@carroll.com> Using OpenSSL 1.1.0-pre7-dev, our SSL server app is reporting: 10308:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl\statem\statem_srvr.c:1420: Client & server both set to use TLS_method() with default ciphers. With -DCIPHER_DEBUG enabled in our OpenSSL build, we get the following: 0:[00000004:00000008:0000008C:00000014]003C6A08:ECDHE-ECDSA-AES256-GCM-SHA38 4 0:[00000004:00000001:0000008C:00000014]003C6A80:ECDHE-RSA-AES256-GCM-SHA384 0:[00000002:00000001:0000008C:00000014]003C5CAC:DHE-RSA-AES256-GCM-SHA384 0:[00000004:00000008:0000008C:00000014]003C7458:ECDHE-ECDSA-CHACHA20-POLY130 5 0:[00000004:00000001:0000008C:00000014]003C741C:ECDHE-RSA-CHACHA20-POLY1305 0:[00000002:00000001:0000008C:00000014]003C7494:DHE-RSA-CHACHA20-POLY1305 0:[00000004:00000008:0000008C:00000014]003C69CC:ECDHE-ECDSA-AES128-GCM-SHA25 6 0:[00000004:00000001:0000008C:00000014]003C6A44:ECDHE-RSA-AES128-GCM-SHA256 0:[00000002:00000001:0000008C:00000014]003C5C70:DHE-RSA-AES128-GCM-SHA256 0:[00000004:00000008:0000008C:00000014]003C6918:ECDHE-ECDSA-AES256-SHA384 0:[00000004:00000001:0000008C:00000014]003C6990:ECDHE-RSA-AES256-SHA384 0:[00000002:00000001:0000008C:00000014]003C56D0:DHE-RSA-AES256-SHA256 0:[00000004:00000008:0000008C:00000014]003C68DC:ECDHE-ECDSA-AES128-SHA256 0:[00000004:00000001:0000008C:00000014]003C6954:ECDHE-RSA-AES128-SHA256 0:[00000002:00000001:0000008C:00000014]003C5658:DHE-RSA-AES128-SHA256 0:[00000004:00000008:0000008C:00000014]003C64A4:ECDHE-ECDSA-AES256-SHA 0:[00000004:00000001:0000008C:00000014]003C6594:ECDHE-RSA-AES256-SHA 0:[00000002:00000001:0000008C:00000014]003C5400:DHE-RSA-AES256-SHA 0:[00000004:00000008:0000008C:00000014]003C6468:ECDHE-ECDSA-AES128-SHA 0:[00000004:00000001:0000008C:00000014]003C6558:ECDHE-RSA-AES128-SHA 0:[00000002:00000001:0000008C:00000014]003C5310:DHE-RSA-AES128-SHA 0:[00000004:00000008:0000008C:00000014]003C642C:ECDHE-ECDSA-DES-CBC3-SHA 0:[00000004:00000001:0000008C:00000014]003C651C:ECDHE-RSA-DES-CBC3-SHA 0:[00000002:00000001:0000008C:00000014]003C516C:DHE-RSA-DES-CBC3-SHA 0:[00000001:00000001:0000008C:00000014]003C5C34:AES256-GCM-SHA384 0:[00000001:00000001:0000008C:00000014]003C5BF8:AES128-GCM-SHA256 0:[00000001:00000001:0000008C:00000014]003C54F0:AES256-SHA256 0:[00000001:00000001:0000008C:00000014]003C54B4:AES128-SHA256 0:[00000001:00000001:0000008C:00000014]003C5388:AES256-SHA 0:[00000001:00000001:0000008C:00000014]003C5298:AES128-SHA 0:[00000001:00000001:0000008C:00000014]003C50F4:DES-CBC3-SHA It looks like both client & server have a lot of cipher's they could use together, but for a reason I can't yet understand, the server is refusing to accept the client's offered ciphers. Could anyone shed any light on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4722 bytes Desc: not available URL: From jvp at forthepolls.org Sat Aug 6 14:31:50 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Sat, 6 Aug 2016 07:31:50 -0700 Subject: [openssl-users] output from: dh, dhparam, pkeyparam Message-ID: <57A5F4D6.4030201@forthepolls.org> since 0.9.6 or before, five (5) example PEM files have been included in the 'crypto/dh' directory of the pkg. these represent bit-sizes from 192 to 4096. certainly 192-/512-/1024-bits are hardly applicable today and that leaves the 2048-/4096-bit files subject to current interest. at that, i am not certain what utility these files have since they are not installed. quite a while ago i noticed the 'dh2048.pem' file when deciding to create custom DH param files. this file has two (2) sets of param's. since these files may have originated in some early dev phase, i can see where someone mistakenly appended the second param set instead of supplanting the first. this brings to the fore my actual question. 'pkeyparam' shares the same DH feature of its predecessors in that it ignores all content not included between the /*first*/ PEM header and its accompanying footer. that means virtually anything can surround the first param and will be ignored by whatever call(s) this wrapper is making. i can understand that this may have been coded this way to allow for the history DH param's have with openssl whereby only the PKCS#3 variant has been supported and that format might co-exist in some files. however, it would seem prudent that everything outside the first DH param should not be completely ignored. to wit: consider the very real possibility that a programmatic error is made -- such as the dh2048.pem example, supra -- and an append is performed and the new param is completely ignored and nobody is the wiser. moreover, since it is remarkably unlikely that anyone is hand coding these files or that comments would be inserted; it seems to make a lot of sense for a utilizing module to _*warn*_ of excess content that is not PKCS and _*fail*_ if more than a single PEM-type param is included. -- Thank you, Johann v. Preu?en -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From rsalz at akamai.com Sat Aug 6 14:39:54 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 6 Aug 2016 14:39:54 +0000 Subject: [openssl-users] output from: dh, dhparam, pkeyparam In-Reply-To: <57A5F4D6.4030201@forthepolls.org> References: <57A5F4D6.4030201@forthepolls.org> Message-ID: OpenSSL behavior is pretty consistent, when reading a PEM file, everything before the first PEM marker (of the right type!) is ignored. From jim at carroll.com Sat Aug 6 20:59:54 2016 From: jim at carroll.com (Jim Carroll) Date: Sat, 6 Aug 2016 16:59:54 -0400 Subject: [openssl-users] 'no shared cipher', TLS_method on OpenSSL-1-1-0-pre7-dev In-Reply-To: <00d301d1efd1$7ef984a0$7cec8de0$@carroll.com> References: <00d301d1efd1$7ef984a0$7cec8de0$@carroll.com> Message-ID: <012101d1f025$7b6f6850$724e38f0$@carroll.com> My bad - needed to initialize SSL_CTX_set_tmp_dh() BEFORE calling SSL_new(). From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Jim Carroll Sent: Saturday, August 06, 2016 6:59 AM To: openssl-users at openssl.org Subject: [openssl-users] 'no shared cipher', TLS_method on OpenSSL-1-1-0-pre7-dev Using OpenSSL 1.1.0-pre7-dev, our SSL server app is reporting: 10308:error:1417A0C1:SSL routines:tls_post_process_client_hello:no shared cipher:ssl\statem\statem_srvr.c:1420: Client & server both set to use TLS_method() with default ciphers. With -DCIPHER_DEBUG enabled in our OpenSSL build, we get the following: 0:[00000004:00000008:0000008C:00000014]003C6A08:ECDHE-ECDSA-AES256-GCM-SHA38 4 0:[00000004:00000001:0000008C:00000014]003C6A80:ECDHE-RSA-AES256-GCM-SHA384 0:[00000002:00000001:0000008C:00000014]003C5CAC:DHE-RSA-AES256-GCM-SHA384 0:[00000004:00000008:0000008C:00000014]003C7458:ECDHE-ECDSA-CHACHA20-POLY130 5 0:[00000004:00000001:0000008C:00000014]003C741C:ECDHE-RSA-CHACHA20-POLY1305 0:[00000002:00000001:0000008C:00000014]003C7494:DHE-RSA-CHACHA20-POLY1305 0:[00000004:00000008:0000008C:00000014]003C69CC:ECDHE-ECDSA-AES128-GCM-SHA25 6 0:[00000004:00000001:0000008C:00000014]003C6A44:ECDHE-RSA-AES128-GCM-SHA256 0:[00000002:00000001:0000008C:00000014]003C5C70:DHE-RSA-AES128-GCM-SHA256 0:[00000004:00000008:0000008C:00000014]003C6918:ECDHE-ECDSA-AES256-SHA384 0:[00000004:00000001:0000008C:00000014]003C6990:ECDHE-RSA-AES256-SHA384 0:[00000002:00000001:0000008C:00000014]003C56D0:DHE-RSA-AES256-SHA256 0:[00000004:00000008:0000008C:00000014]003C68DC:ECDHE-ECDSA-AES128-SHA256 0:[00000004:00000001:0000008C:00000014]003C6954:ECDHE-RSA-AES128-SHA256 0:[00000002:00000001:0000008C:00000014]003C5658:DHE-RSA-AES128-SHA256 0:[00000004:00000008:0000008C:00000014]003C64A4:ECDHE-ECDSA-AES256-SHA 0:[00000004:00000001:0000008C:00000014]003C6594:ECDHE-RSA-AES256-SHA 0:[00000002:00000001:0000008C:00000014]003C5400:DHE-RSA-AES256-SHA 0:[00000004:00000008:0000008C:00000014]003C6468:ECDHE-ECDSA-AES128-SHA 0:[00000004:00000001:0000008C:00000014]003C6558:ECDHE-RSA-AES128-SHA 0:[00000002:00000001:0000008C:00000014]003C5310:DHE-RSA-AES128-SHA 0:[00000004:00000008:0000008C:00000014]003C642C:ECDHE-ECDSA-DES-CBC3-SHA 0:[00000004:00000001:0000008C:00000014]003C651C:ECDHE-RSA-DES-CBC3-SHA 0:[00000002:00000001:0000008C:00000014]003C516C:DHE-RSA-DES-CBC3-SHA 0:[00000001:00000001:0000008C:00000014]003C5C34:AES256-GCM-SHA384 0:[00000001:00000001:0000008C:00000014]003C5BF8:AES128-GCM-SHA256 0:[00000001:00000001:0000008C:00000014]003C54F0:AES256-SHA256 0:[00000001:00000001:0000008C:00000014]003C54B4:AES128-SHA256 0:[00000001:00000001:0000008C:00000014]003C5388:AES256-SHA 0:[00000001:00000001:0000008C:00000014]003C5298:AES128-SHA 0:[00000001:00000001:0000008C:00000014]003C50F4:DES-CBC3-SHA It looks like both client & server have a lot of cipher's they could use together, but for a reason I can't yet understand, the server is refusing to accept the client's offered ciphers. Could anyone shed any light on this? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4722 bytes Desc: not available URL: From vaporg at gmail.com Mon Aug 8 05:41:41 2016 From: vaporg at gmail.com (Vladimir A. Petrov) Date: Mon, 8 Aug 2016 13:41:41 +0800 Subject: [openssl-users] Migration from AES_ctr128_encrypt to EVP Message-ID: Hello, I need to migrate some code from the old style software implemented AES_ctr128_encrypt to the EVP interface. I spent pretty much time reading OpenSSL manual pages and Wiki as well as googling. Unfortunately, I still can't get an idea how to migrate from these AES_* functions to the API provided by EVP. The closest info that I found is the proposal made by Dr Stephen N. Henson ( https://mta.openssl.org/pipermail/openssl-users/2015-March/000776.html) to switch to EVP_aes_128_ctr, but there is no such 'ctr' mode in EVP for AES. Could you please point me on some useful documentation, piece of code or any other source of information which would provide the guidelines for accomplishing my task? Or maybe somebody of you already have the experience in such migration which could be shared. Thanks in advance, Vladimir. -- /vap/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From testossl2016 at gmail.com Mon Aug 8 09:32:35 2016 From: testossl2016 at gmail.com (Test ssl) Date: Mon, 8 Aug 2016 15:02:35 +0530 Subject: [openssl-users] issue while compiling openssl1.02h Message-ID: Hi , I am trying to compile openssl 1.0.2h for my project. i am facing compilation error related to "ASN1_OBJECT". Error is as given below :- asn1.h:530: error: expected specifier-qualifier-list before 'ASN1_OBJECT' asn1.h:783: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token asn1.h:784: error: expected ')' before '*' token asn1.h:785: error: expected ')' before '*' token asn1.h:786: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token asn1.h:788: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token asn1.h:917: error: expected declaration specifiers or '...' before 'ASN1_OBJECT' asn1.h:921: error: expected declaration specifiers or '...' before 'ASN1_OBJECT' asn1.h:924: error: expected '=', ',', ';', 'asm' or '__attribute__' before '*' token this above error is coming while compiling for "libcurl" - curl-7.46.0. Is there any dependency of curl version for openssl 1.0.2h? Regrads, -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris at konagma.com Mon Aug 8 11:39:54 2016 From: kris at konagma.com (Krzysztof Konopko) Date: Mon, 8 Aug 2016 13:39:54 +0200 Subject: [openssl-users] Loading engines recursively and crypto engine lock Message-ID: Hi, TL;DR; Is it allowed to initialise engines recursively, ie. call `engine2->init` from `engine1->init`? -- I have a solution in a consumer product based on OpenSSL 1.0.2 series that uses two engines: one (engine1) for selecting client certificate chain (TLS client auth) and another one (engine2) for RPC operations on associated private keys stored in H/W. This works only if supplied (installed) locks are recursive as for each engine initialisation `CRYPTO_LOCK_ENGINE` is taken. >From what I see, OpenSSL 1.1.x onward, provides locking internally and it's non-recursive. Also `lock_dbg_cb()` implementation in OpenSSL before 1.1.x suggests locks are not expected to be recursive. Here's some more context of my use case.? OpenSSL loads `engine1` for me automatically (` ?? ? OPENSSL_SSL_CLIENT_ENGINE_AUTO` variable) which is convenient as I don't have control over application's `main()` function. In my case it's proprietary code but equally it could be Python script (I do not fancy patching Python interpreter to get to its `main()` function and load/initialise engines explicitly). So my _only_ entry point is `engine1->init`. In that entry point I initialise engine2 which is a fairly slow operation (need to load certs from permanent storage) so definitely want to do this only once. Oh, and the app is heavily multi-threaded so I'm glad OpenSSL carefully takes crypto engine lock where needed. But because engines are initialised recursively, the locking implementation I supply uses recursive mutex which works very well and makes perfect sense to me in this case (I know that the same thread calls locked functions recursively for a reason). This works only before 1.1.x. Alternatively I could lazy-initialise engine2 in certificate callback function but any initialisation failure here would be less meaningful and it would require another lock to protect engine2 handle. In `engine1->init` I know a lock is already held so I thought it's safer to do more initialisation here. Besides `engine2->init` is not called directly but through a layer of application logic so conceptually these two engines are orthogonal and know nothing about each other. I guess initialising engines recursively does not work in OpenSSL 1.1.x (it'd be a dead-lock) and I need to seek for a different place to initialise engine2, for example in certificate cb? This would mean I "leak" some knowledge of engine2 existence into engine1, have guarantee that crypto engine lock is not held in certificate callabck function and need another lock to protect access to engine2 handle. Please let me know what your views are and if the above makes sense. Thanks, Kris -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Mon Aug 8 14:51:04 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 8 Aug 2016 09:51:04 -0500 Subject: [openssl-users] output from: dh, dhparam, pkeyparam In-Reply-To: <57A5F4D6.4030201@forthepolls.org> References: <57A5F4D6.4030201@forthepolls.org> Message-ID: <57f734fb-0728-2d83-b64c-6febc53fab38@akamai.com> What Rich said, and also note that it's perfectly valid usage of the PEM routines to read one type from a BIO and then go on to read another (potentially different) type from the same BIO, as would happen if they were in the same file concatenated after each other. So, attempting to peek and see if there was other stuff after the read PEM object would be a strange special case. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Mon Aug 8 15:07:29 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 8 Aug 2016 15:07:29 +0000 Subject: [openssl-users] Migration from AES_ctr128_encrypt to EVP In-Reply-To: References: Message-ID: <20160808150729.GA30454@openssl.org> On Mon, Aug 08, 2016, Vladimir A. Petrov wrote: > Hello, > > I need to migrate some code from the old style software implemented > AES_ctr128_encrypt to the EVP interface. I spent pretty much time reading > OpenSSL manual pages and Wiki as well as googling. Unfortunately, I still > can't get an idea how to migrate from these AES_* functions to the API > provided by EVP. The closest info that I found is the proposal made by Dr > Stephen N. Henson ( > https://mta.openssl.org/pipermail/openssl-users/2015-March/000776.html) to > switch to EVP_aes_128_ctr, but there is no such 'ctr' mode in EVP for AES. > > I'm not sure what you mean by "but there is no such 'ctr' mode in EVP for AES": can you clarify? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From bkaduk at akamai.com Mon Aug 8 15:08:54 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Mon, 8 Aug 2016 10:08:54 -0500 Subject: [openssl-users] issue while compiling openssl1.02h In-Reply-To: References: Message-ID: <3cb10d9c-750e-da69-cd05-bb198def1308@akamai.com> You'll probably need to provide more information; what is the compiler command line and full output for this failing file; is openssl installed once or in multiple places on the machine; etc. -Ben On 08/08/2016 04:32 AM, Test ssl wrote: > Hi , > > > I am trying to compile openssl 1.0.2h for my project. > > i am facing compilation error related to "ASN1_OBJECT". Error is as > given below :- > > asn1.h:530: error: expected specifier-qualifier-list before 'ASN1_OBJECT' > asn1.h:783: error: expected '=', ',', ';', 'asm' or '__attribute__' > before '*' token > asn1.h:784: error: expected ')' before '*' token > asn1.h:785: error: expected ')' before '*' token > asn1.h:786: error: expected '=', ',', ';', 'asm' or '__attribute__' > before '*' token > asn1.h:788: error: expected '=', ',', ';', 'asm' or '__attribute__' > before '*' token > asn1.h:917: error: expected declaration specifiers or '...' before > 'ASN1_OBJECT' > asn1.h:921: error: expected declaration specifiers or '...' before > 'ASN1_OBJECT' > asn1.h:924: error: expected '=', ',', ';', 'asm' or '__attribute__' > before '*' token > > > this above error is coming while compiling for "libcurl" - curl-7.46.0. > > Is there any dependency of curl version for openssl 1.0.2h? > > > Regrads, > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Mon Aug 8 17:13:53 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Mon, 8 Aug 2016 13:13:53 -0400 Subject: [openssl-users] Migration from AES_ctr128_encrypt to EVP In-Reply-To: References: Message-ID: > Could you please point me on some useful documentation, piece of code or any > other source of information which would provide the guidelines for > accomplishing my task? Or maybe somebody of you already have the experience > in such migration which could be shared. https://wiki.openssl.org/index.php/EVP_Symmetric_Encryption_and_Decryption and https://wiki.openssl.org/index.php/EVP_Authenticated_Encryption_and_Decryption. If you detail a specific problem, then better advice can probably be provided. Jeff From CONRAD.GERHART.WELLING at leidos.com Mon Aug 8 23:21:57 2016 From: CONRAD.GERHART.WELLING at leidos.com (Welling, Conrad Gerhart) Date: Mon, 8 Aug 2016 23:21:57 +0000 Subject: [openssl-users] Unexpected SSL23_GET_SERVER_HELLO unsupported protocol Error In-Reply-To: References: Message-ID: Never mind ... I was sailing by the Bellman's map. The IIS servers cited were not configured correctly or as indicated. No problems, of course, with openssl .... From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Welling, Conrad Gerhart Sent: Friday, August 05, 2016 5:47 PM To: openssl-users at openssl.org Subject: [openssl-users] Unexpected SSL23_GET_SERVER_HELLO unsupported protocol Error --- Reformatted and resent --- I am encountering curl-7.44.0+openssl-1.0.2d (FIPS-capable) TLS session-initialization failures like ... * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol on only ONE (HOSTX) of two 2008 R2 IIS 7.5 HTTPS servers (HOSTX, ROOM40) which are supposed to be configured the same. I am using OpenSSL 1.0.2d-fips 9 Jul 2015 curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ROOM40 and HOSTX servers run IIS 7.5 or IIS 8.0, and, the values of the keys (SSL 2.0 - TLS 1.2, Client and Server) in the registry branch HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols are the same (see following). All the OTHER ..\Protocols keys - Ciphers, CipherSuites, Hashes, and KeyExchangeAlgorithms - are the same (all blank). SSL 2.0 Client "DisabledByDefault"=dword:00000001 "Enabled"=dword:00000000 Server SSL 3.0 Client "Enabled"=dword:00000000 Server "Enabled"=dword:00000000 TLS 1.0 (Does not exist on HOSTX) Client Server TLS 1.1 Client "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 Server "DisabledByDefault"=dword:00000000 "Enabled"=dword:00000001 TLS 1.2 Client "Enabled"=dword:00000001 Server "Enabled"=dword:00000001 I've researched "TLS version intolerance", SNI, ALPN and more, but, haven't figured this out yet. Following are four curl-7.44.0+openssl-1.0.2d (FIPS- capable) attempts to "upload" a file. The 1st attempt to server ROOM40 succeeds, but the subsequent three attempts to server HOSTX all fail. Any hints or insights are very much appreciated ... Note: The following output has been been edited to enhance readability and disguise client and servers. =============================================================================== ==> openssl version OpenSSL 1.0.2d-fips 9 Jul 2015 ==> curl --version curl 7.44.0 (i386-pc-win32) libcurl/7.44.0 OpenSSL/1.0.2d Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smb smbs smtp smtps telnet tftp Features: AsynchDNS Largefile NTLM SSL ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT TO UPLOAD TO ROOM40 (Successful) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user matahari:18761917 https://ROOM40/datasink/ * Trying 10.11.51.37... * Connected to ROOM40 (10.11. 51.37) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * TLSv1.2 (IN), TLS handshake, Server hello (2): * TLSv1.2 (IN), TLS handshake, Certificate (11): * TLSv1.2 (IN), TLS handshake, Server key exchange (12): * TLSv1.2 (IN), TLS handshake, Server finished (14): * TLSv1.2 (OUT), TLS handshake, Client key exchange (16): * TLSv1.2 (OUT), TLS change cipher, Client hello (1): * TLSv1.2 (OUT), TLS handshake, Finished (20): * TLSv1.2 (IN), TLS change cipher, Client hello (1): * TLSv1.2 (IN), TLS handshake, Finished (20): * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-SHA256 * ALPN, server did not agree to a protocol * Server certificate: * subject: C=US; ST=CA; L=Los Angeles; O=CID; OU=LA DEV; CN=ROOM40 * start date: 2014-05-01 15:44:59 GMT * expire date: 2018-02-05 22:10:46 GMT * common name: ROOM40 (matched) * issuer: CN=DISRAELI * SSL certificate verify ok. * Server auth using Basic with user 'matahari' > PUT /datasink/stuff.dat HTTP/1.1 > Host: ROOM40 > Authorization: Basic ZnRwd2FsbDoxMzRGa3JlVDk1andfMlE= > User-Agent: curl/7.44.0 > Accept: */* > Content-Length: 161 > Expect: 100-continue > < HTTP/1.1 100 Continue * We are completely uploaded and fine < HTTP/1.1 201 Created < Location: http://ROOM40/datasink/stuff.dat < Server: Microsoft-IIS/7.5 < X-Powered-By: ASP.NET < Date: Thu, 04 Aug 2016 01:31:09 GMT < Content-Length: 0 < * Connection #0 to host ROOM40 left intact ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #1 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DES-CBC3-SHA * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #2 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --ciphers AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: AES128-SHA256:AES256-SHA256:DHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256 * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * Unknown SSL protocol error in connection to hostx.area51.gov:443 * Closing connection 0 curl: (35) Unknown SSL protocol error in connection to hostx.area51.gov:443 ==> REM ----------------------------------------------------------------------- ==> REM ATTEMPT #3 TO UPLOAD TO HOSTX (Fails) ==> REM ----------------------------------------------------------------------- ==> %CD%\curl.exe --verbose -T "stuff.dat" --tlsv1.2 --capath ..\certs --user TELawrence:18881935 https://hostx.area51.gov/upload/ * Trying 211.3.150.21... * Connected to hostx.area51.gov (211.3.150.21) port 443 (#0) * ALPN, offering http/1.1 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH * successfully set certificate verify locations: * CAfile: none CApath: ..\certs * TLSv1.2 (OUT), TLS header, Certificate Status (22): * TLSv1.2 (OUT), TLS handshake, Client hello (1): * error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol * Closing connection 0 curl: (35) error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol -------------- next part -------------- An HTML attachment was scrubbed... URL: From neutrino.network1 at gmail.com Tue Aug 9 03:56:42 2016 From: neutrino.network1 at gmail.com (neutrino network) Date: Tue, 9 Aug 2016 08:56:42 +0500 Subject: [openssl-users] OPENSSL provided by Cavium Message-ID: Hi, Cavium provides a configured OPENSSL for better performance on their hardware. It usage must lowers the CPU utilization by crypto operations offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the only way to use this Cavium OPENSSL is by making simple executive application/user space and use the provided OPENSSL as an API. Please guide and share any details (readme, tutorial, link etc) regarding Cavium OPENSSL. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From sugu.ece28 at gmail.com Tue Aug 9 08:32:22 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Tue, 9 Aug 2016 01:32:22 -0700 (MST) Subject: [openssl-users] How to make EVP functions returns false Message-ID: <1470731542209-67775.post@n7.nabble.com> Hi, I am using EVP encryption and decryption and rsa key generation api from openssl for my project. I need to write unit tests for my code including failure conditions also. Could you please help me to make below functions returns false without getting valgrind error. 1. EVP_EncryptInit_ex() & EVP_DecryptInit_ex() 2. EVP_EncryptUpdate() & EVP_DecryptUpdate() 3. EVP_EncryptFinal_ex() & EVP_DecryptFinal_ex() 4. SHA256_Init() 5. SHA256_Update() 6. SHA256_Final() 7. RSA_generate_key_ex() 8. PEM_write_RSAPrivateKey() & PEM_read_RSAPrivateKey 9. PEM_write_RSA_PUBKEY() 10. PEM_read_bio_RSA_PUBKEY() & PEM_read_bio_RSAPrivateKey -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-make-EVP-functions-returns-false-tp67775.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From onurtuna.lj at gmail.com Tue Aug 9 12:03:41 2016 From: onurtuna.lj at gmail.com (Onur Tuna) Date: Tue, 9 Aug 2016 15:03:41 +0300 Subject: [openssl-users] Android openssl linking Message-ID: Dear openssl users, I have an issue on linking libcrypto and libssl.so to my project. I'm using Android Studio 2.2 and everything about C++ worked properly so far. I have used the shell scripts in the following link: https://github.com/stdchpie/android-openssl. 6 for each .so file have been obtained as arm64-v8a, armeabi, mips, mips64, x86, x86_64. The project structure is attached with this e-mail. I don't have an Android.mk file but build.gradle(app). I'm trying to link these libraries, which I think they're wrong or have missing things, using the part of the gradle script below: cmake { cppFlags "-std=c++11 -frtti -fexceptions -DWITH_NONAMESPACES -DWITH_OPENSSL" cppFlags.add("-I${file("src/main/include")}".toString()) cppFlags.add("-L${file("src/main/jniLibs")}".toString()) } The script above is enclosed inside externalNativeBuild which enclosed inside android. [image: Inline image 1] The error I'm getting is as below: FAILURE: Build failed with an exception. * What went wrong: Execution failed for task ':app:externalNativeBuildDebug'. > com.android.ide.common.process.ProcessException: Error while executing '/Users/onurtuna/Library/Android/sdk/cmake/bin/cmake' with arguments {--build /Users/onurtuna/AndroidStudioProjects/theProject/app/.externalNativeBuild/cmake/debug/mips64 --target service-lib} [1/18] Building CXX object CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/envC.cpp.o [2/18] Building CXX object CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/stdsoap2.cpp.o [3/18] Building CXX object CMakeFiles/service-lib.dir/src/main/cpp/ServiceManagerClient.cpp.o ..... ..... [18/18] Linking CXX shared library ../obj/mips64/libservice-lib.so FAILED: : && /Users/onurtuna/Library/Android/sdk/ndk-bundle/toolchains/mips64el-linux-android-4.9/prebuilt/darwin-x86_64/bin/mips64el-linux-android-gcc -fPIC -fexceptions -frtti -Wno-psabi --sysroot=/Users/onurtuna/Library/Android/sdk/ndk-bundle/platforms/android-21/arch-mips64 -fno-strict-aliasing -finline-functions -funwind-tables -fmessage-length=0 -fno-inline-functions-called-once -fgcse-after-reload -frerun-cse-after-loop -frename-registers -fsigned-char -no-canonical-prefixes -fdata-sections -ffunction-sections -Wa,--noexecstack -std=c++11 -frtti -fexceptions -DWITH_NONAMESPACES -DWITH_OPENSSL -I/Users/onurtuna/AndroidStudioProjects/theProject/app/src/main/include -B/Users/onurtuna/AndroidStudioProjects/theProject/app/src/main/jniLibs -fno-omit-frame-pointer -O0 -g -DDEBUG -D_DEBUG -Wl,--no-undefined -Wl,-allow-shlib-undefined -Wl,--gc-sections -Wl,-z,noexecstack -Wl,-z,relro -Wl,-z,now -Wl,--build-id -shared -Wl,-soname,libservice-lib.so -o ../obj/mips64/libservice-lib.so CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/envC.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/stdsoap2.cpp.o CMakeFiles/service-lib.dir/src/main/cpp/ServiceManagerClient.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/ServiceManagerIVSOSServiceManagerProxy.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/ServiceManagerC.cpp.o CMakeFiles/service-lib.dir/src/main/cpp/SessionManagerClient.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/SessionManagerC.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/SessionManagerIVSOSSessionManagerProxy.cpp.o CMakeFiles/service-lib.dir/src/main/cpp/CameraManagerClient.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/CameraManagerC.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/CameraManagerIVSOSEncoderManagerProxy.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/DVR_WebServiceC.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/DVR_WebServiceinfodifDVRProxy.cpp.o CMakeFiles/service-lib.dir/src/main/cpp/NvrManagerClient.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/NvrManagerC.cpp.o CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/NvrManagerIVSOSNvrManagerProxy.cpp.o CMakeFiles/service-lib.dir/src/main/cpp/SslInit.cpp.o -L/Users/onurtuna/Library/Android/sdk/ndk-bundle/toolchains/mips64el-linux-android-4.9/prebuilt/darwin-x86_64/user/libs/mips64 "/Users/onurtuna/Library/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/libs/mips64/libgnustl_static.a" "/Users/onurtuna/Library/Android/sdk/ndk-bundle/sources/cxx-stl/gnu-libstdc++/4.9/libs/mips64/libsupc++.a" -lm && : CMakeFiles/service-lib.dir/Users/onurtuna/AndroidStudioProjects/Proxy/stdsoap2.cpp.o: In function `fsend': /Users/onurtuna/AndroidStudioProjects/Proxy/stdsoap2.cpp:591: undefined reference to `SSL_write' ..... ..... /Users/onurtuna/AndroidStudioProjects/theProject/app/src/main/cpp/SslInit.cpp:81: undefined reference to `CRYPTO_num_locks' collect2: error: ld returned 1 exit status ninja: build stopped: subcommand failed. Thank you very much in advance. Kindly, Onur -- Onur Tuna, Web: http://onurtuna.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2016-08-09 at 14.50.45.png Type: image/png Size: 40879 bytes Desc: not available URL: From rsalz at akamai.com Tue Aug 9 12:09:15 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 9 Aug 2016 12:09:15 +0000 Subject: [openssl-users] OPENSSL provided by Cavium In-Reply-To: References: Message-ID: <2b647945e8cb4b07b1d96edac7cd3422@usma1ex-dag1mb1.msg.corp.akamai.com> Ask Cavium. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: neutrino network [mailto:neutrino.network1 at gmail.com] Sent: Monday, August 08, 2016 11:57 PM To: openssl-users at openssl.org; openssl-dev at openssl.org Subject: [openssl-users] OPENSSL provided by Cavium Hi, Cavium provides a configured OPENSSL for better performance on their hardware. It usage must lowers the CPU utilization by crypto operations offloading. I wanted to ask whether we can install Cavium OPENSSL Toolkit on Linux OS (on Cavium hardware), just as we install a standard OPENSSL? OR the only way to use this Cavium OPENSSL is by making simple executive application/user space and use the provided OPENSSL as an API. Please guide and share any details (readme, tutorial, link etc) regarding Cavium OPENSSL. Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvp at forthepolls.org Tue Aug 9 16:49:38 2016 From: jvp at forthepolls.org (=?UTF-8?Q?Johann_v._Preu=c3=9fen?=) Date: Tue, 9 Aug 2016 09:49:38 -0700 Subject: [openssl-users] DH custom param generation/usage Message-ID: <57AA09A2.5080407@forthepolls.org> *use case:* '/openssl genpkey -genparam -algorithm DH/' the '/genpkey/' doc's '*DH PARAMETER GENERATION OPTIONS'* section: * first, before i forget -- again -- openssl's doc's should indicate that the using the '-pkeyopt' option requires that the 'dh_paramgen_generator' setting must precede the 'dh_paramgen_prime_len' if it is present or the setting is ignored and results in a default setting of '2' (which could stand to be mentioned as happening if the "generator" option is missing). Moreover, it also might be useful to mention the default for "len" is '1024' if the setting is missing. * this section could use a note that the '-text' option appends the PKCS#3-formatted data to the PEM-formatted data in the output. i am not knowledgeable enough re PKCS-bound app's to be aware of where this additional data might be required or if it is just a decade-old hold-over of no current value. * it also could be noted that '-outform' is ignored and the output default of 'PEM' rules (while possibly being followed by the PKCS#3 data, as indicated). not everyone is aware that there is no such thing as a DER-formatted file for DH param's. ***DH param file controls:* now, the '-out' option creates a parameter file or the output goes to stdout if missing. it is inconceivable that this option is not used in any automation mode and barely likely that it would be missing in a CLI environment because that would then require copying the stdout for insertion into some file. that leaves the possibility of errors in manual edits and the CLI/script mode wherein the stdout is '>' or '>>' to a file. obviously, '>>' or a language equivalent is an appending blooper worth preventing because the new param set will be ignored if a prior DH param set already exists in the file. using the '-out' option is a not-so-strange 'special case' that openssl itself has created. while not stated in the doc's, using this option will silently over-write any pre-existent file and, thus, create a single-use file that can only be used for the provision of custom DH param's: no other param's, key, certs, or whatever that may have been present in the original file remain after running in this mode. because this openssl-created result is a user/developer expectation (i.e., an openssl-established standard), it is reasonable to expect that openssl's down-stream modules will enforce this standard and that is not happening. later on, when the file is parsed, a search is made for the _*first*_ DH param set and everything else before and after (no matter whether it is other valid PEM data, a subsequent valid DH set, or just junk alpha-num lines) is completely ignored. it is proposed that the openssl file-creation "standard" be enforced in all modules. such enforcement would serve to guard against human error that can creep into the file via manual edits and/or faulty scripting -- such as the ages-old openssl snafu in openssl's own packages in the 'crypto/dh/dh2048.pem' file which contains two (2) valid DH param sets and has been present in every package version since at least 0.9.6. while we are mentioning this example, it would prevent people from getting the wrong idea if the like-situated files representing bit-lengths of 192, 512, and 1024 were removed since virtually all current recommendations suggest starting at 2048 bits or more in 1024-bit steps. the reason i have presented the need for further controls is because a real-world case was brought to me by one of my former students who was testing all the servers on his new job. he found that c. a third of the servers were running under very-old and far-less-secure param's than they thought were in use everywhere. we tracked it down to the same type of error that openssl itself made, supra. if nobody thinks it is a good idea for openssl to prevent mistakes such as this happening and/or make clarifying additions to the doc's, there is no need to make further reply to this thread. -- Johann -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3825 bytes Desc: S/MIME Cryptographic Signature URL: From vallesluiggi at gmail.com Tue Aug 9 17:26:44 2016 From: vallesluiggi at gmail.com (Luiggi Valles) Date: Tue, 9 Aug 2016 13:26:44 -0400 Subject: [openssl-users] Info Request Message-ID: > > > Helo. > > I'm trying to used OPENSSL to generate a sign XDAS-BES with PHP and I have > some problem but the most important is the function exec(). > > I would like to know how I do that: the exec () function does not block the > function of OpenSSL? > > Can you please tell me more about this? Please. > > Regards > Jose Valles > -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.king at quentustech.com Tue Aug 9 19:10:33 2016 From: william.king at quentustech.com (William King) Date: Tue, 9 Aug 2016 14:10:33 -0500 Subject: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr Message-ID: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> What is needed to be able to BIO_seek() on a bio_f_cipher() with a cipher of EVP_aes_256_ctr() without the counter, or IV or another internal state getting corrupted? It seems that doing a seek any direction results in corrupted output. -- William King Senior Engineer Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (877) 211-9337 Office: (206) 388-4772 Cell: (253) 686-5518 william.king at quentustech.com From bhat.jayalakshmi at gmail.com Wed Aug 10 07:09:05 2016 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Wed, 10 Aug 2016 12:39:05 +0530 Subject: [openssl-users] Certificates generated using 3k/4k CSR generated with OpenSSL fails on Windows 2008R2 Message-ID: Hi All, I am generating 1k/2k/3k/4k CSR's on our device using OpenSSL library. I am generating these CSR on our device. We have windows 2008 R2 servers and I am signing these CSR using certificate authority on windows server. I am setting only client and server authentication bits in the CSR since these are simple end entity certificates. Once certificates are generated , I am able to install the certificates on our device. These certificates are working well with 802.1x (EAP-TLS) setup on the same windows 2008 R2 server. However when I was trying to test IPsec with certificate based authentication, authentication is failing.Enabling the IPsec event viewer shows error in accepting the certificate and generates a ?invalid signature? message which looks to be generic. Failures are seen only with 3k and 4k certificates. Later I refered to a link http://blog.gentilkiwi.com/tag/bag-attributes added -LMK -CSP "xxx" -name options, certificate worked well. I wanted to know is any one having similar experience with 3k and 4k ID certificates that does not have these fields on windows system. Any help is appreciated. Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From nagesh.shamnur at huawei.com Wed Aug 10 12:25:16 2016 From: nagesh.shamnur at huawei.com (Nagesh shamnur) Date: Wed, 10 Aug 2016 12:25:16 +0000 Subject: [openssl-users] Checking for AES-NI accelration Message-ID: <4AC96705FB868F42B2075BA50F806DEB55CF95AD@szxeml512-mbs.china.huawei.com> Hi Group, I am running an application which transfers huge chunks of data every second (850Mbps) and the same is secured using openssl. However the CPU usage on windows is very high ( ~ 100%). So as a part of the analysis, I stumbled upon the information that, when using AES encryption, if the underlying hardware is Intel CPU, it can support AES-NI instruction set and hence make the crypto processing faster. So, I wanted to confirm if the same is enabled in my hardware. So, I wanted to know how to verify if the run is able to use the AES-NI instruction set available in the hardware. I have built openssl and have ensured enabling the asm in both linux and windows build. For windows, to confirm if AES-NI is enabled, support of tools available like truecrypt, CPU-Z and blackbox were used if the same was enabled in OS usage. And I found that the same is disabled. Also I found in some blogs that the same needs to be enabled in BIOS. When checked the BIOS settings, the option was not be found and a BIOS update is required to enable the same. However in linux I was unable to conclude if AES-NI is disabled since I didn?t had access to any such tools on linux. I checked "#cpuinfo | grep aes" and i was unable to find any line regarding AES-NI. However when i run the ./openssl speed -evp aes-128-gcm and OPENSSL_ia32cap="~0x200000200000000" ./openssl speed -elapsed -evp aes-128-gcm i am able to find the difference in speed. So i wanted to check how to confirm if my linux build has AES-NI enabled or not? Environment Information: CPU: E5-2620 0 @2.0GHz OS: Windows Server 2008 Linux: Ubuntu 3.11.0-15-generic Openssl versoin: 1.0.2h Mainboard: Manufacturer Huawei Technologies Co. Ltd., Model: BC11SRSH1 V100R002 BIOS: Brand: INsyde Corp, RMISV061, 06/20/2013 Regards, Nagesh. ________________________________ ???????? Huawei Technologies Co., Ltd. [Company_logo] Phone: Fax: Mobile: Email: ??????????????? ???518129 Huawei Technologies Co., Ltd. Bantian, Longgang District,Shenzhen 518129, P.R.China http://www.huawei.com ________________________________ ???????????????????????????????????????? ???????????????????????????????????????? ??????????????????????????????????? This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it! -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 6737 bytes Desc: image001.jpg URL: From jb-openssl at wisemo.com Wed Aug 10 13:15:15 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 15:15:15 +0200 Subject: [openssl-users] Info Request In-Reply-To: References: Message-ID: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> On 09/08/2016 19:26, Luiggi Valles wrote: > > > Helo. > > I'm trying to used OPENSSL to generate a sign XDAS-BES with PHP > and I have some problem but the most important is the function exec(). > > I would like to know howI do that: the exec () function does not > block the function of OpenSSL? > > Can you please tell me more about this? Please. > Please clarify: Are you using generic PHP calls to run the "openssl" command line program, or are you using a PHP extension that wraps OpenSSL calls (and if so, which one). 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 kgoldman at us.ibm.com Wed Aug 10 13:26:15 2016 From: kgoldman at us.ibm.com (Kenneth Goldman) Date: Wed, 10 Aug 2016 09:26:15 -0400 Subject: [openssl-users] Openssl and floating point In-Reply-To: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> Message-ID: We have a platform that does not support floating point operations. We discovered that openssl uses floating point in the random number generator. Is there any build or compile time flag that uses an alternative to floating point? -- Ken Goldman kgoldman at us.ibm.com 914-945-2415 (862-2415) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Aug 10 13:31:50 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 15:31:50 +0200 Subject: [openssl-users] Loading engines recursively and crypto engine lock In-Reply-To: References: Message-ID: <37bca885-b504-2299-4bd3-a7213ba7c0c5@wisemo.com> On 08/08/2016 13:39, Krzysztof Konopko wrote: > Hi, > > TL;DR; > Is it allowed to initialise engines recursively, ie. call > `engine2->init` from `engine1->init`? > > -- > > I have a solution in a consumer product based on OpenSSL 1.0.2 series > that uses two engines: one (engine1) for selecting client certificate > chain (TLS client auth) and another one (engine2) for RPC operations > on associated private keys stored in H/W. This works only if supplied > (installed) locks are recursive as for each engine initialisation > `CRYPTO_LOCK_ENGINE` is taken. > > From what I see, OpenSSL 1.1.x onward, provides locking internally and > it's non-recursive. Also `lock_dbg_cb()` implementation in OpenSSL > before 1.1.x suggests locks are not expected to be recursive. > > Here's some more context of my use case.? > > OpenSSL loads `engine1` for me automatically (` > ?? > ? > OPENSSL_SSL_CLIENT_ENGINE_AUTO` variable) which is convenient as I > don't have control over application's `main()` function. In my case > it's proprietary code but equally it could be Python script (I do not > fancy patching Python interpreter to get to its `main()` function and > load/initialise engines explicitly). > > So my _only_ entry point is `engine1->init`. In that entry point I > initialise engine2 which is a fairly slow operation (need to load > certs from permanent storage) so definitely want to do this only once. > Oh, and the app is heavily multi-threaded so I'm glad OpenSSL > carefully takes crypto engine lock where needed. > > But because engines are initialised recursively, the locking > implementation I supply uses recursive mutex which works very well and > makes perfect sense to me in this case (I know that the same thread > calls locked functions recursively for a reason). This works only > before 1.1.x. > > Alternatively I could lazy-initialise engine2 in certificate callback > function but any initialisation failure here would be less meaningful > and it would require another lock to protect engine2 handle. In > `engine1->init` I know a lock is already held so I thought it's safer > to do more initialisation here. Besides `engine2->init` is not called > directly but through a layer of application logic so conceptually > these two engines are orthogonal and know nothing about each other. > > I guess initialising engines recursively does not work in OpenSSL > 1.1.x (it'd be a dead-lock) and I need to seek for a different place > to initialise engine2, for example in certificate cb? This would mean > I "leak" some knowledge of engine2 existence into engine1, have > guarantee that crypto engine lock is not held in certificate callabck > function and need another lock to protect access to engine2 handle. > > Please let me know what your views are and if the above makes sense. > I am not part of the OpenSSL team and have no idea what their thinking or suggestions are. However the following should be a generic workaround: 1. Create a third engine3 which loads both engine1 and engine2 internally (without going through OpenSSL and its locks). So for example engine3->init calls both engine2->init and engine1->init. 2. engine3 would export/provide all the methods from engine1 and engine2 by forwarding or reexporting the calls. 3. OpenSSL itself is instructed to use only your engine3 wrapper. 4. As a more ambitious project, someone could write a generic "engine3" which loads a list of actual engines from a config file. At the OpenSSL design level, the OpenSSL team might extend the OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a colon-separatedlist of engines rather than just a single engine. 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 kris at konagma.com Wed Aug 10 13:49:46 2016 From: kris at konagma.com (Krzysztof Konopko) Date: Wed, 10 Aug 2016 15:49:46 +0200 Subject: [openssl-users] Loading engines recursively and crypto engine lock In-Reply-To: <37bca885-b504-2299-4bd3-a7213ba7c0c5@wisemo.com> References: <37bca885-b504-2299-4bd3-a7213ba7c0c5@wisemo.com> Message-ID: On 10 August 2016 at 15:31, Jakob Bohm wrote: > I am not part of the OpenSSL team and have no idea what their > thinking or suggestions are. > ?Thanks for responding! ? > > However the following should be a generic workaround: > > 1. Create a third engine3 which loads both engine1 and engine2 > internally ( > ?? > without going through OpenSSL and its locks). > So for example engine3->init calls both engine2->init and > engine1->init. > > ?I don't understand how engine3 could be initialised ?" ? without going through OpenSSL and its locks ?" as it's OpenSSL taking the lock whenever initialising _every_ engine. Also when I call `ENGINE_init()` (indirectly, somewhere deep inside engine1), the implementation of `ENGINE_init()` ? takes the engine lock. as well which is the source of the problem. ? > 2. engine3 would export/provide all the methods from engine1 > and engine2 by forwarding or reexporting the calls. > > 3. OpenSSL itself is instructed to use only your engine3 > wrapper. > > 4. As a more ambitious project, someone could write a generic > "engine3" which loads a list of actual engines from a config > file. > > At the OpenSSL design level, the OpenSSL team might extend the > OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a > colon-separatedlist of engines rather than just a single engine. > > > ?That sounds interesting but engines in general (and specifically in my case) are independent of each other and in different situations I may want to load one but not the other (for example when testing). But I guess that would be a matter of moving the configuration control from where I have it now into whatever mechanism OpenSSL could have (as proposed above). Thanks, Kris? -------------- next part -------------- An HTML attachment was scrubbed... URL: From janjust at nikhef.nl Wed Aug 10 13:28:01 2016 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 10 Aug 2016 15:28:01 +0200 Subject: [openssl-users] Checking for AES-NI accelration In-Reply-To: <4AC96705FB868F42B2075BA50F806DEB55CF95AD@szxeml512-mbs.china.huawei.com> References: <4AC96705FB868F42B2075BA50F806DEB55CF95AD@szxeml512-mbs.china.huawei.com> Message-ID: <57AB2BE1.7080301@nikhef.nl> Hi, On 10/08/16 14:25, Nagesh shamnur wrote: > > Hi Group, > > I am running an application which transfers huge chunks of data every > second (850Mbps) and the same is secured using openssl. However the > CPU usage on windows is very high ( ~ 100%). So as a part of the > analysis, I stumbled upon the information that, when using AES > encryption, if the underlying hardware is Intel CPU, it can support > AES-NI instruction set and hence make the crypto processing faster. > So, I wanted to confirm if the same is enabled in my hardware. > > So, I wanted to know how to verify if the run is able to use the > AES-NI instruction set available in the hardware. > > I have built openssl and have ensured enabling the asm in both linux > and windows build. > > For windows, to confirm if AES-NI is enabled, support of tools > available like truecrypt, CPU-Z and blackbox were used if the same was > enabled in OS usage. And I found that the same is disabled. Also I > found in some blogs that the same needs to be enabled in BIOS. When > checked the BIOS settings, the option was not be found and a BIOS > update is required to enable the same. > > However in linux I was unable to conclude if AES-NI is disabled since > I didn?t had access to any such tools on linux. I checked "#cpuinfo | > grep aes" and i was unable to find any line regarding AES-NI. However > when i run the ./openssl speed -evp aes-128-gcm and > OPENSSL_ia32cap="~0x200000200000000" ./openssl speed -elapsed -evp > aes-128-gcm i am able to find the difference in speed. So i wanted to > check how to confirm if my linux build has AES-NI enabled or not? > > Environment Information: > > CPU: E5-2620 0 @2.0GHz > > OS: Windows Server 2008 > > Linux: Ubuntu 3.11.0-15-generic > > Openssl versoin: 1.0.2h > > I've got a server with that exact same CPU over here; with openssl 1.0.2d I see the following results: $ ./openssl speed -evp aes-128-gcm [...] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 184391.41k 465791.06k 689190.61k .65k 781295.62k $ OPENSSL_ia32cap=0 ./openssl speed -evp aes-128-gcm [...] type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes aes-128-gcm 43906.03k 49490.24k 51037.70k 51554.65k 51699.71k i.e. with AES-NI disabled performance is about ~15 times less. On this CPU turboboost is not working so your numbers maybe slightly different. Another good way to test whether AES-NI is working is by comparing BF-CBC to AES-256-CBC: without AES-NI, BF will be faster. with AES-NI, AES will be faster. HTH, JJK -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Aug 10 14:19:59 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 16:19:59 +0200 Subject: [openssl-users] Loading engines recursively and crypto engine lock In-Reply-To: References: <37bca885-b504-2299-4bd3-a7213ba7c0c5@wisemo.com> Message-ID: <5a7e34ad-d1d5-04e1-e859-fafff675c2f9@wisemo.com> On 10/08/2016 15:49, Krzysztof Konopko wrote: > On 10 August 2016 at 15:31, Jakob Bohm >wrote: > > I am not part of the OpenSSL team and have no idea what their > thinking or suggestions are. > > > ?Thanks for responding! > ? > > > However the following should be a generic workaround: > > 1. Create a third engine3 which loads both engine1 and engine2 > internally ( > ?? > without going through OpenSSL and its locks). > So for example engine3->init calls both engine2->init and > engine1->init. > > > ?I don't understand how engine3 could be initialised ?" > ? > without going through OpenSSL and its locks > ?" as it's OpenSSL taking the lock whenever initialising _every_ > engine. Also when I call `ENGINE_init()` (indirectly, somewhere deep > inside engine1), the implementation of > `ENGINE_init()` > ? takes the engine lock. as well which is the source of the problem. engine3 would call engine1 and engine2 without going through a call to ENGINE_init(), thus making OpenSSL itself see the engine1 and engine2 code as part of engine3 (even though engine3 really just calls the functions in engine1 and engine2). > ? > > 2. engine3 would export/provide all the methods from engine1 > and engine2 by forwarding or reexporting the calls. > > 3. OpenSSL itself is instructed to use only your engine3 > wrapper. > > 4. As a more ambitious project, someone could write a generic > "engine3" which loads a list of actual engines from a config > file. > > At the OpenSSL design level, the OpenSSL team might extend the > OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a > colon-separatedlist of engines rather than just a single engine. > > > > ?That sounds interesting but engines in general (and specifically in > my case) are independent of each other and in different situations I > may want to load one but not the other (for example when testing). > But I guess that would be a matter of moving the configuration control > from where I have it now into whatever mechanism OpenSSL could have > (as proposed above). The idea would be that "engine3" would be a workaround engine that simulates the (possibly missing) ability to specify multiple engines via the OPENSSL_SSL_CLIENT_ENGINE_AUTO variable. This not-independent engine3 would do nothing but load other engines, and may or may not be configurable as to which real engines it loads. By doing this, engine3 would also compensate for the fact that many other OpenSSL APIs seem to allow only a single engine reference as parameter. With engine3 responsible for initializing engine2 before engine1, engine1 would no longer contain code to load engine2, making engine1 more independent from engine2. 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 rsalz at akamai.com Wed Aug 10 14:28:59 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 10 Aug 2016 14:28:59 +0000 Subject: [openssl-users] Openssl and floating point In-Reply-To: References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> Message-ID: > We have a platform that does not support floating point operations. ?We discovered that openssl uses floating point in the random number generator. There are other places, too, like bio_print, the poly135 code, etc. Good luck... > Is there any build or compile time flag that uses an alternative to floating point? -Ddouble=long ? :) From aerowolf at gmail.com Wed Aug 10 14:51:18 2016 From: aerowolf at gmail.com (Kyle Hamilton) Date: Wed, 10 Aug 2016 07:51:18 -0700 Subject: [openssl-users] Openssl and floating point In-Reply-To: References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> Message-ID: This is compiler-dependent, and because you didn't specify what platform you're targeting or what compiler you're using, there's no way for us to provide an answer. Check your compiler's documentation. GCC, for example, provides software-emulated floating point for platforms without hardware support. Many other open-source and commercial compilers do as well. -Kyle H On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman wrote: > We have a platform that does not support floating point operations. We > discovered that openssl uses floating point in the random number generator. > > Is there any build or compile time flag that uses an alternative to > floating point? > > -- > Ken Goldman kgoldman at us.ibm.com > 914-945-2415 (862-2415) > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kris at konagma.com Wed Aug 10 15:46:22 2016 From: kris at konagma.com (Krzysztof Konopko) Date: Wed, 10 Aug 2016 17:46:22 +0200 Subject: [openssl-users] Loading engines recursively and crypto engine lock In-Reply-To: <5a7e34ad-d1d5-04e1-e859-fafff675c2f9@wisemo.com> References: <37bca885-b504-2299-4bd3-a7213ba7c0c5@wisemo.com> <5a7e34ad-d1d5-04e1-e859-fafff675c2f9@wisemo.com> Message-ID: On 10 August 2016 at 16:19, Jakob Bohm wrote: > On 10/08/2016 15:49, Krzysztof Konopko wrote: > >> On 10 August 2016 at 15:31, Jakob Bohm > jb-openssl at wisemo.com>>wrote: >> ? >> 1. Create a third engine3 which loads both engine1 and engine2 >> internally ( >> ?? >> without going through OpenSSL and its locks). >> So for example engine3->init calls both engine2->init and >> engine1->init. >> >> >> ?I don't understand how engine3 could be initialised ?" >> ? >> without going through OpenSSL and its locks >> ?" as it's OpenSSL taking the lock whenever initialising _every_ engine. >> Also when I call `ENGINE_init()` (indirectly, somewhere deep inside >> engine1), the implementation of >> `ENGINE_init()` >> ? takes the engine lock. as well which is the source of the problem. >> > engine3 would call engine1 and engine2 without going through > a call to ENGINE_init(), thus making OpenSSL itself see the > engine1 and engine2 code as part of engine3 (even though > engine3 really just calls the functions in engine1 and > engine2). ?Oh, I see. engine1 and engine2 would expose individual functions which engine3 would bound as its engine function own (or use some plumbing to forward calls to the original functions). This means engine3 would either link with engine1 and engine2 libraries or `dlopen()` them. Or something like that. I think I get the idea now. ? > > ? >> >> 2. engine3 would export/provide all the methods from engine1 >> and engine2 by forwarding or reexporting the calls. >> >> 3. OpenSSL itself is instructed to use only your engine3 >> wrapper. >> >> 4. As a more ambitious project, someone could write a generic >> "engine3" which loads a list of actual engines from a config >> file. >> >> At the OpenSSL design level, the OpenSSL team might extend the >> OPENSSL_SSL_CLIENT_ENGINE_AUTOvariable to accept a >> colon-separatedlist of engines rather than just a single engine. >> >> >> >> ?That sounds interesting but engines in general (and specifically in my >> case) are independent of each other and in different situations I may want >> to load one but not the other (for example when testing). But I guess that >> would be a matter of moving the configuration control from where I have it >> now into whatever mechanism OpenSSL could have (as proposed above). >> > The idea would be that "engine3" would be a workaround engine > that simulates the (possibly missing) ability to specify > multiple engines via the OPENSSL_SSL_CLIENT_ENGINE_AUTO > variable. This not-independent engine3 would do nothing but > load other engines, and may or may not be configurable as to > which real engines it loads. By doing this, engine3 would also > compensate for the fact that many other OpenSSL APIs seem to > allow only a single engine reference as parameter. > > With engine3 responsible for initializing engine2 before engine1, > engine1 would no longer contain code to load engine2, making > engine1 more independent from engine2. > > > > ?OK, fair enough. That makes sense. In my case some re-factoring would be required as the code that initialises engine2 does so explicitly with `ENGINE_by_id()` and `ENGINE_init()` and it doesn't "know" it's called from engine1. And vice versa, engine1 does not know that the code it calls loads and initialises an engine. But I get the idea and it seems plausible. Also it's important to me that this way or the other there's someone who admits OpenSSL has a problem with loading engines recursively (or does not support that intentionally) and I need to address that. Thanks again! Kris? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Aug 10 15:52:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 17:52:46 +0200 Subject: [openssl-users] Openssl and floating point In-Reply-To: References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> Message-ID: (Top posting for consistency in this part of the thread) Note, however that emulated floating point tends to add code size and startup overhead even when not called. Hence the need to compile with an option to not use floating point at all, at least on platforms that don't have platform- specific optimizations via hardware floating point (such as the SSE optimizations for some operations on x86 or the VFP optimizations on later ARM hardware types). Rich suggested a "hackish" preprocessor trick, which depends on no current or future OpenSSL code using floating point in a way that is seriously broken by that trick. On 10/08/2016 16:51, Kyle Hamilton wrote: > This is compiler-dependent, and because you didn't specify what > platform you're targeting or what compiler you're using, there's no > way for us to provide an answer. Check your compiler's documentation. > GCC, for example, provides software-emulated floating point for > platforms without hardware support. Many other open-source and > commercial compilers do as well. > > On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman >wrote: > > We have a platform that does not support floating point > operations. We discovered that openssl uses floating point in the > random number generator. > > Is there any build or compile time flag that uses an alternative > to floating point? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Wed Aug 10 16:00:21 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 18:00:21 +0200 Subject: [openssl-users] output from: dh, dhparam, pkeyparam In-Reply-To: <57f734fb-0728-2d83-b64c-6febc53fab38@akamai.com> References: <57A5F4D6.4030201@forthepolls.org> <57f734fb-0728-2d83-b64c-6febc53fab38@akamai.com> Message-ID: <032bc7ec-61aa-17ad-1eae-34b3bcad903c@wisemo.com> On 08/08/2016 16:51, Benjamin Kaduk wrote: > What Rich said, and also note that it's perfectly valid usage of the > PEM routines to read one type from a BIO and then go on to read > another (potentially different) type from the same BIO, as would > happen if they were in the same file concatenated after each other. > So, attempting to peek and see if there was other stuff after the read > PEM object would be a strange special case. > Maybe there should be a general check-no-more-data-in-file(BIO*,bool*bIsPEM) routine called from the functions that take a file name as argument, open it as a BIO, loads some PEM data and closes the BIO, thus giving the caller no opportunity to use (or check for) any extra PEM blocks (or DER blocks for DER input). 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 bkaduk at akamai.com Wed Aug 10 16:45:25 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 10 Aug 2016 11:45:25 -0500 Subject: [openssl-users] output from: dh, dhparam, pkeyparam In-Reply-To: <032bc7ec-61aa-17ad-1eae-34b3bcad903c@wisemo.com> References: <57A5F4D6.4030201@forthepolls.org> <57f734fb-0728-2d83-b64c-6febc53fab38@akamai.com> <032bc7ec-61aa-17ad-1eae-34b3bcad903c@wisemo.com> Message-ID: <1cfb9491-1e24-fbed-0e79-a48a9a0612bb@akamai.com> On 08/10/2016 11:00 AM, Jakob Bohm wrote: > On 08/08/2016 16:51, Benjamin Kaduk wrote: >> What Rich said, and also note that it's perfectly valid usage of the >> PEM routines to read one type from a BIO and then go on to read >> another (potentially different) type from the same BIO, as would >> happen if they were in the same file concatenated after each other. >> So, attempting to peek and see if there was other stuff after the >> read PEM object would be a strange special case. >> > Maybe there should be a general > check-no-more-data-in-file(BIO*,bool*bIsPEM) > routine called from the functions that take a file name as > argument, open it as a BIO, loads some PEM data and closes > the BIO, thus giving the caller no opportunity to use (or > check for) any extra PEM blocks (or DER blocks for DER > input). That level of foot-shooting-protection seems overkill to me, though my opinion doesn't really matter since I'm not on the dev team. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From norm.green at gemtalksystems.com Wed Aug 10 17:02:03 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Wed, 10 Aug 2016 10:02:03 -0700 Subject: [openssl-users] Checking for AES-NI accelration In-Reply-To: <57AB2BE1.7080301@nikhef.nl> References: <4AC96705FB868F42B2075BA50F806DEB55CF95AD@szxeml512-mbs.china.huawei.com> <57AB2BE1.7080301@nikhef.nl> Message-ID: <7f78b983-bad6-6720-d082-86dc96d1d9c6@gemtalksystems.com> I've been wondering how and when OpenSSL decides whether it can use the new aes instructions? Does it decide at build time or at run time? If I build on a CPU that supports aes instructions but run on a cpu that does not, will bad things happen? Or is OpenSSL smart enough to call functions implemented without aes instructions in that case? Norm Green On 8/10/16 06:28, Jan Just Keijser wrote: > Hi, > > On 10/08/16 14:25, Nagesh shamnur wrote: >> >> Hi Group, >> >> I am running an application which transfers huge chunks of data every >> second (850Mbps) and the same is secured using openssl. However the >> CPU usage on windows is very high ( ~ 100%). So as a part of the >> analysis, I stumbled upon the information that, when using AES >> encryption, if the underlying hardware is Intel CPU, it can support >> AES-NI instruction set and hence make the crypto processing faster. >> So, I wanted to confirm if the same is enabled in my hardware. >> >> So, I wanted to know how to verify if the run is able to use the >> AES-NI instruction set available in the hardware. >> >> I have built openssl and have ensured enabling the asm in both linux >> and windows build. >> >> For windows, to confirm if AES-NI is enabled, support of tools >> available like truecrypt, CPU-Z and blackbox were used if the same >> was enabled in OS usage. And I found that the same is disabled. Also >> I found in some blogs that the same needs to be enabled in BIOS. When >> checked the BIOS settings, the option was not be found and a BIOS >> update is required to enable the same. >> >> However in linux I was unable to conclude if AES-NI is disabled since >> I didn?t had access to any such tools on linux. I checked "#cpuinfo | >> grep aes" and i was unable to find any line regarding AES-NI. However >> when i run the ./openssl speed -evp aes-128-gcm and >> OPENSSL_ia32cap="~0x200000200000000" ./openssl speed -elapsed -evp >> aes-128-gcm i am able to find the difference in speed. So i wanted to >> check how to confirm if my linux build has AES-NI enabled or not? >> >> Environment Information: >> >> CPU: E5-2620 0 @2.0GHz >> >> OS: Windows Server 2008 >> >> Linux: Ubuntu 3.11.0-15-generic >> >> Openssl versoin: 1.0.2h >> >> > I've got a server with that exact same CPU over here; with openssl > 1.0.2d I see the following results: > > $ ./openssl speed -evp aes-128-gcm > [...] > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > aes-128-gcm 184391.41k 465791.06k 689190.61k .65k 781295.62k > > $ OPENSSL_ia32cap=0 ./openssl speed -evp aes-128-gcm > [...] > type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 > bytes > aes-128-gcm 43906.03k 49490.24k 51037.70k 51554.65k > 51699.71k > > i.e. with AES-NI disabled performance is about ~15 times less. On this > CPU turboboost is not working so your numbers maybe slightly different. > Another good way to test whether AES-NI is working is by comparing > BF-CBC to AES-256-CBC: without AES-NI, BF will be faster. with AES-NI, > AES will be faster. > > HTH, > > JJK > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Aug 10 17:20:59 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 10 Aug 2016 19:20:59 +0200 Subject: [openssl-users] Checking for AES-NI accelration In-Reply-To: <7f78b983-bad6-6720-d082-86dc96d1d9c6@gemtalksystems.com> References: <4AC96705FB868F42B2075BA50F806DEB55CF95AD@szxeml512-mbs.china.huawei.com> <57AB2BE1.7080301@nikhef.nl> <7f78b983-bad6-6720-d082-86dc96d1d9c6@gemtalksystems.com> Message-ID: On 10/08/2016 19:02, Norm Green wrote: > I've been wondering how and when OpenSSL decides whether it can use > the new aes instructions? Does it decide at build time or at run time? > > If I build on a CPU that supports aes instructions but run on a cpu > that does not, will bad things happen? Or is OpenSSL smart enough to > call functions implemented without aes instructions in that case? > > Runtime. See the file crypto/x86cpuid.pl which gets converted to compiler-specific assembler source code. 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 sivagopi059 at gmail.com Thu Aug 11 10:18:16 2016 From: sivagopi059 at gmail.com (siva gopi raju kudeti) Date: Thu, 11 Aug 2016 15:48:16 +0530 Subject: [openssl-users] CVE-2016-2180 Message-ID: Hi OpenSSL team, I am using openssl-1.0.0e in my product. Here i want to know that OpenSSL is CVE-2016-2180 vulnerable or not. https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca373 65e8c7403a?diff=unified In this page showing some modifications to the function TS_OBJ_print_bio. Is these changes are fix this vulnerability? Here i don't know how to test this vulnerability. Can you please provide me with the test process or ant other information about this vulnerability to go further. I will wait for your reply. best regards, Gopi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Aug 11 12:23:10 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Aug 2016 12:23:10 +0000 Subject: [openssl-users] CVE-2016-2180 In-Reply-To: References: Message-ID: <7ec825ce3af1496197691bb9ade9c659@usma1ex-dag1mb1.msg.corp.akamai.com> There is no test. That fix can be applied. 1.0.0 is really old and unsupported, you should upgrade as soon as possible -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: siva gopi raju kudeti [mailto:sivagopi059 at gmail.com] Sent: Thursday, August 11, 2016 6:18 AM To: openssl-users at openssl.org Subject: [openssl-users] CVE-2016-2180 Hi OpenSSL team, I am using openssl-1.0.0e in my product. Here i want to know that OpenSSL is CVE-2016-2180 vulnerable or not. https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a?diff=unified In this page showing some modifications to the function TS_OBJ_print_bio. Is these changes are fix this vulnerability? Here i don't know how to test this vulnerability. Can you please provide me with the test process or ant other information about this vulnerability to go further. I will wait for your reply. best regards, Gopi. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Thu Aug 11 15:20:41 2016 From: tshort at akamai.com (Short, Todd) Date: Thu, 11 Aug 2016 15:20:41 +0000 Subject: [openssl-users] Openssl and floating point In-Reply-To: References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> Message-ID: <5B64FFCE-8739-4010-9439-DE69130203A9@akamai.com> The -Ddouble=long hack might very well cause problems with standard headers. I?m assuming you are not talking about x86 or any other platform for which there is assembly support. In such a case, I suggest #ifdef?ing out the code that you don?t care about, and making it into a configuration option, the submitting a patch for it. There may be some use for this configuration, especially on low-power IoT-type things. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 10, 2016, at 11:52 AM, Jakob Bohm > wrote: (Top posting for consistency in this part of the thread) Note, however that emulated floating point tends to add code size and startup overhead even when not called. Hence the need to compile with an option to not use floating point at all, at least on platforms that don't have platform- specific optimizations via hardware floating point (such as the SSE optimizations for some operations on x86 or the VFP optimizations on later ARM hardware types). Rich suggested a "hackish" preprocessor trick, which depends on no current or future OpenSSL code using floating point in a way that is seriously broken by that trick. On 10/08/2016 16:51, Kyle Hamilton wrote: This is compiler-dependent, and because you didn't specify what platform you're targeting or what compiler you're using, there's no way for us to provide an answer. Check your compiler's documentation. GCC, for example, provides software-emulated floating point for platforms without hardware support. Many other open-source and commercial compilers do as well. On Wed, Aug 10, 2016 at 6:26 AM, Kenneth Goldman >wrote: We have a platform that does not support floating point operations. We discovered that openssl uses floating point in the random number generator. Is there any build or compile time flag that uses an alternative to floating point? 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From william.king at quentustech.com Thu Aug 11 15:29:46 2016 From: william.king at quentustech.com (William King) Date: Thu, 11 Aug 2016 10:29:46 -0500 Subject: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr In-Reply-To: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> References: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> Message-ID: Without any of the error checking code in place, this is what I'm testing: /* START CODE BLOCK */ const EVP_CIPHER *cipher = EVP_aes_256_ctr(); const EVP_MD *digest = EVP_sha256(); BIO *enc = BIO_new(BIO_f_cipher()); BIO *in = BIO_new(BIO_s_file()); EVP_CIPHER_CTX *ctx = NULL; char *path = "/path/to/file.wav", *key = "fake secret key", *iv = "fake iv"; BIO_get_cipher_ctx(enc, &context->ctx); if (BIO_read_filename(in, path) <= 0 ) { assert(0); } BIO_push(enc, in); BIO_set_cipher(enc, cipher, key, iv, 0); BIO_seek(enc, 2056); BIO_read(enc, buffer, 128); /* END CODE BLOCK */ What I'm finding is that using fread() of the unencrypted file and comparing that to the BIO_seek() then BIO_read(), the data is not properly decrypted. Comparing fread() of the unencrypted file, to just doing BIO_read()'s does decrypt the file correctly. William King Senior Engineer Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (877) 211-9337 Office: (206) 388-4772 Cell: (253) 686-5518 william.king at quentustech.com On 8/9/16 2:10 PM, William King wrote: > What is needed to be able to BIO_seek() on a bio_f_cipher() with a > cipher of EVP_aes_256_ctr() without the counter, or IV or another > internal state getting corrupted? > > It seems that doing a seek any direction results in corrupted output. > From william.king at quentustech.com Thu Aug 11 15:38:20 2016 From: william.king at quentustech.com (William King) Date: Thu, 11 Aug 2016 10:38:20 -0500 Subject: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr In-Reply-To: References: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> Message-ID: <8d76f6aa-a04b-61d1-b7cf-2c2efdc361bc@quentustech.com> Same decryption issue happens if I run something like: char buffer[1024] = {}, buffer2[1024] = {0}; size_t pos = BIO_tell(enc); BIO_read(enc, buffer, 1024); BIO_seek(enc, pos); BIO_read(enc, buffer2, 1024); if (memcmp(buffer, buffer2, 1024)) { printf("Mismatched\n"); } else { printf("Matched\n"); } Does the BIO_seek() not handle incrementing or decrementing the IV counter? is there a callback that needs to be set to calculate what the IV counter value should be for a given file position for the cipher? William King Senior Engineer Quentus Technologies, INC 1037 NE 65th St Suite 273 Seattle, WA 98115 Main: (877) 211-9337 Office: (206) 388-4772 Cell: (253) 686-5518 william.king at quentustech.com On 8/11/16 10:29 AM, William King wrote: > Without any of the error checking code in place, this is what I'm testing: > > /* START CODE BLOCK */ > const EVP_CIPHER *cipher = EVP_aes_256_ctr(); > const EVP_MD *digest = EVP_sha256(); > BIO *enc = BIO_new(BIO_f_cipher()); > BIO *in = BIO_new(BIO_s_file()); > EVP_CIPHER_CTX *ctx = NULL; > char *path = "/path/to/file.wav", *key = "fake secret key", *iv = "fake iv"; > > BIO_get_cipher_ctx(enc, &context->ctx); > > if (BIO_read_filename(in, path) <= 0 ) { > assert(0); > } > > BIO_push(enc, in); > > BIO_set_cipher(enc, cipher, key, iv, 0); > > BIO_seek(enc, 2056); > > BIO_read(enc, buffer, 128); > > /* END CODE BLOCK */ > > What I'm finding is that using fread() of the unencrypted file and > comparing that to the BIO_seek() then BIO_read(), the data is not > properly decrypted. Comparing fread() of the unencrypted file, to just > doing BIO_read()'s does decrypt the file correctly. > > William King > Senior Engineer > Quentus Technologies, INC > 1037 NE 65th St Suite 273 > Seattle, WA 98115 > Main: (877) 211-9337 > Office: (206) 388-4772 > Cell: (253) 686-5518 > william.king at quentustech.com > > On 8/9/16 2:10 PM, William King wrote: >> What is needed to be able to BIO_seek() on a bio_f_cipher() with a >> cipher of EVP_aes_256_ctr() without the counter, or IV or another >> internal state getting corrupted? >> >> It seems that doing a seek any direction results in corrupted output. >> From rsalz at akamai.com Thu Aug 11 16:57:00 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 11 Aug 2016 16:57:00 +0000 Subject: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr In-Reply-To: <8d76f6aa-a04b-61d1-b7cf-2c2efdc361bc@quentustech.com> References: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> <8d76f6aa-a04b-61d1-b7cf-2c2efdc361bc@quentustech.com> Message-ID: <6d3751a26f7a43bc8f813217546fcb73@usma1ex-dag1mb1.msg.corp.akamai.com> > Does the BIO_seek() not handle incrementing or decrementing the IV > counter? is there a callback that needs to be set to calculate what the IV > counter value should be for a given file position for the cipher? It does not. From steve at openssl.org Thu Aug 11 18:09:27 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 11 Aug 2016 18:09:27 +0000 Subject: [openssl-users] BIO_seek() on bio_f_cipher with EVP_aes_256_ctr In-Reply-To: <8d76f6aa-a04b-61d1-b7cf-2c2efdc361bc@quentustech.com> References: <10faaff9-6277-fcf8-1db5-549faa4fe8f3@quentustech.com> <8d76f6aa-a04b-61d1-b7cf-2c2efdc361bc@quentustech.com> Message-ID: <20160811180927.GA25219@openssl.org> On Thu, Aug 11, 2016, William King wrote: > > > Does the BIO_seek() not handle incrementing or decrementing the IV > counter? is there a callback that needs to be set to calculate what the > IV counter value should be for a given file position for the cipher? > Calling BIO_seek() on a chain of BIOs can have unpredictable results especially if any buffer data or have internal state. I'd suggest you use the cipher directly instead of through a cipher BIO. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Fri Aug 12 00:03:52 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 12 Aug 2016 02:03:52 +0200 Subject: [openssl-users] iOS assembler questions In-Reply-To: <48cb6c60-49e2-055d-d863-21d280ba1b94@wisemo.com> References: <48cb6c60-49e2-055d-d863-21d280ba1b94@wisemo.com> Message-ID: <47b3b2a5-8792-94c6-e2b3-dd3fbebc8e12@wisemo.com> On 04/08/2016 19:19, Jakob Bohm wrote: > I am trying to build the OpenSSL 1.0.2h ARM optimized assembler > routines for Apple iOS (the default build config doesn't do that > yet). > > However the Apple version of the LLVM 7.3.0 ARM assembler seems > to reject some of the notation used by the current source code > (.type, .size and address subtraction). > > Is there a known workaround/solution, or should I create my own > patch to fix this? > Bump 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 rakshesh.1.bhatt at nokia.com Fri Aug 12 05:02:13 2016 From: rakshesh.1.bhatt at nokia.com (Bhatt, Rakshesh 1. (Nokia - IN/Bangalore)) Date: Fri, 12 Aug 2016 05:02:13 +0000 Subject: [openssl-users] Is authorized_keys2 read in Openssh version 4/5.x? Message-ID: Hi OpenSSL team, How can I find out if authorized_keys2 is read in Openssh version 4.x/5.x? I understand that this is deprecated from version 3.0 onwards, but release notes of version 3.0 just says that," Future releases are likely not to read these files." So I am not able to tell for sure that it is not used in subsequent release or not. Regards, Rakshesh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Aug 12 06:31:53 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 12 Aug 2016 08:31:53 +0200 Subject: [openssl-users] Is authorized_keys2 read in Openssh version 4/5.x? In-Reply-To: References: Message-ID: <50c95f0c-a1f8-d021-ba8d-445fcd2c302a@wisemo.com> On 12/08/2016 07:02, Bhatt, Rakshesh 1. (Nokia - IN/Bangalore) wrote: > > Hi OpenSSL team, > > How can I find out if authorized_keys2 is read in Openssh version > 4.x/5.x? I understand that this is deprecated from version 3.0 > onwards, but release notes of version 3.0 just says that,?Future > releases are likely not to read these files.?So I am not able to tell > for sure that it is not used in subsequent release or not. > UTSL or just RTFM, both contain the answer (I just checked in OpenSSH 7.2, and the answer is clearly visible in both source and documentation). (For the OpenSSH 7.2 source I checked, the answer seems to be yes). 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 scott_n at xypro.com Fri Aug 12 19:10:49 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 12 Aug 2016 19:10:49 +0000 Subject: [openssl-users] CVE-2016-2177 Message-ID: CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. Does this mean that the fix is not applied to the 1.0.1 series (in particular 1.0.1t)? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Aug 12 19:20:46 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 12 Aug 2016 19:20:46 +0000 Subject: [openssl-users] CVE-2016-2177 In-Reply-To: References: Message-ID: Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Scott Neugroschl [mailto:scott_n at xypro.com] Sent: Friday, August 12, 2016 3:11 PM To: openssl-users at openssl.org Subject: [openssl-users] CVE-2016-2177 CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. Does this mean that the fix is not applied to the 1.0.1 series (in particular 1.0.1t)? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Fri Aug 12 20:00:52 2016 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 12 Aug 2016 16:00:52 -0400 Subject: [openssl-users] Openssl and floating point In-Reply-To: <5B64FFCE-8739-4010-9439-DE69130203A9@akamai.com> References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> <5B64FFCE-8739-4010-9439-DE69130203A9@akamai.com> Message-ID: On 8/11/2016 11:20 AM, Short, Todd wrote: > > In such a case, I suggest #ifdef?ing out the code that you don?t care > about, and making it into a configuration option, the submitting a patch > for it. I wouldn't go near deciding what "I don't care about". There is history to non-experts #ifdef'ing out code in the random number generator and it didn't go well. :-( From rsalz at akamai.com Sat Aug 13 02:04:57 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 13 Aug 2016 02:04:57 +0000 Subject: [openssl-users] Openssl and floating point In-Reply-To: References: <89900da4-a9a9-f3d6-4960-afb6f6dd171d@wisemo.com> <5B64FFCE-8739-4010-9439-DE69130203A9@akamai.com> Message-ID: <8fd649cdc4294a83a17e7423a18a8501@usma1ex-dag1mb1.msg.corp.akamai.com> > I wouldn't go near deciding what "I don't care about". There is history to > non-experts #ifdef'ing out code in the random number generator and it > didn't go well. :-( True :) The parameter here is a user-supplied measure of the entropy being added. You can fix it to an integral constant appropriate for your platform. There's really no need for it to be floating-point. Oh well. From thomas.knauth at googlemail.com Mon Aug 15 06:49:08 2016 From: thomas.knauth at googlemail.com (Thomas Knauth) Date: Mon, 15 Aug 2016 08:49:08 +0200 Subject: [openssl-users] additional data (MAC'ed only) over TLS connection? Message-ID: Hi list, the EVP_EncryptUpdate function has the option to pass data that is only MAC'ed but not encrypted. Is there some similar provision in the BIO interface? I have a use case, where I'd like to "inject" pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a low-effort way to do this? Kind regards, Thomas. From vaporg at gmail.com Mon Aug 15 11:23:18 2016 From: vaporg at gmail.com (Vladimir A. Petrov) Date: Mon, 15 Aug 2016 19:23:18 +0800 Subject: [openssl-users] Migration from AES_ctr128_encrypt to EVP In-Reply-To: <20160808150729.GA30454@openssl.org> References: <20160808150729.GA30454@openssl.org> Message-ID: Hello Steve, I was solved. Actually we had a bit old version of the OpenSSL library in our repository which didn't contain CTR support. Upgrade resolved the problem. BTW, e.g. this page https://www.openssl.org/docs/manmaster/crypto/ does not have a reference on EVP_aes_128_ctr. Thanks, Vladimir. On Aug 8, 2016 11:08 PM, "Dr. Stephen Henson" wrote: > On Mon, Aug 08, 2016, Vladimir A. Petrov wrote: > > > Hello, > > > > I need to migrate some code from the old style software implemented > > AES_ctr128_encrypt to the EVP interface. I spent pretty much time reading > > OpenSSL manual pages and Wiki as well as googling. Unfortunately, I still > > can't get an idea how to migrate from these AES_* functions to the API > > provided by EVP. The closest info that I found is the proposal made by Dr > > Stephen N. Henson ( > > https://mta.openssl.org/pipermail/openssl-users/2015-March/000776.html) > to > > switch to EVP_aes_128_ctr, but there is no such 'ctr' mode in EVP for > AES. > > > > > > I'm not sure what you mean by "but there is no such 'ctr' mode in EVP for > AES": can you clarify? > > 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 rsalz at akamai.com Mon Aug 15 11:44:37 2016 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 15 Aug 2016 11:44:37 +0000 Subject: [openssl-users] additional data (MAC'ed only) over TLS connection? In-Reply-To: References: Message-ID: > the EVP_EncryptUpdate function has the option to pass data that is only > MAC'ed but not encrypted. Is there some similar provision in the BIO > interface? I have a use case, where I'd like to "inject" > pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a low- > effort way to do this? You mean you have an SSL BIO, and you want to avoid the SSL encryption/record-layer/etc for part of it? Not possible. From steve at openssl.org Mon Aug 15 11:56:22 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 15 Aug 2016 11:56:22 +0000 Subject: [openssl-users] additional data (MAC'ed only) over TLS connection? In-Reply-To: References: Message-ID: <20160815115622.GA16224@openssl.org> On Mon, Aug 15, 2016, Thomas Knauth wrote: > Hi list, > > the EVP_EncryptUpdate function has the option to pass data that is > only MAC'ed but not encrypted. Is there some similar provision in the > BIO interface? I have a use case, where I'd like to "inject" > pre-encrypted/pre-mac'ed data into a TLS stream. Any suggestion on a > low-effort way to do this? > In the BIO interface as such, no. However you can retrieve the EVP_CIPHER_CTX associated with the BIO and handle things that way. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From norm.green at gemtalksystems.com Mon Aug 15 19:03:59 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 15 Aug 2016 12:03:59 -0700 Subject: [openssl-users] EVP_SealInit question Message-ID: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> The man page for EVP_SealInit says: "The public key must be RSA because it is the only OpenSSL public key algorithm that supports key transport." 1 ) Is this still true? 2) Will this restriction change now that RSA key transport is being dropped from TLS 1.3 (or so I've read...)? Norm Green -------------- next part -------------- An HTML attachment was scrubbed... URL: From Marcus.Daniel at profil.com Mon Aug 15 19:22:55 2016 From: Marcus.Daniel at profil.com (Marcus.Daniel at profil.com) Date: Mon, 15 Aug 2016 21:22:55 +0200 Subject: [openssl-users] =?iso-8859-1?q?AUTO=3A_Marcus_Daniel_is_out_of_th?= =?iso-8859-1?q?e_office_=28R=FCckkehr_am_17=2E08=2E2016=29?= Message-ID: Ich kehre zur?ck am 17.08.2016. Hinweis: Dies ist eine automatische Antwort auf Ihre Nachricht "[openssl-users] EVP_SealInit question" gesendet am 15.08.2016 21:03:59. Diese ist die einzige Benachrichtigung, die Sie empfangen werden, w?hrend diese Person abwesend ist. From steve at openssl.org Mon Aug 15 21:38:30 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Mon, 15 Aug 2016 21:38:30 +0000 Subject: [openssl-users] EVP_SealInit question In-Reply-To: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> Message-ID: <20160815213830.GA26884@openssl.org> On Mon, Aug 15, 2016, Norm Green wrote: > The man page for EVP_SealInit says: > > "The public key must be RSA because it is the only OpenSSL public > key algorithm that supports key transport." > > 1 ) Is this still true? Yes: the only algorithm we currently support which handles key transport is RSA. > 2) Will this restriction change now that RSA key transport is being > dropped from TLS 1.3 (or so I've read...)? > Don't undertand. The algorithm limitation has nothing to do with TLS restrictions. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From norm.green at gemtalksystems.com Mon Aug 15 22:09:16 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 15 Aug 2016 15:09:16 -0700 Subject: [openssl-users] EVP_SealInit question In-Reply-To: <20160815213830.GA26884@openssl.org> References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> <20160815213830.GA26884@openssl.org> Message-ID: Ok, thanks. What I don't understand is what key transport has to do with EV_SealInit() ? Why is key transport important here ? Norm Green On 8/15/2016 2:38 PM, Dr. Stephen Henson wrote: > On Mon, Aug 15, 2016, Norm Green wrote: > >> The man page for EVP_SealInit says: >> >> "The public key must be RSA because it is the only OpenSSL public >> key algorithm that supports key transport." >> >> 1 ) Is this still true? > Yes: the only algorithm we currently support which handles key transport is > RSA. > >> 2) Will this restriction change now that RSA key transport is being >> dropped from TLS 1.3 (or so I've read...)? >> > Don't undertand. The algorithm limitation has nothing to do with TLS > restrictions. > > 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 Aug 16 00:31:43 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 16 Aug 2016 00:31:43 +0000 Subject: [openssl-users] EVP_SealInit question In-Reply-To: References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> <20160815213830.GA26884@openssl.org> Message-ID: <20160816003143.GA32627@openssl.org> On Mon, Aug 15, 2016, Norm Green wrote: > Ok, thanks. > > What I don't understand is what key transport has to do with > EV_SealInit() ? Why is key transport important here ? > Because EVP_SealInit() generates a random symmetric key and encrypts it using one or more public keys. For this to work the public key algorithm has to support encryption of the symmetric key using a public key aka key transport. Of the public key algorithms OpenSSL currently implements only RSA has that operation. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From norm.green at gemtalksystems.com Tue Aug 16 00:38:36 2016 From: norm.green at gemtalksystems.com (Norm Green) Date: Mon, 15 Aug 2016 17:38:36 -0700 Subject: [openssl-users] EVP_SealInit question In-Reply-To: <20160816003143.GA32627@openssl.org> References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> <20160815213830.GA26884@openssl.org> <20160816003143.GA32627@openssl.org> Message-ID: <572c8c83-f7de-cea6-2652-e4f72a61b3bd@gemtalksystems.com> Sorry, I'm still not quite getting it. It sounds like you're saying that only RSA supports encrypting with a public key. But can't any asymmetric encryption algorithm encrypt using the public key? Why is RSA special in this regard? Norm Green On 8/15/2016 5:31 PM, Dr. Stephen Henson wrote: > On Mon, Aug 15, 2016, Norm Green wrote: > >> Ok, thanks. >> >> What I don't understand is what key transport has to do with >> EV_SealInit() ? Why is key transport important here ? >> > Because EVP_SealInit() generates a random symmetric key and encrypts it using > one or more public keys. For this to work the public key algorithm has to > support encryption of the symmetric key using a public key aka key transport. > > Of the public key algorithms OpenSSL currently implements only RSA has that > operation. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org From jb-openssl at wisemo.com Tue Aug 16 02:34:09 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 16 Aug 2016 04:34:09 +0200 Subject: [openssl-users] EVP_SealInit question In-Reply-To: <572c8c83-f7de-cea6-2652-e4f72a61b3bd@gemtalksystems.com> References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> <20160815213830.GA26884@openssl.org> <20160816003143.GA32627@openssl.org> <572c8c83-f7de-cea6-2652-e4f72a61b3bd@gemtalksystems.com> Message-ID: <9aef5b21-65f3-073b-3058-532fc68ea2c9@wisemo.com> There are (generally) 3 kinds of asymmetric cryptographic algorithms: 1. Signature algorithms, such as DSS, ECDSS, Ed255, and 3 modes of the RSA algorithm. 2. Key exchange/generation algorithms such as DH, ECDH and SRP. 3. Key encryption algorithms, such as 2 other modes of the RSA algorithm. EVP_SealInit() is a function to invoke key encryption algorithms with a brand new random key. On 16/08/2016 02:38, Norm Green wrote: > Sorry, I'm still not quite getting it. > > It sounds like you're saying that only RSA supports encrypting with a > public key. But can't any asymmetric encryption algorithm encrypt > using the public key? Why is RSA special in this regard? > > Norm Green > > On 8/15/2016 5:31 PM, Dr. Stephen Henson wrote: >> On Mon, Aug 15, 2016, Norm Green wrote: >> >>> Ok, thanks. >>> >>> What I don't understand is what key transport has to do with >>> EV_SealInit() ? Why is key transport important here ? >>> >> Because EVP_SealInit() generates a random symmetric key and encrypts >> it using >> one or more public keys. For this to work the public key algorithm >> has to >> support encryption of the symmetric key using a public key aka key >> transport. >> >> Of the public key algorithms OpenSSL currently implements only RSA >> has that >> operation. >> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Tue Aug 16 02:37:40 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 16 Aug 2016 04:37:40 +0200 Subject: [openssl-users] CVE-2016-2177 In-Reply-To: References: Message-ID: Just to clarify for anyone searching the archives in the future: Is that commit included in release 1.0.1t or not? (I could probably dig it up myself, but I am not an authoritative source on the matter, so not good enough for future readers). On 12/08/2016 21:20, Salz, Rich wrote: > > Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 > > *From:*Scott Neugroschl [mailto:scott_n at xypro.com] > *Sent:* Friday, August 12, 2016 3:11 PM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] CVE-2016-2177 > > CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. > Does this mean that the fix is not applied to the 1.0.1 series (in > particular 1.0.1t)? > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From doctor at doctor.nl2k.ab.ca Tue Aug 16 06:35:18 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 16 Aug 2016 00:35:18 -0600 Subject: [openssl-users] openssl 1.0.2 20160816 snap Message-ID: <20160816063518.7ftjgolh4odgscny@doctor.nl2k.ab.ca> This error showed up /usr/local/bin/clang38 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -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 pvkfmt.c -o pvkfmt.o pvkfmt.c:279:34: error: use of undeclared identifier 'PEM_R_HEADER_TOO_LONG' PEMerr(PEM_F_DO_B2I_BIO, PEM_R_HEADER_TOO_LONG); ^ 1 error generated. in FreeBSD 10.3 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 Time for the USA to hold a referendum on its republic and vote to dissolve!! From matt at openssl.org Tue Aug 16 08:09:20 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Aug 2016 09:09:20 +0100 Subject: [openssl-users] CVE-2016-2177 In-Reply-To: References: Message-ID: <473b5243-4054-6450-16fe-1347379d6e6f@openssl.org> On 16/08/16 03:37, Jakob Bohm wrote: > Just to clarify for anyone searching the archives in the future: > > Is that commit included in release 1.0.1t or not? No, its not yet in an official release. It will be included in the next 1.0.1 release - whenever that is. Matt > > (I could probably dig it up myself, but I am not an authoritative > source on the matter, so not good enough for future readers). > > On 12/08/2016 21:20, Salz, Rich wrote: >> >> Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 >> >> *From:*Scott Neugroschl [mailto:scott_n at xypro.com] >> *Sent:* Friday, August 12, 2016 3:11 PM >> *To:* openssl-users at openssl.org >> *Subject:* [openssl-users] CVE-2016-2177 >> >> CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. >> Does this mean that the fix is not applied to the 1.0.1 series (in >> particular 1.0.1t)? >> > Enjoy > > Jakob From sanumesh at in.ibm.com Tue Aug 16 08:50:31 2016 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Tue, 16 Aug 2016 14:20:31 +0530 Subject: [openssl-users] CVE-2016-2177 In-Reply-To: References: Message-ID: Hi Has this been officially published in openSSL ? Haven't seen a security advisory for the same. Regards Sandeep From: "Salz, Rich" To: "openssl-users at openssl.org" Date: 08/13/2016 12:51 AM Subject: Re: [openssl-users] CVE-2016-2177 Sent by: "openssl-users" Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From: Scott Neugroschl [mailto:scott_n at xypro.com] Sent: Friday, August 12, 2016 3:11 PM To: openssl-users at openssl.org Subject: [openssl-users] CVE-2016-2177 CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. Does this mean that the fix is not applied to the 1.0.1 series (in particular 1.0.1t)? --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: graycol.gif Type: image/gif Size: 105 bytes Desc: not available URL: From matt at openssl.org Tue Aug 16 08:53:38 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 16 Aug 2016 09:53:38 +0100 Subject: [openssl-users] CVE-2016-2177 In-Reply-To: References: Message-ID: <63ea1850-bc34-9347-56ee-0c0266224cb1@openssl.org> On 16/08/16 09:50, Sandeep Umesh wrote: > Hi > > Has this been officially published in openSSL ? Haven't seen a security > advisory for the same. > No. This is a low severity issue. As per our security policy we push fixes for these to our repo as soon as we have them. They are then rolled up in the next official release whenever that happens to be: https://www.openssl.org/policies/secpolicy.html For a discussion on this specific issue, see: https://www.openssl.org/blog/blog/2016/06/27/undefined-pointer-arithmetic/ Matt > Regards > Sandeep > > > Inactive hide details for "Salz, Rich" ---08/13/2016 12:51:19 > AM---Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 --"Salz, > Rich" ---08/13/2016 12:51:19 AM---Commit > 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 -- > > From: "Salz, Rich" > To: "openssl-users at openssl.org" > Date: 08/13/2016 12:51 AM > Subject: Re: [openssl-users] CVE-2016-2177 > Sent by: "openssl-users" > > ------------------------------------------------------------------------ > > > > Commit 6f35f6deb5ca7daebe289f86477e061ce3ee5f46 in 1.0.1 > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > *From:*Scott Neugroschl [mailto:scott_n at xypro.com] * > Sent:*Friday, August 12, 2016 3:11 PM* > To:*openssl-users at openssl.org* > Subject:*[openssl-users] CVE-2016-2177 > > CVE 2016-2177 notes that it applies to all versions up to 1.0.2h. Does > this mean that the fix is not applied to the 1.0.1 series (in particular > 1.0.1t)? > > > --- > Scott Neugroschl | XYPRO Technology Corporation > 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 > 583-2874|Fax 805 583-0124 | > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > From rsalz at akamai.com Tue Aug 16 12:17:32 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 16 Aug 2016 12:17:32 +0000 Subject: [openssl-users] EVP_SealInit question In-Reply-To: <572c8c83-f7de-cea6-2652-e4f72a61b3bd@gemtalksystems.com> References: <39cb3f21-d726-ab75-af03-96303ae43fdd@gemtalksystems.com> <20160815213830.GA26884@openssl.org> <20160816003143.GA32627@openssl.org> <572c8c83-f7de-cea6-2652-e4f72a61b3bd@gemtalksystems.com> Message-ID: <9c8bc14c0be44882b57cf8ff1426c653@usma1ex-dag1mb1.msg.corp.akamai.com> > It sounds like you're saying that only RSA supports encrypting with a public > key. But can't any asymmetric encryption algorithm encrypt using the public > key? Why is RSA special in this regard? Because that is the only thing we have implemented. The API's (and code to call them) to do it with ECC aren't there. From skerur at grundfos.com Wed Aug 17 04:58:16 2016 From: skerur at grundfos.com (ssk1506) Date: Tue, 16 Aug 2016 21:58:16 -0700 (MST) Subject: [openssl-users] Using Openssl for eCOS platform Message-ID: <1471409896742-67892.post@n7.nabble.com> Hi,I am using openssl on a n eCOS platform. I need only the secure authentication (no encryption needed).I integrated the openssl source code with my application. When I trying to build, I am getting some linking errors.:undefined reference to 'getpid':undefined reference to 'RANDpoll'I am trying to find how to enable or disable the macros (switches to enable or disable a feature/service). But it seems that openssl.conf is generated from some utitlity program and from a file opensslconf.h.inPl. anyone suggest how to configure.Regards,SSK -- View this message in context: http://openssl.6102.n7.nabble.com/Using-Openssl-for-eCOS-platform-tp67892.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From devadas.kk at gmail.com Wed Aug 17 09:55:33 2016 From: devadas.kk at gmail.com (Devadas kk) Date: Wed, 17 Aug 2016 15:25:33 +0530 Subject: [openssl-users] Using Openssl for eCOS platform In-Reply-To: <1471409896742-67892.post@n7.nabble.com> References: <1471409896742-67892.post@n7.nabble.com> Message-ID: Hi, Best way to do is to modify e_os.h header file. This file has to do with OS specific changes. Something like #ifdef ECOS #define getpid ecos_task_id_fn #endif ecos_task_id_fn is a placed holder, find out actual function name to get process ID. GetThreadID is the function in NETWARE. Regards, Devadas On Wed, Aug 17, 2016 at 10:28 AM, ssk1506 wrote: > Hi, I am using openssl on a n eCOS platform. I need only the secure > authentication (no encryption needed). I integrated the openssl source code > with my application. When I trying to build, I am getting some linking > errors. :undefined reference to 'getpid' :undefined reference to 'RANDpoll' > I am trying to find how to enable or disable the macros (switches to enable > or disable a feature/service). But it seems that openssl.conf is generated > from some utitlity program and from a file opensslconf.h.in Pl. anyone > suggest how to configure. Regards, SSK > ------------------------------ > View this message in context: Using Openssl for eCOS platform > > Sent from the OpenSSL - User mailing list archive > at Nabble.com. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matea.Pejcinovic at asseco-see.hr Wed Aug 17 11:59:50 2016 From: Matea.Pejcinovic at asseco-see.hr (=?iso-8859-2?Q?Matea_Pej=E8inovi=E6?=) Date: Wed, 17 Aug 2016 11:59:50 +0000 Subject: [openssl-users] Checking certificate validity using engine Message-ID: <7B4E72FE6A889749980951B7FDAC027D93F4A8@hrzg1ex01.hr.asseco-see.local> Hello, First, i would like to apologize if his is not the right mailing list for my question. I am working on an engine implementation that should provide a functionality for checking if certificate is valid. As far as I could understand, an engine can have its own implementation of RSA methods, such as those for encryption and decryption, RSA signing etc. Taking this into account, I cannot find the way to implement method for certificate verification. I am refering to steps in the engine initialization and binding method, similarly to ENGINE_set_RSA(). I realized that there is ENGINE_set_STORE() method but I don't really understand how it should be used and is this method the one I should use at all. Any help would be appreciated... Matea This communication is for informational purposes only. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Present message and any attached files may be or contain privileged information and is the property exclusive of ASSECO SEE CAPITAL GROUP. This transmission may contain information that is privileged, confidential, legally privileged, and/or exempt from disclosure under applicable law. The information contained in this message is solely intended for the physical or legal person to whom it is addressed and to the authorized persons for receiving it. In the case you are not the intended recipient or the authorized person to receive this message, we inform that disclosure, duplicate, distribution or taking up any actions on information contained in this message are strictly forbidden and are under civil and legal responsibility. In case you received it by error, you are requested to notify the sender and to destroy the original e-mail message from your system. Opinions, conclusions or any other information contained into this message, which are not related to ASSECO SEE CAPITAL GROUP activity must not be understood to be expressed or should be endorsed by ASSECO SEE CAPITAL GROUP. The interpretation expressed in the present message did not reflect ASSECO SEE CAPITAL GROUP opinion. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vikram.kamaraj at hcl.com Wed Aug 17 13:10:43 2016 From: vikram.kamaraj at hcl.com (Vikram Kamaraj - ERS, HCL Tech) Date: Wed, 17 Aug 2016 13:10:43 +0000 Subject: [openssl-users] OpenSSL - FIPS 140 Compliant Message-ID: <4DF596DC0EA13946A78AF62C49D75A2728BB1755@CHN-HCLT-MBS02.HCLT.CORP.HCL.IN> Hello OpenSSL, Which version of OpenSSL is FIPS 140 compliant? Thanks, Vikram K ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From jayf0ster at roadrunner.com Wed Aug 17 15:31:04 2016 From: jayf0ster at roadrunner.com (Jay Foster) Date: Wed, 17 Aug 2016 08:31:04 -0700 Subject: [openssl-users] Using Openssl for eCOS platform In-Reply-To: References: <1471409896742-67892.post@n7.nabble.com> Message-ID: <573dc45a-48e3-c821-df2a-3303cec71bca@roadrunner.com> I have used the following snippet (along with some others) in the e_os.h header file: # if defined(__ECOS) # define __INITIAL_POINTER_SIZE 0 # define GETPID_IS_MEANINGLESS # define NO_CHMOD # define NO_SYSLOG # define HAVE_LONG_LONG 1 # define HAVE_LONG_DOUBLE 1 # define OPENSSL_THREADS # undef DEVRANDOM_EGD # endif The GETPID_IS_MEANINGLESS might work for you. Jay On 8/17/2016 2:55 AM, Devadas kk wrote: > Hi, > Best way to do is to modify e_os.h header file. > This file has to do with OS specific changes. > > Something like > > #ifdef ECOS > #define getpid ecos_task_id_fn > #endif > > ecos_task_id_fn is a placed holder, find out actual function name to > get process ID. > GetThreadID is the function in NETWARE. > Regards, > Devadas > > On Wed, Aug 17, 2016 at 10:28 AM, ssk1506 > wrote: > > Hi, I am using openssl on a n eCOS platform. I need only the > secure authentication (no encryption needed). I integrated the > openssl source code with my application. When I trying to build, I > am getting some linking errors. :undefined reference to 'getpid' > :undefined reference to 'RANDpoll' I am trying to find how to > enable or disable the macros (switches to enable or disable a > feature/service). But it seems that openssl.conf is generated from > some utitlity program and from a file opensslconf.h.in > Pl. anyone suggest how to configure. > Regards, SSK > ------------------------------------------------------------------------ > View this message in context: Using Openssl for eCOS platform > > Sent from the OpenSSL - User mailing list archive > at > Nabble.com. > > -- > 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 Wed Aug 17 15:56:35 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 17 Aug 2016 11:56:35 -0400 Subject: [openssl-users] OpenSSL - FIPS 140 Compliant In-Reply-To: <4DF596DC0EA13946A78AF62C49D75A2728BB1755@CHN-HCLT-MBS02.HCLT.CORP.HCL.IN> References: <4DF596DC0EA13946A78AF62C49D75A2728BB1755@CHN-HCLT-MBS02.HCLT.CORP.HCL.IN> Message-ID: <4d8d7018-53fe-d0d8-d62a-4e52458e30a1@openssl.com> On 08/17/2016 09:10 AM, Vikram Kamaraj - ERS, HCL Tech wrote: > Hello OpenSSL, > > > > Which version of OpenSSL is FIPS 140 compliant? None. A more useful question to ask is "for which versions of OpenSSL are compatible FIPS modules available?". The answer to that is 1.0.1/1.0.2 with the OpenSSL FIPS Object Module 2.0, and (in a year or two) OpenSSL 1.1 with a new FIPS module still to be developed and validated (but in progress). You may want to take a look at the OpenSSL FIPS module user guide: https://www-origin.openssl.org/docs/fips/UserGuide-2.0.pdf The background discussion there will still be relevant for the new FIPS module. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 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 Andrew_Porter at bmc.com Wed Aug 17 15:59:07 2016 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Wed, 17 Aug 2016 15:59:07 +0000 Subject: [openssl-users] OpenSSL - FIPS 140 Compliant In-Reply-To: <4DF596DC0EA13946A78AF62C49D75A2728BB1755@CHN-HCLT-MBS02.HCLT.CORP.HCL.IN> References: <4DF596DC0EA13946A78AF62C49D75A2728BB1755@CHN-HCLT-MBS02.HCLT.CORP.HCL.IN> Message-ID: <6db3daeb22fe456f815f0557b419d59b@phx-exmbprd-02.adprod.bmc.com> Multiple versions of OpenSSL can, with an additional source package (the OpenSSL FIPS module) be built by you to be 140-2 compliant. See http://openssl.com/fips/ for more info. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Vikram Kamaraj - ERS, HCL Tech Sent: Wednesday, August 17, 2016 06:11 To: openssl-users at openssl.org Subject: [openssl-users] OpenSSL - FIPS 140 Compliant Hello OpenSSL, Which version of OpenSSL is FIPS 140 compliant? Thanks, Vikram K ::DISCLAIMER:: ---------------------------------------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. E-mail transmission is not guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or may contain viruses in transmission. The e mail and its contents (with or without referred errors) shall therefore not attach any liability on the originator or HCL or its affiliates. Views or opinions, if any, presented in this email are solely those of the author and may not necessarily reflect the views or opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of authorized representative of HCL is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any email and/or attachments, please check them for viruses and other defects. ---------------------------------------------------------------------------------------------------------------------------------------------------- -------------- next part -------------- An HTML attachment was scrubbed... URL: From skerur at grundfos.com Thu Aug 18 08:52:39 2016 From: skerur at grundfos.com (ssk1506) Date: Thu, 18 Aug 2016 01:52:39 -0700 (MST) Subject: [openssl-users] Using Openssl for eCOS platform In-Reply-To: <573dc45a-48e3-c821-df2a-3303cec71bca@roadrunner.com> References: <1471409896742-67892.post@n7.nabble.com> <573dc45a-48e3-c821-df2a-3303cec71bca@roadrunner.com> Message-ID: <1471510359981-67922.post@n7.nabble.com> Hi Jay, Thanks for your reply. Our requirement is as follows 1. only using openssl for authenticaion and a key wrap algorithm. No encryption is needed. 2. For MAC alogorithm, we need to use M_SHA1 / M_SHA256 For key wrap algo, we need to use AES 128 or AES 256 algo. Following are the steps we followed 1. As we have eCOS platform, we just integrated the openssl files (1.0.1g) and added to them to our makefile to build them (only .c and .h files) 2 In our applicatoin we call the openssl functions to above two functions from the openssl. key wrap algorithm to decrupt the session key which is received from the master. AES_set_decrypt_key, AES_unwrap_key MAC algo to generate a mac value for a message (HMAC(), EVP_sha1(), EVP_sha256()) 3. But during the linking stage we are getting the errors as ""undefined reference to a function " Example": openssl/openssl101g/crypto/engine/tb_rand.o(.text.ENGINE_get_default_RAND+0x8): In function `ENGINE_get_default_RAND': undefined reference to `engine_table_select' 4. Not able to figure out if there is any common setting file (to configure openssl ) so that we can enable /disable some features and services. We tried doing the method as your had suggested. But it seems that there is not much effect for the declaration of eCos Request to please let us know what mistake we are making, or we have missed out any configuration. Regards, SSK -- View this message in context: http://openssl.6102.n7.nabble.com/Using-Openssl-for-eCOS-platform-tp67892p67922.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From skerur at grundfos.com Thu Aug 18 11:39:14 2016 From: skerur at grundfos.com (ssk1506) Date: Thu, 18 Aug 2016 04:39:14 -0700 (MST) Subject: [openssl-users] Using Openssl for eCOS platform In-Reply-To: <573dc45a-48e3-c821-df2a-3303cec71bca@roadrunner.com> References: <1471409896742-67892.post@n7.nabble.com> <573dc45a-48e3-c821-df2a-3303cec71bca@roadrunner.com> Message-ID: Hi Jay, Thanks for your reply. Our requirement is as follows 1. only using openssl for authenticaion and a key wrap algorithm. No encryption is needed. 2. For MAC alogorithm, we need to use M_SHA1 / M_SHA256 For key wrap algo, we need to use AES 128 or AES 256 algo. Following are the steps we followed 1. As we have eCOS platform, we just integrated the openssl files (1.0.1g) and added to them to our makefile to build them (only .c and .h files) 2 In our applicatoin we call the openssl functions to above two functions from the openssl. key wrap algorithm to decrupt the session key which is received from the master. AES_set_decrypt_key, AES_unwrap_key MAC algo to generate a mac value for a message (HMAC(), EVP_sha1(), EVP_sha256()) 3. But during the linking stage we are getting the errors as ""undefined reference to a function " Example": openssl/openssl101g/crypto/engine/tb_rand.o(.text.ENGINE_get_default_RAND+0x8): In function `ENGINE_get_default_RAND': undefined reference to `engine_table_select' 4. Not able to figure out if there is any common setting file (to configure openssl ) so that we can enable /disable some features and services. We tried doing the method as your had suggested. But it seems that there is not much effect for the declaration of eCos Request to please let us know what mistake we are making, or we have missed out any configuration. Regards, SSK ________________________________ From: Jay Foster-2 [via OpenSSL] [mailto:ml-node+s6102n67903h61 at n7.nabble.com] Sent: 17 August 2016 07:53 PM To: Sunil Kerur Subject: Re: Using Openssl for eCOS platform I have used the following snippet (along with some others) in the e_os.h header file: # if defined(__ECOS) # define __INITIAL_POINTER_SIZE 0 # define GETPID_IS_MEANINGLESS # define NO_CHMOD # define NO_SYSLOG # define HAVE_LONG_LONG 1 # define HAVE_LONG_DOUBLE 1 # define OPENSSL_THREADS # undef DEVRANDOM_EGD # endif The GETPID_IS_MEANINGLESS might work for you. Jay On 8/17/2016 2:55 AM, Devadas kk wrote: Hi, Best way to do is to modify e_os.h header file. This file has to do with OS specific changes. Something like #ifdef ECOS #define getpid ecos_task_id_fn #endif ecos_task_id_fn is a placed holder, find out actual function name to get process ID. GetThreadID is the function in NETWARE. Regards, Devadas On Wed, Aug 17, 2016 at 10:28 AM, ssk1506 <[hidden email]> wrote: Hi, I am using openssl on a n eCOS platform. I need only the secure authentication (no encryption needed). I integrated the openssl source code with my application. When I trying to build, I am getting some linking errors. :undefined reference to 'getpid' :undefined reference to 'RANDpoll' I am trying to find how to enable or disable the macros (switches to enable or disable a feature/service). But it seems that openssl.conf is generated from some utitlity program and from a file opensslconf.h.in Pl. anyone suggest how to configure. Regards, SSK ________________________________ View this message in context: Using Openssl for eCOS platform Sent from the OpenSSL - User mailing list archive at Nabble.com. -- 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 ________________________________ If you reply to this email, your message will be added to the discussion below: http://openssl.6102.n7.nabble.com/Using-Openssl-for-eCOS-platform-tp67892p67903.html To start a new topic under OpenSSL - User, email ml-node+s6102n3h61 at n7.nabble.com To unsubscribe from Using Openssl for eCOS platform, click here. NAML -- View this message in context: http://openssl.6102.n7.nabble.com/Using-Openssl-for-eCOS-platform-tp67892p67926.html Sent from the OpenSSL - User mailing list archive at Nabble.com. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rocklee_104 at outlook.com Fri Aug 19 02:26:53 2016 From: rocklee_104 at outlook.com (Lee Rock) Date: Fri, 19 Aug 2016 02:26:53 +0000 Subject: [openssl-users] _armv7_tick undefined instruction error Message-ID: Hi, all: When I specify "user_debug=31" in kernel cmdline, I get undefined instruction error. And I figured it out that PC pointed at "mrc p15,0,r0,c9,c13,0". I know this instruction is used to get CPU tick. Unless PMUSERENR(Performance Monitors User Enable Register) is set, this instruction is not allowed to execute in user mode. I wonder why openssl use this instruction in user mode, as PMUSERENR is not set by default. BTW, My architecture is ARM v7, kernel is 3.18, openssl 1.0.1. BR Rock Lee From pzb at amzn.com Fri Aug 19 03:41:59 2016 From: pzb at amzn.com (Peter Bowen) Date: Thu, 18 Aug 2016 20:41:59 -0700 Subject: [openssl-users] OCSP verification issue Message-ID: <998F44A4-0E4B-48C3-95CE-9BA8ECC84CE3@amzn.com> I recently ran into a bug with verification of OCSP responses that appears to be in all versions of OpenSSL (including current 1.1.0 builds). RFC 6960 and its predecessor 2560 allow that the response may be signed by the key for "the CA who issued the certificate in question? (section 2.2). In this case it should not be necessary to include any certs in the basicResponse, as the signature can be validated using the public key used to validate the certificate whose status is being checked. While this is contemplated by the RFCs, OpenSSL fails in certain cases if no certificates are provided in the response. If there are at least two intermediate CAs in the certificate chain between a trust anchor and end entity certificate, then OCSP_basic_verify will return a certificate verify error. The code below reproduces the failure and demonstrates that reducing the path length from anchor to end entity certificate resolves the issue as does adding a certificate from the trust anchor to the first CA to the response. I think the correct behaviour would be to check if the issuer of the certificate matches the signer of the OCSP response and, if so, simply skip the X509_verify_cert check. Thanks, Peter #!/usr/bin/env ruby # Copyright 2016 Amazon.com, Inc. or its affiliates. All Rights Reserved. # # Licensed under the OpenSSL license (the "License"). You may not use # this file except in compliance with the License. You can obtain a copy # in the file LICENSE in the source distribution or at # https://www.openssl.org/source/license.html require 'openssl' require 'base64' require 'open3' # Ruby has no to_text method for OCSP responses, so shell out def ocsp_to_text(ocsp_der) # Figure out if our base64 uses -D or -d to decode %x/echo | base64 -D/ if $? == 0 dparam="-D" else dparam="-d" end out = "" Open3::popen2("/bin/bash -t") do |i, o, t| i.puts("openssl ocsp -noverify -text -respin <(echo #{Base64.strict_encode64(ocsp_der)} | base64 #{dparam})") o.each{|l|out += l} end out end # Set up Names and Keys for all the certs nodes = { :root => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "Beyond Hypersecure Root CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ca1 => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "Beyond Hypersecure Inc", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "Beyond Hypersecure Partner CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ca2 => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["O", "HyperCyberHost LLC", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "HyperCyberHost Server CA", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048) }, :ee => { :name => OpenSSL::X509::Name.new([["C", "US", OpenSSL::ASN1::PRINTABLESTRING], ["CN", "localdemo.sslmap.com", OpenSSL::ASN1::PRINTABLESTRING]]), :key => OpenSSL::PKey::RSA.new(2048), :sans => "DNS:localdemo.sslmap.com" } } # Generate all the certs root_cert = OpenSSL::X509::Certificate.new root_cert.version = 0x2 root_cert.serial = 0x0 root_cert.not_before = Time.new(2004,01,01,00,00,01) root_cert.not_after = Time.new(2028,12,31,23,59,59) root_cert.subject = nodes[:root][:name] root_cert.issuer = root_cert.subject root_cert.public_key = nodes[:root][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.subject_certificate = root_cert ef.issuer_certificate = root_cert root_cert.add_extension(ef.create_extension("subjectKeyIdentifier", "hash", false)) root_cert.add_extension(ef.create_extension("basicConstraints", "CA:TRUE", true)) root_cert.add_extension(ef.create_extension("keyUsage","digitalSignature, keyCertSign, cRLSign", true)) root_cert.sign(nodes[:root][:key], OpenSSL::Digest::SHA256.new) puts root_cert.to_text puts root_cert.to_pem ca1_cert = OpenSSL::X509::Certificate.new ca1_cert.version = 0x2 ca1_cert.serial = 0xa ca1_cert.not_before = Time.new(2011,01,01,00,00,01) ca1_cert.not_after = Time.new(2020,12,31,23,59,59) ca1_cert.subject = nodes[:ca1][:name] ca1_cert.issuer = root_cert.subject ca1_cert.public_key = nodes[:ca1][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.config = OpenSSL::Config.parse(' [polsect] policyIdentifier = 2.5.29.32.0 CPS.1="http://beyondhypersecure.example.com/cps" ') ef.subject_certificate = ca1_cert ef.issuer_certificate = root_cert ca1_cert.add_extension(ef.create_extension("subjectKeyIdentifier", "hash", false)) ca1_cert.add_extension(ef.create_extension("authorityKeyIdentifier", "keyid:always", false)) ca1_cert.add_extension(ef.create_extension("basicConstraints", "CA:TRUE", true)) ca1_cert.add_extension(ef.create_extension("certificatePolicies","2.5.29.32.0")) ca1_cert.add_extension(ef.create_extension("keyUsage","digitalSignature, keyCertSign, cRLSign", true)) ca1_cert.add_extension(ef.create_extension("authorityInfoAccess","caIssuers;URI:http://beyondhypersecure.example.com/root.cer,OCSP;URI:http://ocsp.beyondhypersecure.example.com")) ca1_cert.add_extension(ef.create_extension("crlDistributionPoints","URI:http://beyondhypersecure.example.com/root.crl")) ca1_cert.sign(nodes[:root][:key], OpenSSL::Digest::SHA256.new) puts ca1_cert.to_text puts ca1_cert.to_pem ca2_cert = OpenSSL::X509::Certificate.new ca2_cert.version = 0x2 ca2_cert.serial = 0xfb ca2_cert.not_before = Time.new(2012,01,01,00,00,01) ca2_cert.not_after = Time.new(2018,12,31,23,59,59) ca2_cert.subject = nodes[:ca2][:name] ca2_cert.issuer = ca1_cert.subject ca2_cert.public_key = nodes[:ca2][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.config = OpenSSL::Config.parse(' [polsect] policyIdentifier = 2.5.29.32.0 CPS.1="http://beyondhypersecure.example.com/cps" ') ef.subject_certificate = ca2_cert ef.issuer_certificate = ca1_cert ca2_cert.add_extension(ef.create_extension("subjectKeyIdentifier", "hash", false)) ca2_cert.add_extension(ef.create_extension("authorityKeyIdentifier", "keyid:always", false)) ca2_cert.add_extension(ef.create_extension("basicConstraints", "CA:TRUE", true)) ca2_cert.add_extension(ef.create_extension("certificatePolicies","2.5.29.32.0")) ca2_cert.add_extension(ef.create_extension("keyUsage","digitalSignature, keyCertSign, cRLSign", true)) ca2_cert.add_extension(ef.create_extension("authorityInfoAccess","caIssuers;URI:http://beyondhypersecure.example.com/ca1.cer,OCSP;URI:http://ocsp.beyondhypersecure.example.com")) ca2_cert.add_extension(ef.create_extension("crlDistributionPoints","URI:http://beyondhypersecure.example.com/ca1.crl")) ca2_cert.sign(nodes[:ca1][:key], OpenSSL::Digest::SHA256.new) puts ca2_cert.to_text puts ca2_cert.to_pem ee_cert = OpenSSL::X509::Certificate.new ee_cert.version = 0x2 ee_cert.serial = OpenSSL::BN.rand(64, -1, 0) ee_cert.not_before = Time.new(2015,02,26,16,00,00) ee_cert.not_after = Time.new(2016,02,28,15,59,59) ee_cert.subject = nodes[:ee][:name] ee_cert.issuer = ca2_cert.subject ee_cert.public_key = nodes[:ee][:key] ef = OpenSSL::X509::ExtensionFactory.new ef.config = OpenSSL::Config.parse(' [polsect] policyIdentifier = 2.23.140.1.2.1 CPS.1="http://beyondhypersecure.example.com/cps" ') ef.subject_certificate = ee_cert ef.issuer_certificate = ca2_cert ee_cert.add_extension(ef.create_extension("authorityKeyIdentifier", "keyid:always", false)) ee_cert.add_extension(ef.create_extension("certificatePolicies","@polsect")) ee_cert.add_extension(ef.create_extension("subjectAltName",nodes[:ee][:sans])) ee_cert.add_extension(ef.create_extension("keyUsage","digitalSignature,keyEncipherment", true)) ee_cert.add_extension(ef.create_extension("extendedKeyUsage", "serverAuth, clientAuth")) ee_cert.add_extension(ef.create_extension("crlDistributionPoints","URI:http://beyondhypersecure.example.com/ca2.crl")) ee_cert.add_extension(ef.create_extension("authorityInfoAccess","caIssuers;URI:http://beyondhypersecure.example.com/ca2.cer,OCSP;URI:http://ocsp.beyondhypersecure.example.com")) ee_cert.sign(nodes[:ca2][:key], OpenSSL::Digest::SHA256.new) puts nodes[:ee][:key].to_text puts nodes[:ee][:key].to_pem puts ee_cert.to_text puts ee_cert.to_pem bres = OpenSSL::OCSP::BasicResponse.new cid = OpenSSL::OCSP::CertificateId.new(ee_cert, ca2_cert, OpenSSL::Digest::SHA1.new) bres.add_status(cid, OpenSSL::OCSP::V_CERTSTATUS_GOOD, 0, nil, -1*60*60*6, 60*60*24*3, []) bres.sign(ca2_cert, nodes[:ca2][:key], nil, OpenSSL::OCSP::RESPID_KEY) ocsp_res = OpenSSL::OCSP::Response.create(OpenSSL::OCSP::RESPONSE_STATUS_SUCCESSFUL, bres) ocsp_res_1_der = ocsp_res.to_der puts ocsp_to_text(ocsp_res_1_der) puts "-----BEGIN OCSP RESPONSE 1-----" puts Base64.encode64(ocsp_res_1_der) puts "-----END OCSP RESPONSE 1-----" bres.sign(ca2_cert, nodes[:ca2][:key], [ca1_cert], OpenSSL::OCSP::RESPID_KEY) ocsp_res = OpenSSL::OCSP::Response.create(OpenSSL::OCSP::RESPONSE_STATUS_SUCCESSFUL, bres) ocsp_res_2_der = ocsp_res.to_der # OCSP_basic_sign adds the signer cert unless OCSP_NOCERTS is passed # Ruby doesn't expose OCSP_basic_add1_cert, so instead we rip out the signer # cert, just leaving the certs we explicitly passed to OCSP_basic_sign # (Yes, this is a horrible hack) a = OpenSSL::ASN1.decode(ocsp_res_2_der) bres_a = OpenSSL::ASN1.decode(a.value[1].value[0].value[1].value) bres_a.value[3].value[0].value.delete_at(0) a.value[1].value[0].value[1].value = bres_a.to_der ocsp_res_2_der = a.to_der puts ocsp_to_text(ocsp_res_2_der) puts "-----BEGIN OCSP RESPONSE 2-----" puts Base64.encode64(ocsp_res_2_der) puts "-----END OCSP RESPONSE 2-----" ## Now test # Encode/decode loops to ensure the client test objects are clean trust_store_1 = OpenSSL::X509::Store.new [root_cert].each do |c| trust_store_1.add_cert(OpenSSL::X509::Certificate.new(c.to_der)) end trust_store_2 = OpenSSL::X509::Store.new [root_cert, ca1_cert].each do |c| trust_store_2.add_cert(OpenSSL::X509::Certificate.new(c.to_der)) end server_chain = [ee_cert, ca2_cert, ca1_cert].map{|c|OpenSSL::X509::Certificate.new(c.to_der)} ocsp_res_1 = OpenSSL::OCSP::Response.new(ocsp_res_1_der) ocsp_res_2 = OpenSSL::OCSP::Response.new(ocsp_res_2_der) puts "\nTrying with only root cert in trust store" puts ocsp_res_1.basic.verify(server_chain, trust_store_1) puts "\nTrying with root and issuer of CA cert in trust store" puts ocsp_res_1.basic.verify(server_chain, trust_store_2) puts "\nTrying with only root cert in trust store and with CA1 cert in response" puts ocsp_res_2.basic.verify(server_chain, trust_store_1) puts "\nTrying with root and issuer of CA cert in trust store and with CA1 cert in response" puts ocsp_res_2.basic.verify(server_chain, trust_store_2) From Imran.Ali at enghouse.com Fri Aug 19 11:20:11 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Fri, 19 Aug 2016 11:20:11 +0000 Subject: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance Message-ID: Hi Guys, I need some help. I am looking for some evidence which I can provide to my auditor for FOM 2.0.12 is FIPS-140 compliance when compiled and used in Windows environment. When I look at the NIST web site under http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 I cannot see 2.0.12 version. Is there something I am missing? Regards, Imran Ali Engineering Product Lead [cid:image001.gif at 01CE15D3.C9808950] t: +44 (0) 118 943 0485 m: +44 (0) 780 113 7865 w: www.enghouseinteractive.com e: Imran.ali at enghouse.com [cid:image002.gif at 01CE15D3.C9808950] Enghouse Interactive (UK) Ltd is a company registered in England and Wales. Registered number: 04230977. Registered office: Imperium, Imperial Way, Reading, Berkshire, RG2 0TD. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image005.jpg Type: image/jpeg Size: 1940 bytes Desc: image005.jpg URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image006.jpg Type: image/jpeg Size: 7658 bytes Desc: image006.jpg URL: From marquess at openssl.com Fri Aug 19 13:30:34 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 19 Aug 2016 09:30:34 -0400 Subject: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance In-Reply-To: References: Message-ID: <344a5bef-6037-7853-cd66-57a5147c9bc7@openssl.com> On 08/19/2016 07:20 AM, Imran Ali wrote: > Hi Guys, > > > > I need some help. I am looking for some evidence which I can provide to > my auditor for FOM 2.0.12 is FIPS-140 compliance when compiled and used > in Windows environment. When I look at the NIST web site under > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#1747 > I cannot see 2.0.12 version. > > > > Is there something I am missing? Yes, it's rather confusing. The one and only OpenSSL FIPS module ("OpenSSL FIPS Object Module 2.0") is -- for perverse bureaucratic reasons[*] -- covered by three separate[**] FIPS-140 validations: #1747 (revisions 2.0, 2.0.1, ..., 2.0.10) #2389 (revisions 2.0.9, ..., 2.0.13) #2473 (revisions 2.0.9, 2.0.10) As always the latest revision (for a given validation) subsumes all tested platforms listed for that validation. So for instance, 2.0.13 can be used for all 33 platforms currently listed for validation #2398. There are about 200 distinct platforms now across all validations. So you need to look at the listed platforms for all validations[**], and find which of them cover your platform (possibly more than one). Then use the latest revision of the module for that validation. If you only find your platform(s) of interest on a validation ending at revision 2.0.10 (#1747, #2473), then you're forced to use revision 2.0.10 even though 2.0.13 (and future revisions) are completely backward compatible. From a technical perspective 2.0.N is completely functionally equivalent to all previous revisions < N, but down in the FIPS-140 rabbit hole you're limited to the latest revision for the relevant validation(s)[***]. The easy way to remember it is "one real-world module, multiple FIPS-land validations". Or as one of my colleagues would put it, "...multiple flavors of FIPS-140 magical pixie dust". The choice of validation certificate number is a paper-chase exercise. -Steve M. [*] Obscenely perverse, I'm not even going to try and explain it. In fact IMHO no rational explanation is possible. [**] Technically speaking more than three; validations #2391, #2422, #2454, #2575, #2631, #2676, and possibly others are "copycat" clones done by third parties that introduce yet more platforms. Since these validations are for the same OpenSSL FIPS module they are also accessible to all under the OpenSSL license. [***] OTOH note the later revisions aren't "better" than the earlier ones in any meaningful sense, as we're not allowed to do feature enhancements or bug-fixes (not even vulnerability mitigations). With most software it's prudent to always use the latest revision to pick up bugfixes and refinements; for the FIPS module it doesn't matter. -- Steve Marquess OpenSSL Validation Services, Inc. 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 jonetsu at teksavvy.com Fri Aug 19 16:43:57 2016 From: jonetsu at teksavvy.com (jonetsu) Date: Fri, 19 Aug 2016 12:43:57 -0400 Subject: [openssl-users] Reasons to go from 2.0.9 FOM to 2.0.12 ? Message-ID: <8c260d12826eae9d7a39a1787d22e1b9@teksavvy.com> Hello, We are using FOM 2.0.9 for an embedded product that will go for FIPS validation.? Validation of the full product, that is.? All development so far is with 2.0.9.? What would be the reasons, if any, to update to 2.0.12 before going to the lab ? Thanks - comments much appreciated. From marquess at openssl.com Fri Aug 19 17:16:11 2016 From: marquess at openssl.com (Steve Marquess) Date: Fri, 19 Aug 2016 13:16:11 -0400 Subject: [openssl-users] Reasons to go from 2.0.9 FOM to 2.0.12 ? In-Reply-To: <8c260d12826eae9d7a39a1787d22e1b9@teksavvy.com> References: <8c260d12826eae9d7a39a1787d22e1b9@teksavvy.com> Message-ID: <4bc9aaae-be9e-1c71-d5ab-6c73ec26d4d3@openssl.com> On 08/19/2016 12:43 PM, jonetsu wrote: > Hello, > > We are using FOM 2.0.9 for an embedded product that will go for FIPS > validation. Validation of the full product, that is. All > development so far is with 2.0.9. What would be the reasons, if any, > to update to 2.0.12 before going to the lab ? > > Thanks - comments much appreciated. > > > No reason at all, if 2.0.9 works for you as-is and you're getting your own validation. Unlike the usual case for software, where continual improvements and bugfixes are routinely implemented, we're not allowed to do bugfixes or refinements (not even security vulnerability mitigations) for validated modules. So later revisions of the OpenSSL FIPS Object Module are not "better" in any meaningful way as you'd normally assume. The only difference between revisions[*] is the addition of platform specific portability mods. As part of the validation process we have to demonstrate that the revision mods can't have any effect on any previously tested platforms. On the other hand, since there are no substantive differences between 2.0.9 and 2.0.13, and since you're apparently going to the expense and trouble of obtaining a copycat validation, there's no reason for you *not* to use 2.0.13. That way you'd potentially have coverage for more platforms. -Steve M. [*] Removal of Dual EC DRBG -- arguably a vulnerability mitigation -- at revisions 2.0.6 and 2.0.8 is a singular exception to that rule. -- Steve Marquess OpenSSL Validation Services, Inc. 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 doctor at doctor.nl2k.ab.ca Sat Aug 20 12:44:49 2016 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sat, 20 Aug 2016 06:44:49 -0600 Subject: [openssl-users] openssl 1.0.2 Daily Snapshot issue Message-ID: <20160820124449.o67af6cks45dmt5v@doctor.nl2k.ab.ca> /usr/local/bin/clang39 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -O3 -Wall -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_STORE -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 jpake.c -o jpake.o jpake.c:157:9: error: void function 'hashbn' should not return a value [-Wreturn-type] return NULL; ^ ~~~~ 1 error generated. 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 Time for the USA to hold a referendum on its republic and vote to dissolve!! From rschm2 at unh.newhaven.edu Sun Aug 21 14:05:13 2016 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Sun, 21 Aug 2016 14:05:13 +0000 Subject: [openssl-users] Crypto Module Config Message-ID: <3723919089109384.0f12a877-41c2-4e85-a909-57e1cf2808f5@mail.outlook.com> Hello, I am working on building a new crypto module that works with openssl. I have looked through the source code and found the /crypto/ folder which would be where this module would reside. However, if I duplicate a folder such as md5 within the /crypto/ folder and rename it to say ?helloworld?, helloworld does not show up to be compiled in the makefile. I edited line 856 to include ?helloworld? in the config file. What is the proper way for the config file, in the root directory, to add ?helloworld? into the makefile. Any guidance would be much appreciated. Best, Rob Schmicker -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsware at gmail.com Mon Aug 22 18:09:16 2016 From: wsware at gmail.com (Scott Ware) Date: Mon, 22 Aug 2016 14:09:16 -0400 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) Message-ID: We use libeay32.dll and ssleay32.dll from https://slproweb.com/products/Win32OpenSSL.html in our applications and we recently moved from version 1.0.2a to 1.0.2g and now on a few machines running a AMD Geode processor we are getting "Unhandled exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction". We ended up building OpennSSL so we could debug into it and found it is failing on "movsd xmm0,mmword" (see below) which the AMD Geode does not seem to support. I have tried "SET OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I may not be using OPENSSL_ia32cap correctly. This happens when calling SSL_CTX_new which then calls RAND_add. Any ideas on the best thing to do? We don't want to have to manage different compiled versions of libeay32.dll and ssleay32.dll if we can help it. Thanks, Scott Ware ==================== Unhandled exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction. ==================== if (netstatget(NULL, L"LanmanWorkstation", 0, 0, &outbuf) == 0) { 005904B6 lea edx,[outbuf] 005904BC push edx 005904BD push 0 005904BF push 0 005904C1 push offset string L"LanmanWorkstation" (629C8Ch) 005904C6 push 0 005904C8 call dword ptr [netstatget] 005904CE test eax,eax 005904D0 jne RAND_poll+16Ah (59050Ah) RAND_add(outbuf, sizeof(STAT_WORKSTATION_0), 45); 005904D2 mov eax,8 005904D7 call _chkstk (611F20h) =>005904DC movsd xmm0,mmword ptr [__real at 4046800000000000 (629E90h)] 005904E4 movsd mmword ptr [esp],xmm0 005904E9 push 0D8h 005904EE mov eax,dword ptr [outbuf] 005904F4 push eax 005904F5 call RAND_add (58FF10h) 005904FA add esp,10h -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Mon Aug 22 19:04:27 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 22 Aug 2016 21:04:27 +0200 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: Message-ID: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> On 22/08/2016 20:09, Scott Ware wrote: > We use libeay32.dll and ssleay32.dll from > https://slproweb.com/products/Win32OpenSSL.htmlin our applications and > we recently moved from version 1.0.2a to 1.0.2g and now on a few > machines running a AMD Geode processor we are getting "Unhandled > exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: > Illegal Instruction". We ended up building OpennSSL so we could debug > into it and found it is failing on "movsd xmm0,mmword" (see below) > which the AMD Geode does not seem to support. I have tried "SET > OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", and > "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I may > not be using OPENSSL_ia32cap correctly. This happens when calling > SSL_CTX_new which then calls RAND_add. > > Any ideas on the best thing to do? We don't want to have to manage > different compiled versions of libeay32.dll and ssleay32.dll if we can > help it. > Your disassembly looks like the C compiler was invoked with options that caused regular C floating point code (in this case, the passing of 45.0 as an argument to RAND_add()) to be compiled into MMX/SSE instructions instead of backwards compatible 80x87 floating point instructions or (for simple cases like this) regular integer unit data movement instructions (such as two pushes of 32 bit constants that contain the halves of the 64 bit double constant, which would have been more efficient on every x86 CPU). Did the build scripts or other source code contain any differences from the official source code that can be downloaded from openssl.org? How did you invoke the build scripts (command sequence, special build environment, special environment variables etc.)? Which compiler and compiler version/edition did you use? It would be interesting to know if one of the common Windows compilers does this unconditionally, making it unsuitable for use in programs that need to be backwards compatible. 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 scott_n at xypro.com Mon Aug 22 19:08:47 2016 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 22 Aug 2016 19:08:47 +0000 Subject: [openssl-users] Building OpenSSL 1.0.1t without tls1.1 support? Message-ID: I've done a custom build of OpenSSL where I ran Configure with "no-ssl2" and "no-ssl3". I'd like to disable TLS1 and 1.1 if possible. Will the no-tls1 option disable just TLS1 or all TLS1.x protocols? Thanks, ScottN -------------- next part -------------- An HTML attachment was scrubbed... URL: From wsware at gmail.com Mon Aug 22 20:33:34 2016 From: wsware at gmail.com (Scott Ware) Date: Mon, 22 Aug 2016 16:33:34 -0400 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm wrote: > On 22/08/2016 20:09, Scott Ware wrote: > >> We use libeay32.dll and ssleay32.dll from https://slproweb.com/products/ >> Win32OpenSSL.htmlin our applications and we recently moved from version >> 1.0.2a to 1.0.2g and now on a few machines running a AMD Geode processor we >> are getting "Unhandled exception at 0x005904dc (libeay32.dll) in Test.exe: >> 0xC000001D: Illegal Instruction". We ended up building OpennSSL so we could >> debug into it and found it is failing on "movsd xmm0,mmword" (see below) >> which the AMD Geode does not seem to support. I have tried "SET >> OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", and "SET >> OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I may not be >> using OPENSSL_ia32cap correctly. This happens when calling SSL_CTX_new >> which then calls RAND_add. >> >> Any ideas on the best thing to do? We don't want to have to manage >> different compiled versions of libeay32.dll and ssleay32.dll if we can help >> it. >> >> Your disassembly looks like the C compiler was invoked with > options that caused regular C floating point code (in this > case, the passing of 45.0 as an argument to RAND_add()) to > be compiled into MMX/SSE instructions instead of backwards > compatible 80x87 floating point instructions or (for simple > cases like this) regular integer unit data movement > instructions (such as two pushes of 32 bit constants that > contain the halves of the 64 bit double constant, which > would have been more efficient on every x86 CPU). > > Did the build scripts or other source code contain any > differences from the official source code that can be > downloaded from openssl.org? > > How did you invoke the build scripts (command sequence, > special build environment, special environment variables > etc.)? > > Which compiler and compiler version/edition did you use? > > It would be interesting to know if one of the common Windows > compilers does this unconditionally, making it unsuitable > for use in programs that need to be backwards compatible. > > > I compiled using this process and seem to be getting the same result as the .dll I downloaded from slproweb.com I downloaded the 1.0.2g source from openssl.com and didn't change anything. >From the "Developer Command Promt for VS2013" perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg ms\do_ms nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak install -------------- next part -------------- An HTML attachment was scrubbed... URL: From etksubs at gmail.com Mon Aug 22 20:46:54 2016 From: etksubs at gmail.com (etksubs at gmail.com) Date: Mon, 22 Aug 2016 16:46:54 -0400 Subject: [openssl-users] FIPS_incore_fingerprint inconsistent text section results on iOS Message-ID: <14E18137-05EB-43DE-945D-D39838D748FF@gmail.com> I am having a problem where FIPS_incore_fingerprint is failing to generate the same signature as our build script. If I set a breakpoint in FIPS_incore_fingerprint it appears that p1-p4 are all being set correctly. If I dump memory for each section (p1-p2 and p3-p4) and concatenate the binary data and run openssl sha1 -hmac etaonrishdlcupfm concatenateddata.bin I get the same result as we are storing into FIPS_signature. However, after the HMAC_Final call in FIPS_incore_fingerprint the resulting signature is not the same. I set breakpoints and skipped the second HMAC_Update (so as to just hash the text section) and I do not get the same result as expected for just that section. If I skip the first HMAC_Update to just hash the data section, then that does return the expected result for that section every time. I have dumped the text section (p1-p2) before and after the first HMAC_Update and there is no difference in the memory contents, and I get the same contents for every run, yet the resulting hash for that chunk is different every time. Any idea what might be going on here? Thanks, Erik Tkal From jb-openssl at wisemo.com Tue Aug 23 00:05:12 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 23 Aug 2016 02:05:12 +0200 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: On 22/08/2016 22:33, Scott Ware wrote: > > On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >wrote: > > On 22/08/2016 20:09, Scott Ware wrote: > > We use libeay32.dll and ssleay32.dll from > https://slproweb.com/products/Win32OpenSSL.htmlin > our > applications and we recently moved from version 1.0.2a to > 1.0.2g and now on a few machines running a AMD Geode processor > we are getting "Unhandled exception at 0x005904dc > (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction". > We ended up building OpennSSL so we could debug into it and > found it is failing on "movsd xmm0,mmword" (see below) which > the AMD Geode does not seem to support. I have tried "SET > OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", > and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to > change. I may not be using OPENSSL_ia32cap correctly. This > happens when calling SSL_CTX_new which then calls RAND_add. > > Any ideas on the best thing to do? We don't want to have to > manage different compiled versions of libeay32.dll and > ssleay32.dll if we can help it. > > Your disassembly looks like the C compiler was invoked with > options that caused regular C floating point code (in this > case, the passing of 45.0 as an argument to RAND_add()) to > be compiled into MMX/SSE instructions instead of backwards > compatible 80x87 floating point instructions or (for simple > cases like this) regular integer unit data movement > instructions (such as two pushes of 32 bit constants that > contain the halves of the 64 bit double constant, which > would have been more efficient on every x86 CPU). > > Did the build scripts or other source code contain any > differences from the official source code that can be > downloaded from openssl.org ? > > How did you invoke the build scripts (command sequence, > special build environment, special environment variables > etc.)? > > Which compiler and compiler version/edition did you use? > > It would be interesting to know if one of the common Windows > compilers does this unconditionally, making it unsuitable > for use in programs that need to be backwards compatible. > > > > I compiled using this process and seem to be getting the same result > as the .dll I downloaded from slproweb.com > I downloaded the 1.0.2g source from openssl.com > and didn't change anything. > > From the "Developer Command Promt for VS2013" > perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg > ms\do_ms > nmake -f ms\ntdll.mak > nmake -f ms\ntdll.mak install According to the following page https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx Visual Studio 2012 and later requires the following compiler option to generate code compatible with older CPUs (this is the default in Visual Studio 2010, and VS2010 does not support the option): /arch:IA32 This compiler gotcha is specific to the 32 bit x86 architecture, the default looks like it is still sane for x86_64. Note to the FIPS team: Please check if this affects the FIPS module building procedure. 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 Tue Aug 23 07:18:23 2016 From: Imran.Ali at enghouse.com (Imran Ali) Date: Tue, 23 Aug 2016 07:18:23 +0000 Subject: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance In-Reply-To: <344a5bef-6037-7853-cd66-57a5147c9bc7@openssl.com> References: <344a5bef-6037-7853-cd66-57a5147c9bc7@openssl.com> Message-ID: <639b07d1655f4c1884bc2426e288aa97@UK-MAIL-001.edge.local> Thanks Steve, I cannot find any certificate that can use 2.0.12 under Windows Operating System which suggests to me that we will have to revert back to 2.0.10 which is listed under #1747 and use G.5 (user affirmation) to leverage new platforms. Is there no plans to include Windows platforms for 2.0.12 and newer version? Regards, Imran -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Steve Marquess Sent: 19 August 2016 14:31 To: openssl-users at openssl.org Subject: Re: [openssl-users] OpenSSL FOM 2.0.12 - Windows Compliance On 08/19/2016 07:20 AM, Imran Ali wrote: > Hi Guys, > > > > I need some help. I am looking for some evidence which I can provide > to my auditor for FOM 2.0.12 is FIPS-140 compliance when compiled and > used in Windows environment. When I look at the NIST web site under > http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#17 > 47 > I cannot see 2.0.12 version. > > > > Is there something I am missing? Yes, it's rather confusing. The one and only OpenSSL FIPS module ("OpenSSL FIPS Object Module 2.0") is -- for perverse bureaucratic reasons[*] -- covered by three separate[**] FIPS-140 validations: #1747 (revisions 2.0, 2.0.1, ..., 2.0.10) #2389 (revisions 2.0.9, ..., 2.0.13) #2473 (revisions 2.0.9, 2.0.10) As always the latest revision (for a given validation) subsumes all tested platforms listed for that validation. So for instance, 2.0.13 can be used for all 33 platforms currently listed for validation #2398. There are about 200 distinct platforms now across all validations. So you need to look at the listed platforms for all validations[**], and find which of them cover your platform (possibly more than one). Then use the latest revision of the module for that validation. If you only find your platform(s) of interest on a validation ending at revision 2.0.10 (#1747, #2473), then you're forced to use revision 2.0.10 even though 2.0.13 (and future revisions) are completely backward compatible. From a technical perspective 2.0.N is completely functionally equivalent to all previous revisions < N, but down in the FIPS-140 rabbit hole you're limited to the latest revision for the relevant validation(s)[***]. The easy way to remember it is "one real-world module, multiple FIPS-land validations". Or as one of my colleagues would put it, "...multiple flavors of FIPS-140 magical pixie dust". The choice of validation certificate number is a paper-chase exercise. -Steve M. [*] Obscenely perverse, I'm not even going to try and explain it. In fact IMHO no rational explanation is possible. [**] Technically speaking more than three; validations #2391, #2422, #2454, #2575, #2631, #2676, and possibly others are "copycat" clones done by third parties that introduce yet more platforms. Since these validations are for the same OpenSSL FIPS module they are also accessible to all under the OpenSSL license. [***] OTOH note the later revisions aren't "better" than the earlier ones in any meaningful sense, as we're not allowed to do feature enhancements or bug-fixes (not even vulnerability mitigations). With most software it's prudent to always use the latest revision to pick up bugfixes and refinements; for the FIPS module it doesn't matter. -- Steve Marquess OpenSSL Validation Services, Inc. 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 wsware at gmail.com Tue Aug 23 13:56:41 2016 From: wsware at gmail.com (Scott Ware) Date: Tue, 23 Aug 2016 09:56:41 -0400 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm wrote: > On 22/08/2016 22:33, Scott Ware wrote: > >> >> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm > >wrote: >> >> On 22/08/2016 20:09, Scott Ware wrote: >> >> We use libeay32.dll and ssleay32.dll from >> https://slproweb.com/products/Win32OpenSSL.htmlin >> our >> applications and we recently moved from version 1.0.2a to >> 1.0.2g and now on a few machines running a AMD Geode processor >> we are getting "Unhandled exception at 0x005904dc >> (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction". >> We ended up building OpennSSL so we could debug into it and >> found it is failing on "movsd xmm0,mmword" (see below) which >> the AMD Geode does not seem to support. I have tried "SET >> OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", >> and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to >> change. I may not be using OPENSSL_ia32cap correctly. This >> happens when calling SSL_CTX_new which then calls RAND_add. >> >> Any ideas on the best thing to do? We don't want to have to >> manage different compiled versions of libeay32.dll and >> ssleay32.dll if we can help it. >> >> Your disassembly looks like the C compiler was invoked with >> options that caused regular C floating point code (in this >> case, the passing of 45.0 as an argument to RAND_add()) to >> be compiled into MMX/SSE instructions instead of backwards >> compatible 80x87 floating point instructions or (for simple >> cases like this) regular integer unit data movement >> instructions (such as two pushes of 32 bit constants that >> contain the halves of the 64 bit double constant, which >> would have been more efficient on every x86 CPU). >> >> Did the build scripts or other source code contain any >> differences from the official source code that can be >> downloaded from openssl.org ? >> >> How did you invoke the build scripts (command sequence, >> special build environment, special environment variables >> etc.)? >> >> Which compiler and compiler version/edition did you use? >> >> It would be interesting to know if one of the common Windows >> compilers does this unconditionally, making it unsuitable >> for use in programs that need to be backwards compatible. >> >> >> >> I compiled using this process and seem to be getting the same result as >> the .dll I downloaded from slproweb.com >> I downloaded the 1.0.2g source from openssl.com and >> didn't change anything. >> >> From the "Developer Command Promt for VS2013" >> perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg >> ms\do_ms >> nmake -f ms\ntdll.mak >> nmake -f ms\ntdll.mak install >> > According to the following page > > https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx > > Visual Studio 2012 and later requires the following compiler > option to generate code compatible with older CPUs (this is the > default in Visual Studio 2010, and VS2010 does not support the > option): > > /arch:IA32 > > > This compiler gotcha is specific to the 32 bit x86 architecture, > the default looks like it is still sane for x86_64. > > Note to the FIPS team: Please check if this affects the FIPS > module building procedure. Jakob! Thank you so much! That was the issue.I added /arch:IA32 to the APP_CFLAG and LIB_CFLAG in ms\ntdll.mak and I was able to compile a new build that works on the problem machine. Is it worth doing a bug report on so they might add that to the build scripts? Without it it seems like the whole OPENSSL_ia32cap system is broken. Before I had found this answer I had also installed nasm so I didn't have to do the no-asm. So My current build process is: >From the "Developer Command Promt for VS2013" perl Configure VC-WIN32 --prefix=C:\OpenSSL-VC-32-DLL ms\do_ms ms\do_nasm.bat (Edit ms\ntdll.mak to add /arch:IA32 to the APP_CFLAG and LIB_CFLAG) nmake -f ms\ntdll.mak nmake -f ms\ntdll.mak install Thank you Jakob and the OpenSSL mailing list for the quick answers! - Scott Ware -------------- next part -------------- An HTML attachment was scrubbed... URL: From testossl2016 at gmail.com Wed Aug 24 13:31:51 2016 From: testossl2016 at gmail.com (Test ssl) Date: Wed, 24 Aug 2016 19:01:51 +0530 Subject: [openssl-users] regarding openssl and openssl fips Message-ID: Hi, I am having a product which is right now using openssl1.0.1s and opensslfips 2.0.1 I am upgrading to openssl1.0.2h, is it OK to still be at openssfips 2.0.1 or do i need to upgrade the opensslfips too to 2.0.12? Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Aug 24 13:51:32 2016 From: marquess at openssl.com (Steve Marquess) Date: Wed, 24 Aug 2016 09:51:32 -0400 Subject: [openssl-users] regarding openssl and openssl fips In-Reply-To: References: Message-ID: <77f8ec57-cf51-c6ce-6d21-f4bdacae4df9@openssl.com> On 08/24/2016 09:31 AM, Test ssl wrote: > Hi, > > I am having a product which is right now using openssl1.0.1s and > opensslfips 2.0.1 > > I am upgrading to openssl1.0.2h, is it OK to still be at openssfips > 2.0.1 or do i need to upgrade the opensslfips too to 2.0.12? > > Regards, > > Yes, it's fine to stay at 2.0.1 if that's working for you now. With one singular exception, we're not allowed to implement improvements or bug fixes in a validated cryptographic module, so the later revisions of the OpenSSL FIPS module (now up to 2.0.13) are not "better" in any real-world sense (i.e. better performance, security vulnerability mitigations, etc.). The permitted mods are for platform portability and have to implemented in a way that does not impact any previously tested platforms. The exception is the complete removal of Dual EC DRBG as of 2.0.6 (and again for 2.0.8, long story). The Dual EC DRBG was disabled all along, but its complete removal was arguably a vulnerability mitigation. I think that was only allowed (after much delay) as a special case exception due to the notoriety of that algorithm. If not having a dormant Dual EC DRBG matters to you then upgrade to any revision 2.0.8 or later. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 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 totszwai at gmail.com Wed Aug 24 19:50:07 2016 From: totszwai at gmail.com (Eric To) Date: Wed, 24 Aug 2016 15:50:07 -0400 Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? Message-ID: Can someone give an example on how to use the SSL_SESSION_set_ex_data? I'm trying to set custom information in apache mod_ssl and after trying many different ways, but can't get it to stick... struct st_blah_t { int blah; } BLAH; my_data_idx = SSL_SESSION_get_ex_new_index(0, "BLAH", NULL, NULL, NULL); BLAH b; b.blah = 12345; SSL_SESSION *session = SSL_get_session(ssl); SSL_SESSION_set_ex_data(session, my_data_idx, &b); SSL_set_session(ssl, sess); Am I using the functions right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Aug 24 19:56:54 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 24 Aug 2016 19:56:54 +0000 Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? In-Reply-To: References: Message-ID: > BLAH b; > b.blah = 12345; > > SSL_SESSION *session = SSL_get_session(ssl); > SSL_SESSION_set_ex_data(session, my_data_idx, &b); > SSL_set_session(ssl, sess); Is "b" a stack variable? You should malloc it. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From Michael.Wojcik at microfocus.com Wed Aug 24 22:21:05 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 24 Aug 2016 22:21:05 +0000 Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? In-Reply-To: References: Message-ID: (Top-posting because Outlook still can't handle HTML email correctly.) Unless I'm missing something, you're using the OpenSSL functions correctly - though I admit I just looked at them here and didn't check the documentation or my own use of them. Perhaps you're not using C correctly. We can't tell what the storage class of "b" is, because we don't have context. Is it static or automatic? If it's automatic, then as soon as it goes out of scope, bang - the pointer you've stored is invalid. The pointer you store should be to an object of static or dynamic storage class. Static doesn't generally make sense, unless your sessions need to be associated with one of a handful of objects that don't change after creation. More typically you'd use a dynamic object. For example: static const BLAH blah0 = {0}; BLAH *bp = malloc(sizeof *bp); if (! bp) { error handling } *bp = blah0; bp->b = 12345; ... SSL_SESSION_set_ex_data(session, my_data_idx, bp); If you're using C++, of course, you'd want to create an object instance using operator new, rather than calling malloc. But the principle remains the same - don't use a pointer to an object which will be invalidated when it goes out of scope. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eric To Sent: Wednesday, August 24, 2016 15:50 To: openssl-users at openssl.org Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? Can someone give an example on how to use the SSL_SESSION_set_ex_data? I'm trying to set custom information in apache mod_ssl and after trying many different ways, but can't get it to stick... struct st_blah_t { int blah; } BLAH; my_data_idx = SSL_SESSION_get_ex_new_index(0, "BLAH", NULL, NULL, NULL); BLAH b; b.blah = 12345; SSL_SESSION *session = SSL_get_session(ssl); SSL_SESSION_set_ex_data(session, my_data_idx, &b); SSL_set_session(ssl, sess); Am I using the functions right? -------------- next part -------------- An HTML attachment was scrubbed... URL: From changzheng.wei at intel.com Thu Aug 25 01:04:54 2016 From: changzheng.wei at intel.com (Wei, Changzheng) Date: Thu, 25 Aug 2016 01:04:54 +0000 Subject: [openssl-users] [openssl-user] How to use memory debug functions (CRYPTO_mem_leaks) in OpenSSL 1.1.0 (pre6 release) ? Message-ID: <936BE946F26E274A8595DBF91A05BD764B30B26F@SHSMSX101.ccr.corp.intel.com> I used memory debug functions (such as CRYPTO_mem_leaks/CRYPTO_mem_leaks_fp) to check the memory leak. In the old version, such as openssl-1.0.2d, I can call CRYPTO_mem_leaks() functions any time in my application to dump the memory information. But in OpenSSL-1.1.0, it will fail due to the new CRYPTO_mem_leaks() introduce the RUN_ONCE() function to initialize the memory lock and cleanup the locks at the end of the function. My application is a multi-process application, parent process will perform the memory lock initialization once, so in child process the RUN_ONCE() function will never be performed. After I perform CRYPTO_mem_leaks(), at the end of this function, the malloc_lock will be freed, so it will cause unexpected coredump if I insert CRYPTO_mem_leaks() function in my code. What I can do now is register this function to atexit(), when the process exit, CRYPTO_mem_leaks() will be performed to dump the memory leakage information. Is this behavior expected? int CRYPTO_mem_leaks(BIO *b) { MEM_LEAK ml; /* * OPENSSL_cleanup() will free the ex_data locks so we can't have any * ex_data hanging around */ bio_free_ex_data(b); /* Ensure all resources are released */ OPENSSL_cleanup(); if (!RUN_ONCE(&memdbg_init, do_memdbg_init)) return -1; CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_DISABLE); ml.bio = b; ml.bytes = 0; ml.chunks = 0; if (mh != NULL) lh_MEM_doall_MEM_LEAK(mh, print_leak, &ml); if (ml.chunks != 0) { BIO_printf(b, "%ld bytes leaked in %d chunks\n", ml.bytes, ml.chunks); } else { /* * Make sure that, if we found no leaks, memory-leak debugging itself * does not introduce memory leaks (which might irritate external * debugging tools). (When someone enables leak checking, but does not * call this function, we declare it to be their fault.) */ int old_mh_mode; CRYPTO_THREAD_write_lock(malloc_lock); /* * avoid deadlock when lh_free() uses CRYPTO_mem_debug_free(), which uses * mem_check_on */ old_mh_mode = mh_mode; mh_mode = CRYPTO_MEM_CHECK_OFF; lh_MEM_free(mh); mh = NULL; mh_mode = old_mh_mode; CRYPTO_THREAD_unlock(malloc_lock); } CRYPTO_mem_ctrl(CRYPTO_MEM_CHECK_OFF); /* Clean up locks etc */ CRYPTO_THREAD_cleanup_local(&appinfokey); CRYPTO_THREAD_lock_free(malloc_lock); CRYPTO_THREAD_lock_free(long_malloc_lock); malloc_lock = NULL; long_malloc_lock = NULL; return ml.chunks == 0 ? 1 : 0; } -------------- next part -------------- An HTML attachment was scrubbed... URL: From lily.zhang at emc.com Thu Aug 25 03:10:19 2016 From: lily.zhang at emc.com (Zhang, Lily (USD)) Date: Thu, 25 Aug 2016 03:10:19 +0000 Subject: [openssl-users] CVE-2016-2108 and openssl 0.9.8zf Message-ID: Hi >From the openssl website, it mentioned that CVE-2016-2108 affected version of Openssl prior to April 2015. We used openssl 0.98zf in our old product which was released several years ago. Do you know if CVE-2016-2108 affected version 0.9.8zf? We want to get this info to plan our work. Thanks Lily CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] This issue affected versions of OpenSSL prior to April 2015. CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] * Fixed in OpenSSL 1.0.1o (Affected 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) * Fixed in OpenSSL 1.0.2c (Affected 1.0.2b, 1.0.2a, 1.0.2) -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.gif Type: image/gif Size: 76 bytes Desc: image001.gif URL: From rsalz at akamai.com Thu Aug 25 03:42:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 25 Aug 2016 03:42:30 +0000 Subject: [openssl-users] [openssl-user] How to use memory debug functions (CRYPTO_mem_leaks) in OpenSSL 1.1.0 (pre6 release) ? In-Reply-To: <936BE946F26E274A8595DBF91A05BD764B30B26F@SHSMSX101.ccr.corp.intel.com> References: <936BE946F26E274A8595DBF91A05BD764B30B26F@SHSMSX101.ccr.corp.intel.com> Message-ID: <913808ef3ebc4ad4925a5d67a8f26fb1@usma1ex-dag1mb1.msg.corp.akamai.com> Look at what the apps or test programs do From sivagopi059 at gmail.com Thu Aug 25 08:21:40 2016 From: sivagopi059 at gmail.com (sivagopiraju) Date: Thu, 25 Aug 2016 01:21:40 -0700 (MST) Subject: [openssl-users] CVE-2016-2180 Message-ID: <1472113300324-68032.post@n7.nabble.com> I am using openssl-1.0.0e in my product. Here i want to know that OpenSSL is CVE-2016-2180 vulnerable or not. https://github.com/openssl/openssl/commit/0ed26acce328ec16a3aa635f1ca37365e8c7403a?diff=unified In this page showing some information about CVE-2016-2180 vulnerability. Actually i read some information from the internet that, to reproduce this vulnerability need to "*create specially crafted time stamp file and used with the "openssl ts"*" command. How to create "specially crafted time stamp file". In the CVE-2016-2180 vulnerability talk about TS_OBJ_print_bio function creating the crash. This function is present in the openssl i have. Is there any patch available for this vulnerability. -- View this message in context: http://openssl.6102.n7.nabble.com/CVE-2016-2180-tp68032.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From afredrikn at gmail.com Thu Aug 25 10:03:04 2016 From: afredrikn at gmail.com (Fredrik Nilsson) Date: Thu, 25 Aug 2016 12:03:04 +0200 Subject: [openssl-users] Transmit on a specific nic Message-ID: Hi, I am having trouble getting my application to send out DTLS packets on a specific nic/vlan. My application needs to bypass the local routing table and force packets to go out via a specified nic. The way I do it in plaintext mode is to simply bind the output socket to that specific nic which works well. So before I call SSL_new() and BIO_new_dgram() I do a bind() on the socket so the transmitted packets should be forced to go out on a specific nic instead of handing over that decision to the local routing table. But no luck for me, the packets still go out the way that are specified in the routing table when I use OpenSSL. Any thoughts around where this might go wrong is greatly appreciated. Regards Fredrik -------------- next part -------------- An HTML attachment was scrubbed... URL: From meissner at suse.de Thu Aug 25 10:34:25 2016 From: meissner at suse.de (Marcus Meissner) Date: Thu, 25 Aug 2016 12:34:25 +0200 Subject: [openssl-users] CVE-2016-2108 and openssl 0.9.8zf In-Reply-To: References: Message-ID: <20160825103425.GF20585@suse.de> Hi, to my knowledge older versions are also affected. Ciao, Marcus On Thu, Aug 25, 2016 at 03:10:19AM +0000, Zhang, Lily (USD) wrote: > Hi > > From the openssl website, it mentioned that CVE-2016-2108 affected version of Openssl prior to April 2015. > We used openssl 0.98zf in our old product which was released several years ago. > > Do you know if CVE-2016-2108 affected version 0.9.8zf? We want to get this info to plan our work. > > Thanks > Lily > > CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > This issue affected versions of OpenSSL prior to April 2015. > > CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > * Fixed in OpenSSL 1.0.1o (Affected 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) > * Fixed in OpenSSL 1.0.2c (Affected 1.0.2b, 1.0.2a, 1.0.2) > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real From tshort at akamai.com Thu Aug 25 12:21:15 2016 From: tshort at akamai.com (Short, Todd) Date: Thu, 25 Aug 2016 12:21:15 +0000 Subject: [openssl-users] Building OpenSSL 1.0.1t without tls1.1 support? In-Reply-To: References: Message-ID: <786204F1-1C75-40ED-91AC-B317EE987676@akamai.com> 1.0.1 is old, and not really supported, except some security fixes. 1.0.x does not provide the ability to compile out TLSv1.0 from 1.1 from 1.2. The upcoming 1.1.x does. If you disable tls1, then you?ve also disabled all later versions, so enable tlsv1 at config time and use the SSL options to enable/disable the protocols at run time. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Aug 22, 2016, at 3:08 PM, Scott Neugroschl > wrote: I?ve done a custom build of OpenSSL where I ran Configure with ?no-ssl2? and ?no-ssl3?. I?d like to disable TLS1 and 1.1 if possible. Will the no-tls1 option disable just TLS1 or all TLS1.x protocols? Thanks, ScottN -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From totszwai at gmail.com Thu Aug 25 13:29:06 2016 From: totszwai at gmail.com (Eric To) Date: Thu, 25 Aug 2016 09:29:06 -0400 Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? Message-ID: Thanks Rich and Michael. That was it, I was under the impression that these set functions would behave like those i2d function that would put the actual data inside... as I don't want to deal with the deallocation later (as I am modifying apache's mod_ssl). This seems to work as I can immediately read it back (before I couldn't) with get_ex_data. Do I still need to call SSL_set_session to put the updated session back in the SSL? According to the documentation: "If there is already a session set inside ssl (because it was set with SSL_set_session() before or because the same ssl was already used for a connection), SSL_SESSION_free() will be called for that session." > > BLAH b; > > b.blah = 12345; > > > > SSL_SESSION *session = SSL_get_session(ssl); > > SSL_SESSION_set_ex_data(session, my_data_idx, &b); > > SSL_set_session(ssl, sess); > > Is "b" a stack variable? You should malloc it. > > -- > Senior Architect, Akamai Technologies > IM: richsalz at jabber.at Twitter: RichSalz > > ------------------------------ > > > (Top-posting because Outlook still can't handle HTML email correctly.) > > Unless I'm missing something, you're using the OpenSSL functions correctly > - though I admit I just looked at them here and didn't check the > documentation or my own use of them. Perhaps you're not using C correctly. > > We can't tell what the storage class of "b" is, because we don't have > context. Is it static or automatic? If it's automatic, then as soon as it > goes out of scope, bang - the pointer you've stored is invalid. > > The pointer you store should be to an object of static or dynamic storage > class. Static doesn't generally make sense, unless your sessions need to be > associated with one of a handful of objects that don't change after > creation. More typically you'd use a dynamic object. For example: > > static const BLAH blah0 = {0}; > BLAH *bp = malloc(sizeof *bp); > if (! bp) { error handling } > *bp = blah0; > bp->b = 12345; > ... > SSL_SESSION_set_ex_data(session, my_data_idx, bp); > > If you're using C++, of course, you'd want to create an object instance > using operator new, rather than calling malloc. But the principle remains > the same - don't use a pointer to an object which will be invalidated when > it goes out of scope. > > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Aug 25 13:51:52 2016 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 25 Aug 2016 13:51:52 +0000 Subject: [openssl-users] Example on SSL_SESSION_set_ex_data? In-Reply-To: References: Message-ID: Sorry, I missed that call to SSL_set_session. No, you don't need to call SSL_set_session. SSL_get_session is a get0-type function; it just returns a copy of the pointer in the SSL object. So any changes you make to that SSL_SESSION object are to the one that's already in the SSL object. Calling SSL_set_session with the same session that's already in the SSL should be OK, because the code increments the reference count on the SSL_SESSION before calling SSL_SESSION_free - and so the free will just decrement the count again. But it doesn't do anything useful. (SSL_set_session could do a reference comparison on the existing and new sessions and return without doing anything if they're the same, but there's probably little real-world value in adding such an optimization.) The code's in ssl/ssl_sess.c (at least for 1.0.2), if you want to have a look for yourself. It's quite straightforward, which is not *always* the case with OpenSSL. Michael Wojcik Distinguished Engineer, Micro Focus From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Eric To Sent: Thursday, August 25, 2016 09:29 To: openssl-users at openssl.org Subject: Re: [openssl-users] Example on SSL_SESSION_set_ex_data? Thanks Rich and Michael. That was it, I was under the impression that these set functions would behave like those i2d function that would put the actual data inside... as I don't want to deal with the deallocation later (as I am modifying apache's mod_ssl). This seems to work as I can immediately read it back (before I couldn't) with get_ex_data. Do I still need to call SSL_set_session to put the updated session back in the SSL? According to the documentation: "If there is already a session set inside ssl (because it was set with SSL_set_session() before or because the same ssl was already used for a connection), SSL_SESSION_free() will be called for that session." -------------- next part -------------- An HTML attachment was scrubbed... URL: From guru at unixarea.de Thu Aug 25 14:21:44 2016 From: guru at unixarea.de (Matthias Apitz) Date: Thu, 25 Aug 2016 16:21:44 +0200 Subject: [openssl-users] libssl.so.1.0.0 -> Java1.6 net.ssl gives: dh key too small:s3_clnt.c:3617: Message-ID: <20160825142144.GA2303@c720-r292778-amd64.oa.oclc.org> Hello, We have a C written OpenSSL application which talks to a server written in Java1.6. The client side (i.e. OpenSSL) rejects connecting with the error: 25.08.2016-10:58:06 Error - SSL_connect() returned:<-1> - connection failed 25.08.2016-10:58:06 SSL_get_error() returned SSL_ERROR_SSL, ERR_print_errors_fp(): 4087322300:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3617: I read in Don Google that is due to a stronger check in OpenSSL since somewhere in September 2015. The problem is of course with the old Java 1.6 server and does not show up when we talk to a newer version of our server runninng on Java1.8. It works also with 1.6 when I use on the C side some older shared lib libssl.so.1.0.0 from Januar 2015, i.e. it seems exactly the bug as described in https://groups.google.com/forum/#!topic/ganeti/ds0TwfroS8A : The used keystore is generated with the Java keytool. It does not help generate the keystore with Java1.8 keytool and use this in the Java1.6 server. Is there some workaround? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, ? http://www.unixarea.de/ ? +49-176-38902045 From jb-openssl at wisemo.com Thu Aug 25 16:29:08 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 25 Aug 2016 18:29:08 +0200 Subject: [openssl-users] libssl.so.1.0.0 -> Java1.6 net.ssl gives: dh key too small:s3_clnt.c:3617: In-Reply-To: <20160825142144.GA2303@c720-r292778-amd64.oa.oclc.org> References: <20160825142144.GA2303@c720-r292778-amd64.oa.oclc.org> Message-ID: <5cd47179-7105-20f7-30ec-504a699f723b@wisemo.com> On 25/08/2016 16:21, Matthias Apitz wrote: > Hello, > > We have a C written OpenSSL application which talks to a server written > in Java1.6. The client side (i.e. OpenSSL) rejects connecting with the > error: > > 25.08.2016-10:58:06 Error - SSL_connect() returned:<-1> - connection failed > 25.08.2016-10:58:06 SSL_get_error() returned SSL_ERROR_SSL, ERR_print_errors_fp(): > 4087322300:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3617: > > I read in Don Google that is due to a stronger check in OpenSSL since > somewhere in September 2015. The problem is of course with the old Java 1.6 > server and does not show up when we talk to a newer version of our > server runninng on Java1.8. It works also with 1.6 when I use on the C > side some older shared lib libssl.so.1.0.0 from Januar 2015, i.e. it > seems exactly the bug as described in > https://groups.google.com/forum/#!topic/ganeti/ds0TwfroS8A : > > The used keystore is generated with the Java keytool. It does not help > generate the keystore with Java1.8 keytool and use this in the Java1.6 > server. > > Is there some workaround? > According to the information published by Qualsys, Java 1.6 supports DH group parameters (primes) up to 1024 bit. OpenSSL and other modern clients rejects DH group parameters smaller than 768 or 1024 bits. So configuring the Java 1.6 server to use a (brand new, not shared with other sites) 1024 bit prime in its DH group parameters should be the best available compromise. Upgrading to a current version of Java would allow using a more secure prime size such as 2048 bits or more, but could involve incompatibilities in other parts of Java. I don't know how to tell the SSL/TLS code in Java 1.6 to use specific DH group parameters, or to generate new such parameters on a regular basis (it's a somewhat slow task, so should be done in background while incoming connections use the previous group parameters stored in an on-disk cache of some kind). 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 Andrew_Porter at bmc.com Thu Aug 25 15:38:38 2016 From: Andrew_Porter at bmc.com (Porter, Andrew) Date: Thu, 25 Aug 2016 15:38:38 +0000 Subject: [openssl-users] libssl.so.1.0.0 -> Java1.6 net.ssl gives: dh key too small:s3_clnt.c:3617: In-Reply-To: <20160825142144.GA2303@c720-r292778-amd64.oa.oclc.org> References: <20160825142144.GA2303@c720-r292778-amd64.oa.oclc.org> Message-ID: <8a609902f17e446fb13057856359f864@hou-exmbprd-02.adprod.bmc.com> There may be other solutions but here are two I've used: (1) Upgrade the Java the server uses to a recent Java 8. It should run fine. The product I work in is built with the Java 6 development kit but runs without any problems on Java 6 - 8. (2) Update the server Java 6 to the latest version of 6 with security updates. This is NOT publicly available but is available under support from Oracle. If the server is running on Red Hat Enterprise Linux and has support you are able to get the latest Java 6 through Red Hat by adding a special subscription channel and using the standard system update tools to install/update Oracle Java. Don't know about other operating systems. Andrew -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthias Apitz Sent: Thursday, August 25, 2016 07:22 To: openssl-users at openssl.org Subject: [openssl-users] libssl.so.1.0.0 -> Java1.6 net.ssl gives: dh key too small:s3_clnt.c:3617: Hello, We have a C written OpenSSL application which talks to a server written in Java1.6. The client side (i.e. OpenSSL) rejects connecting with the error: 25.08.2016-10:58:06 Error - SSL_connect() returned:<-1> - connection failed 25.08.2016-10:58:06 SSL_get_error() returned SSL_ERROR_SSL, ERR_print_errors_fp(): 4087322300:error:14082174:SSL routines:ssl3_check_cert_and_algorithm:dh key too small:s3_clnt.c:3617: I read in Don Google that is due to a stronger check in OpenSSL since somewhere in September 2015. The problem is of course with the old Java 1.6 server and does not show up when we talk to a newer version of our server runninng on Java1.8. It works also with 1.6 when I use on the C side some older shared lib libssl.so.1.0.0 from Januar 2015, i.e. it seems exactly the bug as described in https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_forum_-23-21topic_ganeti_ds0TwfroS8A&d=CwIGaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=zyF1KGGEdIw5t8MZBZhZYjK_goSnyFnKtB2cxUvFm5Q&s=9It2fqYqL0MrbGps6_nQksmKlroixvU1_OGDrUFtrWQ&e= : The used keystore is generated with the Java keytool. It does not help generate the keystore with Java1.8 keytool and use this in the Java1.6 server. Is there some workaround? Thanks matthias -- Matthias Apitz, ? guru at unixarea.de, ? https://urldefense.proofpoint.com/v2/url?u=http-3A__www.unixarea.de_&d=CwIGaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=zyF1KGGEdIw5t8MZBZhZYjK_goSnyFnKtB2cxUvFm5Q&s=G05u61yon8Fp-9mwaRO2ujd87dFGPboM4uGXo7IhMIU&e= ? +49-176-38902045 -- openssl-users mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Dusers&d=CwIGaQ&c=UrUhmHsiTVT5qkaA4d_oSzcamb9hmamiCDMzBAEwC7E&r=rM-xapYCunnmjke6suxLaVU8krc3wfCZvRQxfT87RRc&m=zyF1KGGEdIw5t8MZBZhZYjK_goSnyFnKtB2cxUvFm5Q&s=bXIMkT6q0xTjcZ6C6_6c9QRue1Na6iyGeDZ20yqzgMo&e= From openssl at openssl.org Thu Aug 25 16:46:45 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 25 Aug 2016 16:46:45 +0000 Subject: [openssl-users] OpenSSL version 1.1.0 published Message-ID: <20160825164645.GA30454@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0 released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0 of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0.tar.gz Size: 5146831 SHA1 checksum: 15e651c40424abdaeba5d5c1a8658e8668e798c8 SHA256 checksum: f5c69ff9ac1472c80b868efc1c1c0d8dcfc746d29ebe563de2365dd56dbd8c82 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0.tar.gz openssl sha256 openssl-1.1.0.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJXvw7WAAoJENnE0m0OYESRmhkH/1UTJ3I1v52w3NDWKK5XGyxH HKr/EMgjo05IdmtmY3lLB0aPwN50am5Y9w8SmFnXA8+bsKwH61+G5Sr9L+ABuhI2 95QQzxAyQBHf0IxH1hYBLZxI0Hr46O9qefphr7lcBIh/XrFu6Hg96s8lo/87UEEC LUzOAGAEpM6kicBA4bxrLdXSV+IR+j/2mRrkGvw4Ecb9aQYxWJ6daWxJcvXKKy8N S8Gw4DNJH2636UyKsbY/6bMGlBWbjmL9GLzbD1YT+NxvSsWPPRkrdDhMKxkxDrP4 gIBBSE4C7mZgqvSxVIo2GQszQgTUdroyd9UStUDsBF/xYK2a8bvoL0PtihZF+0E= =Zq4E -----END PGP SIGNATURE----- From lily.zhang at emc.com Fri Aug 26 02:16:47 2016 From: lily.zhang at emc.com (Zhang, Lily (USD)) Date: Fri, 26 Aug 2016 02:16:47 +0000 Subject: [openssl-users] CVE-2016-2108 and openssl 0.9.8zf In-Reply-To: <20160825103425.GF20585@suse.de> References: <20160825103425.GF20585@suse.de> Message-ID: Thanks Marcus! Lily -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Marcus Meissner Sent: Thursday, August 25, 2016 6:34 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] CVE-2016-2108 and openssl 0.9.8zf Hi, to my knowledge older versions are also affected. Ciao, Marcus On Thu, Aug 25, 2016 at 03:10:19AM +0000, Zhang, Lily (USD) wrote: > Hi > > From the openssl website, it mentioned that CVE-2016-2108 affected version of Openssl prior to April 2015. > We used openssl 0.98zf in our old product which was released several years ago. > > Do you know if CVE-2016-2108 affected version 0.9.8zf? We want to get this info to plan our work. > > Thanks > Lily > > CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > This issue affected versions of OpenSSL prior to April 2015. > > CVE-2016-2108 (OpenSSL advisory) [High severity] 3rd May 2016: [https://www.openssl.org/img/up.gif] > * Fixed in OpenSSL 1.0.1o (Affected 1.0.1n, 1.0.1m, 1.0.1l, 1.0.1k, 1.0.1j, 1.0.1i, 1.0.1h, 1.0.1g, 1.0.1f, 1.0.1e, 1.0.1d, 1.0.1c, 1.0.1b, 1.0.1a, 1.0.1) > * Fixed in OpenSSL 1.0.2c (Affected 1.0.2b, 1.0.2a, 1.0.2) > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Marcus Meissner,SUSE LINUX GmbH; Maxfeldstrasse 5; D-90409 Nuernberg; Zi. 3.1-33,+49-911-740 53-432,,serv=loki,mail=wotan,type=real -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From wsware at gmail.com Fri Aug 26 03:42:26 2016 From: wsware at gmail.com (Scott Ware) Date: Thu, 25 Aug 2016 23:42:26 -0400 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm wrote: > On 22/08/2016 22:33, Scott Ware wrote: >> >> >> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm > >wrote: >> >> On 22/08/2016 20:09, Scott Ware wrote: >> >> We use libeay32.dll and ssleay32.dll from >> https://slproweb.com/products/Win32OpenSSL.htmlin >> our >> applications and we recently moved from version 1.0.2a to >> 1.0.2g and now on a few machines running a AMD Geode processor >> we are getting "Unhandled exception at 0x005904dc >> (libeay32.dll) in Test.exe: 0xC000001D: Illegal Instruction". >> We ended up building OpennSSL so we could debug into it and >> found it is failing on "movsd xmm0,mmword" (see below) which >> the AMD Geode does not seem to support. I have tried "SET >> OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", >> and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to >> change. I may not be using OPENSSL_ia32cap correctly. This >> happens when calling SSL_CTX_new which then calls RAND_add. >> >> Any ideas on the best thing to do? We don't want to have to >> manage different compiled versions of libeay32.dll and >> ssleay32.dll if we can help it. >> >> Your disassembly looks like the C compiler was invoked with >> options that caused regular C floating point code (in this >> case, the passing of 45.0 as an argument to RAND_add()) to >> be compiled into MMX/SSE instructions instead of backwards >> compatible 80x87 floating point instructions or (for simple >> cases like this) regular integer unit data movement >> instructions (such as two pushes of 32 bit constants that >> contain the halves of the 64 bit double constant, which >> would have been more efficient on every x86 CPU). >> >> Did the build scripts or other source code contain any >> differences from the official source code that can be >> downloaded from openssl.org ? >> >> How did you invoke the build scripts (command sequence, >> special build environment, special environment variables >> etc.)? >> >> Which compiler and compiler version/edition did you use? >> >> It would be interesting to know if one of the common Windows >> compilers does this unconditionally, making it unsuitable >> for use in programs that need to be backwards compatible. >> >> >> >> I compiled using this process and seem to be getting the same result as >> the .dll I downloaded from slproweb.com >> I downloaded the 1.0.2g source from openssl.com and >> didn't change anything. >> >> From the "Developer Command Promt for VS2013" >> perl Configure debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg >> ms\do_ms >> nmake -f ms\ntdll.mak >> nmake -f ms\ntdll.mak install > > According to the following page > > https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx > > Visual Studio 2012 and later requires the following compiler > option to generate code compatible with older CPUs (this is the > default in Visual Studio 2010, and VS2010 does not support the > option): > > /arch:IA32 > > > This compiler gotcha is specific to the 32 bit x86 architecture, > the default looks like it is still sane for x86_64. > > Note to the FIPS team: Please check if this affects the FIPS > module building procedure. Well, I tried to get my normal distribution source to compile with /arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM, Thomas J. Hruska wrote: > On 8/23/2016 7:19 AM, Scott Ware wrote: >> >> Shining Light Productions, >> Would you consider implementing this in your builds? VS2012 and >> above require the /arch:IA32 flag to produce x86 code compatible with >> older CPUs. >> >> https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html >> >> Thanks, >> Scott Ware > > > This is an upstream issue. I only do default builds. Contact the OpenSSL > developers if you want that flag added to the default build process. > > SSE2 is the default target architecture for Visual Studio when /arch is not > specified. If you don't have a CPU with SSE2 instruction support, then it > is long past due for a hardware upgrade. > > -- > Thomas Hruska > Shining Light Productions > > Home of BMP2AVI and Win32 OpenSSL. > http://www.slproweb.com/ From jb-openssl at wisemo.com Fri Aug 26 04:21:47 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 26 Aug 2016 06:21:47 +0200 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: On 26/08/2016 05:42, Scott Ware wrote: > On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm > wrote: >> On 22/08/2016 22:33, Scott Ware wrote: >>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >> >wrote: On 22/08/2016 20:09, Scott >>> Ware wrote: We use libeay32.dll and ssleay32.dll from >>> https://slproweb.com/products/Win32OpenSSL.htmlin >>> our applications >>> and we recently moved from version 1.0.2a to 1.0.2g and now on a few >>> machines running a AMD Geode processor we are getting "Unhandled >>> exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: >>> Illegal Instruction". We ended up building OpennSSL so we could >>> debug into it and found it is failing on "movsd xmm0,mmword" (see >>> below) which the AMD Geode does not seem to support. I have tried >>> "SET OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", >>> and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I >>> may not be using OPENSSL_ia32cap correctly. This happens when >>> calling SSL_CTX_new which then calls RAND_add. Any ideas on the best >>> thing to do? We don't want to have to manage different compiled >>> versions of libeay32.dll and ssleay32.dll if we can help it. Your >>> disassembly looks like the C compiler was invoked with options that >>> caused regular C floating point code (in this case, the passing of >>> 45.0 as an argument to RAND_add()) to be compiled into MMX/SSE >>> instructions instead of backwards compatible 80x87 floating point >>> instructions or (for simple cases like this) regular integer unit >>> data movement instructions (such as two pushes of 32 bit constants >>> that contain the halves of the 64 bit double constant, which would >>> have been more efficient on every x86 CPU). Did the build scripts or >>> other source code contain any differences from the official source >>> code that can be downloaded from openssl.org ? >>> How did you invoke the build scripts (command sequence, special >>> build environment, special environment variables etc.)? Which >>> compiler and compiler version/edition did you use? It would be >>> interesting to know if one of the common Windows compilers does this >>> unconditionally, making it unsuitable for use in programs that need >>> to be backwards compatible. I compiled using this process and seem >>> to be getting the same result as the .dll I downloaded from >>> slproweb.com I downloaded the 1.0.2g source >>> from openssl.com and didn't change anything. >>> From the "Developer Command Promt for VS2013" perl Configure >>> debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg ms\do_ms nmake >>> -f ms\ntdll.mak nmake -f ms\ntdll.mak install >> According to the following page >> https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx >> Visual Studio 2012 and later requires the following compiler option >> to generate code compatible with older CPUs (this is the default in >> Visual Studio 2010, and VS2010 does not support the option): >> /arch:IA32 This compiler gotcha is specific to the 32 bit x86 >> architecture, the default looks like it is still sane for x86_64. >> Note to the FIPS team: Please check if this affects the FIPS module >> building procedure. > Well, I tried to get my normal distribution source to compile with > /arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM, > Thomas J. Hruska wrote: >> On 8/23/2016 7:19 AM, Scott Ware wrote: >>> Shining Light Productions, Would you consider implementing this in >>> your builds? VS2012 and above require the /arch:IA32 flag to produce >>> x86 code compatible with older CPUs. >>> https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html >>> Thanks, Scott Ware >> This is an upstream issue. I only do default builds. Contact the >> OpenSSL developers if you want that flag added to the default build >> process. SSE2 is the default target architecture for Visual Studio >> when /arch is not specified. If you don't have a CPU with SSE2 >> instruction support, then it is long past due for a hardware upgrade. >> -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 >> OpenSSL. http://www.slproweb.com/ Bad on them, those of us that have seen this kind of hardware all know that Geode CPUs use very very little power compared to modern Intel CPUs, less even than most of Intel's "Atom" CPUs. I have a Geode SC1100 based server running 24/7 at 266MHz using less than about 7W peak with no heatsink. Even a real 486DX @33MHz couldn't do that. This server actually replaced a 486DX @33MHz to save power and was not upgraded to a more power hungry successor product based on an Atom. This is clearly a compiler misfeature in the VS2012+ compiler, which assumes by default the compiled binaries will only be used on desktop or higher class CPUs that can run Windows 8, not on pared down CPUs that are designed for power saving embedded Windows. But anyway, just doing your own scripted builds instead of waiting for Shining Light should be just fine. P.S. Instead of editing the generated .mak files, you may just be able to pass the -arch:IA32 option to "perl Configure", but test it first. If it works, it would make it a lot easier to script the whole process in a batch file or two as part of your product build. 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 shinelight at shininglightpro.com Fri Aug 26 06:10:39 2016 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Thu, 25 Aug 2016 23:10:39 -0700 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> Message-ID: <0a8537b7-762e-6439-a6d6-be0961b00e0a@shininglightpro.com> On 8/25/2016 9:21 PM, Jakob Bohm wrote: > On 26/08/2016 05:42, Scott Ware wrote: >> On Mon, Aug 22, 2016 at 8:05 PM, Jakob Bohm >> wrote: >>> On 22/08/2016 22:33, Scott Ware wrote: >>>> On Mon, Aug 22, 2016 at 3:04 PM, Jakob Bohm >>> >wrote: On 22/08/2016 20:09, Scott >>>> Ware wrote: We use libeay32.dll and ssleay32.dll from >>>> https://slproweb.com/products/Win32OpenSSL.htmlin >>>> our applications >>>> and we recently moved from version 1.0.2a to 1.0.2g and now on a few >>>> machines running a AMD Geode processor we are getting "Unhandled >>>> exception at 0x005904dc (libeay32.dll) in Test.exe: 0xC000001D: >>>> Illegal Instruction". We ended up building OpennSSL so we could >>>> debug into it and found it is failing on "movsd xmm0,mmword" (see >>>> below) which the AMD Geode does not seem to support. I have tried >>>> "SET OPENSSL_ia32cap=~0x1000000", "SET OPENSSL_ia32cap=~0x2000000", >>>> and "SET OPENSSL_ia32cap=~0x7000000"; and nothing seems to change. I >>>> may not be using OPENSSL_ia32cap correctly. This happens when >>>> calling SSL_CTX_new which then calls RAND_add. Any ideas on the best >>>> thing to do? We don't want to have to manage different compiled >>>> versions of libeay32.dll and ssleay32.dll if we can help it. Your >>>> disassembly looks like the C compiler was invoked with options that >>>> caused regular C floating point code (in this case, the passing of >>>> 45.0 as an argument to RAND_add()) to be compiled into MMX/SSE >>>> instructions instead of backwards compatible 80x87 floating point >>>> instructions or (for simple cases like this) regular integer unit >>>> data movement instructions (such as two pushes of 32 bit constants >>>> that contain the halves of the 64 bit double constant, which would >>>> have been more efficient on every x86 CPU). Did the build scripts or >>>> other source code contain any differences from the official source >>>> code that can be downloaded from openssl.org ? >>>> How did you invoke the build scripts (command sequence, special >>>> build environment, special environment variables etc.)? Which >>>> compiler and compiler version/edition did you use? It would be >>>> interesting to know if one of the common Windows compilers does this >>>> unconditionally, making it unsuitable for use in programs that need >>>> to be backwards compatible. I compiled using this process and seem >>>> to be getting the same result as the .dll I downloaded from >>>> slproweb.com I downloaded the 1.0.2g source >>>> from openssl.com and didn't change anything. >>>> From the "Developer Command Promt for VS2013" perl Configure >>>> debug-VC-WIN32 no-asm --prefix=C:\OpenSSL-VC-32-dbg ms\do_ms nmake >>>> -f ms\ntdll.mak nmake -f ms\ntdll.mak install >>> According to the following page >>> https://msdn.microsoft.com/en-us/library/7t5yh4fd%28v=vs.120%29.aspx >>> Visual Studio 2012 and later requires the following compiler option >>> to generate code compatible with older CPUs (this is the default in >>> Visual Studio 2010, and VS2010 does not support the option): >>> /arch:IA32 This compiler gotcha is specific to the 32 bit x86 >>> architecture, the default looks like it is still sane for x86_64. >>> Note to the FIPS team: Please check if this affects the FIPS module >>> building procedure. >> Well, I tried to get my normal distribution source to compile with >> /arch:IA32. Didn't go well. :( On Thu, Aug 25, 2016 at 10:12 PM, >> Thomas J. Hruska wrote: >>> On 8/23/2016 7:19 AM, Scott Ware wrote: >>>> Shining Light Productions, Would you consider implementing this in >>>> your builds? VS2012 and above require the /arch:IA32 flag to produce >>>> x86 code compatible with older CPUs. >>>> https://mta.openssl.org/pipermail/openssl-users/2016-August/004260.html >>>> Thanks, Scott Ware >>> This is an upstream issue. I only do default builds. Contact the >>> OpenSSL developers if you want that flag added to the default build >>> process. SSE2 is the default target architecture for Visual Studio >>> when /arch is not specified. If you don't have a CPU with SSE2 >>> instruction support, then it is long past due for a hardware upgrade. > Bad on them, those of us that have seen this kind of hardware > all know that Geode CPUs use very very little power compared > to modern Intel CPUs, less even than most of Intel's "Atom" > CPUs. Then push a request upstream to change the default build settings. Don't blame me. The binaries that are built are built strictly with default settings with the only exception being the various funky runtime linker options (/MD, /MT, etc). If you don't like the defaults, then get the upstream changed. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From wsware at gmail.com Fri Aug 26 12:58:19 2016 From: wsware at gmail.com (Scott Ware) Date: Fri, 26 Aug 2016 08:58:19 -0400 Subject: [openssl-users] Unhandled exception at 0x005904dc (libeay32.dll) (Windows x86) In-Reply-To: <0a8537b7-762e-6439-a6d6-be0961b00e0a@shininglightpro.com> References: <949ca17f-2f43-3782-5aa0-67ef81e95166@wisemo.com> <0a8537b7-762e-6439-a6d6-be0961b00e0a@shininglightpro.com> Message-ID: On Fri, Aug 26, 2016 at 2:10 AM, Thomas J. Hruska wrote: > Then push a request upstream to change the default build settings. Don't > blame me. The binaries that are built are built strictly with default > settings with the only exception being the various funky runtime linker > options (/MD, /MT, etc). If you don't like the defaults, then get the > upstream changed. > Hey Thomas! Actually the people to blame is Microsoft. They changed the behavior of Visual Studio. VS2008 was fine, but now in VS2012 and above SSE is enabled by default. https://msdn.microsoft.com/en-us/library/7t5yh4fd(v=vs.110).aspx I will work with the Configure scripts and see if I can find a solution to detect the version of VS and add the flag for VS2012 and above and then try to get it accepted. -Scott Ware From nicolas.raby34 at gmail.com Fri Aug 26 18:20:01 2016 From: nicolas.raby34 at gmail.com (Nicolas Raby) Date: Fri, 26 Aug 2016 20:20:01 +0200 Subject: [openssl-users] compiling openssl android on arm64 Message-ID: Hello, Due to issue in openSSL 1.0.1l , I have to update openSSL in a project on 4 android platforms : armv7, 64 x86 & x64 I m following this guide, but having trouble compiling the 4 versions. while I managed to build armv7, I failing building other versions Can someone help me finding the right variables to edit in setenv-android.sh ? Does anyone knows where to find a more user friendly script ? Here s what I edited for arm64 but it fails with making depend in crypto... ../util/domd: line 26: arm-linux-androideabi-gcc: command not found make[1]: *** [local_depend] Error 1 _ANDROID_NDK="android-ndk-r12b" _ANDROID_EABI="aarch64-linux-android-4.9" _ANDROID_ARCH=arch-arm64 _ANDROID_API="android-19" When I launch the setenv script it only complains about FIPS but I dont need it. iMac-de-Nicolas:openSSLBuild erwan$ . ./setenv-android-arm64.sh ERROR ERROR ERROR Error: FIPS_SIG does not specify incore module. Please edit this script. ANDROID_NDK_ROOT: /Developer/android-ndk-r12b ANDROID_ARCH: arch-arm64 ANDROID_EABI: aarch64-linux-android-4.9 ANDROID_API: android-23 ANDROID_SYSROOT: /Developer/android-ndk-r12b/platforms/android-23/arch-arm64 ANDROID_TOOLCHAIN: /Developer/android-ndk-r12b/toolchains/aarch64-linux-android-4.9/prebuilt/darwin-x86_64/bin FIPS_SIG: CROSS_COMPILE: arm-linux-androideabi- ANDROID_DEV: /Developer/android-ndk-r12b/platforms/android-23/arch-arm64/usr I m on macOS el capitan thanks, Nicolas -------------- next part -------------- An HTML attachment was scrubbed... URL: From kaarl.harster at navy.mil Fri Aug 26 18:17:31 2016 From: kaarl.harster at navy.mil (Harster, Kaarl C CIV NAVSEA KPWA, 104) Date: Fri, 26 Aug 2016 18:17:31 +0000 Subject: [openssl-users] Help installing OpenSSL 1.1.0 pre6 on Windows 2012 R2 Message-ID: Hello, I've tried many times now to install OpenSSL 1.1.0 pre6 on my Windows 2012 R2 64bit machine. We are wanting to run 64bit everything. I have installed ActivePerl 5.24.0.2400 Microsoft Visual Studio Ultimate 2012 version 11.0.50727.1 RTMREL with Visual C++2012 installed in it. When I try to use OpenSSL 1.1.0 pre6 for some reason it can't find the nmake commend and it looks to me that the do_win54a and other files are missing in the ms folder. Sorry but I'm new to ActivePerl. I think the nmake is a perl problem maybe. Is there additional step you have to do after installing Activeperl to get the nmake command to work? I did find on the ActiveState site the following: "For 64-bit Perl on 64-bit Windows currently the only supported compiler is the Visual C++ compiler included in the Windows Server 2003 SP1 Platform SDK (aka the April 2005 edition). Use the SetEnv.cmd script to set the PATH, LIB, and INCLUDE environment variables to the correct value for building ActivePerl extensions with this command: "C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd" /XP64 /RETAIL" I tried installing the SDK on my Windows 2012 R2 64bit machine and of course it will not install can't find files it needs. Has anyone tried this? So I tried going back a version on openSSL When I try to use the 1.0.2h version of openSSL, the nmake and the other do_ files are in the ms folder and seem to work but I cannot seem to get past the following error message: c:\openssl\openssl-1.0.2h>nmake -f ms\nt.mak ... Assembling: tmp32\sha1-586.asm tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 \VC\BIN\ml.EXE"' : return code '0x1' Stop. Or when I try the following I get a different error: c:\openssl\openssl-1.0.2h>perl configure VC-WIN64A --prefix=C:\_openssl-1.0.2a_x 64_release_static Configuring for VC-WIN64A no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) no-gmp [default] OPENSSL_NO_GMP (skip dir) no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 no-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 [default] OPENSSL_NO_SSL2 (skip dir) no-store [experimental] OPENSSL_NO_STORE (skip dir) no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) no-zlib [default] no-zlib-dynamic [default] IsMK1MF=1 CC =cl CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYS NAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_N O_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DO PENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVP AES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM EX_LIBS = CPUID_OBJ =x86_64cpuid.o BN_ASM =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rs az-x86_64.o rsaz-avx2.o EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o DES_ENC =des_enc.o fcrypt_b.o AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-s ha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o BF_ENC =bf_enc.o CAST_ENC =c_enc.o RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o RC5_ENC =rc5_enc.o MD5_OBJ_ASM =md5-x86_64.o SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sh a256-mb-x86_64.o RMD160_OBJ_ASM= CMLL_ENC =cmll-x86_64.o cmll_misc.o MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o ENGINES_OBJ = PROCESSOR = RANLIB =true ARFLAGS = PERL =perl SIXTY_FOUR_BIT mode DES_INT used RC4_CHUNK is unsigned long long Configured for VC-WIN64A. c:\openssl\openssl-1.0.2h>ms\do_win64a c:\openssl\openssl-1.0.2h>perl util\mkfiles.pl 1>MINFO c:\openssl\openssl-1.0.2h>cmd /c "nasm -f win64 -v" 1>NUL 2>&1 c:\openssl\openssl-1.0.2h>if 1 NEQ 0 goto ml64 c:\openssl\openssl-1.0.2h>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm c:\openssl\openssl-1.0.2h>ml64 -c -Foms\uptable.obj ms\uptable.asm Microsoft (R) Macro Assembler (x64) Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. Assembling: ms\uptable.asm c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl VC-WIN64A 1>ms\nt.mak c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl dll VC-WIN64A 1>ms\ntdll.mak c:\openssl\openssl-1.0.2h>perl util\mkdef.pl 32 libeay 1>ms\libeay32.def c:\openssl\openssl-1.0.2h>perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def c:\openssl\openssl-1.0.2h>nmake -f ms\nt.mak Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 Copyright (C) Microsoft Corporation. All rights reserved. Building OpenSSL perl .\util\copy-if-different.pl ".\crypto\buildinf.h" "tmp32\buildinf.h " Copying: ./crypto/buildinf.h to tmp32/buildinf.h perl .\util\copy-if-different.pl ".\crypto\opensslconf.h" "inc32\openssl \opensslconf.h" Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h lib /nologo /out:out32\libeay32.lib @C:\Users\KAARLH~1.LOC\AppData\Local \Temp\nm327D.tmp tmp32\x86_64cpuid.obj : fatal error LNK1112: module machine type 'x64' conflicts with target machine type 'X86' NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 \VC\BIN\lib.EXE"' : return code '0x458' Stop. Kaarl Harster -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5615 bytes Desc: not available URL: From matt at openssl.org Fri Aug 26 19:25:15 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Aug 2016 20:25:15 +0100 Subject: [openssl-users] Help installing OpenSSL 1.1.0 pre6 on Windows 2012 R2 In-Reply-To: References: Message-ID: <0758c617-8fb6-5a2d-9fa7-5e823afb7800@openssl.org> On 26/08/16 19:17, Harster, Kaarl C CIV NAVSEA KPWA, 104 wrote: > Hello, > I've tried many times now to install OpenSSL 1.1.0 pre6 on my Windows 2012 R2 64bit machine. 1.1.0 pre6 is the beta version, but the final 1.1.0 release was made available yesterday, so to start with I suggest you use that. > We are wanting to run 64bit everything. > I have installed > ActivePerl 5.24.0.2400 > Microsoft Visual Studio Ultimate 2012 version 11.0.50727.1 RTMREL with Visual C++2012 installed in it. You also need NASM. See NOTES.WIN > > When I try to use OpenSSL 1.1.0 pre6 for some reason it can't find the nmake commend and it looks to me that the do_win54a and other files are missing in the ms folder. > Sorry but I'm new to ActivePerl. I think the nmake is a perl problem maybe. Is there additional step you have to do after installing Activeperl to get the nmake command to work? nmake comes with Visual Studio. Typically if you use the MSVC developer command prompt it will be available on your PATH. https://msdn.microsoft.com/en-GB/library/ms229859(v=vs.110).aspx > I did find on the ActiveState site the following: > "For 64-bit Perl on 64-bit Windows currently the only supported compiler is the Visual C++ compiler included in the Windows Server 2003 SP1 Platform SDK (aka the April 2005 edition). > Use the SetEnv.cmd script to set the PATH, LIB, and INCLUDE environment variables to the correct value for building ActivePerl extensions with this command: > "C:\Program Files\Microsoft Platform SDK\SetEnv.Cmd" /XP64 /RETAIL" > > I tried installing the SDK on my Windows 2012 R2 64bit machine and of course it will not install can't find files it needs. > Has anyone tried this? > > So I tried going back a version on openSSL > When I try to use the 1.0.2h version of openSSL, the nmake and the other do_ files are in the ms folder and seem to work but I cannot seem to get past the following error message: > c:\openssl\openssl-1.0.2h>nmake -f ms\nt.mak > ... > Assembling: tmp32\sha1-586.asm > tmp32\sha1-586.asm(1432) : error A2070:invalid instruction operands > tmp32\sha1-586.asm(1576) : error A2070:invalid instruction operands > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 > \VC\BIN\ml.EXE"' : return code '0x1' > Stop. You are using the MASM assembler that comes with MSVC. That is no longer officially supported. Use NASM instead. Matt > > Or when I try the following I get a different error: > > c:\openssl\openssl-1.0.2h>perl configure VC-WIN64A --prefix=C:\_openssl-1.0.2a_x > 64_release_static > Configuring for VC-WIN64A > no-ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 (skip dir) > no-gmp [default] OPENSSL_NO_GMP (skip dir) > no-jpake [experimental] OPENSSL_NO_JPAKE (skip dir) > no-krb5 [krb5-flavor not specified] OPENSSL_NO_KRB5 > no-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 [default] OPENSSL_NO_SSL2 (skip dir) > no-store [experimental] OPENSSL_NO_STORE (skip dir) > no-unit-test [default] OPENSSL_NO_UNIT_TEST (skip dir) > no-weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS (skip dir) > no-zlib [default] > no-zlib-dynamic [default] > IsMK1MF=1 > CC =cl > CFLAG =-DOPENSSL_THREADS -DDSO_WIN32 -W3 -Gs0 -Gy -nologo -DOPENSSL_SYS > NAME_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -DUNICODE -D_UNICODE -D_CRT_SECURE_N > O_DEPRECATE -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DO > PENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVP > AES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > EX_LIBS = > CPUID_OBJ =x86_64cpuid.o > BN_ASM =bn_asm.o x86_64-mont.o x86_64-mont5.o x86_64-gf2m.o rsaz_exp.o rs > az-x86_64.o rsaz-avx2.o > EC_ASM =ecp_nistz256.o ecp_nistz256-x86_64.o > DES_ENC =des_enc.o fcrypt_b.o > AES_ENC =aes-x86_64.o vpaes-x86_64.o bsaes-x86_64.o aesni-x86_64.o aesni-s > ha1-x86_64.o aesni-sha256-x86_64.o aesni-mb-x86_64.o > BF_ENC =bf_enc.o > CAST_ENC =c_enc.o > RC4_ENC =rc4-x86_64.o rc4-md5-x86_64.o > RC5_ENC =rc5_enc.o > MD5_OBJ_ASM =md5-x86_64.o > SHA1_OBJ_ASM =sha1-x86_64.o sha256-x86_64.o sha512-x86_64.o sha1-mb-x86_64.o sh > a256-mb-x86_64.o > RMD160_OBJ_ASM= > CMLL_ENC =cmll-x86_64.o cmll_misc.o > MODES_OBJ =ghash-x86_64.o aesni-gcm-x86_64.o > ENGINES_OBJ = > PROCESSOR = > RANLIB =true > ARFLAGS = > PERL =perl > SIXTY_FOUR_BIT mode > DES_INT used > RC4_CHUNK is unsigned long long > > Configured for VC-WIN64A. > > c:\openssl\openssl-1.0.2h>ms\do_win64a > > c:\openssl\openssl-1.0.2h>perl util\mkfiles.pl 1>MINFO > > c:\openssl\openssl-1.0.2h>cmd /c "nasm -f win64 -v" 1>NUL 2>&1 > > c:\openssl\openssl-1.0.2h>if 1 NEQ 0 goto ml64 > > c:\openssl\openssl-1.0.2h>perl ms\uplink-x86_64.pl masm 1>ms\uptable.asm > > c:\openssl\openssl-1.0.2h>ml64 -c -Foms\uptable.obj ms\uptable.asm > Microsoft (R) Macro Assembler (x64) Version 11.00.50727.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > Assembling: ms\uptable.asm > > c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl VC-WIN64A 1>ms\nt.mak > > c:\openssl\openssl-1.0.2h>perl util\mk1mf.pl dll VC-WIN64A 1>ms\ntdll.mak > > c:\openssl\openssl-1.0.2h>perl util\mkdef.pl 32 libeay 1>ms\libeay32.def > > c:\openssl\openssl-1.0.2h>perl util\mkdef.pl 32 ssleay 1>ms\ssleay32.def > > c:\openssl\openssl-1.0.2h>nmake -f ms\nt.mak > > Microsoft (R) Program Maintenance Utility Version 11.00.50727.1 > Copyright (C) Microsoft Corporation. All rights reserved. > > Building OpenSSL > perl .\util\copy-if-different.pl ".\crypto\buildinf.h" "tmp32\buildinf.h > " > Copying: ./crypto/buildinf.h to tmp32/buildinf.h > perl .\util\copy-if-different.pl ".\crypto\opensslconf.h" "inc32\openssl > \opensslconf.h" > Copying: ./crypto/opensslconf.h to inc32/openssl/opensslconf.h > lib /nologo /out:out32\libeay32.lib @C:\Users\KAARLH~1.LOC\AppData\Local > \Temp\nm327D.tmp > tmp32\x86_64cpuid.obj : fatal error LNK1112: module machine type 'x64' conflicts > with target machine type 'X86' > NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 11.0 > \VC\BIN\lib.EXE"' : return code '0x458' > Stop. > > Kaarl Harster > > > > From thespamer at gmail.com Fri Aug 26 20:16:27 2016 From: thespamer at gmail.com (Juliano Souza) Date: Fri, 26 Aug 2016 17:16:27 -0300 Subject: [openssl-users] (no subject) Message-ID: Hi! In order to authenticate users without user and password, I?d like to generate users .p12 .pfx certificates to install on their browsers and identify them by CN. Is there any howto or tutorial explaining some of... 1-Generate my own CA 2-Generate users .p12 / .pfx certs ? 3-In apache how to verify client certificate, if some user try to connect my URL without this p12/pfx, access is denied. Is there a lot of documentation (googling), but very old or incomplete. My set is ; centos 7.2 | Apache 2.4.6 | openssl 1.0.1e-fips Thank you and best regards, -- Juliano Souza -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Fri Aug 26 20:37:10 2016 From: leamhall at gmail.com (Leam Hall) Date: Fri, 26 Aug 2016 16:37:10 -0400 Subject: [openssl-users] genpkey DSA error Message-ID: <52bc3166-00fb-c9af-cf7c-4f46ab4138e7@gmail.com> More than likely it's operator error. OS Version: CentOS 6, patched. openssl version: OpenSSL 1.0.1e-fips 11 Feb 2013 Works: openssl genpkey -algorithm RSA -out fred_ssl.key ........++++++ ........++++++ Fails: openssl genpkey -algorithm DSA -out fred_ssl.key Error generating key 140421332879176:error:0A07906B:dsa routines:PKEY_DSA_KEYGEN:no parameters set:dsa_pmeth.c:271: Suggestions? Thanks! Leam From matt at openssl.org Fri Aug 26 22:51:35 2016 From: matt at openssl.org (Matt Caswell) Date: Fri, 26 Aug 2016 23:51:35 +0100 Subject: [openssl-users] genpkey DSA error In-Reply-To: <52bc3166-00fb-c9af-cf7c-4f46ab4138e7@gmail.com> References: <52bc3166-00fb-c9af-cf7c-4f46ab4138e7@gmail.com> Message-ID: <9a6c7120-53fd-8884-351a-b68a0176353d@openssl.org> On 26/08/16 21:37, Leam Hall wrote: > More than likely it's operator error. > > OS Version: > CentOS 6, patched. > > openssl version: > OpenSSL 1.0.1e-fips 11 Feb 2013 > > Works: > openssl genpkey -algorithm RSA -out fred_ssl.key > ........++++++ > ........++++++ > > Fails: > openssl genpkey -algorithm DSA -out fred_ssl.key > Error generating key > 140421332879176:error:0A07906B:dsa routines:PKEY_DSA_KEYGEN:no > parameters set:dsa_pmeth.c:271: > > > Suggestions? DSA needs parameters specifying. Try this: openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 -out dsa.params openssl genpkey -paramfile dsa.params -out dsa.key Matt From thespamer at gmail.com Fri Aug 26 22:56:22 2016 From: thespamer at gmail.com (Juliano Souza) Date: Fri, 26 Aug 2016 19:56:22 -0300 Subject: [openssl-users] (no subject) In-Reply-To: References: Message-ID: I just found it. Hope to help someone with same requirement. http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2ForSSLTLSMutualAuthentication.html 2016-08-26 17:16 GMT-03:00 Juliano Souza : > Hi! > > > > In order to authenticate users without user and password, I?d like to > generate users .p12 .pfx certificates to install on their browsers and > identify them by CN. > > > > Is there any howto or tutorial explaining some of... > > > > 1-Generate my own CA > > 2-Generate users .p12 / .pfx certs ? > > 3-In apache how to verify client certificate, if some user try to connect > my URL without this p12/pfx, access is denied. > > > > Is there a lot of documentation (googling), but very old or incomplete. > > > > My set is ; centos 7.2 | Apache 2.4.6 | openssl 1.0.1e-fips > > > > Thank you and best regards, > > -- > Juliano Souza > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- Juliano Souza -------------- next part -------------- An HTML attachment was scrubbed... URL: From leamhall at gmail.com Fri Aug 26 23:36:41 2016 From: leamhall at gmail.com (Leam Hall) Date: Fri, 26 Aug 2016 19:36:41 -0400 Subject: [openssl-users] genpkey DSA error In-Reply-To: <9a6c7120-53fd-8884-351a-b68a0176353d@openssl.org> References: <52bc3166-00fb-c9af-cf7c-4f46ab4138e7@gmail.com> <9a6c7120-53fd-8884-351a-b68a0176353d@openssl.org> Message-ID: On 08/26/16 18:51, Matt Caswell wrote: > > DSA needs parameters specifying. > > Try this: > > openssl genpkey -genparam -algorithm DSA -pkeyopt dsa_paramgen_bits:2048 > -out dsa.params > > openssl genpkey -paramfile dsa.params -out dsa.key > > > Matt Matt, thanks! That was it. Leam From noloader at gmail.com Sat Aug 27 00:45:32 2016 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 26 Aug 2016 20:45:32 -0400 Subject: [openssl-users] (no subject) In-Reply-To: References: Message-ID: On Fri, Aug 26, 2016 at 6:56 PM, Juliano Souza wrote: > I just found it. > > Hope to help someone with same requirement. > > http://www.cafesoft.com/products/cams/ps/docs32/admin/ConfiguringApache2ForSSLTLSMutualAuthentication.html > There's also Origin Bound Certificates (OCB), http://www.czeskis.com/research/pubs/tls-obc.pdf. They are like "tear-off" personal certificates. A user generates one on the fly for an origin/site, and then uses it when needed. Its not signed by an authority, so its like the user equivalent to a server's self signed certificate. The appealing thing with them is they effectively stop the MitM games played by many user agents. Not surprisingly, the browser have mostly rejected them because in their security model, interception is a valid use case. Jeff From shinelight at shininglightpro.com Sat Aug 27 19:11:26 2016 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Sat, 27 Aug 2016 12:11:26 -0700 Subject: [openssl-users] Help installing OpenSSL 1.1.0 pre6 on Windows 2012 R2 In-Reply-To: <0758c617-8fb6-5a2d-9fa7-5e823afb7800@openssl.org> References: <0758c617-8fb6-5a2d-9fa7-5e823afb7800@openssl.org> Message-ID: <37b58c22-1f03-b57a-c2d7-ba42642acc8f@shininglightpro.com> On 8/26/2016 12:25 PM, Matt Caswell wrote: > On 26/08/16 19:17, Harster, Kaarl C CIV NAVSEA KPWA, 104 wrote: >> Hello, >> I've tried many times now to install OpenSSL 1.1.0 pre6 on my Windows 2012 R2 64bit machine. > > 1.1.0 pre6 is the beta version, but the final 1.1.0 release was made > available yesterday, so to start with I suggest you use that. @Kaarl - Prebuilt 64-bit Windows *default* binaries of 1.1.0 can be obtained from here: https://slproweb.com/products/Win32OpenSSL.html If you need non-default, then you're on your own for building. Have fun? @Everyone else - Anyway, on to the real reason for posting... >> We are wanting to run 64bit everything. >> I have installed >> ActivePerl 5.24.0.2400 I've been building binaries using Strawberry Perl Portable for a few years now. The ActiveState Perl installer and binaries were (and are) a nightmare to obtain and work with. Also, most environments where you would use ActivePerl technically violate the ActivePerl license agreement which, of course, no one ever reads. I'm never going back to that mess. Strawberry Perl is comparatively much, much easier to obtain, install, legally use, and it works just fine. The OpenSSL Configure and Perl other scripts in the source tree barely scratch the surface of the Perl scripting language, so any decent flavor of Perl has a pretty good chance of working. Unless someone *needs* ActivePerl for other things besides building OpenSSL and they have funky Perl code sitting around that depends on the ActivePerl flavor, Strawberry Perl is probably more than sufficient and won't make a mess of the system that it's installed onto. Strawberry is also the flavor of Perl that Larry Wall (the guy who created Perl) uses when he is at a Windows box. So there's that too. In my opinion, Strawberry Perl should be the recommended flavor of Perl for building OpenSSL on Windows instead of ActivePerl. The Strawberry Perl Portable edition is most useful to *me*, but using it requires a few extra environment variables to be set beforehand. Therefore, the Portable variant isn't for everyone. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From sugu.ece28 at gmail.com Sat Aug 27 18:32:03 2016 From: sugu.ece28 at gmail.com (Sugumar) Date: Sat, 27 Aug 2016 11:32:03 -0700 (MST) Subject: [openssl-users] How to make EVP functions returns false In-Reply-To: <1470731542209-67775.post@n7.nabble.com> References: <1470731542209-67775.post@n7.nabble.com> Message-ID: <1472322723593-68091.post@n7.nabble.com> Can any one help me on this? Thanks. -- View this message in context: http://openssl.6102.n7.nabble.com/How-to-make-EVP-functions-returns-false-tp67775p68091.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From mowiener at cisco.com Mon Aug 29 08:59:35 2016 From: mowiener at cisco.com (Moshe Wiener (mowiener)) Date: Mon, 29 Aug 2016 08:59:35 +0000 Subject: [openssl-users] RSA sign using SHA256 with mgf1 padding Message-ID: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> Hello, I'm running an application which runs an authentication session with a server. The server provides some random data, and my application needs to sign it with its private key, and send back the signature. The server which knows the public key verifies the signature, and it good then the client which runs my application is authenticated. This session used to run OK, until the server was changed so instead of using PKCS#1_v1.5 now it uses PKCS#1_v2.1 Now, the server uses signature algorithm of SHA256 WITH RSA AN DMGF1. In my application I use OpenSSL. I think that I need to use 'RSA_padding_add_PKCS1_OAEP_mgf1' but couldn't figure out what to put in each of its arguments. Is there somewhere a sample code which implements RSA signature with mgf1 padding and a SHA256 hash? Many thanks, Moshe -------------- next part -------------- An HTML attachment was scrubbed... URL: From lilulo at gmail.com Mon Aug 29 13:27:00 2016 From: lilulo at gmail.com (lilulo) Date: Mon, 29 Aug 2016 09:27:00 -0400 Subject: [openssl-users] BIO Pair vs Custom BIO for non standard transport Message-ID: Hi All, I need to use TLS on the top of our collection of low-level transport classes. It looks like the standard choice is to create a BIO Pair and to manage data transfer between transport layer and the TLS through it. This looks fine but actual implementation of a socket's BIO in openssl\crypto\bio\bss_sock.c looks much cleaner then the code which is using BIO Pairs and I think I can create a custom BIO which is talking to our layer, instead of socket, based on this as an example. Is it considered a normal practice to create a custom BIO? The actual structure for BIO is hidden in openssl\include\internal\bio.h and it doesn't look like it is really encouraged to use it. Thanks, Ian -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 29 13:38:56 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 29 Aug 2016 14:38:56 +0100 Subject: [openssl-users] BIO Pair vs Custom BIO for non standard transport In-Reply-To: References: Message-ID: <87812a7a-d1d7-1587-b1e1-824ade65c993@openssl.org> On 29/08/16 14:27, lilulo wrote: > Hi All, > > I need to use TLS on the top of our collection of low-level transport > classes. It looks like the standard choice is to create a BIO Pair and > to manage data transfer between transport layer and the TLS through it. > This looks fine but actual implementation of a socket's BIO in > openssl\crypto\bio\bss_sock.c looks much cleaner then the code which is > using BIO Pairs and I think I can create a custom BIO which is talking > to our layer, instead of socket, based on this as an example. > > Is it considered a normal practice to create a custom BIO? The actual > structure for BIO is hidden in openssl\include\internal\bio.h and it > doesn't look like it is really encouraged to use it. It is perfectly Ok to create a custom BIO. There are a set of functions for creating them. See: https://www.openssl.org/docs/man1.1.0/crypto/BIO_meth_new.html Note that in OpenSSL versions prior to 1.1.0 these functions did not exist, but the BIO structure was in a public header file. Matt From jvermillard at gmail.com Mon Aug 29 16:08:30 2016 From: jvermillard at gmail.com (Julien Vermillard) Date: Mon, 29 Aug 2016 18:08:30 +0200 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash Message-ID: I have a DTLS 1.2 server based on last master (commit d196305aa0de1fc38837c27cb1ea6e60af9dd98d) I try to add ocsp stapling support (based on code in s_server.c). Basicaly in my callback I set the OCSP response by: if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { return SSL_TLSEXT_ERR_NOACK; } else { return SSL_TLSEXT_ERR_OK; } but if my server manage to get an OCSP response it crash with this message: ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH Any clue? -- Julien Vermillard -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Aug 29 16:13:01 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 29 Aug 2016 17:13:01 +0100 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: References: Message-ID: On 29/08/16 17:08, Julien Vermillard wrote: > I have a DTLS 1.2 server based on last master (commit > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) > I try to add ocsp stapling support (based on code in s_server.c). > > Basicaly in my callback I set the OCSP response by: > > > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { > return SSL_TLSEXT_ERR_NOACK; > } else { > return SSL_TLSEXT_ERR_OK; > } > > but if my server manage to get an OCSP response it crash with this message: > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > Any clue? Do you have some minimal reproducer? Matt From jvermillard at gmail.com Mon Aug 29 16:17:18 2016 From: jvermillard at gmail.com (Julien Vermillard) Date: Mon, 29 Aug 2016 18:17:18 +0200 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: References: Message-ID: It's a mix of C and Go, so it's really not minimal, but I'll try to modify s_server to see if I can reproduce it. -- Julien Vermillard On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell wrote: > > > On 29/08/16 17:08, Julien Vermillard wrote: > > I have a DTLS 1.2 server based on last master (commit > > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) > > I try to add ocsp stapling support (based on code in s_server.c). > > > > Basicaly in my callback I set the OCSP response by: > > > > > > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { > > return SSL_TLSEXT_ERR_NOACK; > > } else { > > return SSL_TLSEXT_ERR_OK; > > } > > > > but if my server manage to get an OCSP response it crash with this > message: > > > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > > > Any clue? > > Do you have some minimal reproducer? > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvermillard at gmail.com Mon Aug 29 16:37:10 2016 From: jvermillard at gmail.com (Julien Vermillard) Date: Mon, 29 Aug 2016 18:37:10 +0200 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: References: Message-ID: I patched s_server to send a fake OCSP content (4 bytes). I suppose the server will just push that to the client and the client should fail complaining it's not a correct OCSP response. But the server crash with: ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH Command line used: ./openssl s_server -dtls1_2 -port 5684 -cipher ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 -CAfile ca.pem -cert server.pem -key server.key -chainCAfile bundle.pem -status -status_verbose -mtu 1200 and ./openssl s_client -dtls1_2 -port 5684 -psk 73656372657450534b -host localhost -cipher ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 -CAfile ca.pem -verify_hostname "IMEI:1234567890" -cert client.pem -key client.key -chainCAfile bundle-client.pem -status I attached also the test certificate and keys. -- Julien Vermillard On Mon, Aug 29, 2016 at 6:17 PM, Julien Vermillard wrote: > It's a mix of C and Go, so it's really not minimal, but I'll try to modify > s_server to see if I can reproduce it. > > -- > Julien Vermillard > > On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell wrote: > >> >> >> On 29/08/16 17:08, Julien Vermillard wrote: >> > I have a DTLS 1.2 server based on last master (commit >> > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) >> > I try to add ocsp stapling support (based on code in s_server.c). >> > >> > Basicaly in my callback I set the OCSP response by: >> > >> > >> > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { >> > return SSL_TLSEXT_ERR_NOACK; >> > } else { >> > return SSL_TLSEXT_ERR_OK; >> > } >> > >> > but if my server manage to get an OCSP response it crash with this >> message: >> > >> > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: >> > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH >> > >> > Any clue? >> >> Do you have some minimal reproducer? >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-simple-response.patch Type: text/x-patch Size: 4340 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle.pem Type: application/x-x509-ca-cert Size: 2722 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ca.pem Type: application/x-x509-ca-cert Size: 753 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.key Type: application/x-iwork-keynote-sffkey Size: 241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: server.pem Type: application/x-x509-ca-cert Size: 1025 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bundle-client.pem Type: application/x-x509-ca-cert Size: 2678 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: client.key Type: application/x-iwork-keynote-sffkey Size: 241 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: client.pem Type: application/x-x509-ca-cert Size: 985 bytes Desc: not available URL: From matt at openssl.org Mon Aug 29 16:44:11 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 29 Aug 2016 17:44:11 +0100 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: References: Message-ID: <9de8ff4b-a1a3-36da-a90e-34241fe66cba@openssl.org> Ok - thanks. I'll try and take a look tomorrow. Matt On 29/08/16 17:37, Julien Vermillard wrote: > I patched s_server to send a fake OCSP content (4 bytes). > I suppose the server will just push that to the client and the client > should fail complaining it's not a correct OCSP response. > But the server crash with: > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > Command line used: > > ./openssl s_server -dtls1_2 -port 5684 -cipher > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 > -CAfile ca.pem -cert server.pem -key server.key -chainCAfile bundle.pem > -status -status_verbose -mtu 1200 > > and > ./openssl s_client -dtls1_2 -port 5684 -psk 73656372657450534b -host > localhost -cipher > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 > -CAfile ca.pem -verify_hostname "IMEI:1234567890" -cert client.pem -key > client.key -chainCAfile bundle-client.pem -status > > > I attached also the test certificate and keys. > > -- > Julien Vermillard > > On Mon, Aug 29, 2016 at 6:17 PM, Julien Vermillard > > wrote: > > It's a mix of C and Go, so it's really not minimal, but I'll try to > modify s_server to see if I can reproduce it. > > -- > Julien Vermillard > > On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell > wrote: > > > > On 29/08/16 17:08, Julien Vermillard wrote: > > I have a DTLS 1.2 server based on last master (commit > > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) > > I try to add ocsp stapling support (based on code in s_server.c). > > > > Basicaly in my callback I set the OCSP response by: > > > > > > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { > > return SSL_TLSEXT_ERR_NOACK; > > } else { > > return SSL_TLSEXT_ERR_OK; > > } > > > > but if my server manage to get an OCSP response it crash with this message: > > > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > > > Any clue? > > Do you have some minimal reproducer? > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From jb-openssl at wisemo.com Tue Aug 30 09:39:46 2016 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 30 Aug 2016 11:39:46 +0200 Subject: [openssl-users] How to make EVP functions returns false In-Reply-To: <1472322723593-68091.post@n7.nabble.com> References: <1470731542209-67775.post@n7.nabble.com> <1472322723593-68091.post@n7.nabble.com> Message-ID: <3167cbfd-faf1-929d-88d3-c34d9eb9a44a@wisemo.com> On 27/08/2016 20:32, Sugumar wrote: > Can any one help me on this? Thanks. Some of the calls you mention can be made to fail if you can tell valgrind to simulate an out-of-memory (malloc fail) during the call. Some of the others fail only for invalid parameters or only under extremely rare conditions. Some cannot fail. Also note that on your list of functions, the functions whose names do not contain "EVP" are not EVP calls, but traditional OpenSSL/SSLeay crypto calls that are probably discontinued in OpenSSL 1.1.0. 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 matt at openssl.org Tue Aug 30 09:43:40 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 30 Aug 2016 10:43:40 +0100 Subject: [openssl-users] How to make EVP functions returns false In-Reply-To: <3167cbfd-faf1-929d-88d3-c34d9eb9a44a@wisemo.com> References: <1470731542209-67775.post@n7.nabble.com> <1472322723593-68091.post@n7.nabble.com> <3167cbfd-faf1-929d-88d3-c34d9eb9a44a@wisemo.com> Message-ID: <236dd37f-8de4-b96e-d0ea-79eede11dadf@openssl.org> On 30/08/16 10:39, Jakob Bohm wrote: > Also note that on your list of functions, the functions whose > names do not contain "EVP" are not EVP calls, but traditional > OpenSSL/SSLeay crypto calls that are probably discontinued in > OpenSSL 1.1.0. No, all of those non-EVP calls are still available in 1.1.0. Matt From matt at openssl.org Tue Aug 30 14:26:56 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 30 Aug 2016 15:26:56 +0100 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: References: Message-ID: <743b4c53-b0bd-fd12-4102-1870d97fd2d8@openssl.org> On 29/08/16 17:37, Julien Vermillard wrote: > I patched s_server to send a fake OCSP content (4 bytes). > I suppose the server will just push that to the client and the client > should fail complaining it's not a correct OCSP response. > But the server crash with: > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > Command line used: > > ./openssl s_server -dtls1_2 -port 5684 -cipher > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 > -CAfile ca.pem -cert server.pem -key server.key -chainCAfile bundle.pem > -status -status_verbose -mtu 1200 > > and > ./openssl s_client -dtls1_2 -port 5684 -psk 73656372657450534b -host > localhost -cipher > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 > -CAfile ca.pem -verify_hostname "IMEI:1234567890" -cert client.pem -key > client.key -chainCAfile bundle-client.pem -status > > > I attached also the test certificate and keys. Actually, even the unpatched s_server has this problem. AFAICT this has never worked for DTLS. I'm quite surprised no one has noticed before! Even 1.0.2 has this problem (although the symptoms are different)...and probably 1.0.1 although I haven't checked. I have a fix here: https://github.com/openssl/openssl/pull/1516 Only the first commit with the changes to ssl/statem/statem_srvr.c are the fix itself. Everything else in the second commit is about adding a test for this. Matt > > -- > Julien Vermillard > > On Mon, Aug 29, 2016 at 6:17 PM, Julien Vermillard > > wrote: > > It's a mix of C and Go, so it's really not minimal, but I'll try to > modify s_server to see if I can reproduce it. > > -- > Julien Vermillard > > On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell > wrote: > > > > On 29/08/16 17:08, Julien Vermillard wrote: > > I have a DTLS 1.2 server based on last master (commit > > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) > > I try to add ocsp stapling support (based on code in s_server.c). > > > > Basicaly in my callback I set the OCSP response by: > > > > > > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { > > return SSL_TLSEXT_ERR_NOACK; > > } else { > > return SSL_TLSEXT_ERR_OK; > > } > > > > but if my server manage to get an OCSP response it crash with this message: > > > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > > > Any clue? > > Do you have some minimal reproducer? > > Matt > > -- > openssl-users mailing list > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > From jvermillard at gmail.com Tue Aug 30 15:58:34 2016 From: jvermillard at gmail.com (Julien Vermillard) Date: Tue, 30 Aug 2016 17:58:34 +0200 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: <743b4c53-b0bd-fd12-4102-1870d97fd2d8@openssl.org> References: <743b4c53-b0bd-fd12-4102-1870d97fd2d8@openssl.org> Message-ID: Awesome thanks :) I'll try it. Yes I have the feeling I'm the first user of stapling with DTLS -- Julien Vermillard On Tue, Aug 30, 2016 at 4:26 PM, Matt Caswell wrote: > > > On 29/08/16 17:37, Julien Vermillard wrote: > > I patched s_server to send a fake OCSP content (4 bytes). > > I suppose the server will just push that to the client and the client > > should fail complaining it's not a correct OCSP response. > > But the server crash with: > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: > > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH > > > > Command line used: > > > > ./openssl s_server -dtls1_2 -port 5684 -cipher > > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256- > CCM8:PSK-AES128-CCM8 > > -CAfile ca.pem -cert server.pem -key server.key -chainCAfile bundle.pem > > -status -status_verbose -mtu 1200 > > > > and > > ./openssl s_client -dtls1_2 -port 5684 -psk 73656372657450534b -host > > localhost -cipher > > ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256- > CCM8:PSK-AES128-CCM8 > > -CAfile ca.pem -verify_hostname "IMEI:1234567890" -cert client.pem -key > > client.key -chainCAfile bundle-client.pem -status > > > > > > I attached also the test certificate and keys. > > Actually, even the unpatched s_server has this problem. AFAICT this has > never worked for DTLS. I'm quite surprised no one has noticed before! > Even 1.0.2 has this problem (although the symptoms are different)...and > probably 1.0.1 although I haven't checked. > > I have a fix here: > > https://github.com/openssl/openssl/pull/1516 > > Only the first commit with the changes to ssl/statem/statem_srvr.c are > the fix itself. Everything else in the second commit is about adding a > test for this. > > Matt > > > > > -- > > Julien Vermillard > > > > On Mon, Aug 29, 2016 at 6:17 PM, Julien Vermillard > > > wrote: > > > > It's a mix of C and Go, so it's really not minimal, but I'll try to > > modify s_server to see if I can reproduce it. > > > > -- > > Julien Vermillard > > > > On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell > > wrote: > > > > > > > > On 29/08/16 17:08, Julien Vermillard wrote: > > > I have a DTLS 1.2 server based on last master (commit > > > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) > > > I try to add ocsp stapling support (based on code in > s_server.c). > > > > > > Basicaly in my callback I set the OCSP response by: > > > > > > > > > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == > 0) { > > > return SSL_TLSEXT_ERR_NOACK; > > > } else { > > > return SSL_TLSEXT_ERR_OK; > > > } > > > > > > but if my server manage to get an OCSP response it crash with > this message: > > > > > > ssl/statem/statem_dtls.c:127: OpenSSL internal error: > assertion failed: > > > s->init_num == (int)s->d1->w_msg_hdr.msg_len + > DTLS1_HM_HEADER_LENGTH > > > > > > Any clue? > > > > Do you have some minimal reproducer? > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at edeca.net Tue Aug 30 18:27:51 2016 From: lists at edeca.net (David) Date: Tue, 30 Aug 2016 19:27:51 +0100 Subject: [openssl-users] Obtaining PKCS7 data length Message-ID: <420e88c6-a91d-3ef7-4a14-f118d409703a@edeca.net> Hi, I have some PKCS7 data which I can read like this with OpenSSL: $ openssl asn1parse -i -inform der -in data.dat 0:d=0 hl=4 l=16208 cons: SEQUENCE 4:d=1 hl=2 l= 9 prim: OBJECT :pkcs7-signedData .. more .. I can load it in code like so: // buf contains the raw data, len the length BIO *bio = BIO_new_mem_buf(buf, len); PKCS7 *pkcs7 = d2i_PKCS7_bio(bio, NULL); if (!pkcs7) { // die } printf("Success!"); This works fine and I can successfully obtain signer information etc. However I'd like to obtain the length value as parsed from the input data. In my example this was 16208, seen in the second line of the ASN1 output. I noticed there is a length attribute to the PKCS7 structure (see include/openssl/pkcs7.h) but pkcs7->length is always zero when I print it. How can I obtain the length of the overall sequence which contains PKCS7 signed data? This is important because the length I already have may be longer than the actual PKCS7 data. David From matt at openssl.org Tue Aug 30 20:21:31 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 30 Aug 2016 21:21:31 +0100 Subject: [openssl-users] Setting an OCSP stapling response on a DTLS server result in crash In-Reply-To: <743b4c53-b0bd-fd12-4102-1870d97fd2d8@openssl.org> References: <743b4c53-b0bd-fd12-4102-1870d97fd2d8@openssl.org> Message-ID: <692988cd-a6e5-ec1a-a36b-dc67e45b182e@openssl.org> On 30/08/16 15:26, Matt Caswell wrote: > > > On 29/08/16 17:37, Julien Vermillard wrote: >> I patched s_server to send a fake OCSP content (4 bytes). >> I suppose the server will just push that to the client and the client >> should fail complaining it's not a correct OCSP response. >> But the server crash with: >> ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: >> s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH >> >> Command line used: >> >> ./openssl s_server -dtls1_2 -port 5684 -cipher >> ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 >> -CAfile ca.pem -cert server.pem -key server.key -chainCAfile bundle.pem >> -status -status_verbose -mtu 1200 >> >> and >> ./openssl s_client -dtls1_2 -port 5684 -psk 73656372657450534b -host >> localhost -cipher >> ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES128-CCM8:PSK-AES256-CCM8:PSK-AES128-CCM8 >> -CAfile ca.pem -verify_hostname "IMEI:1234567890" -cert client.pem -key >> client.key -chainCAfile bundle-client.pem -status >> >> >> I attached also the test certificate and keys. > > Actually, even the unpatched s_server has this problem. AFAICT this has > never worked for DTLS. I'm quite surprised no one has noticed before! > Even 1.0.2 has this problem (although the symptoms are different)...and > probably 1.0.1 although I haven't checked. > > I have a fix here: > > https://github.com/openssl/openssl/pull/1516 > > Only the first commit with the changes to ssl/statem/statem_srvr.c are > the fix itself. Everything else in the second commit is about adding a > test for this. This fix has now been merged in commit 06314c029. Matt > > Matt > >> >> -- >> Julien Vermillard >> >> On Mon, Aug 29, 2016 at 6:17 PM, Julien Vermillard >> > wrote: >> >> It's a mix of C and Go, so it's really not minimal, but I'll try to >> modify s_server to see if I can reproduce it. >> >> -- >> Julien Vermillard >> >> On Mon, Aug 29, 2016 at 6:13 PM, Matt Caswell > > wrote: >> >> >> >> On 29/08/16 17:08, Julien Vermillard wrote: >> > I have a DTLS 1.2 server based on last master (commit >> > d196305aa0de1fc38837c27cb1ea6e60af9dd98d) >> > I try to add ocsp stapling support (based on code in s_server.c). >> > >> > Basicaly in my callback I set the OCSP response by: >> > >> > >> > if (SSL_set_tlsext_status_ocsp_resp(s,dataPtr,respLen) == 0) { >> > return SSL_TLSEXT_ERR_NOACK; >> > } else { >> > return SSL_TLSEXT_ERR_OK; >> > } >> > >> > but if my server manage to get an OCSP response it crash with this message: >> > >> > ssl/statem/statem_dtls.c:127: OpenSSL internal error: assertion failed: >> > s->init_num == (int)s->d1->w_msg_hdr.msg_len + DTLS1_HM_HEADER_LENGTH >> > >> > Any clue? >> >> Do you have some minimal reproducer? >> >> Matt >> >> -- >> openssl-users mailing list >> To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-users >> >> >> >> >> >> From tjboring at gmail.com Wed Aug 31 01:28:19 2016 From: tjboring at gmail.com (Tim Boring) Date: Wed, 31 Aug 2016 01:28:19 +0000 Subject: [openssl-users] Question about stateOrProvince Message-ID: When creating a CSR, openssl displays the following State or Province Name (full name) [Some-State]: But, I can't find anywhere in the OpenSSL codebase that validates that the input is indeed a "full name"--e.g., that the input is "New York" instead of "NY". I've done this search in Github: https://github.com/openssl/openssl/search?utf8=%E2%9C%93&q=state%2Fprovince&type=Code After looking through the code, I stumbed across the "ub_locality_name" size limit: https://goo.gl/zAUe9w And a couple lines up from that is a comment pointing to RFC 3280 , which defines the following: id-at-stateOrProvinceName AttributeType ::= { id-at 8 } X520StateOrProvinceName ::= CHOICE { teletexString TeletexString (SIZE (1..ub-state-name)), printableString PrintableString (SIZE (1..ub-state-name)), universalString UniversalString (SIZE (1..ub-state-name)), utf8String UTF8String (SIZE (1..ub-state-name)), bmpString BMPString (SIZE(1..ub-state-name)) } ub-state-name INTEGER ::= 128 I'm curious about this because the openssl command will create a CSR where stateOrProvince has a two-character (U.S.) state name, and (at least one) CA (Comodo) will happily issue a cert using such a CSR. Is there any issue with a cert generated using such a CSR? Should the openssl command validate stateOrProvince? If not, then maybe it's just a matter of changing the prompt (I'm happy to submit a PR for such a minor change). Thanks, Tim -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Aug 31 02:03:26 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 31 Aug 2016 02:03:26 +0000 Subject: [openssl-users] Question about stateOrProvince In-Reply-To: References: Message-ID: <909a022e7df645b88b4c7e9c03a01165@usma1ex-dag1mb1.msg.corp.akamai.com> Perhaps one way to read it as state or full name if a province. Or just remove the "full name" part of the text, I suppose. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From wiml at omnigroup.com Wed Aug 31 02:52:53 2016 From: wiml at omnigroup.com (Wim Lewis) Date: Tue, 30 Aug 2016 19:52:53 -0700 Subject: [openssl-users] Question about stateOrProvince In-Reply-To: References: Message-ID: <7E59EF02-4CE0-47FD-B15D-68ED84A88CC9@omnigroup.com> On Aug 30, 2016, at 6:28 PM, Tim Boring wrote: > When creating a CSR, openssl displays the following > > > State or Province Name (full name) [Some-State]: > ... > And a couple lines up from that is a comment pointing to RFC 3280, which defines the following: The original definition is from X.520, I suppose, which doesn't explicitly say whether abbreviations are allowed, although the example it gives is for a full name (Ohio). [1] > I'm curious about this because the openssl command will create a CSR where stateOrProvince has a two-character (U.S.) state name, and (at least one) CA (Comodo) will happily issue a cert using such a CSR. I think for ordinary domain-validated certificates, almost nothing in the Subject is actually validated or used by the browser, and I'd guess not inspected by the CA either. In situations where people actually care, the full name seems to be required for that attribute. The following language shows up in a few places via google: From the CAB Forum guidelines for EV certs [3]: > State, province, or locality information (where applicable) must use the full name of the applicable jurisdiction. From a randomly found ITU-T draft of what became the EV certificate guidelines (TD 0411 [2], section 8.1.1 (4)): > State or province or locality information (where applicable) for the Subject?s Jurisdiction of Incorporation or Registration MUST be specified using the full name of the applicable jurisdiction. My understanding from all this is that the correct use of that attribute is to have the full name, not an abbreviation, but that in most cases, a certificate's subject can contain any old garbage you like and it'll still work for TLS. For situations other than TLS, of course, it's even vaguer, but I read X.520 as implying that the full name is preferred, but abbreviations may be used as alternatives in directories and so on. > If not, then maybe it's just a matter of changing the prompt (I'm happy to submit a PR for such a minor change). I'd argue that the prompt should stay the same. The user can type an abbreviation if they like, but if they're uncertain whether to type an abbreviation or a full name, then it's nice to include that guidance. (The country attribute, in contrast, is required to be an ISO3166 code according to X.520.) [1] http://www.itu.int/rec/T-REC-X.520 [2] https://www.first.org/global/standardisation/docs/t09-sg17-090916-td-plen-0411__msw-e.doc [3] https://cabforum.org/ev-certificate-contents/ From nicolas.brunie at kalray.eu Wed Aug 31 12:17:40 2016 From: nicolas.brunie at kalray.eu (Nicolas Brunie) Date: Wed, 31 Aug 2016 14:17:40 +0200 Subject: [openssl-users] Sequential / parallel OpenSSL sessions with Async Message-ID: <57C6CAE4.9000707@kalray.eu> Hi All, I have been playing around with OpenSSL ASYNC JOB and an asynchronous offloading engine and a stupid question came to mind: It is not possible to make several parallel/pending calls to SSL_read (or SSL_write) on a single SSL* object (with different output/input buffers) so that multiple offloading operation can be done in parallel (on a single SSL object). I am quite new to TLS but it may seem that you can not enqueue multiple calls to the same SSL_ until the first one called has returned (in the sens completely finished and not just return an SSL_ERROR_WANT_ASYNC), it that so ? best regards, Nicolas Brunie P.S: SSL* obj = ... /* accept and init */ int err = SSL_read(obj, buf0, READ_SIZE); if (err < 0 && SSL_get_error(obj, err) == SSL_ERROR_WANT_ASYNC) {...}/* pending buf0 crypto but go on */ /* the following is illegal if I have not called back SSL_read(obj, buf0, READ_SIZE) and it * has returned with completion (no want async error), right ? */ SSL_read(obj, buf1, READ_SIZE); From matt at openssl.org Wed Aug 31 15:45:31 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 31 Aug 2016 16:45:31 +0100 Subject: [openssl-users] Sequential / parallel OpenSSL sessions with Async In-Reply-To: <57C6CAE4.9000707@kalray.eu> References: <57C6CAE4.9000707@kalray.eu> Message-ID: <6748e929-8460-2ceb-9760-20227a74f6c7@openssl.org> On 31/08/16 13:17, Nicolas Brunie wrote: > Hi All, I have been playing around with OpenSSL ASYNC JOB and an > asynchronous offloading engine and a stupid question came to mind: > It is not possible to make several parallel/pending calls to SSL_read > (or SSL_write) on a single SSL* object (with different output/input > buffers) so that multiple offloading operation can be done in parallel > (on a single SSL object). > I am quite new to TLS but it may seem that you can not enqueue > multiple calls to the same SSL_ until the first one called has > returned (in the sens completely finished and not just return an > SSL_ERROR_WANT_ASYNC), it that so ? You can use the new 1.1.0 "pipelining" feature to achieve something like what you want - although it works slightly differently to the approach you describe. >From CHANGES: Added support for "pipelining". Ciphers that have the EVP_CIPH_FLAG_PIPELINE flag set have a capability to process multiple encryptions/decryptions simultaneously. There are currently no built-in ciphers with this property but the expectation is that engines will be able to offer it to significantly improve throughput. Support has been extended into libssl so that multiple records for a single connection can be processed in one go (for >=TLS 1.1). See the dasync engine for an example implementation of this. At the SSL layer see this page for a description of how pipelining works: https://www.openssl.org/docs/man1.1.0/ssl/SSL_CTX_set_split_send_fragment.html Essentially when you call SSL_write() you should send through a large chunk of data in one go. You also configure OpenSSL to split this up into multiple records (as described in the above man page). The encryption for all records can then occur in a single call through to the pipeline capable engine which can then process them in parallel. It works in a similar way for SSL_read(), although it does depend on having received multiple records in one go in order to benefit from any possible parallelisation. Pipelining and async are two different features which can be used independently. However you can also combine them, so that a pipeline capable engine could choose to work on multiple parallel encryptions/decryptions simultaneously and return control to the application in the meantime until the processing has been completed. Matt From mounir.idrassi at idrix.net Wed Aug 31 16:07:20 2016 From: mounir.idrassi at idrix.net (Mounir IDRASSI) Date: Wed, 31 Aug 2016 18:07:20 +0200 Subject: [openssl-users] RSA sign using SHA256 with mgf1 padding In-Reply-To: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> References: <2cd90924c05c43a79794168b0af03c3e@XCH-RCD-012.cisco.com> Message-ID: <1b704769-d803-aee3-913e-d680ea24c90e@idrix.net> Hi, I have written a sample few years ago that performs PSS signature using SHA256 like what you need. You can get it from https://www.idrix.fr/Root/Samples/openssl_pss_signature.c It uses the maximum salt length. You should check that the server expects this as well. Cheers, -- Mounir IDRASSI Le 29/08/2016 ? 10:59, Moshe Wiener (mowiener) a ?crit : > > Hello, > > I?m running an application which runs an authentication session with a > server. The server provides some random data, and my application needs > to sign it with its private key, and send back the signature. The > server which knows the public key verifies the signature, and it good > then the client which runs my application is authenticated. > > This session used to run OK, until the server was changed so instead > of using PKCS#1_v1.5 now it uses PKCS#1_v2.1 > > Now, the server uses signature algorithm of SHA256 WITH RSA AN DMGF1. > > In my application I use OpenSSL. > > I think that I need to use ?RSA_padding_add_PKCS1_OAEP_mgf1? but > couldn?t figure out what to put in each of its arguments. > > Is there somewhere a sample code which implements RSA signature with > mgf1 padding and a SHA256 hash? > > Many thanks, > > Moshe > > > > > > > From kjetil at skifremme.no Wed Aug 31 16:42:08 2016 From: kjetil at skifremme.no (Kjetil Birkeland Moe) Date: Wed, 31 Aug 2016 18:42:08 +0200 Subject: [openssl-users] Working with s_time and nginx Message-ID: <1b16da10-7061-89be-ff66-e16369a8f871@skifremme.no> Dear all, I have turned to /s_time/ to evaluate the performance of a local Nginx server setup, but seems to immediately run into problems that do not appear when using /s_client/. Server setup is largely based on recommendations from bettercrypto.org, which also demonstrate the same problems with their setup as I currently do: "openssl s_time -connect bettercrypto.org:443 -cipher AES128-GCM-SHA256 -time 2" returns * "140373676381952:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:ssl/record/rec_layer_s3.c:1362:SSL alert number 40" in OpenSSL 1.1.0 * "140416684930936:error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure:s23_clnt.c:769:" in version 1.0.2h. This problem has been found when running from Fedora 24, and also with other ciphers than just the one mentioned above, as ECDHE-ECDSA-AES256-GCM-SHA384, ECDHE-ECDSA-AES128-SHA, AES256-SHA, but not with AES128-SHA. (Looking at the error message, there seems to be ssl3 involved. Though I believe that only TLS connections are allowed on the servers mentioned.) I am greatful for insight that would make it possible to use /s_time/ properly. best regards, Kjetil Birkeland Moe -------------- next part -------------- An HTML attachment was scrubbed... URL: From deff80 at yahoo.com Wed Aug 31 18:51:43 2016 From: deff80 at yahoo.com (deff) Date: Wed, 31 Aug 2016 20:51:43 +0200 Subject: [openssl-users] error: FIPS routines:fips_pkey_signature_test:test failure:fips_post.c Message-ID: <57C7273F.9010702@yahoo.com> I'm getting strange ssl errors on a server 140405310092952:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:166: 140405310092952:error:2D06A07F:FIPS routines:FIPS_CHECK_EC:pairwise test failed:ec_key.c:249: 140405310092952:error:1409802B:SSL routines:ssl3_send_client_key_exchange:reason(43):s3_clnt.c:2869: What could be wrong? It's a VM inside OpenStack, on Xeon. OS: Ubuntu 16.04 cloud image from 30-Aug-2016, apt-get upgraded uname -a: Linux host 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux openssl version: OpenSSL 1.0.2g-fips 1 Mar 2016 If I try it in a different VM, same OS, same packages, but different hardware (i7, VMWare Workstation) openssl connections work as expected. Shorter output follows, output with -debug -msg -state is at http://pastebin.com/ELRPqSe7 # openssl s_client -connect getcomposer.org:443 CONNECTED(00000003) depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA verify return:1 depth=1 C = US, O = DigiCert Inc, CN = DigiCert SHA2 Secure Server CA verify return:1 depth=0 C = CH, ST = Z\C3\BCrich, L = Z\C3\BCrich, O = Nelmio AG, CN = getcomposer.org verify return:1 140405310092952:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:166: 140405310092952:error:2D06A07F:FIPS routines:FIPS_CHECK_EC:pairwise test failed:ec_key.c:249: 140405310092952:error:1409802B:SSL routines:ssl3_send_client_key_exchange:reason(43):s3_clnt.c:2869: --- Certificate chain 0 s:/C=CH/ST=Z\xC3\xBCrich/L=Z\xC3\xBCrich/O=Nelmio AG/CN=getcomposer.org i:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA 1 s:/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA i:/C=US/O=DigiCert Inc/OU=www.digicert.com/CN=DigiCert Global Root CA --- Server certificate -----BEGIN CERTIFICATE----- MIIFGTCCBAGgAwIBAgIQA/CSzSaY2b4dUqeC6GV40DANBgkqhkiG9w0BAQsFADBN MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMScwJQYDVQQDEx5E aWdpQ2VydCBTSEEyIFNlY3VyZSBTZXJ2ZXIgQ0EwHhcNMTQwNjMwMDAwMDAwWhcN MTcwODAxMTIwMDAwWjBfMQswCQYDVQQGEwJDSDEQMA4GA1UECAwHWsO8cmljaDEQ MA4GA1UEBwwHWsO8cmljaDESMBAGA1UEChMJTmVsbWlvIEFHMRgwFgYDVQQDEw9n ZXRjb21wb3Nlci5vcmcwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDY /rinDi/amwLzf4Nc6vaWfRgRV4UMstDp0aPpF9ZJVApUzks6adk4i/1GbgusjQ8j xuCpUih7FQdM0H/rwGAB1ydvMzvvQBa18DU3/2FNdEcQwJnK3VE/xV4OCKIS7xFa LQm/W0jhkY3k++a68aGB/T3/mPxkQMxFNVFKwRRlS+GeKVIavfYkJZrfWobztVjb bMFsxaIqHBCb7Jo0pGAbYoaedWncuUYDNIaez04ejIataxW5rwBapsKBRtRe92bn sbU40IxrJ9R9amksYayJLYNhG/V8PIkQiibMrP4KVZH2XVZOMCpkrJFyW9l4Y2rm aB89RzCU3a0yRu3NCv2fAgMBAAGjggHhMIIB3TAfBgNVHSMEGDAWgBQPgGEcgjFh 1S8o541GOLQs4cbZ4jAdBgNVHQ4EFgQUm5Dn9S1j0h3hvmp9dp3CIY9UpSowLwYD VR0RBCgwJoIPZ2V0Y29tcG9zZXIub3JnghN3d3cuZ2V0Y29tcG9zZXIub3JnMA4G A1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYBBQUHAwIwawYD VR0fBGQwYjAvoC2gK4YpaHR0cDovL2NybDMuZGlnaWNlcnQuY29tL3NzY2Etc2hh Mi1nMi5jcmwwL6AtoCuGKWh0dHA6Ly9jcmw0LmRpZ2ljZXJ0LmNvbS9zc2NhLXNo YTItZzIuY3JsMEIGA1UdIAQ7MDkwNwYJYIZIAYb9bAEBMCowKAYIKwYBBQUHAgEW HGh0dHBzOi8vd3d3LmRpZ2ljZXJ0LmNvbS9DUFMwfAYIKwYBBQUHAQEEcDBuMCQG CCsGAQUFBzABhhhodHRwOi8vb2NzcC5kaWdpY2VydC5jb20wRgYIKwYBBQUHMAKG Omh0dHA6Ly9jYWNlcnRzLmRpZ2ljZXJ0LmNvbS9EaWdpQ2VydFNIQTJTZWN1cmVT ZXJ2ZXJDQS5jcnQwDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQsFAAOCAQEAZ07d PUGJmdueSrFMytwKiHB92OxqNRDtiGseYWidWIYuF9Uegj/oq8lZWdTyZuOl0fGG z7eqNJQlNQ0Nee2bX0bBz3777HReracJ+p+0GeJlF0eXDpSLjh+8n6u/CsRJ/kmQ 9Q5bAS/YIk+P/gXgG9Mf3YjlhmglyFxxWtY66ivj4KpoggkitmEz6k6gEBnRMHYA JuOeVeOQxXBFt5h1fOIrQP7mqfZ/1LADDVwxoepjczWplc+S2Q9Ciij/QoqPyGbK ASMziu/XDQWm0+3HCZr5HbVGWybk4DaaCbWrYfQED3yFkOi54YNLBrVLHyUft77R qL7FH5cFtqPuT+BqEg== -----END CERTIFICATE----- subject=/C=CH/ST=Z\xC3\xBCrich/L=Z\xC3\xBCrich/O=Nelmio AG/CN=getcomposer.org issuer=/C=US/O=DigiCert Inc/CN=DigiCert SHA2 Secure Server CA --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 2921 bytes and written 0 bytes --- New, (NONE), Cipher is (NONE) Server public key is 2048 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : 0000 Session-ID: Session-ID-ctx: Master-Key: Key-Arg : None PSK identity: None PSK identity hint: None SRP username: None Start Time: 1472668388 Timeout : 300 (sec) Verify return code: 0 (ok) -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian at virtru.com Wed Aug 31 20:12:45 2016 From: brian at virtru.com (Brian Jost) Date: Wed, 31 Aug 2016 13:12:45 -0700 Subject: [openssl-users] fips_premain.c bitcode for iOS Message-ID: We ran into an issue where we were selecting 'Include bitcode' when submitting to apple and when doing ad-hoc builds. It seems doing this with the fips_premain.c file included in the xcode compile sources phase causes an instant crash on start up. What is the proper way to get past this bitcode issue? If we select to NOT 'Include bitcode' the app doesn't crash. I have narrowed this down to the fips_premain.c file by Including bitcode but removing fips from the project and it working. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nikola.n.milev at gmail.com Wed Aug 31 22:16:39 2016 From: nikola.n.milev at gmail.com (Nikola Milev) Date: Thu, 1 Sep 2016 00:16:39 +0200 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: References: Message-ID: To whom it may concern, I have been experiencing issues with OpenSSL and DraginoYun. If you are not the person I should have contacted, please redirect me. Thank you! Recently, I have tried using OpenSSL to establish a simple server application on Dragino Yun version 2.4. First, I tested the code on my Acer Aspire 5750ZG running Ubuntu 14.04 and it worked fine. Afterwards, I used OpenWrt SDK to cross-compile the application. However, the application is unable to bind the socket; the BIO_do_accept function fails. Here is the error stack the code provided: "2006783048:error:0200407C:lib(2):func(4):reason(124):NA:0:port='5354' 2006783048:error:20069076:lib(32):func(105):reason(118):NA:0:" errstr returned these as answers: "$ openssl errstr 0200407C error:0200407C:system library:socket:Wrong medium type $ openssl errstr 20069076 error:20069076:BIO routines:BIO_get_accept_socket:unable to create socket " I suppose that the second one is a product of the first one. I have checked iptables and I have checked ports that are currently in use, all seems to be in order. However, the OpenSSL s_server (in combination with s_client on the other side) works fine. May this be an OpenSSL bug? If not, do you have any suggestions? OpenSSL version on Acer is 1.0.1f 6 Jan 2014 and on Dragino 1.0.1h 5 Jun 2014. In the attachment, I am providing the code(though I am not sure if it is available on the list), mostly taken from O'Reilly "Network Security with OpenSSL". All the passkeys are "raspberry". (these certificates and keys were generated for testing purposes) Of course, should you need any additional information, I'd be happy to provide it. I originally addressed Matt Caswell regarding the issue and I am pasting his response to my question and my response to that. His response: "Hello, I'm not really the best person to ask about such low level stuff. The best place to raise these questions is on the openssl-users email list. It also means any questions/answers are publicly archived and available for other users. Details are here: https://mta.openssl.org However, I did have a quick look and discovered the following. The code that raises this error looks like this: s = socket(server.sa.sa_family, SOCK_STREAM, SOCKET_PROTOCOL); if (s == INVALID_SOCKET) { SYSerr(SYS_F_SOCKET, get_last_socket_error()); ERR_add_error_data(3, "port='", host, "'"); BIOerr(BIO_F_BIO_GET_ACCEPT_SOCKET, BIO_R_UNABLE_TO_CREATE_SOCKET); goto err; } So this is a call to the non-OpenSSL networking function "socket". In this context "server.sa.sa_family" has been set to AF_INET a few lines above, and "SOCKET_PROTOCOL" is a macro defined at the beginning of the file as follows: # define SOCKET_PROTOCOL IPPROTO_TCP In other words the function that is failing is doing this: socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) This seems like a fairly fundamental failure, and might suggest that the platform in question has no TCP/IP support available for some reason?" My response to his: " Hi Matt, The platform supports TCP/IP, if I deduced correctly. I have programmed an application similar to the example in Unix Network Programming (a basic TCP/IP echo server) and it works without any issues. Also, openssl s_server works correctly; I tried using it with openssl s_client on the other machine. I will forward my question to the email list, including both of our responses. I am grateful for your quick response. Best regards, Nikola Milev " My original mail to him is almost the same as the first part of this mail. I am thankful for you support! Best regards, Nikola Milev -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: src.tar.gz Type: application/x-gzip Size: 12850 bytes Desc: not available URL: From matt at openssl.org Wed Aug 31 22:46:13 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 31 Aug 2016 23:46:13 +0100 Subject: [openssl-users] OpenSSL Dragino Yun Issues In-Reply-To: References: Message-ID: On 31/08/16 23:16, Nikola Milev wrote: > In other words the function that is failing is doing this: > > socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) It would be interesting to know whether a minimalist program that just does the above successfully creates a socket or not. If it does succeed then this might suggest my analysis is wrong, and the socket call doesn't send the parameters that I think it does. If that's the case then it would be interesting to try and figure out what it actually sends. If it fails then you have a non-OpenSSL issue to try and figure out. Matt