From rsalz at akamai.com Fri May 1 01:42:22 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 1 May 2015 01:42:22 +0000 Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: References: Message-ID: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> > In case you are interested in seeing the condition/decision source code > coverage as achieved through the OpenSSL test suite: > > http://www.opencoverage.net/projects/openssl/index_html/sources.html > > We now regularly generate the reports from the tip of the master branch. This is great, thanks. I am curious to see what the numbers look like from, say, yesterday compared to, roughly, early next week. We are well into a huge overall edit that turns code like If (p) free(p) Into free(p); And not just for free, but for several dozen OpenSSL functions. This will probably remove a couple of thousand decision points. The code certainly looks much simpler. From porten at froglogic.com Fri May 1 12:43:23 2015 From: porten at froglogic.com (Harri Porten) Date: Fri, 1 May 2015 14:43:23 +0200 (CEST) Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> References: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: On Fri, 1 May 2015, Salz, Rich wrote: > I am curious to see what the numbers look like from, say, yesterday compared to, roughly, early next week. > We are well into a huge overall edit that turns code like > If (p) free(p) > Into > free(p); > And not just for free, but for several dozen OpenSSL functions. This will probably remove a couple of thousand decision points. The code certainly looks much simpler. Yeah. A commit like 222561fe8e should definitely show up in the statistics. We could do a comparison against the OpenSSL_1_0_2a release tag for example. It'll now only show the difference in absolute numbers but also deltas for changed files and functions. Should be ready on Monday or Tuesday. Harri. From rt at openssl.org Sat May 2 02:16:29 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 04:16:29 +0200 Subject: [openssl-dev] [openssl.org #3769] Bug in v3_alt.c In-Reply-To: <43e1595dda1a4d729230a52316e01243@usma1ex-dag1mb2.msg.corp.akamai.com> References: <43e1595dda1a4d729230a52316e01243@usma1ex-dag1mb2.msg.corp.akamai.com> Message-ID: not valid From rt at openssl.org Sat May 2 06:04:59 2015 From: rt at openssl.org (Chris Cooksey via RT) Date: Sat, 2 May 2015 08:04:59 +0200 Subject: [openssl-dev] [openssl.org #3829] Bug Report In-Reply-To: References: Message-ID: OpenSSL 1.0.2 a has a bug in crypto/x509v3/v3_util.c line 810: int atend = (i == len - 1 || p[i + i] == '.'); It is supposed to read: int atend = (i == len - 1 || p[i + 1] == '.'); Note the the expression p[i + i] is patently wrong. Thanks, Chris Cooksey This email and any attachments may contain confidential and proprietary information of Blackboard that is for the sole use of the intended recipient. If you are not the intended recipient, disclosure, copying, re-distribution or other use of any of this information is strictly prohibited. Please immediately notify the sender and delete this transmission if you received this email in error. From rt at openssl.org Sat May 2 06:05:21 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Sat, 2 May 2015 08:05:21 +0200 Subject: [openssl-dev] [openssl.org #3830] [PATCH] Fix test execution on Windows In-Reply-To: References: Message-ID: Hello, Summary: fix test case execution on Windows so that all the tests will be run. Additional data: 1) Operating systems affected: all versions of Windows. 2) OpenSSL versions affected: all versions running on Windows. Thank you, Gunnar Kudrjavets -------------- next part -------------- >From 3a27a5e98f883034c0d61928f6e71f364fcc024a Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Fri, 1 May 2015 13:07:20 -0700 Subject: [PATCH] Fix test execution on Windows Currently running tests on Windows is broken because '.\ms\testss.bat' references 'certCA.srl' instead of '..\ms\certCA.srl'. Given that the working directory during test execution is not 'ms' then this means that not all the tests will be executed. The fix is trivial. We just copy the file from '..\ms\'. Referencing it directly would cause the contents to change which will mark the file as modified every time test cases will be executed. If everything goes well then after running 'nmake -f ms\ntdll.mak test' one should see 'passed all tests' in the output. --- ms/testss.bat | 3 +++ 1 file changed, 3 insertions(+) diff --git a/ms/testss.bat b/ms/testss.bat index 5afa131..291532d 100755 --- a/ms/testss.bat +++ b/ms/testss.bat @@ -48,6 +48,9 @@ if errorlevel 1 goto e_req_gen echo -- echo sign certificate request with the just created CA via 'x509' +rem The serial number file is not in the current directory. Need to copy it +rem from the source location so that the next test will pass. +copy /y ..\ms\%CAserial% . %x509cmd% -CAcreateserial -in %Ureq% -days 30 -req -out %Ucert% -CA %CAcert% -CAkey %CAkey% -CAserial %CAserial% if errorlevel 1 goto e_x_sign -- 1.9.5.msysgit.1 From rt at openssl.org Sat May 2 11:47:32 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 13:47:32 +0200 Subject: [openssl-dev] [openssl.org #3812] asn1parse -genconf may cause access to uninitialized variable In-Reply-To: <20150418160602.421c223c@pc1.fritz.box> References: <20150418160602.421c223c@pc1.fritz.box> Message-ID: OpenSSL_1_0_1-stable cd258a8 Fix uninitialized variable. OpenSSL_1_0_2-stable 6b3a315 Fix uninitialized variable. master 539ed89 Fix uninitialized variable. Author: Hanno Boeck Date: Fri May 1 22:27:20 2015 -0400 Fix uninitialized variable. Signed-off-by: Rich Salz Reviewed-by: Viktor Dukhovni From rt at openssl.org Sat May 2 11:58:24 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 13:58:24 +0200 Subject: [openssl-dev] [openssl.org #3776] Memory corruption in X509_VERIFY_PARAM_new In-Reply-To: References: Message-ID: OpenSSL_1_0_2-stable 5b38d54 RT3776: Wrong size for malloc master 53ba0a9 RT3776: Wrong size for malloc Author: Rich Salz Date: Fri May 1 22:06:07 2015 -0400 RT3776: Wrong size for malloc Use sizeof *foo parameter, to avoid these errors. Reviewed-by: Viktor Dukhovni From rt at openssl.org Sat May 2 12:03:09 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 14:03:09 +0200 Subject: [openssl-dev] [openssl.org #3820] [PATCH] Remove an unnecessary call to USER32!GetDesktopWindow In-Reply-To: References: Message-ID: OpenSSL_1_0_0-stable 6c63867 RT3820: Don't call GetDesktopWindow() OpenSSL_1_0_1-stable ee827ad RT3820: Don't call GetDesktopWindow() OpenSSL_1_0_2-stable a659386 RT3820: Don't call GetDesktopWindow() master bed2edf RT3820: Don't call GetDesktopWindow() Author: Gilles Khouzam Date: Fri May 1 22:20:42 2015 -0400 RT3820: Don't call GetDesktopWindow() Signed-off-by: Rich Salz Reviewed-by: Richard Levitte From rt at openssl.org Sat May 2 13:14:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 15:14:44 +0200 Subject: [openssl-dev] [openssl.org #3185] Patch to add -tls switch to s_client In-Reply-To: References: Message-ID: There are {no,}{ssl3,tls1,tls1_1,tls1_2} flags available now. So -no_ssl3 gets the effect you want. From rt at openssl.org Sat May 2 13:41:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 15:41:44 +0200 Subject: [openssl-dev] [openssl.org #3190] Patch to add -tls switch to s_server In-Reply-To: References: Message-ID: as with s_client, you can do -no_ssl3 to get the same effect now. From rt at openssl.org Sat May 2 13:43:26 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 15:43:26 +0200 Subject: [openssl-dev] [openssl.org #3539] x509 application supports additional fingerprint digests (sha2) not shown in help. In-Reply-To: References: Message-ID: We sort-of sidestepped this; the help now says -* Any supported digest which is reasonable for a summary. (All commands that take a message-digest or encryption-type parameter now do this same thing.) From rt at openssl.org Sat May 2 14:14:07 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 16:14:07 +0200 Subject: [openssl-dev] [openssl.org #601] extend opensslconf.h to have a flag for every available feature In-Reply-To: <3EAE7330.4070208@trustcenter.de> References: <3EAE7330.4070208@trustcenter.de> Message-ID: It's been a very long time, and while I prefer the "positive" approach about features, it's too much work to change this for not enough benefit. From rt at openssl.org Sat May 2 14:16:11 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 16:16:11 +0200 Subject: [openssl-dev] [openssl.org #843] EBCDIC patches for 0.9.7c In-Reply-To: <4058A620.4000305@fujitsu-siemens.com> References: <4058A620.4000305@fujitsu-siemens.com> Message-ID: It's been a decade with no action. Pretty clearly, the openssl team is not going to do more EBCDIC work than what's already in the openssl command. Closing this ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat May 2 14:17:24 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 16:17:24 +0200 Subject: [openssl-dev] [openssl.org #844] [Fwd: Bug#235600: openssl: CA.pl and -signcert: some minor issues] In-Reply-To: <4059B07B.6070506@uni-mainz.de> References: <4059B07B.6070506@uni-mainz.de> Message-ID: We rewrote CA.pl.in for 1.1; see the master branch. If there are still issues, please open a new ticket. From rt at openssl.org Sat May 2 14:19:05 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 16:19:05 +0200 Subject: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl] In-Reply-To: <42723BA5.5040302@uni-mainz.de> References: <42723BA5.5040302@uni-mainz.de> Message-ID: After ten years, the answer is "no we are not supporting this now." -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat May 2 14:26:38 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 16:26:38 +0200 Subject: [openssl-dev] [openssl.org #1132] Re: submission of OpenSSL changes for smime In-Reply-To: References: Message-ID: Being realistic, we're not going to do this. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Sat May 2 15:27:52 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sat, 2 May 2015 17:27:52 +0200 Subject: [openssl-dev] [openssl.org #3231] default ciphers include insecure export cipher suites In-Reply-To: References: Message-ID: Kurt fixed this with commit f417997a324037025be61737288e40e171a8218c From dwmw2 at infradead.org Sat May 2 18:29:38 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 02 May 2015 19:29:38 +0100 Subject: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl] In-Reply-To: References: <42723BA5.5040302@uni-mainz.de> Message-ID: <1430591378.14112.3.camel@infradead.org> On Sat, 2015-05-02 at 16:19 +0200, Rich Salz via RT wrote: > After ten years, the answer is "no we are not supporting this now." We really ought to fix PKCS#11 support though, to make it a first class citizen. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From rt at openssl.org Sat May 2 18:46:24 2015 From: rt at openssl.org (David Woodhouse via RT) Date: Sat, 2 May 2015 20:46:24 +0200 Subject: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl] In-Reply-To: <1430591378.14112.3.camel@infradead.org> References: <42723BA5.5040302@uni-mainz.de> <1430591378.14112.3.camel@infradead.org> Message-ID: On Sat, 2015-05-02 at 16:19 +0200, Rich Salz via RT wrote: > After ten years, the answer is "no we are not supporting this now." We really ought to fix PKCS#11 support though, to make it a first class citizen. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5745 bytes Desc: not available URL: From rt at openssl.org Sat May 2 20:33:36 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 2 May 2015 22:33:36 +0200 Subject: [openssl-dev] [openssl.org #3793] rec_layer_s3.c and `if (&s->rlayer.read_ahead && !SSL_IS_DTLS(s))` In-Reply-To: References: Message-ID: I fixed this a few weeks ago in commit 4118dfdcc8, but forgot to close the ticket. Closing now. Thanks for the report. Matt From rt at openssl.org Sat May 2 20:40:17 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Sat, 2 May 2015 22:40:17 +0200 Subject: [openssl-dev] [openssl.org #2839] [PATCH] Support DTLS compatibility with DTLS1_BAD_VER client In-Reply-To: <231876B4FF1F7E45A50FE6F8D176322E06D61E52@BL2PRD0610MB385.namprd06.prod.outlook.com> References: <231876B4FF1F7E45A50FE6F8D176322E06D61E52@BL2PRD0610MB385.namprd06.prod.outlook.com> Message-ID: Thanks for the patch, but (as you might have guessed by now!) we will not be adding this capability. Matt From rt at openssl.org Sat May 2 22:28:10 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 3 May 2015 00:28:10 +0200 Subject: [openssl-dev] [openssl.org #1055] [Fwd: Bug#272281: include musclecard engine support in openssl] In-Reply-To: <42723BA5.5040302@uni-mainz.de> References: <42723BA5.5040302@uni-mainz.de> Message-ID: re-closing. From doctor at doctor.nl2k.ab.ca Sun May 3 11:54:44 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 3 May 2015 05:54:44 -0600 Subject: [openssl-dev] openssl 20150503 SNAP issue Message-ID: <20150503115444.GA19929@doctor.nl2k.ab.ca> Script started on Sun May 3 05:43:13 2015 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ make && make tes t making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in crypto/hmac... making all in crypto/ripemd... making all in crypto/whrlpool... making all in crypto/des... making all in crypto/aes... making all in crypto/rc2... making all in crypto/rc4... making all in crypto/rc5... making all in crypto/idea... making all in crypto/bf... making all in crypto/cast... making all in crypto/camellia... making all in crypto/seed... making all in crypto/modes... making all in crypto/bn... making all in crypto/ec... making all in crypto/rsa... making all in crypto/dsa... making all in crypto/ecdsa... making all in crypto/dh... making all in crypto/ecdh... making all in crypto/dso... making all in crypto/engine... making all in crypto/buffer... making all in crypto/bio... making all in crypto/stack... making all in crypto/lhash... making all in crypto/rand... making all in crypto/err... making all in crypto/evp... making all in crypto/asn1... making all in crypto/pem... making all in crypto/x509... making all in crypto/x509v3... making all in crypto/conf... making all in crypto/txt_db... making all in crypto/pkcs7... making all in crypto/pkcs12... making all in crypto/comp... making all in crypto/ocsp... making all in crypto/ui... making all in crypto/krb5... making all in crypto/cms... making all in crypto/pqueue... making all in crypto/ts... making all in crypto/jpake... making all in crypto/srp... making all in crypto/store... making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc making all in ssl... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libssl.so.1.0.0); fi [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc making all in engines... echo making all in engines/ccgost... making all in apps... making all in test... making all in tools... testing... making all in apps... ../util/shlib_wrap.sh ./destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ../util/shlib_wrap.sh ./ideatest ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha1test test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha256t Testing SHA-256 ... passed. Testing SHA-224 ... passed. ../util/shlib_wrap.sh ./sha512t Testing SHA-512 ... passed. Testing SHA-384 ... passed. ../util/shlib_wrap.sh ./md4test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./md5test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./hmactest test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok ../util/shlib_wrap.sh ./md2test No MD2 support ../util/shlib_wrap.sh ./mdc2test pad1 - ok pad2 - ok ../util/shlib_wrap.sh ./wp_test Testing Whirlpool ......... passed. ../util/shlib_wrap.sh ./rmdtest test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok test 8 ok ../util/shlib_wrap.sh ./rc2test ecb RC2 ok ../util/shlib_wrap.sh ./rc4test test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test end processing ....................done test multi-call ....................done bulk test ok ../util/shlib_wrap.sh ./rc5test ecb RC5 ok cbc RC5 ok ../util/shlib_wrap.sh ./bftest testing blowfish in raw ecb mode testing blowfish in ecb mode testing blowfish set_key testing blowfish in cbc mode testing blowfish in cfb64 mode testing blowfish in ofb64 ../util/shlib_wrap.sh ./casttest ecb cast5 ok This test will take some time....123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr test BN_mul test BN_div test BN_div_word test BN_div_recp test BN_mod test BN_mod_mul test BN_mont test BN_mod_exp test BN_mod_exp_mont_consttime test BN_exp test BN_kronecker .................++++++ .................................................................................................... test BN_mod_sqrt ..... ..... ..... ..... ..... ..... ..... ..... ...++++++++++++ ..... .......++++++++++++ ..... ..............................++++++++++++ ..... .++++++++++++ ..... .++++++++++++ ..... ...........................................++++++++++++ ..... ..............++++++++++++ ..... ..++++++++++++ ..... test BN_GF2m_add test BN_GF2m_mod test BN_GF2m_mod_mul test BN_GF2m_mod_sqr test BN_GF2m_mod_inv test BN_GF2m_mod_div test BN_GF2m_mod_exp test BN_GF2m_mod_sqrt test BN_GF2m_mod_solve_quad running bc verify BN_add.................................................................................................... verify BN_sub...................................................................................................................................................... verify BN_lshift1.................................................................................................... verify BN_lshift (fixed).................................................................................................... verify BN_lshift.................................................................................................... verify BN_rshift1.................................................................................................... verify BN_rshift.................................................................................................... verify BN_sqr...................................................................................................... verify BN_mul...................................................................................................................................................... verify BN_div............................................................................................................................................................................................................................................................................................................ verify BN_div_word........................................................................................................................................................................................................ verify BN_div_recp............................................................................................................................................................................................................................................................................................................ verify BN_mod.................................................................................................... verify BN_mod_mul............................................................................................................................................................................................................................................................................................................ verify BN_mont..... verify BN_mod_exp..... verify BN_mod_exp_mont_consttime..... verify BN_exp..... verify BN_kronecker verify BN_mod_sqrt verify BN_GF2m_add verify BN_GF2m_mod verify BN_GF2m_mod_mul verify BN_GF2m_mod_sqr verify BN_GF2m_mod_inv verify BN_GF2m_mod_div verify BN_GF2m_mod_exp verify BN_GF2m_mod_sqrt verify BN_GF2m_mod_solve_quad 2222 tests passed test a^b%c implementations ../util/shlib_wrap.sh ./exptest ........................................................................................................................................................................................................ done test elliptic curves ../util/shlib_wrap.sh ./ectest Curve defined by Weierstrass equation y^2 = x^3 + a*x + b (mod 0x17) a = 0x1 b = 0x1 A cyclic subgroup: point at infinity x = 0xD, y = 0x7 x = 0x5, y = 0x4 x = 0x11, y = 0x3 x = 0x11, y = 0x14 x = 0x5, y = 0x13 x = 0xD, y = 0x10 Generator as octet string, compressed form: 030D Generator as octet string, uncompressed form: 040D07 Generator as octet string, hybrid form: 070D07 A representation of the inverse of that generator in Jacobian projective coordinates: X = 0xC, Y = 0xF, Z = 0xA SEC2 curve secp160r1 -- Generator: x = 0x4A96B5688EF573284664698968C38BB913CBFC82 y = 0x23A628553168947D59DCC912042351377AC5FB32 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-192 -- Generator: x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012 y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-224 -- Generator: x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21 y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-256 -- Generator: x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296 y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-384 -- Generator: x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7 y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-521 -- Generator: x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66 y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok Curve defined by Weierstrass equation y^2 + x*y = x^3 + a*x^2 + b (mod 0x13) a = 0x3 b = 0x1 (0x... means binary polynomial) A cyclic subgroup: point at infinity x = 0x6, y = 0x8 x = 0x1, y = 0xD x = 0x7, y = 0x2 x = 0x0, y = 0x1 x = 0x7, y = 0x5 x = 0x1, y = 0xC x = 0x6, y = 0xE Generator as octet string, uncompressed form: 040608 NIST curve K-163 -- Generator: x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-163 -- Generator: x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36 y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-233 -- Generator: x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126 y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-233 -- Generator: x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-283 -- Generator: x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836 y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-283 -- Generator: x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053 y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-409 -- Generator: x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746 y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-409 -- Generator: x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7 y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-571 -- Generator: x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972 y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-571 -- Generator: x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19 y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok testing internal curves: ................................................................................. ok test ecdsa ../util/shlib_wrap.sh ./ecdsatest some tests from X9.62: testing prime192v1: .... ok testing prime239v1: .... ok testing c2tnb191v1: .... ok testing c2tnb239v1: .... ok testing ECDSA_sign() and ECDSA_verify() with some internal curves: secp160k1: ........ ok secp160r1: ........ ok secp160r2: ........ ok secp192k1: ........ ok secp224k1: ........ ok secp224r1: ........ ok secp256k1: ........ ok secp384r1: ........ ok secp521r1: ........ ok prime192v1: ........ ok prime192v2: ........ ok prime192v3: ........ ok prime239v1: ........ ok prime239v2: ........ ok prime239v3: ........ ok prime256v1: ........ ok sect163k1: ........ ok sect163r1: ........ ok sect163r2: ........ ok sect193r1: ........ ok sect193r2: ........ ok sect233k1: ........ ok sect233r1: ........ ok sect239k1: ........ ok sect283k1: ........ ok sect283r1: ........ ok sect409k1: ........ ok sect409r1: ........ ok sect571k1: ........ ok sect571r1: ........ ok c2pnb163v1: ........ ok c2pnb163v2: ........ ok c2pnb163v3: ........ ok c2pnb176v1: ........ ok c2tnb191v1: ........ ok c2tnb191v2: ........ ok c2tnb191v3: ........ ok c2pnb208w1: ........ ok c2tnb239v1: ........ ok c2tnb239v2: ........ ok c2tnb239v3: ........ ok c2pnb272w1: ........ ok c2pnb304w1: ........ ok c2tnb359v1: ........ ok c2pnb368w1: ........ ok c2tnb431r1: ........ ok wap-wsg-idm-ecid-wtls3: ........ ok wap-wsg-idm-ecid-wtls5: ........ ok wap-wsg-idm-ecid-wtls7: ........ ok wap-wsg-idm-ecid-wtls9: ........ ok wap-wsg-idm-ecid-wtls10: ........ ok wap-wsg-idm-ecid-wtls11: ........ ok wap-wsg-idm-ecid-wtls12: ........ ok brainpoolP160r1: ........ ok brainpoolP160t1: ........ ok brainpoolP192r1: ........ ok brainpoolP192t1: ........ ok brainpoolP224r1: ........ ok brainpoolP224t1: ........ ok brainpoolP256r1: ........ ok brainpoolP256t1: ........ ok brainpoolP320r1: ........ ok brainpoolP320t1: ........ ok brainpoolP384r1: ........ ok brainpoolP384t1: ........ ok brainpoolP512r1: ........ ok brainpoolP512t1: ........ ok ECDSA test passed test ecdh ../util/shlib_wrap.sh ./ecdhtest Testing key generation with NIST Prime-Curve P-192 .... ok Testing key generation with NIST Prime-Curve P-224 .... ok Testing key generation with NIST Prime-Curve P-256 .... ok Testing key generation with NIST Prime-Curve P-384 .... ok Testing key generation with NIST Prime-Curve P-521 .... ok Testing key generation with NIST Binary-Curve K-163 .... ok Testing key generation with NIST Binary-Curve B-163 .... ok Testing key generation with NIST Binary-Curve K-233 .... ok Testing key generation with NIST Binary-Curve B-233 .... ok Testing key generation with NIST Binary-Curve K-283 .... ok Testing key generation with NIST Binary-Curve B-283 .... ok Testing key generation with NIST Binary-Curve K-409 .... ok Testing key generation with NIST Binary-Curve B-409 .... ok Testing key generation with NIST Binary-Curve K-571 .... ok Testing key generation with NIST Binary-Curve B-571 .... ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok cat base64 aes-128-cbc aes-128-cbc base64 aes-128-ecb aes-128-ecb base64 aes-192-cbc aes-192-cbc base64 aes-192-ecb aes-192-ecb base64 aes-256-cbc aes-256-cbc base64 aes-256-ecb aes-256-ecb base64 base64 base64 base64 bf bf base64 bf-cbc bf-cbc base64 bf-cfb bf-cfb base64 bf-ecb bf-ecb base64 bf-ofb bf-ofb base64 camellia-128-cbc camellia-128-cbc base64 camellia-128-ecb camellia-128-ecb base64 camellia-192-cbc camellia-192-cbc base64 camellia-192-ecb camellia-192-ecb base64 camellia-256-cbc camellia-256-cbc base64 camellia-256-ecb camellia-256-ecb base64 cast cast base64 cast-cbc cast-cbc base64 cast5-cbc cast5-cbc base64 cast5-cfb cast5-cfb base64 cast5-ecb cast5-ecb base64 cast5-ofb cast5-ofb base64 des des base64 des-cbc des-cbc base64 des-cfb des-cfb base64 des-ecb des-ecb base64 des-ede des-ede base64 des-ede-cbc des-ede-cbc base64 des-ede-cfb des-ede-cfb base64 des-ede-ofb des-ede-ofb base64 des-ede3 des-ede3 base64 des-ede3-cbc des-ede3-cbc base64 des-ede3-cfb des-ede3-cfb base64 des-ede3-ofb des-ede3-ofb base64 des-ofb des-ofb base64 des3 des3 base64 desx desx base64 idea idea base64 idea-cbc idea-cbc base64 idea-cfb idea-cfb base64 idea-ecb idea-ecb base64 idea-ofb idea-ofb base64 rc2 rc2 base64 rc2-40-cbc rc2-40-cbc base64 rc2-64-cbc rc2-64-cbc base64 rc2-cbc rc2-cbc base64 rc2-cfb rc2-cfb base64 rc2-ecb rc2-ecb base64 rc2-ofb rc2-ofb base64 rc4 rc4 base64 rc4-40 rc4-40 base64 rc5 rc5 base64 rc5-cbc rc5-cbc base64 rc5-cfb rc5-cfb base64 rc5-ecb rc5-ecb base64 rc5-ofb rc5-ofb base64 seed seed base64 seed-cbc seed-cbc base64 seed-cfb seed-cfb base64 seed-ecb seed-ecb base64 seed-ofb seed-ofb base64 zlib zlib base64 echo test normal x509v1 certificate test normal x509v1 certificate sh ./tx509 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p echo test first x509v3 certificate test first x509v3 certificate sh ./tx509 v3-cert1.pem 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p echo test second x509v3 certificate test second x509v3 certificate sh ./tx509 v3-cert2.pem 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p rsa testing rsa conversions p -> d p -> p d -> d p -> d d -> p p -> p ../util/shlib_wrap.sh ./rsa_test PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok testing crl conversions p -> d p -> p d -> d p -> d d -> p p -> p testing session-id conversions p -> d p -> p d -> d p -> d d -> p p -> p Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 1024 bit RSA private key ....................++++++ ..................++++++ writing new private key to 'testkey.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AU State or Province Name (full name) [Queensland]: Locality Name (eg, city) []:Brisbane Organization Name (eg, company) []:CryptSoft Pty Ltd Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:Eric Young Email Address []:eay at mincom.oz.au verify OK testing req conversions p -> d p -> p d -> d p -> d d -> p p -> p testing req conversions p -> d p -> p d -> d p -> d d -> p p -> p testing pkcs7 conversions p -> d p -> p d -> d p -> d d -> p p -> p testing pkcs7 conversions (2) p -> d p -> p d -> d p -> d d -> p p -> p The following command should have some OK's and some failures There are definitly a few expired certificates ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem Segmentation fault *** Error code 139 Stop. *** Error code 1 Stop. ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ x sh: x: command not found ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150503$ exit exit Script done on Sun May 3 05:46:57 2015 Please fix. This was working in 20150502 Snapshots. -- 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 Alberta time to save the province from corruption! Vote Liberal on 5 May 2015!! From rt at openssl.org Sun May 3 12:54:10 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 3 May 2015 14:54:10 +0200 Subject: [openssl-dev] [openssl.org #3802] [PATCH] Fixes some typos in doc/ In-Reply-To: References: Message-ID: Commit 186bb90705f848806783de512b3df6872552b304 in master. From rt at openssl.org Sun May 3 12:55:04 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 3 May 2015 14:55:04 +0200 Subject: [openssl-dev] [openssl.org #3545] [PATCH] Fix a typo: distrubution In-Reply-To: <20140924.173858.562890203452860553.kou@clear-code.com> References: <20140924.173858.562890203452860553.kou@clear-code.com> Message-ID: Commit 8332f91cc0db4955259bca9f9138b5eff94d6e8c in master. From rt at openssl.org Sun May 3 12:55:27 2015 From: rt at openssl.org (Rich Salz via RT) Date: Sun, 3 May 2015 14:55:27 +0200 Subject: [openssl-dev] [openssl.org #3796] doc for verify does misspell -CRLfile option In-Reply-To: <20150411140931.1ac670cf@pc1.fritz.box> References: <20150411140931.1ac670cf@pc1.fritz.box> Message-ID: Commit 8332f91cc0db4955259bca9f9138b5eff94d6e8c in master. From rsalz at akamai.com Sun May 3 18:21:15 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 3 May 2015 18:21:15 +0000 Subject: [openssl-dev] openssl 20150503 SNAP issue In-Reply-To: <20150503115444.GA19929@doctor.nl2k.ab.ca> References: <20150503115444.GA19929@doctor.nl2k.ab.ca> Message-ID: <5d14748f44fa4ec4a9b7b23616566bd5@usma1ex-dag1mb4.msg.corp.akamai.com> SNAP releases are just that, snapshots. If you see the same problem twice, say, it is worth reporting. From rt at openssl.org Sun May 3 20:12:45 2015 From: rt at openssl.org (Jeff Hodges via RT) Date: Sun, 3 May 2015 22:12:45 +0200 Subject: [openssl-dev] [openssl.org #3231] default ciphers include insecure export cipher suites In-Reply-To: References: Message-ID: I disagree that this is closed with f417997a324037025be61737288e40e171a8218c. It only removes the EXPORT ciphers, but does not handle the LOW ones. It's 2015, and we can drop them by default now. openssl ciphers LOW prints out: EDH-RSA-DES-CBC-SHA:EDH-DSS-DES-CBC-SHA:DH-RSA-DES-CBC-SHA:DH-DSS-DES-CBC-SHA:ADH-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5 Which of these are actually have substantial use without any other cipher suites available? I have no found any. On Sat, May 2, 2015 at 8:27 AM Rich Salz via RT wrote: > Kurt fixed this with commit f417997a324037025be61737288e40e171a8218c > > From openssl-users at dukhovni.org Sun May 3 20:21:15 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 3 May 2015 20:21:15 +0000 Subject: [openssl-dev] [openssl.org #3231] default ciphers include insecure export cipher suites In-Reply-To: References: Message-ID: <20150503202114.GJ17743@mournblade.imrryr.org> On Sun, May 03, 2015 at 10:12:45PM +0200, Jeff Hodges via RT wrote: > I disagree that this is closed with f417997a324037025be61737288e40e171a8218c. > It only removes the EXPORT ciphers, but does not handle the LOW ones. It's > 2015, and we can drop them by default now. Likely so, I would guess that the single-DES LOW ciphers are/were used even less than the EXPORT ciphers. So yes, I think it is reasonable to also remove "LOW" from DEFAULT. Mind you, removing EXPORT removes ephemeral RSA key transport, which is a significant reduction in attack surface. Disabling single DES just disables a cipher, so the benefit is not as great, but I support doing it anyway.. -- Viktor. From fweimer at redhat.com Mon May 4 09:59:09 2015 From: fweimer at redhat.com (Florian Weimer) Date: Mon, 04 May 2015 11:59:09 +0200 Subject: [openssl-dev] [openssl.org #2293] OpenSSL dependence on external threading functions is a critical design flaw In-Reply-To: References: <97B4F695-9736-44C9-9D03-0736C630965C@apple.com> Message-ID: <554742ED.1070201@redhat.com> On 09/03/2014 11:50 PM, Rich Salz via RT wrote: > We're going to try to clean up the threads situation post-1.0.2, but closing > this particular ticket. Can you at least change the FAQ to make sure that OpenSSL is *not* thread safe by default? Currently, it claims the opposite. The error reporting library critically depends on working locking functions. You get strange results if you believe the FAQ that OpenSSL is thread-safe, even if you do not use any objects across threads. -- Florian Weimer / Red Hat Product Security From rsalz at akamai.com Mon May 4 12:22:00 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 4 May 2015 12:22:00 +0000 Subject: [openssl-dev] three-arg open() call Message-ID: <39e07f4d3ea041bebf20f66b875672a8@usma1ex-dag1mb2.msg.corp.akamai.com> If you are using OpenSSL on a supported platform that does not support the three-argument call to open(), please let me know. Thanks. /r$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Mon May 4 12:51:10 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 04 May 2015 08:51:10 -0400 Subject: [openssl-dev] Seg fault during make test Message-ID: <55476B3E.6070301@cisco.com> Is anyone seeing a segmentation fault during the test_verify phase of make test on 32-bit systems? I haven't done a full triage yet. But it appears to have been introduced by 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs when backing out this commit. This could be a faulty commit since the sizeof invocations in this commit would return different values for 32/64 bit systems. From doctor at doctor.nl2k.ab.ca Mon May 4 13:21:11 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Mon, 4 May 2015 07:21:11 -0600 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20150504 error Message-ID: <20150504132111.GA10272@doctor.nl2k.ab.ca> This also occured in openssl-1.0.2-stable-SNAP-20150503 Script started on Mon May 4 07:06:41 2015 ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ egrep bsdi Confi gure "bsdi-elf-gcc", "gcc:-DPERL5 -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall::(unknown)::-ldl:BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", "debug-bsdi-x86-elf", "gcc3:-DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g::${BSDthreads}::-lgmp -ldl -lm -lc:THIRY_TWO_BIT_LONG RC4_CHUNK BN_LLONG ${x86_gcc_des} ${x86_gcc_opts}:${x86_elf_asm}:dlfcn:bsd-gcc-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ mak && make test sh: mak: command not found ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ ^k^ke make && make test making all in crypto... making all in crypto/objects... making all in crypto/md4... making all in crypto/md5... making all in crypto/sha... making all in crypto/mdc2... making all in crypto/hmac... making all in crypto/ripemd... making all in crypto/whrlpool... making all in crypto/des... making all in crypto/aes... making all in crypto/rc2... making all in crypto/rc4... making all in crypto/rc5... making all in crypto/idea... making all in crypto/bf... making all in crypto/cast... making all in crypto/camellia... making all in crypto/seed... making all in crypto/modes... making all in crypto/bn... making all in crypto/ec... making all in crypto/rsa... making all in crypto/dsa... making all in crypto/ecdsa... making all in crypto/dh... making all in crypto/ecdh... making all in crypto/dso... making all in crypto/engine... making all in crypto/buffer... making all in crypto/bio... making all in crypto/stack... making all in crypto/lhash... making all in crypto/rand... making all in crypto/err... making all in crypto/evp... making all in crypto/asn1... making all in crypto/pem... making all in crypto/x509... making all in crypto/x509v3... making all in crypto/conf... making all in crypto/txt_db... making all in crypto/pkcs7... making all in crypto/pkcs12... making all in crypto/comp... making all in crypto/ocsp... making all in crypto/ui... making all in crypto/krb5... making all in crypto/cms... making all in crypto/pqueue... making all in crypto/ts... making all in crypto/jpake... making all in crypto/srp... making all in crypto/store... making all in crypto/cmac... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libcrypto.so.1.0.0); fi [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc making all in ssl... if [ -n "libcrypto.so.1.0.0 libssl.so.1.0.0" ]; then (cd ..; make libssl.so.1.0.0); fi [ -z "" ] || gcc3 -fPIC -DOPENSSL_PIC -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -pthread -D_THREAD_SAFE -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -DPERL5 -DL_ENDIAN -DTERMIOS -fomit-frame-pointer -O2 -Wall -g -DOPENSSL_EXPERIMENTAL_JPAKE -DOPENSSL_EXPERIMENTAL_LIBUNBOUND -DOPENSSL_EXPERIMENTAL_STORE -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DRMD160_ASM -DAES_ASM -DGHASH_ASM -Iinclude -DFINGERPRINT_PREMAIN_DSO_LOAD -o fips_premain_dso fips_premain.c fipscanister.o libcrypto.a -lgmp -ldl -lm -lc making all in engines... echo making all in engines/ccgost... making all in apps... making all in test... making all in tools... testing... making all in apps... ../util/shlib_wrap.sh ./destest Doing cbcm Doing ecb Doing ede ecb Doing cbc Doing desx cbc Doing ede cbc Doing pcbc Doing cfb8 cfb16 cfb32 cfb48 cfb64 cfb64() ede_cfb64() done Doing ofb Doing ofb64 Doing ede_ofb64 Doing cbc_cksum Doing quad_cksum input word alignment test 0 1 2 3 output word alignment test 0 1 2 3 fast crypt test ../util/shlib_wrap.sh ./ideatest ecb idea ok cbc idea ok cfb64 idea ok ../util/shlib_wrap.sh ./shatest test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha1test test 1 ok test 2 ok test 3 ok ../util/shlib_wrap.sh ./sha256t Testing SHA-256 ... passed. Testing SHA-224 ... passed. ../util/shlib_wrap.sh ./sha512t Testing SHA-512 ... passed. Testing SHA-384 ... passed. ../util/shlib_wrap.sh ./md4test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./md5test test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok ../util/shlib_wrap.sh ./hmactest test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok ../util/shlib_wrap.sh ./md2test No MD2 support ../util/shlib_wrap.sh ./mdc2test pad1 - ok pad2 - ok ../util/shlib_wrap.sh ./wp_test Testing Whirlpool ......... passed. ../util/shlib_wrap.sh ./rmdtest test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test 6 ok test 7 ok test 8 ok ../util/shlib_wrap.sh ./rc2test ecb RC2 ok ../util/shlib_wrap.sh ./rc4test test 0 ok test 1 ok test 2 ok test 3 ok test 4 ok test 5 ok test end processing ....................done test multi-call ....................done bulk test ok ../util/shlib_wrap.sh ./rc5test ecb RC5 ok cbc RC5 ok ../util/shlib_wrap.sh ./bftest testing blowfish in raw ecb mode testing blowfish in ecb mode testing blowfish set_key testing blowfish in cbc mode testing blowfish in cfb64 mode testing blowfish in ofb64 ../util/shlib_wrap.sh ./casttest ecb cast5 ok This test will take some time....123456789ABCDEF ok ../util/shlib_wrap.sh ./randtest test 1 done test 2 done test 3 done test 4 done starting big number library test, could take a while... test BN_add test BN_sub test BN_lshift1 test BN_lshift (fixed) test BN_lshift test BN_rshift1 test BN_rshift test BN_sqr test BN_mul test BN_div test BN_div_word test BN_div_recp test BN_mod test BN_mod_mul test BN_mont test BN_mod_exp test BN_mod_exp_mont_consttime test BN_exp test BN_kronecker ....++++++ .................................................................................................... test BN_mod_sqrt ..... ..... ..... ..... ..... ..... ..... ..... ......++++++++++++ ..... ............++++++++++++ ..... .....++++++++++++ ..... .................++++++++++++ ..... .............++++++++++++ ..... ..++++++++++++ ..... .........++++++++++++ ..... ..++++++++++++ ..... test BN_GF2m_add test BN_GF2m_mod test BN_GF2m_mod_mul test BN_GF2m_mod_sqr test BN_GF2m_mod_inv test BN_GF2m_mod_div test BN_GF2m_mod_exp test BN_GF2m_mod_sqrt test BN_GF2m_mod_solve_quad running bc verify BN_add.................................................................................................... verify BN_sub...................................................................................................................................................... verify BN_lshift1.................................................................................................... verify BN_lshift (fixed).................................................................................................... verify BN_lshift.................................................................................................... verify BN_rshift1.................................................................................................... verify BN_rshift.................................................................................................... verify BN_sqr...................................................................................................... verify BN_mul...................................................................................................................................................... verify BN_div............................................................................................................................................................................................................................................................................................................ verify BN_div_word........................................................................................................................................................................................................ verify BN_div_recp............................................................................................................................................................................................................................................................................................................ verify BN_mod.................................................................................................... verify BN_mod_mul............................................................................................................................................................................................................................................................................................................ verify BN_mont..... verify BN_mod_exp..... verify BN_mod_exp_mont_consttime..... verify BN_exp..... verify BN_kronecker verify BN_mod_sqrt verify BN_GF2m_add verify BN_GF2m_mod verify BN_GF2m_mod_mul verify BN_GF2m_mod_sqr verify BN_GF2m_mod_inv verify BN_GF2m_mod_div verify BN_GF2m_mod_exp verify BN_GF2m_mod_sqrt verify BN_GF2m_mod_solve_quad 2222 tests passed test a^b%c implementations ../util/shlib_wrap.sh ./exptest ........................................................................................................................................................................................................ done test elliptic curves ../util/shlib_wrap.sh ./ectest Curve defined by Weierstrass equation y^2 = x^3 + a*x + b (mod 0x17) a = 0x1 b = 0x1 A cyclic subgroup: point at infinity x = 0xD, y = 0x7 x = 0x5, y = 0x4 x = 0x11, y = 0x3 x = 0x11, y = 0x14 x = 0x5, y = 0x13 x = 0xD, y = 0x10 Generator as octet string, compressed form: 030D Generator as octet string, uncompressed form: 040D07 Generator as octet string, hybrid form: 070D07 A representation of the inverse of that generator in Jacobian projective coordinates: X = 0xC, Y = 0xF, Z = 0xA SEC2 curve secp160r1 -- Generator: x = 0x4A96B5688EF573284664698968C38BB913CBFC82 y = 0x23A628553168947D59DCC912042351377AC5FB32 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-192 -- Generator: x = 0x188DA80EB03090F67CBF20EB43A18800F4FF0AFD82FF1012 y = 0x7192B95FFC8DA78631011ED6B24CDD573F977A11E794811 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-224 -- Generator: x = 0xB70E0CBD6BB4BF7F321390B94A03C1D356C21122343280D6115C1D21 y = 0xBD376388B5F723FB4C22DFE6CD4375A05A07476444D5819985007E34 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-256 -- Generator: x = 0x6B17D1F2E12C4247F8BCE6E563A440F277037D812DEB33A0F4A13945D898C296 y = 0x4FE342E2FE1A7F9B8EE7EB4A7C0F9E162BCE33576B315ECECBB6406837BF51F5 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-384 -- Generator: x = 0xAA87CA22BE8B05378EB1C71EF320AD746E1D3B628BA79B9859F741E082542A385502F25DBF55296C3A545E3872760AB7 y = 0x3617DE4A96262C6F5D9E98BF9292DC29F8F41DBD289A147CE9DA3113B5F0B8C00A60B1CE1D7E819D7A431D7C90EA0E5F verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve P-521 -- Generator: x = 0xC6858E06B70404E9CD9E3ECB662395B4429C648139053FB521F828AF606B4D3DBAA14B5E77EFE75928FE1DC127A2FFA8DE3348B3C1856A429BF97E7E31C2E5BD66 y = 0x11839296A789A3BC0045C8A5FB42C7D1BD998F54449579B446817AFBD17273E662C97EE72995EF42640C550B9013FAD0761353C7086A272C24088BE94769FD16650 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok Curve defined by Weierstrass equation y^2 + x*y = x^3 + a*x^2 + b (mod 0x13) a = 0x3 b = 0x1 (0x... means binary polynomial) A cyclic subgroup: point at infinity x = 0x6, y = 0x8 x = 0x1, y = 0xD x = 0x7, y = 0x2 x = 0x0, y = 0x1 x = 0x7, y = 0x5 x = 0x1, y = 0xC x = 0x6, y = 0xE Generator as octet string, uncompressed form: 040608 NIST curve K-163 -- Generator: x = 0x2FE13C0537BBC11ACAA07D793DE4E6D5E5C94EEE8 y = 0x289070FB05D38FF58321F2E800536D538CCDAA3D9 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-163 -- Generator: x = 0x3F0EBA16286A2D57EA0991168D4994637E8343E36 y = 0xD51FBC6C71A0094FA2CDD545B11C5C0C797324F1 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-233 -- Generator: x = 0x17232BA853A7E731AF129F22FF4149563A419C26BF50A4C9D6EEFAD6126 y = 0x1DB537DECE819B7F70F555A67C427A8CD9BF18AEB9B56E0C11056FAE6A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-233 -- Generator: x = 0xFAC9DFCBAC8313BB2139F1BB755FEF65BC391F8B36F8F8EB7371FD558B y = 0x1006A08A41903350678E58528BEBF8A0BEFF867A7CA36716F7E01F81052 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-283 -- Generator: x = 0x503213F78CA44883F1A3B8162F188E553CD265F23C1567A16876913B0C2AC2458492836 y = 0x1CCDA380F1C9E318D90F95D07E5426FE87E45C0E8184698E45962364E34116177DD2259 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-283 -- Generator: x = 0x5F939258DB7DD90E1934F8C70B0DFEC2EED25B8557EAC9C80E2E198F8CDBECD86B12053 y = 0x3676854FE24141CB98FE6D4B20D02B4516FF702350EDDB0826779C813F0DF45BE8112F4 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-409 -- Generator: x = 0x60F05F658F49C1AD3AB1890F7184210EFD0987E307C84C27ACCFB8F9F67CC2C460189EB5AAAA62EE222EB1B35540CFE9023746 y = 0x1E369050B7C4E42ACBA1DACBF04299C3460782F918EA427E6325165E9EA10E3DA5F6C42E9C55215AA9CA27A5863EC48D8E0286B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-409 -- Generator: x = 0x15D4860D088DDB3496B0C6064756260441CDE4AF1771D4DB01FFE5B34E59703DC255A868A1180515603AEAB60794E54BB7996A7 y = 0x61B1CFAB6BE5F32BBFA78324ED106A7636B9C5A7BD198D0158AA4F5488D08F38514F1FDF4B4F40D2181B3681C364BA0273C706 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve K-571 -- Generator: x = 0x26EB7A859923FBC82189631F8103FE4AC9CA2970012D5D46024804801841CA44370958493B205E647DA304DB4CEB08CBBD1BA39494776FB988B47174DCA88C7E2945283A01C8972 y = 0x349DC807F4FBF374F4AEADE3BCA95314DD58CEC9F307A54FFC61EFC006D8A2C9D4979C0AC44AEA74FBEBBB9F772AEDCB620B01A7BA7AF1B320430C8591984F601CD4C143EF1C7A3 verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok NIST curve B-571 -- Generator: x = 0x303001D34B856296C16C0D40D3CD7750A93D1D2955FA80AA5F40FC8DB7B2ABDBDE53950F4C0D293CDD711A35B67FB1499AE60038614F1394ABFA3B4C850D927E1E7769C8EEC2D19 y = 0x37BF27342DA639B6DCCFFFEB73D69D78C6C27A6009CBBCA1980F8533921E8A684423E43BAB08A576291AF8F461BB2A8B3531D2F0485C19B16E2F1516E23DD3C1A4827AF1B8AC15B verify degree ... ok verify group order .... ok long/negative scalar tests allowing precomputation ... without precomputation ... ok combined multiplication ..... ok testing internal curves: ................................................................................. ok test ecdsa ../util/shlib_wrap.sh ./ecdsatest some tests from X9.62: testing prime192v1: .... ok testing prime239v1: .... ok testing c2tnb191v1: .... ok testing c2tnb239v1: .... ok testing ECDSA_sign() and ECDSA_verify() with some internal curves: secp160k1: ........ ok secp160r1: ........ ok secp160r2: ........ ok secp192k1: ........ ok secp224k1: ........ ok secp224r1: ........ ok secp256k1: ........ ok secp384r1: ........ ok secp521r1: ........ ok prime192v1: ........ ok prime192v2: ........ ok prime192v3: ........ ok prime239v1: ........ ok prime239v2: ........ ok prime239v3: ........ ok prime256v1: ........ ok sect163k1: ........ ok sect163r1: ........ ok sect163r2: ........ ok sect193r1: ........ ok sect193r2: ........ ok sect233k1: ........ ok sect233r1: ........ ok sect239k1: ........ ok sect283k1: ........ ok sect283r1: ........ ok sect409k1: ........ ok sect409r1: ........ ok sect571k1: ........ ok sect571r1: ........ ok c2pnb163v1: ........ ok c2pnb163v2: ........ ok c2pnb163v3: ........ ok c2pnb176v1: ........ ok c2tnb191v1: ........ ok c2tnb191v2: ........ ok c2tnb191v3: ........ ok c2pnb208w1: ........ ok c2tnb239v1: ........ ok c2tnb239v2: ........ ok c2tnb239v3: ........ ok c2pnb272w1: ........ ok c2pnb304w1: ........ ok c2tnb359v1: ........ ok c2pnb368w1: ........ ok c2tnb431r1: ........ ok wap-wsg-idm-ecid-wtls3: ........ ok wap-wsg-idm-ecid-wtls5: ........ ok wap-wsg-idm-ecid-wtls7: ........ ok wap-wsg-idm-ecid-wtls9: ........ ok wap-wsg-idm-ecid-wtls10: ........ ok wap-wsg-idm-ecid-wtls11: ........ ok wap-wsg-idm-ecid-wtls12: ........ ok brainpoolP160r1: ........ ok brainpoolP160t1: ........ ok brainpoolP192r1: ........ ok brainpoolP192t1: ........ ok brainpoolP224r1: ........ ok brainpoolP224t1: ........ ok brainpoolP256r1: ........ ok brainpoolP256t1: ........ ok brainpoolP320r1: ........ ok brainpoolP320t1: ........ ok brainpoolP384r1: ........ ok brainpoolP384t1: ........ ok brainpoolP512r1: ........ ok brainpoolP512t1: ........ ok ECDSA test passed test ecdh ../util/shlib_wrap.sh ./ecdhtest Testing key generation with NIST Prime-Curve P-192 .... ok Testing key generation with NIST Prime-Curve P-224 .... ok Testing key generation with NIST Prime-Curve P-256 .... ok Testing key generation with NIST Prime-Curve P-384 .... ok Testing key generation with NIST Prime-Curve P-521 .... ok Testing key generation with NIST Binary-Curve K-163 .... ok Testing key generation with NIST Binary-Curve B-163 .... ok Testing key generation with NIST Binary-Curve K-233 .... ok Testing key generation with NIST Binary-Curve B-233 .... ok Testing key generation with NIST Binary-Curve K-283 .... ok Testing key generation with NIST Binary-Curve B-283 .... ok Testing key generation with NIST Binary-Curve K-409 .... ok Testing key generation with NIST Binary-Curve B-409 .... ok Testing key generation with NIST Binary-Curve K-571 .... ok Testing key generation with NIST Binary-Curve B-571 .... ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP256r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP384r1 ok Testing ECDH shared secret with Brainpool Prime-Curve brainpoolP512r1 ok cat base64 aes-128-cbc aes-128-cbc base64 aes-128-ecb aes-128-ecb base64 aes-192-cbc aes-192-cbc base64 aes-192-ecb aes-192-ecb base64 aes-256-cbc aes-256-cbc base64 aes-256-ecb aes-256-ecb base64 base64 base64 base64 bf bf base64 bf-cbc bf-cbc base64 bf-cfb bf-cfb base64 bf-ecb bf-ecb base64 bf-ofb bf-ofb base64 camellia-128-cbc camellia-128-cbc base64 camellia-128-ecb camellia-128-ecb base64 camellia-192-cbc camellia-192-cbc base64 camellia-192-ecb camellia-192-ecb base64 camellia-256-cbc camellia-256-cbc base64 camellia-256-ecb camellia-256-ecb base64 cast cast base64 cast-cbc cast-cbc base64 cast5-cbc cast5-cbc base64 cast5-cfb cast5-cfb base64 cast5-ecb cast5-ecb base64 cast5-ofb cast5-ofb base64 des des base64 des-cbc des-cbc base64 des-cfb des-cfb base64 des-ecb des-ecb base64 des-ede des-ede base64 des-ede-cbc des-ede-cbc base64 des-ede-cfb des-ede-cfb base64 des-ede-ofb des-ede-ofb base64 des-ede3 des-ede3 base64 des-ede3-cbc des-ede3-cbc base64 des-ede3-cfb des-ede3-cfb base64 des-ede3-ofb des-ede3-ofb base64 des-ofb des-ofb base64 des3 des3 base64 desx desx base64 idea idea base64 idea-cbc idea-cbc base64 idea-cfb idea-cfb base64 idea-ecb idea-ecb base64 idea-ofb idea-ofb base64 rc2 rc2 base64 rc2-40-cbc rc2-40-cbc base64 rc2-64-cbc rc2-64-cbc base64 rc2-cbc rc2-cbc base64 rc2-cfb rc2-cfb base64 rc2-ecb rc2-ecb base64 rc2-ofb rc2-ofb base64 rc4 rc4 base64 rc4-40 rc4-40 base64 rc5 rc5 base64 rc5-cbc rc5-cbc base64 rc5-cfb rc5-cfb base64 rc5-ecb rc5-ecb base64 rc5-ofb rc5-ofb base64 seed seed base64 seed-cbc seed-cbc base64 seed-cfb seed-cfb base64 seed-ecb seed-ecb base64 seed-ofb seed-ofb base64 zlib zlib base64 echo test normal x509v1 certificate test normal x509v1 certificate sh ./tx509 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p echo test first x509v3 certificate test first x509v3 certificate sh ./tx509 v3-cert1.pem 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p echo test second x509v3 certificate test second x509v3 certificate sh ./tx509 v3-cert2.pem 2>/dev/null testing X509 conversions p -> d p -> n p -> p d -> d n -> d p -> d d -> n n -> n p -> n d -> p n -> p p -> p rsa testing rsa conversions p -> d p -> p d -> d p -> d d -> p p -> p ../util/shlib_wrap.sh ./rsa_test PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok PKCS #1 v1.5 encryption/decryption ok OAEP encryption/decryption ok testing crl conversions p -> d p -> p d -> d p -> d d -> p p -> p testing session-id conversions p -> d p -> p d -> d p -> d d -> p p -> p Generate and verify a certificate request generating certificate request rsa There should be a 2 sequences of .'s and some +'s. There should not be more that at most 80 per line This could take some time. Generating a 1024 bit RSA private key .......................++++++ ..........................................................++++++ writing new private key to 'testkey.pem' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:AU State or Province Name (full name) [Queensland]: Locality Name (eg, city) []:Brisbane Organization Name (eg, company) []:CryptSoft Pty Ltd Organizational Unit Name (eg, section) []:. Common Name (eg, YOUR name) []:Eric Young Email Address []:eay at mincom.oz.au verify OK testing req conversions p -> d p -> p d -> d p -> d d -> p p -> p testing req conversions p -> d p -> p d -> d p -> d d -> p p -> p testing pkcs7 conversions p -> d p -> p d -> d p -> d d -> p p -> p testing pkcs7 conversions (2) p -> d p -> p d -> d p -> d d -> p p -> p The following command should have some OK's and some failures There are definitly a few expired certificates ../util/shlib_wrap.sh ../apps/openssl verify -CApath ../certs/demo ../certs/demo/*.pem Segmentation fault *** Error code 139 Stop. *** Error code 1 Stop. ns2.nl2k.ab.ca//usr/source/openssl-1.0.2-stable-SNAP-20150504$ exit exit Script done on Mon May 4 07:09:07 2015 This error does not occur in openssl-1.0.2-stable-SNAP-20150502 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 Alberta time to save the province from corruption! Vote Liberal on 5 May 2015!! From stm at pdflib.com Mon May 4 13:35:45 2015 From: stm at pdflib.com (=?windows-1252?Q?Stephan_M=FChlstrasser?=) Date: Mon, 04 May 2015 15:35:45 +0200 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <55476B3E.6070301@cisco.com> References: <55476B3E.6070301@cisco.com> Message-ID: <554775B1.2070300@pdflib.com> Am 04.05.15 um 14:51 schrieb John Foley: > Is anyone seeing a segmentation fault during the test_verify phase of > make test on 32-bit systems? I haven't done a full triage yet. But it > appears to have been introduced by > 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs > when backing out this commit. This could be a faulty commit since the > sizeof invocations in this commit would return different values for > 32/64 bit systems. The sizeof invocations do not return the pointer sizes, but the size of the structures pointed to. The problem is that there's apparently a copy&paste error: https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa 172 memset(param, 0, sizeof *paramid); 173 memset(paramid, 0, sizeof *paramid); The first memset should be fixed to use "*param" instead of "*paramid": memset(param, 0, sizeof *param); Regards Stephan From foleyj at cisco.com Mon May 4 14:19:11 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 04 May 2015 10:19:11 -0400 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <554775B1.2070300@pdflib.com> References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> Message-ID: <55477FDF.80909@cisco.com> I think you're wrong about sizeof and pointers. It'll return 4 or 8 depending if it's a 32 or 64 bit system. Try the following code: #include typedef struct _s1 { int x; int y; int z; } S1; typedef struct _s2 { double d1; double d2; double d3; double d4; int x1; int x2; } S2; int main (int argc, char *argv[]) { S1 *first; S2 *second; printf("%d %d\n", sizeof(first), sizeof(second)); } You're right about the memset, good catch. So it appears there are two issues with this commit. On 05/04/2015 09:35 AM, Stephan M?hlstrasser wrote: > Am 04.05.15 um 14:51 schrieb John Foley: >> Is anyone seeing a segmentation fault during the test_verify phase of >> make test on 32-bit systems? I haven't done a full triage yet. But it >> appears to have been introduced by >> 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs >> when backing out this commit. This could be a faulty commit since the >> sizeof invocations in this commit would return different values for >> 32/64 bit systems. > > The sizeof invocations do not return the pointer sizes, but the size > of the structures pointed to. > > The problem is that there's apparently a copy&paste error: > > https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa > > > 172 memset(param, 0, sizeof *paramid); > 173 memset(paramid, 0, sizeof *paramid); > > The first memset should be fixed to use "*param" instead of "*paramid": > > memset(param, 0, sizeof *param); > > Regards > Stephan > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rsalz at akamai.com Mon May 4 14:33:15 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 4 May 2015 14:33:15 +0000 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <554775B1.2070300@pdflib.com> References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> Message-ID: <2e85277db8a74d688d2213853544594e@usma1ex-dag1mb2.msg.corp.akamai.com> > 172 memset(param, 0, sizeof *paramid); > 173 memset(paramid, 0, sizeof *paramid); > > The first memset should be fixed to use "*param" instead of "*paramid": Yes, oops. Fixed shortl. From rsalz at akamai.com Mon May 4 14:37:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 4 May 2015 14:37:54 +0000 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <55477FDF.80909@cisco.com> References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> <55477FDF.80909@cisco.com> Message-ID: > printf("%d %d\n", sizeof(first), sizeof(second)); } But the code does sizeof *first and sizeof *second Stephan's write, the memset is bug that slipped through. From stm at pdflib.com Mon May 4 14:36:21 2015 From: stm at pdflib.com (=?windows-1252?Q?Stephan_M=FChlstrasser?=) Date: Mon, 04 May 2015 16:36:21 +0200 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <55477FDF.80909@cisco.com> References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> <55477FDF.80909@cisco.com> Message-ID: <554783E5.3080204@pdflib.com> Am 04.05.15 um 16:19 schrieb John Foley: > I think you're wrong about sizeof and pointers. It'll return 4 or 8 > depending if it's a 32 or 64 bit system. Try the following code: > > #include > > typedef struct _s1 { > int x; > int y; > int z; > } S1; > > typedef struct _s2 { > double d1; > double d2; > double d3; > double d4; > int x1; > int x2; > } S2; > > int main (int argc, char *argv[]) { > S1 *first; > S2 *second; > > printf("%d %d\n", sizeof(first), sizeof(second)); > } Yes, but that is different from what is relevant in the commit 53ba0a9e91ad203de2943edaf1090ab17ec435fa. You're right that in your test program you will get always different output on 32-bit and 64-bit systems because the pointer size is different. But the code in the OpenSSL uses "sizeof(*pointer)" and not "sizeof(pointer)". "sizeof(*pointer)" gets the size of the structure to which "pointer" points. So try the following in your test program printf("%d %d\n", sizeof(*first), sizeof(*second)); This might return different output on 32-bit and 64-bit systems, but it might also return the same output, depending on the size of the basic types and the padding in the structures. > You're right about the memset, good catch. So it appears there are two > issues with this commit. > > > > On 05/04/2015 09:35 AM, Stephan M?hlstrasser wrote: >> Am 04.05.15 um 14:51 schrieb John Foley: >>> Is anyone seeing a segmentation fault during the test_verify phase of >>> make test on 32-bit systems? I haven't done a full triage yet. But it >>> appears to have been introduced by >>> 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer occurs >>> when backing out this commit. This could be a faulty commit since the >>> sizeof invocations in this commit would return different values for >>> 32/64 bit systems. >> >> The sizeof invocations do not return the pointer sizes, but the size >> of the structures pointed to. >> >> The problem is that there's apparently a copy&paste error: >> >> https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa >> >> >> 172 memset(param, 0, sizeof *paramid); >> 173 memset(paramid, 0, sizeof *paramid); >> >> The first memset should be fixed to use "*param" instead of "*paramid": >> >> memset(param, 0, sizeof *param); >> >> Regards >> Stephan >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From foleyj at cisco.com Mon May 4 14:48:50 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 04 May 2015 10:48:50 -0400 Subject: [openssl-dev] Seg fault during make test In-Reply-To: <554783E5.3080204@pdflib.com> References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> <55477FDF.80909@cisco.com> <554783E5.3080204@pdflib.com> Message-ID: <554786D2.1080806@cisco.com> My bad, I overlooked the dereference operator. Thanks for correcting me. On 05/04/2015 10:36 AM, Stephan M?hlstrasser wrote: > Am 04.05.15 um 16:19 schrieb John Foley: >> I think you're wrong about sizeof and pointers. It'll return 4 or 8 >> depending if it's a 32 or 64 bit system. Try the following code: >> >> #include >> >> typedef struct _s1 { >> int x; >> int y; >> int z; >> } S1; >> >> typedef struct _s2 { >> double d1; >> double d2; >> double d3; >> double d4; >> int x1; >> int x2; >> } S2; >> >> int main (int argc, char *argv[]) { >> S1 *first; >> S2 *second; >> >> printf("%d %d\n", sizeof(first), sizeof(second)); >> } > > Yes, but that is different from what is relevant in the commit > 53ba0a9e91ad203de2943edaf1090ab17ec435fa. > > You're right that in your test program you will get always different > output on 32-bit and 64-bit systems because the pointer size is > different. > > But the code in the OpenSSL uses "sizeof(*pointer)" and not > "sizeof(pointer)". "sizeof(*pointer)" gets the size of the structure > to which "pointer" points. > > So try the following in your test program > > printf("%d %d\n", sizeof(*first), sizeof(*second)); > > This might return different output on 32-bit and 64-bit systems, but > it might also return the same output, depending on the size of the > basic types and the padding in the structures. > >> You're right about the memset, good catch. So it appears there are two >> issues with this commit. >> >> >> >> On 05/04/2015 09:35 AM, Stephan M?hlstrasser wrote: >>> Am 04.05.15 um 14:51 schrieb John Foley: >>>> Is anyone seeing a segmentation fault during the test_verify phase of >>>> make test on 32-bit systems? I haven't done a full triage yet. >>>> But it >>>> appears to have been introduced by >>>> 5b38d54753acdabbf6b1d5e15d38ee81fb0612a2. The problem no longer >>>> occurs >>>> when backing out this commit. This could be a faulty commit since the >>>> sizeof invocations in this commit would return different values for >>>> 32/64 bit systems. >>> >>> The sizeof invocations do not return the pointer sizes, but the size >>> of the structures pointed to. >>> >>> The problem is that there's apparently a copy&paste error: >>> >>> https://github.com/openssl/openssl/commit/53ba0a9e91ad203de2943edaf1090ab17ec435fa >>> >>> >>> >>> 172 memset(param, 0, sizeof *paramid); >>> 173 memset(paramid, 0, sizeof *paramid); >>> >>> The first memset should be fixed to use "*param" instead of "*paramid": >>> >>> memset(param, 0, sizeof *param); >>> >>> Regards >>> Stephan >>> _______________________________________________ >>> openssl-dev mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >>> >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > . > From porten at froglogic.com Mon May 4 15:02:42 2015 From: porten at froglogic.com (Harri Porten) Date: Mon, 4 May 2015 17:02:42 +0200 (CEST) Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> References: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: Hi Rich, On Fri, 1 May 2015, Salz, Rich wrote: > I am curious to see what the numbers look like from, say, yesterday compared to, roughly, early next week. We've compared the code coverage of the tests between the 1.0.2a release and today's master state: it rose from 28.1% to 29.6%! And as you predicted the code simplifications might be responsible: the number of decision points went down from 70192 to 67845. Which is good. Provided that the software still does the same thing as before ;) > We are well into a huge overall edit that turns code like > If (p) free(p) > Into > free(p); > And not just for free, but for several dozen OpenSSL functions. This will probably remove a couple of thousand decision points. The code certainly looks much simpler. Drilling down into the file changes of the last two weeks one can see cases of the if()/free() simplification happening in untested code however: http://www.opencoverage.net/projects/openssl-diff/index_html/source_33.html I'm not blaming anyone for that, though. Just pointing out the risk of potentially unnoticed regressions. Harri. From rsalz at akamai.com Mon May 4 15:05:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 4 May 2015 15:05:47 +0000 Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: References: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: <4d525ff98ff44d6b8502a5d42a1cacf2@usma1ex-dag1mb2.msg.corp.akamai.com> > We've compared the code coverage of the tests between the 1.0.2a release > and today's master state: it rose from 28.1% to 29.6%! I don't know that 1.5% deserves an exclamation point, but thanks. :) > And as you predicted the code simplifications might be responsible: the > number of decision points went down from 70192 to 67845. Which is good. That number is more interesting to me. Reducing the run-time complexity of OpenSSL is important. Thanks very much for doing this! Keep us posted. From openssl-users at dukhovni.org Mon May 4 16:06:48 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 4 May 2015 16:06:48 +0000 Subject: [openssl-dev] Seg fault during make test In-Reply-To: References: <55476B3E.6070301@cisco.com> <554775B1.2070300@pdflib.com> <55477FDF.80909@cisco.com> Message-ID: <20150504160648.GS17743@mournblade.imrryr.org> On Mon, May 04, 2015 at 02:37:54PM +0000, Salz, Rich wrote: > > printf("%d %d\n", sizeof(first), sizeof(second)); } > > But the code does sizeof *first and sizeof *second THe problem is a cut/paste error: memset(param, 0, sizeof *paramid); memset(paramid, 0, sizeof *paramid); The first of these should be param, not paramid. -- Viktor. From kurt at roeckx.be Mon May 4 16:59:39 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 4 May 2015 18:59:39 +0200 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20150504 error In-Reply-To: <20150504132111.GA10272@doctor.nl2k.ab.ca> References: <20150504132111.GA10272@doctor.nl2k.ab.ca> Message-ID: <20150504165939.GA14230@roeckx.be> On Mon, May 04, 2015 at 07:21:11AM -0600, The Doctor wrote: > This also occured in openssl-1.0.2-stable-SNAP-20150503 This will most likely be fixed in the next snapshot. Kurt From andrejs.igumenovs at gmail.com Tue May 5 07:37:17 2015 From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs) Date: Tue, 5 May 2015 10:37:17 +0300 Subject: [openssl-dev] [openssl] CA.pl.in script bug fix (#268) In-Reply-To: References: Message-ID: <2A1100F9-9B89-47FA-8BF1-B266EB58A8A8@gmail.com> Hi, It was fixed yesterday: commit 0fd75c7e6e8482489135beb3f536546f27f6d0e5 - Andrejs > On 05.05.2015, at 9:47, Adamzy Lee wrote: > > still get error message. > > ? > Reply to this email directly or view it on GitHub . > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrejs.igumenovs at gmail.com Tue May 5 07:53:18 2015 From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs) Date: Tue, 5 May 2015 10:53:18 +0300 Subject: [openssl-dev] openssl-1.0.2-stable-SNAP-20150504 error In-Reply-To: <20150504165939.GA14230@roeckx.be> References: <20150504132111.GA10272@doctor.nl2k.ab.ca> <20150504165939.GA14230@roeckx.be> Message-ID: Hi, It is fixed in the main repository. Another question is why the test differentiates between the i386 and x86_64. /Andrejs > On 04.05.2015, at 19:59, Kurt Roeckx wrote: > > On Mon, May 04, 2015 at 07:21:11AM -0600, The Doctor wrote: >> This also occured in openssl-1.0.2-stable-SNAP-20150503 > > This will most likely be fixed in the next snapshot. > > > Kurt > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Tue May 5 08:21:28 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 05 May 2015 09:21:28 +0100 Subject: [openssl-dev] Kerberos Message-ID: <55487D88.7010909@openssl.org> I am considering removing Kerberos support from OpenSSL 1.1.0. There are a number of problems with the functionality as it stands, and it seems to me to be a very rarely used feature. I'm interested in hearing any opinions on this (either for or against). Thanks in advance for your input, Matt From uri at ll.mit.edu Tue May 5 12:22:17 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 5 May 2015 12:22:17 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <55487D88.7010909@openssl.org> Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC271A89D5@LLE2K10-MBX01.mitll.ad.local> What are the problems? ----- Original Message ----- From: Matt Caswell [mailto:matt at openssl.org] Sent: Tuesday, May 05, 2015 04:21 AM To: openssl-users at openssl.org ; openssl-dev at openssl.org Subject: [openssl-dev] Kerberos I am considering removing Kerberos support from OpenSSL 1.1.0. There are a number of problems with the functionality as it stands, and it seems to me to be a very rarely used feature. I'm interested in hearing any opinions on this (either for or against). Thanks in advance for your input, Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Tue May 5 12:56:13 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 05 May 2015 13:56:13 +0100 Subject: [openssl-dev] Kerberos In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC271A89D5@LLE2K10-MBX01.mitll.ad.local> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271A89D5@LLE2K10-MBX01.mitll.ad.local> Message-ID: <5548BDED.1060008@openssl.org> On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote: > What are the problems? The code as it exists today is not compiled by default. I recently fixed a set of issues in master that had not been spotted simply because the code is not regularly compiled and used. One possible solution to that is to turn it on by default...but I think that is worse since it unnecessarily increases the attack surface for those that don't use it (the vast majority). As it turns out the "--with-krb5-include" Configure option has not been working correctly in 1.0.2 since it was released...but no-one noticed. Due to the infrequency with which it is being used in practice this means that the code is not being kept up to date. There are some technical issues (including its use of single DES) which mean the existing solution is not fit-for-purpose. Viktor is probably better placed to elaborate on those. Either we should invest in the effort to bring it up to a suitable standard or we get rid of it. Given that (I believe) very few people are using it, it seems more sensible to get rid of it. Part of the purpose of my email was to gauge whether I was right that very few people are using it. Matt From uri at ll.mit.edu Tue May 5 13:10:04 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Tue, 5 May 2015 13:10:04 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <5548BDED.1060008@openssl.org> Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC271A8AD1@LLE2K10-MBX01.mitll.ad.local> I'm hesitant to remove this capability altogether, but your argument is convincing. In view of the progress recently made in the quantum computing field, I think it would be nice to strengthen symmetric crypto capabilities (such as Kerberos), but that implies a lot of work (which I'm not volunteering for :). Between a rock and a hard place. :-) ----- Original Message ----- From: Matt Caswell [mailto:matt at openssl.org] Sent: Tuesday, May 05, 2015 08:56 AM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Kerberos On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote: > What are the problems? The code as it exists today is not compiled by default. I recently fixed a set of issues in master that had not been spotted simply because the code is not regularly compiled and used. One possible solution to that is to turn it on by default...but I think that is worse since it unnecessarily increases the attack surface for those that don't use it (the vast majority). As it turns out the "--with-krb5-include" Configure option has not been working correctly in 1.0.2 since it was released...but no-one noticed. Due to the infrequency with which it is being used in practice this means that the code is not being kept up to date. There are some technical issues (including its use of single DES) which mean the existing solution is not fit-for-purpose. Viktor is probably better placed to elaborate on those. Either we should invest in the effort to bring it up to a suitable standard or we get rid of it. Given that (I believe) very few people are using it, it seems more sensible to get rid of it. Part of the purpose of my email was to gauge whether I was right that very few people are using it. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From support at securenetterm.com Tue May 5 13:22:41 2015 From: support at securenetterm.com (Technical Support) Date: Tue, 5 May 2015 13:22:41 +0000 (UTC) Subject: [openssl-dev] Kerberos In-Reply-To: <5548BDED.1060008@openssl.org> References: <5548BDED.1060008@openssl.org> Message-ID: <52423166.346326.1430832161158.JavaMail.yahoo@mail.yahoo.com> Perhaps people use the --with-krb5-flavor=MIT config?which is what we do, and we use itin all the time?in?1.0.2. Ken InterSoft International, Inc.Phone: 888-823-1541Fax: 866-701-1260http://www.netterm.comhttp://www.securenetterm.com From: Matt Caswell To: openssl-dev at openssl.org Sent: Tuesday, May 5, 2015 7:56 AM Subject: Re: [openssl-dev] Kerberos On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote: > What are the problems? The code as it exists today is not compiled by default. I recently fixed a set of issues in master that had not been spotted simply because the code is not regularly compiled and used. One possible solution to that is to turn it on by default...but I think that is worse since it unnecessarily increases the attack surface for those that don't use it (the vast majority). As it turns out the "--with-krb5-include" Configure option has not been working correctly in 1.0.2 since it was released...but no-one noticed. Due to the infrequency with which it is being used in practice this means that the code is not being kept up to date. There are some technical issues (including its use of single DES) which mean the existing solution is not fit-for-purpose. Viktor is probably better placed to elaborate on those. Either we should invest in the effort to bring it up to a suitable standard or we get rid of it. Given that (I believe) very few people are using it, it seems more sensible to get rid of it. Part of the purpose of my email was to gauge whether I was right that very few people are using it. Matt _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmraz at redhat.com Tue May 5 13:33:46 2015 From: tmraz at redhat.com (Tomas Mraz) Date: Tue, 05 May 2015 15:33:46 +0200 Subject: [openssl-dev] Kerberos In-Reply-To: <52423166.346326.1430832161158.JavaMail.yahoo@mail.yahoo.com> References: <5548BDED.1060008@openssl.org> <52423166.346326.1430832161158.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1430832826.12684.4.camel@redhat.com> On ?t, 2015-05-05 at 13:22 +0000, Technical Support wrote: > Perhaps people use the --with-krb5-flavor=MIT config which is what we do, and we use itin all the time in 1.0.2. > Ken > From: Matt Caswell > To: openssl-dev at openssl.org > Sent: Tuesday, May 5, 2015 7:56 AM > Subject: Re: [openssl-dev] Kerberos > > > > On 05/05/15 13:22, Blumenthal, Uri - 0553 - MITLL wrote: > > What are the problems? > > The code as it exists today is not compiled by default. I recently fixed > a set of issues in master that had not been spotted simply because the > code is not regularly compiled and used. One possible solution to that > is to turn it on by default...but I think that is worse since it > unnecessarily increases the attack surface for those that don't use it > (the vast majority). As it turns out the "--with-krb5-include" Configure > option has not been working correctly in 1.0.2 since it was > released...but no-one noticed. > > Due to the infrequency with which it is being used in practice this > means that the code is not being kept up to date. There are some > technical issues (including its use of single DES) which mean the > existing solution is not fit-for-purpose. Viktor is probably better > placed to elaborate on those. Fedora and Red Hat Enterprise Linux openssl packages have the KRB5 support compiled in. I believe there are some customers that still use it on older RHEL releases. On the other hand the current set of supported ciphers does not make it useful for future use anymore so I do not care much if it is removed from openssl master branch. If you properly announce that the support will be removed unless anybody provides patch adding support for current secure KRB5 algorithms, I am OK with that. Regards, -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb (You'll never know whether the road is wrong though.) From rt at openssl.org Tue May 5 20:01:04 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 5 May 2015 22:01:04 +0200 Subject: [openssl-dev] [openssl.org #2943] Bug Report: openssl enc -bf silently ignores key data after the first 128 bits In-Reply-To: <50CA4279.2080007@brendanlong.com> References: <50CA4279.2080007@brendanlong.com> Message-ID: This had a long time coming. The issues at hand was really that the buffer for the key buffer was EVP_MAX_KEY_LENGTH (which is 64, which is 128 hex characters) and that was the size that the input was checked against, not the actual key length of the cipher that's used. This is now fixed: in master (8920a7cd04f43b1a090d0b0a8c9e16b94c6898d4) in the 1.0.2 branch (3cf40601b7d164ab48addbb0456d7aa59fa38c88) in the 1.0.2 branch (4b771121f2b657f50e8c7a27e9fab0bb043f91bc) Incidently, I fixed the exact same issue with the IV length while I was at it. On Sun Dec 23 14:08:40 2012, self at brendanlong.com wrote: > If I do an openssl enc -bf with a > 128 bit key it just silently > ignores > everything over 128 bits: > > ng at ubuntu:~$ openssl enc -bf -iv 0 -P -K > > 000000000000000000000000000000012345 > > salt=0700000000000000 > > key=00000000000000000000000000000001 > > iv =0000000000000000 > If you go over 128 characters you get an error: > > blong at ubuntu:~/workspace/webkit$ openssl enc -bf -iv 0 -P -K > > > 00000000000000000000000000000001234500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > salt=0700000000000000 > > key=00000000000000000000000000000001 > > iv =0000000000000000 > > blong at ubuntu:~/workspace/webkit$ openssl enc -bf -iv 0 -P -K > > > 000000000000000000000000000000012345000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000 > > hex string is too long > > invalid hex key value > I'm guessing this is a unit mix-up, where it should be complaining > with > > 128 /bits/, but instead it complains at > 128 /characters/. -- Richard Levitte levitte at openssl.org From openssl-users at dukhovni.org Wed May 6 05:19:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 May 2015 05:19:06 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <5548BDED.1060008@openssl.org> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271A89D5@LLE2K10-MBX01.mitll.ad.local> <5548BDED.1060008@openssl.org> Message-ID: <20150506051906.GT17272@mournblade.imrryr.org> On Tue, May 05, 2015 at 01:56:13PM +0100, Matt Caswell wrote: > Due to the infrequency with which it is being used in practice this > means that the code is not being kept up to date. There are some > technical issues (including its use of single DES) which mean the > existing solution is not fit-for-purpose. Viktor is probably better > placed to elaborate on those. A better way to combine TLS with Kerberos, albeit with extra round-trips for initial session establishment, is to use anon-DH (ADH or AECDH) to establish a TLS session, and GSSAPI with channel-binding for mutual authentication. If one then stores GSSAPI authentication results along with TLS session state, resumed connections suffer no extra latency. GSSAPI has a well-defined API, and does not require extra TLS ciphersuites, Direct use of Kerberos makes the TLS library depend on the choice of Kerberos run-time (MIT vs. Heimdal) complicating package management. Also TLS Kerberos ciphersuites are defined only for obsolete ciphers (DES, 3DES, RC4 and IDEA). I don't see any likelihood of more modern KRB5 ciphersuites being added in the future. There are also TLS API difficulties, because it is not easy to configure the server principal name, handle different Kerberos name types, obtain the client principal name on the server side, ... There is little point in any case in doing TLS with Kerberos, it is not widely supported, it makes more sense to use GSSAPI with wrap/unwrap, or Roland Dowdeswell's libknc, that presents a Kerberos authenticated stream abstraction much more cleanly than Kerberos inside TLS. https://github.com/elric1/knc -- Viktor. From rt at openssl.org Wed May 6 05:52:45 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Wed, 6 May 2015 07:52:45 +0200 Subject: [openssl-dev] [openssl.org #3835] [PATCH] Initialize potentially uninitialized local variables In-Reply-To: References: Message-ID: Hello, Fix all the instances of MSVC warning C4701 (potentially uninitialized local variable 'name' used). This warning pretty much means that there's a code path which results in uninitialized variables being used or returned. Thank you, Gunnar Kudrjavets -------------- next part -------------- >From 3f65a16efe0b78f7c994b0317c7ef0eec2d1133b Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Mon, 4 May 2015 11:10:10 -0700 Subject: [PATCH] Initialize potentially uninitialized local variables Compiling OpenSSL code with MSVC and /W4 results in a number of warnings. One category of warnings is particularly interesting - C4701 (potentially uninitialized local variable 'name' used). This warning pretty much means that there's a code path which results in uninitialized variables being used or returned. Depending on compiler, its options, OS, values in registers and/or stack, the results can be nondeterministic. Cases like this are very hard to debug so it's rational to fix these issues. This patch contains a set of trivial fixes for all the C4701 warnings (just initializing variables to 0 or NULL or appropriate error code) to make sure that deterministic values will be returned from all the execution paths. --- apps/apps.c | 2 +- apps/dsaparam.c | 2 +- apps/s_server.c | 2 +- crypto/asn1/asn1_gen.c | 2 +- crypto/asn1/tasn_dec.c | 2 +- crypto/evp/m_sigver.c | 10 +++++----- crypto/evp/p_sign.c | 6 +++--- crypto/evp/p_verify.c | 6 +++--- crypto/pem/pem_lib.c | 2 +- crypto/x509/x509_vfy.c | 8 ++++---- crypto/x509v3/v3_addr.c | 2 +- crypto/x509v3/v3_asid.c | 2 +- crypto/x509v3/v3_conf.c | 2 +- ssl/t1_lib.c | 2 +- test/evp_test.c | 8 ++++---- 15 files changed, 29 insertions(+), 29 deletions(-) diff --git a/apps/apps.c b/apps/apps.c index 797e250..4ee8093 100644 --- a/apps/apps.c +++ b/apps/apps.c @@ -175,7 +175,7 @@ int app_init(long mesgwin); int chopup_args(ARGS *arg, char *buf) { int quoted; - char c, *p; + char c = '\0', *p = NULL; arg->argc = 0; if (arg->size == 0) { diff --git a/apps/dsaparam.c b/apps/dsaparam.c index 62d5fe7..cf29b80 100644 --- a/apps/dsaparam.c +++ b/apps/dsaparam.c @@ -117,7 +117,7 @@ int dsaparam_main(int argc, char **argv) DSA *dsa = NULL; BIO *in = NULL, *out = NULL; BN_GENCB *cb = NULL; - int numbits = -1, num, genkey = 0, need_rand = 0, non_fips_allow = 0; + int numbits = -1, num = 0, genkey = 0, need_rand = 0, non_fips_allow = 0; int informat = FORMAT_PEM, outformat = FORMAT_PEM, noout = 0, C = 0, ret = 1; int i, text = 0; diff --git a/apps/s_server.c b/apps/s_server.c index c1b799f..2d9e96b 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -631,7 +631,7 @@ static tlsextstatusctx tlscstatp = { NULL, NULL, NULL, 0, -1, 0 }; static int cert_status_cb(SSL *s, void *arg) { tlsextstatusctx *srctx = arg; - char *host, *port, *path; + char *host = NULL, *port = NULL, *path = NULL; int use_ssl; unsigned char *rspder = NULL; int rspderlen; diff --git a/crypto/asn1/asn1_gen.c b/crypto/asn1/asn1_gen.c index 049515d..ab82b52 100644 --- a/crypto/asn1/asn1_gen.c +++ b/crypto/asn1/asn1_gen.c @@ -159,7 +159,7 @@ static ASN1_TYPE *generate_v3(char *str, X509V3_CTX *cnf, int depth, unsigned char *p; const unsigned char *cp; int cpy_len; - long hdr_len; + long hdr_len = 0; int hdr_constructed = 0, hdr_tag, hdr_class; int r; diff --git a/crypto/asn1/tasn_dec.c b/crypto/asn1/tasn_dec.c index c5caff7..7a6414a 100644 --- a/crypto/asn1/tasn_dec.c +++ b/crypto/asn1/tasn_dec.c @@ -645,7 +645,7 @@ static int asn1_d2i_ex_primitive(ASN1_VALUE **pval, long plen; char cst, inf, free_cont = 0; const unsigned char *p; - BUF_MEM buf; + BUF_MEM buf = { 0 }; const unsigned char *cont = NULL; long len; if (!pval) { diff --git a/crypto/evp/m_sigver.c b/crypto/evp/m_sigver.c index 65a49ad..288c563 100644 --- a/crypto/evp/m_sigver.c +++ b/crypto/evp/m_sigver.c @@ -128,7 +128,7 @@ int EVP_DigestVerifyInit(EVP_MD_CTX *ctx, EVP_PKEY_CTX **pctx, int EVP_DigestSignFinal(EVP_MD_CTX *ctx, unsigned char *sigret, size_t *siglen) { - int sctx, r = 0; + int sctx = 0, r = 0; EVP_PKEY_CTX *pctx = ctx->pctx; if (pctx->pmeth->flags & EVP_PKEY_FLAG_SIGCTX_CUSTOM) { if (!sigret) @@ -150,7 +150,7 @@ int EVP_DigestSignFinal(EVP_MD_CTX *ctx, unsigned char *sigret, sctx = 0; if (sigret) { unsigned char md[EVP_MAX_MD_SIZE]; - unsigned int mdlen; + unsigned int mdlen = 0; if (ctx->flags & EVP_MD_CTX_FLAG_FINALISE) { if (sctx) r = ctx->pctx->pmeth->signctx(ctx->pctx, sigret, siglen, ctx); @@ -189,9 +189,9 @@ int EVP_DigestVerifyFinal(EVP_MD_CTX *ctx, const unsigned char *sig, size_t siglen) { unsigned char md[EVP_MAX_MD_SIZE]; - int r; - unsigned int mdlen; - int vctx; + int r = 0; + unsigned int mdlen = 0; + int vctx = 0; if (ctx->pctx->pmeth->verifyctx) vctx = 1; diff --git a/crypto/evp/p_sign.c b/crypto/evp/p_sign.c index 541c6e7..07ae252 100644 --- a/crypto/evp/p_sign.c +++ b/crypto/evp/p_sign.c @@ -66,8 +66,8 @@ int EVP_SignFinal(EVP_MD_CTX *ctx, unsigned char *sigret, unsigned int *siglen, EVP_PKEY *pkey) { unsigned char m[EVP_MAX_MD_SIZE]; - unsigned int m_len; - int i = 0, ok = 0, v; + unsigned int m_len = 0; + int i = 0, ok = 0, v = 0; EVP_PKEY_CTX *pkctx = NULL; *siglen = 0; @@ -75,7 +75,7 @@ int EVP_SignFinal(EVP_MD_CTX *ctx, unsigned char *sigret, if (!EVP_DigestFinal_ex(ctx, m, &m_len)) goto err; } else { - int rv; + int rv = 0; EVP_MD_CTX tmp_ctx; EVP_MD_CTX_init(&tmp_ctx); rv = EVP_MD_CTX_copy_ex(&tmp_ctx, ctx); diff --git a/crypto/evp/p_verify.c b/crypto/evp/p_verify.c index 3242931..2277a91 100644 --- a/crypto/evp/p_verify.c +++ b/crypto/evp/p_verify.c @@ -66,15 +66,15 @@ int EVP_VerifyFinal(EVP_MD_CTX *ctx, const unsigned char *sigbuf, unsigned int siglen, EVP_PKEY *pkey) { unsigned char m[EVP_MAX_MD_SIZE]; - unsigned int m_len; - int i = 0, ok = 0, v; + unsigned int m_len = 0; + int i = 0, ok = 0, v = 0; EVP_PKEY_CTX *pkctx = NULL; if (ctx->flags & EVP_MD_CTX_FLAG_FINALISE) { if (!EVP_DigestFinal_ex(ctx, m, &m_len)) goto err; } else { - int rv; + int rv = 0; EVP_MD_CTX tmp_ctx; EVP_MD_CTX_init(&tmp_ctx); rv = EVP_MD_CTX_copy_ex(&tmp_ctx, ctx); diff --git a/crypto/pem/pem_lib.c b/crypto/pem/pem_lib.c index 143d001..bb3b31e 100644 --- a/crypto/pem/pem_lib.c +++ b/crypto/pem/pem_lib.c @@ -339,7 +339,7 @@ int PEM_ASN1_write_bio(i2d_of_void *i2d, const char *name, BIO *bp, int klen, pem_password_cb *callback, void *u) { EVP_CIPHER_CTX ctx; - int dsize = 0, i, j, ret = 0; + int dsize = 0, i = 0, j = 0, ret = 0; unsigned char *p, *data = NULL; const char *objstr = NULL; char buf[PEM_BUFSIZE]; diff --git a/crypto/x509/x509_vfy.c b/crypto/x509/x509_vfy.c index 8c0680b..aa0bf74 100644 --- a/crypto/x509/x509_vfy.c +++ b/crypto/x509/x509_vfy.c @@ -842,7 +842,7 @@ static int check_trust(X509_STORE_CTX *ctx) static int check_revocation(X509_STORE_CTX *ctx) { - int i, last, ok; + int i = 0, last = 0, ok = 0; if (!(ctx->param->flags & X509_V_FLAG_CRL_CHECK)) return 1; if (ctx->param->flags & X509_V_FLAG_CRL_CHECK_ALL) @@ -865,9 +865,9 @@ static int check_revocation(X509_STORE_CTX *ctx) static int check_cert(X509_STORE_CTX *ctx) { X509_CRL *crl = NULL, *dcrl = NULL; - X509 *x; - int ok, cnum; - unsigned int last_reasons; + X509 *x = NULL; + int ok = 0, cnum = 0; + unsigned int last_reasons = 0; cnum = ctx->error_depth; x = sk_X509_value(ctx->chain, cnum); ctx->current_cert = x; diff --git a/crypto/x509v3/v3_addr.c b/crypto/x509v3/v3_addr.c index fecf765..cdc1346 100644 --- a/crypto/x509v3/v3_addr.c +++ b/crypto/x509v3/v3_addr.c @@ -945,7 +945,7 @@ static void *v2i_IPAddrBlocks(const struct v3_ext_method *method, CONF_VALUE *val = sk_CONF_VALUE_value(values, i); unsigned char min[ADDR_RAW_BUF_LEN], max[ADDR_RAW_BUF_LEN]; unsigned afi, *safi = NULL, safi_; - const char *addr_chars; + const char *addr_chars = NULL; int prefixlen, i1, i2, delim, length; if (!name_cmp(val->name, "IPv4")) { diff --git a/crypto/x509v3/v3_asid.c b/crypto/x509v3/v3_asid.c index d7f5848..26ca158 100644 --- a/crypto/x509v3/v3_asid.c +++ b/crypto/x509v3/v3_asid.c @@ -553,7 +553,7 @@ static void *v2i_ASIdentifiers(const struct v3_ext_method *method, for (i = 0; i < sk_CONF_VALUE_num(values); i++) { CONF_VALUE *val = sk_CONF_VALUE_value(values, i); - int i1, i2, i3, is_range, which; + int i1 = 0, i2 = 0, i3 = 0, is_range = 0, which = 0; /* * Figure out whether this is an AS or an RDI. diff --git a/crypto/x509v3/v3_conf.c b/crypto/x509v3/v3_conf.c index 0997d59..bb1146e 100644 --- a/crypto/x509v3/v3_conf.c +++ b/crypto/x509v3/v3_conf.c @@ -267,7 +267,7 @@ static X509_EXTENSION *v3_generic_extension(const char *ext, char *value, X509V3_CTX *ctx) { unsigned char *ext_der = NULL; - long ext_len; + long ext_len = 0; ASN1_OBJECT *obj = NULL; ASN1_OCTET_STRING *oct = NULL; X509_EXTENSION *extension = NULL; diff --git a/ssl/t1_lib.c b/ssl/t1_lib.c index 7af9c7e..9068195 100644 --- a/ssl/t1_lib.c +++ b/ssl/t1_lib.c @@ -2720,7 +2720,7 @@ int tls1_set_server_sigalgs(SSL *s) int ssl_check_clienthello_tlsext_late(SSL *s) { int ret = SSL_TLSEXT_ERR_OK; - int al; + int al = SSL_AD_INTERNAL_ERROR; /* * If status request then ask callback what to do. Note: this must be diff --git a/test/evp_test.c b/test/evp_test.c index 0bba274..51fc6af 100644 --- a/test/evp_test.c +++ b/test/evp_test.c @@ -361,12 +361,12 @@ static int check_unsupported() static int process_test(struct evp_test *t, char *buf, int verbose) { - char *keyword, *value; + char *keyword = NULL, *value = NULL; int rv = 0, add_key = 0; - long save_pos; - struct key_list **lst, *key; + long save_pos = 0; + struct key_list **lst = NULL, *key = NULL; EVP_PKEY *pk = NULL; - const struct evp_test_method *tmeth; + const struct evp_test_method *tmeth = NULL; if (verbose) fputs(buf, stdout); if (!parse_line(&keyword, &value, buf)) -- 1.9.5.msysgit.1 From rt at openssl.org Wed May 6 12:11:19 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 14:11:19 +0200 Subject: [openssl-dev] [openssl.org #3835] [PATCH] Initialize potentially uninitialized local variables In-Reply-To: References: Message-ID: Patch applied. Thanks. Note that actually all of these are bogus warnings. In none of the instances fixed was there an actual code path which resulted in an uninitialised variable being used - it's just that the compiler was unable to figure that out and so issues spurious warnings. Matt From rt at openssl.org Wed May 6 12:45:14 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 14:45:14 +0200 Subject: [openssl-dev] [openssl.org #1709] DTLS BUG: retransmition of handshake messages does not work In-Reply-To: <7A096C5427094432A0FDBD3D85DD0A60@mycomp> References: <7A096C5427094432A0FDBD3D85DD0A60@mycomp> Message-ID: I don't believe this is the case any more. Closing this ticket. Matt From rt at openssl.org Wed May 6 12:47:44 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 14:47:44 +0200 Subject: [openssl-dev] [openssl.org #3109] [openssl.org #3041[PATCH] DTLS message_sequence number wrong in rehandshake ServerHello In-Reply-To: References: Message-ID: This ticket was opened in error. Closing. Matt From rt at openssl.org Wed May 6 13:00:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 15:00:05 +0200 Subject: [openssl-dev] [openssl.org #3041] [Bug] DTLS message_sequence number wrong in rehandshake ServerHello In-Reply-To: <1241527068.602925.1367670791257.JavaMail.root@tpip.net> References: <198952679.602903.1367670658909.JavaMail.root@tpip.net> <1241527068.602925.1367670791257.JavaMail.root@tpip.net> Message-ID: Looks like this patch was applied some time ago in commit 83a3af9f4e61170afad6f79f161fad8245ae1f95. Closing this ticket. Matt From rt at openssl.org Wed May 6 13:04:47 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 15:04:47 +0200 Subject: [openssl-dev] [openssl.org #3487] Possible Bug: Crash in dtls1_do_write In-Reply-To: References: Message-ID: Not enough information in this ticket to track down the problem. I'm assuming that by now you've resolved this issue. If not please send further details to the openssl-users mailing list. Closing this ticket. Matt From rt at openssl.org Wed May 6 13:09:38 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 6 May 2015 15:09:38 +0200 Subject: [openssl-dev] [openssl.org #3008] Possible bug when using DTLS with a BIO pair In-Reply-To: <513675C8.7010500@dell.com> References: <513675C8.7010500@dell.com> Message-ID: The MTU logic has been extensively revised since this ticket was raised so I am assuming this is no longer an issue. If that's not the case please reopen this ticket. Closing. Matt From rt at openssl.org Wed May 6 14:32:19 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Wed, 6 May 2015 16:32:19 +0200 Subject: [openssl-dev] [openssl.org #3836] DOCUMENTATION: missing documentation for SSL_get_certificate In-Reply-To: References: Message-ID: The ECDH callback needs to query the server's certificate to discover the EC group being used. The callback can then return a temporary key in the field. It looks like SSL_get_certificate can be used for the purpose. SSL_get_certificate is used in apps/s_cb.c, but there's no documentation for it. Documentation for the function would probably be a good thing. The docs should state whether the X509* is referenced counted and must be freed (likely so if its similar to SSL_get_peer_certificate). And an example of using it in the ECDH callback would probably be helpful to those using it. From rt at openssl.org Wed May 6 15:58:31 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 6 May 2015 17:58:31 +0200 Subject: [openssl-dev] [openssl.org #3837] Bug in SSL_CTX_check_private_key? In-Reply-To: References: Message-ID: Hello Openssl team, It seems to me there is a bug in the SSL_CTX_check_private_key function. The function ignores RSA_METHOD_FLAG_NO_CHECK flag and always tries to check public/private key match. The only place in real code where this function is used is in the set_cert_key_stuff function, just after the calls to SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey, which carefully process the flag. I would like to suggest a small patch providing the necessary check for RSA_METHOD_FLAG_NO_CHECK here. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl.patch Type: application/octet-stream Size: 572 bytes Desc: not available URL: From openssl-users at dukhovni.org Wed May 6 16:10:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 May 2015 16:10:49 +0000 Subject: [openssl-dev] [openssl.org #3837] Bug in SSL_CTX_check_private_key? In-Reply-To: References: Message-ID: <20150506161049.GZ17272@mournblade.imrryr.org> On Wed, May 06, 2015 at 05:58:31PM +0200, Dmitry Belyavsky via RT wrote: > It seems to me there is a bug in the SSL_CTX_check_private_key function. > > The function ignores RSA_METHOD_FLAG_NO_CHECK flag and always tries to > check public/private key match. I think that's deliberate and correct. When an application calls SSL_CTX_check_private_key(), the key should be checked. Nothing in libssl calls this function, it is provided to applications that want to explicitly check the key. The fact that this flag is algorithm specific is also odd, if it is useful for RSA, it should be useful for ECDSA, etc. It seems rather an odd feature. > The only place in real code where this function is used is in > the set_cert_key_stuff function, just after the calls > to SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey, which carefully > process the flag. That's application code (for openssl(1)). > I would like to suggest a small patch providing the necessary check for > RSA_METHOD_FLAG_NO_CHECK here. I am not convinced this change is correct. The function would then not do what it is supposed to do. The flag suppresses implicit checks only, but suppressing explicit checks seems unexpected. -- Viktor. From beldmit at gmail.com Wed May 6 17:33:37 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 6 May 2015 20:33:37 +0300 Subject: [openssl-dev] [openssl.org #3837] Bug in SSL_CTX_check_private_key? In-Reply-To: <20150506161049.GZ17272@mournblade.imrryr.org> References: <20150506161049.GZ17272@mournblade.imrryr.org> Message-ID: Hello Victor, On Wed, May 6, 2015 at 7:10 PM, Viktor Dukhovni wrote: > On Wed, May 06, 2015 at 05:58:31PM +0200, Dmitry Belyavsky via RT wrote: > > > It seems to me there is a bug in the SSL_CTX_check_private_key function. > > > > The function ignores RSA_METHOD_FLAG_NO_CHECK flag and always tries to > > check public/private key match. > > I think that's deliberate and correct. When an application calls > SSL_CTX_check_private_key(), the key should be checked. Nothing > in libssl calls this function, it is provided to applications that > want to explicitly check the key. > > The fact that this flag is algorithm specific is also odd, if it > is useful for RSA, it should be useful for ECDSA, etc. It seems > rather an odd feature. > I agree that the flag is useful for ECDSA too. AFAIK, BoringSSL has already implemented this feature as unversal. > > The only place in real code where this function is used is in > > the set_cert_key_stuff function, just after the calls > > to SSL_CTX_use_certificate and SSL_CTX_use_PrivateKey, which carefully > > process the flag. > > That's application code (for openssl(1)). > Yes. > > > I would like to suggest a small patch providing the necessary check for > > RSA_METHOD_FLAG_NO_CHECK here. > > I am not convinced this change is correct. The function would then > not do what it is supposed to do. The flag suppresses implicit > checks only, but suppressing explicit checks seems unexpected. > Well, but what is the correct way to provide, for example, HSM key if we have to check match without access to a private key? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed May 6 18:17:40 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 6 May 2015 18:17:40 +0000 Subject: [openssl-dev] [openssl.org #3837] Bug in SSL_CTX_check_private_key? In-Reply-To: References: <20150506161049.GZ17272@mournblade.imrryr.org> Message-ID: <20150506181740.GB17272@mournblade.imrryr.org> On Wed, May 06, 2015 at 08:33:37PM +0300, Dmitry Belyavsky wrote: > > > I would like to suggest a small patch providing the necessary check for > > > RSA_METHOD_FLAG_NO_CHECK here. > > > > I am not convinced this change is correct. The function would then > > not do what it is supposed to do. The flag suppresses implicit > > checks only, but suppressing explicit checks seems unexpected. > > > > Well, but what is the correct way to provide, for example, HSM key if we > have to check match without access to a private key? Well, one might argue that the checking function should support performing the check via engines. Or that explicit checks should not be called when you don't want to check. Perhaps openssl(1) should have a command-line option to suppress the explicit check. I'd still be surprised if calling the explicit check did nothing. However, I might not know enough of the history/intent. Perhaps someone will comment... -- Viktor. From beldmit at gmail.com Wed May 6 21:09:52 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 7 May 2015 00:09:52 +0300 Subject: [openssl-dev] Bug in SSL_CTX_check_private_key? In-Reply-To: <20150506181740.GB17272@mournblade.imrryr.org> References: <20150506161049.GZ17272@mournblade.imrryr.org> <20150506181740.GB17272@mournblade.imrryr.org> Message-ID: Hello Viktor, On Wednesday, May 6, 2015, Viktor Dukhovni wrote: > On Wed, May 06, 2015 at 08:33:37PM +0300, Dmitry Belyavsky wrote: > > > > > I would like to suggest a small patch providing the necessary check > for > > > > RSA_METHOD_FLAG_NO_CHECK here. > > > > > > I am not convinced this change is correct. The function would then > > > not do what it is supposed to do. The flag suppresses implicit > > > checks only, but suppressing explicit checks seems unexpected. > > > > > > > Well, but what is the correct way to provide, for example, HSM key if we > > have to check match without access to a private key? > > Well, one might argue that the checking function should support > performing the check via engines. Or that explicit checks should > not be called when you don't want to check. Perhaps openssl(1) > should have a command-line option to suppress the explicit check. > > I'd still be surprised if calling the explicit check did nothing. > However, I might not know enough of the history/intent. Perhaps > someone will comment... > > https://www.mail-archive.com/openssl-dev at openssl.org/msg04370.html - a very old thread concerning using smartcards with OpenSSL. http://code.google.com/p/chromium/issues/detail?id=395279 - the solution selected in BoringSSL. -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu May 7 07:00:17 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 7 May 2015 07:00:17 +0000 Subject: [openssl-dev] [TLS] Update spec to match current practices for certificate chain order In-Reply-To: <55487D88.7010909@openssl.org> <201505062313.06092.davemgarrett@gmail.com> <02805C01-924F-4B21-B61F-21414D4CE20D@gmail.com> Message-ID: <20150507070017.GI17272@mournblade.imrryr.org> On Thu, May 07, 2015 at 08:49:21AM +0300, Yoav Nir wrote: > > I think there was also discussion on this list at some point suggesting > > changing that "MAY" for omitting the root CA cert to a "SHOULD" or a > > "MUST". (I think the argument for the latter was to reduce wasted bandwidth) Sorry, this is incompatible with use of DANE TLSA records when the ceritificate usage is DANE-TA(2). See: https://tools.ietf.org/html/draft-ietf-dane-smtp-with-dane-16#section-3.1.2 https://tools.ietf.org/html/draft-ietf-dane-ops-07#section-5.2 The first of these is currently in IETF LC, the second in DANE WG LC. > SHOULD is OK, MUST would imply perfect knowledge of how the other side is > configured. As you note, there is more than one way to verify certificates, and the server cannot know exactly which certificates are needed by the client. A SHOULD or MUST would be counter-productive. > The root of trust may or may not be the self-signed certificate. > But it?s probably always fine to omit the self-signed certificate. No, not always. > > Any reason this would be problematic? It'd be a simple change to add > > for the TLS 1.3 spec that would align things better with real-world usage. > > None that I can think of You won't be able to say that next time. :-) -- Viktor. From rt at openssl.org Thu May 7 10:46:48 2015 From: rt at openssl.org (Tim Zhang via RT) Date: Thu, 7 May 2015 12:46:48 +0200 Subject: [openssl-dev] [openssl.org #3838] [PATCH] Fix the comment for POINT_CONVERSION_UNCOMPRESSED, the z should be 0x04 but not 0x02. In-Reply-To: References: Message-ID: Fix the comment for POINT_CONVERSION_UNCOMPRESSED, the z should be 0x04 but not 0x02. $ more mydiffs.patch diff -ur openssl-orig/include/openssl/ec.h openssl-work/include/openssl/ec.h --- openssl-orig/include/openssl/ec.h 2015-05-07 11:37:05.594525940 +0800 +++ openssl-work/include/openssl/ec.h 2015-05-07 11:51:49.680806044 +0800 @@ -106,7 +106,7 @@ /** the point is encoded as z||x, where the octet z specifies * which solution of the quadratic equation y is */ POINT_CONVERSION_COMPRESSED = 2, - /** the point is encoded as z||x||y, where z is the octet 0x02 */ + /** the point is encoded as z||x||y, where z is the octet 0x04 */ POINT_CONVERSION_UNCOMPRESSED = 4, /** the point is encoded as z||x||y, where the octet z specifies * which solution of the quadratic equation y is */ Tim Zhang (???) Senior System Architect, Beijing t: +86 10 85304280 Irdeto Please visit: www.irdeto.com CONFIDENTIAL: This e-mail and any attachments are confidential and intended solely for the use of the individual(s) to whom it is addressed. It can contain proprietary confidential information and be subject to legal privilege and/or subject to a non-disclosure Agreement. Unauthorized use, disclosure or copying is strictly prohibited. If you are not the/an addressee and are in possession of this e-mail, please delete the message and notify us immediately. Please consider the environment before printing this e-mail. Thank you. From rt at openssl.org Thu May 7 12:37:36 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 14:37:36 +0200 Subject: [openssl-dev] [openssl.org #1715] DTLS: Finished message is not buffered for retransmition In-Reply-To: <764F618DAEDD4EB0A2C875EABB0B05CA@mycomp> References: <764F618DAEDD4EB0A2C875EABB0B05CA@mycomp> Message-ID: Don't know when this was fixed - but this is no longer the case. Closing this ticket. Matt From rt at openssl.org Thu May 7 12:39:10 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 14:39:10 +0200 Subject: [openssl-dev] [openssl.org #2662] NPN patch breaks DTLS Finished exchange In-Reply-To: References: Message-ID: Don't know when this was fixed but this is no longer the case. Closing ticket. Matt From rt at openssl.org Thu May 7 12:54:00 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 14:54:00 +0200 Subject: [openssl-dev] [openssl.org #2539] bug: OpenSSL 1.0.0d - unexpected DTLS handshake retransmits In-Reply-To: <647652.95059.qm@web113618.mail.gq1.yahoo.com> References: <647652.95059.qm@web113618.mail.gq1.yahoo.com> Message-ID: I am unable to read the attached pcap for some reason. However the suggested patch does not look correct to me. The timer should be started at this point in order to retransmit the Client's Finished message if required. Without access to the pcap there isn't enough information in this report for me to take it any further, therefore I am closing this ticket. I am assuming after all this time that this is no longer an issue, but if it is then please reopen. Matt From rt at openssl.org Thu May 7 12:56:03 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 14:56:03 +0200 Subject: [openssl-dev] [openssl.org #1711] DTLS: Handshake does not detect missing/incomplete records in flight. In-Reply-To: <8a668310807081009k7f09f43ci734666061d8dbdac@mail.gmail.com> References: <8a668310807081009k7f09f43ci734666061d8dbdac@mail.gmail.com> Message-ID: I don't believe this is an issue any more. Therefore I am closing this ticket. Matt From rt at openssl.org Thu May 7 13:02:45 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:02:45 +0200 Subject: [openssl-dev] [openssl.org #1714] DTLS: Memory leak when server receives close alert from unknown peer In-Reply-To: <0BC7658DFE6C49708E0387C30C5D02C9@mycomp> References: <0BC7658DFE6C49708E0387C30C5D02C9@mycomp> Message-ID: This was fixed some while ago. Closing ticket. Matt From rt at openssl.org Thu May 7 13:05:27 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:05:27 +0200 Subject: [openssl-dev] [openssl.org #1716] Bug report for DTLS In-Reply-To: References: Message-ID: I believe this was fixed some while ago. Closing this ticket. Matt From rt at openssl.org Thu May 7 13:07:49 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:07:49 +0200 Subject: [openssl-dev] [openssl.org #2484] [PATCH] DTLS: wrong fragment reassembly In-Reply-To: <000601cbf00c$4bdd9e00$e398da00$@com> References: <000601cbf00c$4bdd9e00$e398da00$@com> Message-ID: I don't believe this is a current issue. Please reopen if it is. Closing this ticket. Matt From rt at openssl.org Thu May 7 13:09:26 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:09:26 +0200 Subject: [openssl-dev] [openssl.org #2535] [PATCH] Add SCTP support for DTLS (RFC 6083) In-Reply-To: References: Message-ID: SCTP support was added, but this ticket doesn't seem to have been closed. Closing it now. Matt From rt at openssl.org Thu May 7 13:27:41 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:27:41 +0200 Subject: [openssl-dev] [openssl.org #2808] [PATCH] DTLS/SCTP Finished Auth Bug In-Reply-To: <1431DB6F-509C-4779-95D7-470EF6AB36F6@fh-muenster.de> References: <1431DB6F-509C-4779-95D7-470EF6AB36F6@fh-muenster.de> Message-ID: This patch already seems to have been applied. Closing this ticket. Matt From rt at openssl.org Thu May 7 13:30:58 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:30:58 +0200 Subject: [openssl-dev] [openssl.org #2809] [PATCH] DTLS/SCTP struct authchunks Bug In-Reply-To: <7459B7DE-3F3B-4775-9A65-DCB7A5E938A0@fh-muenster.de> References: <7459B7DE-3F3B-4775-9A65-DCB7A5E938A0@fh-muenster.de> Message-ID: This patch seems to have already been applied. Closing this ticket. Matt From rt at openssl.org Thu May 7 13:40:32 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:40:32 +0200 Subject: [openssl-dev] [openssl.org #2829] OpenSSL port in FreeBSD: DTLS networking problem In-Reply-To: <031222CBCF33214AB2EB4ABA279428A3011A2D0170B6@SJCPMAILBOX01.citrite.net> References: <031222CBCF33214AB2EB4ABA279428A3011A2D0170B6@SJCPMAILBOX01.citrite.net> Message-ID: I would be interested in seeing patches against master to provide this capability on platforms other than Linux. In particular Windows would be very useful. However, given the length of time this issue has been open, and the absence of a patch, I am closing this ticket for now. Matt From rt at openssl.org Thu May 7 13:43:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:43:05 +0200 Subject: [openssl-dev] [openssl.org #2869] [PATCH] DTLS Mobility support In-Reply-To: <361698F7-4D5D-4D07-90F5-90E06B1A99C1@fh-muenster.de> References: <361698F7-4D5D-4D07-90F5-90E06B1A99C1@fh-muenster.de> Message-ID: Thanks for your submission. In the absence of an RFC for this, we will not be applying this patch. Matt From rt at openssl.org Thu May 7 13:48:59 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 15:48:59 +0200 Subject: [openssl-dev] [openssl.org #2246] dtls1.h includes winsock.h, overriding the #undefs from ossl_typ.h on Windows In-Reply-To: <4BD55BCF.1090107@egenix.com> References: <4BD55BCF.1090107@egenix.com> Message-ID: I don't believe the specific compilation problems described are a current issue. dtls1.h does still include winsock.h as previously discussed on openssl-dev (re ticket 2187). This has been removed from the forthcoming OpenSSL 1.1.0. Closing this ticket. Matt From rt at openssl.org Thu May 7 14:21:17 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 16:21:17 +0200 Subject: [openssl-dev] [openssl.org #3662] [bug report]DTLS memory leak in dtls1_accept when use PSK in opensll 1.0.1j In-Reply-To: References: Message-ID: Please see: https://www.openssl.org/support/faq.html#PROG13 Also see RT ticket 3824. Closing this ticket as 3824 seems the better place to track this issue. Matt From rt at openssl.org Thu May 7 14:59:31 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Thu, 7 May 2015 16:59:31 +0200 Subject: [openssl-dev] [openssl.org #3711] [RFC PATCH] 1.0.2 regresssion: Wrong SSL version in DTLS_BAD_VER ClientHello In-Reply-To: <1424220216.24248.47.camel@infradead.org> References: <1424220216.24248.47.camel@infradead.org> Message-ID: Closing this ticket now. I've given some consideration to the proposal for a DTLSv0_9_client_method(). I think however that the audience for this is *very* limited...certainly no new applications should be using this. I am sincerely hoping that sooner or later the whole DTLS1_BAD_VER thing will disappear and it can be removed from the code completely. Given that we have a mechanism for supporting this through SSL_OP_CISCO_ANYCONNECT, I'm not convinced its a good thing to add a new API to support this dying version. Matt From rt at openssl.org Thu May 7 15:47:18 2015 From: rt at openssl.org (Michele Cicciotti via RT) Date: Thu, 7 May 2015 17:47:18 +0200 Subject: [openssl-dev] [openssl.org #3839] [BUG][PATCH] Compilation error when building with EVP_CHECK_DES_KEY In-Reply-To: <554B7198.4010505@privatewave.com> References: <554B7198.4010505@privatewave.com> Message-ID: A simple typo in des_ede_init_key. See the attached patch -------------- next part -------------- diff -r -u crypto/evp/e_des3.c crypto/evp/e_des3.c --- crypto/evp/e_des3.c 2015-03-19 14:30:36.000000000 +0100 +++ crypto/evp/e_des3.c 2015-05-07 16:05:04.000000000 +0200 @@ -289,7 +289,7 @@ # endif # ifdef EVP_CHECK_DES_KEY if (DES_set_key_checked(&deskey[0], &dat->ks1) - ! !DES_set_key_checked(&deskey[1], &dat->ks2)) + || DES_set_key_checked(&deskey[1], &dat->ks2)) return 0; # else DES_set_key_unchecked(&deskey[0], &dat->ks1); From rt at openssl.org Thu May 7 18:03:09 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 7 May 2015 20:03:09 +0200 Subject: [openssl-dev] [openssl.org #3829] Bug Report In-Reply-To: References: Message-ID: - Log ----------------------------------------------------------------- commit 8dfe1e4dd27c21a0ccebbb97d9b6a3612e8d54ef Author: Viktor Dukhovni Date: Thu May 7 13:43:36 2015 -0400 Fix typo in valid_star Reviewed-by: Rich Salz From rt at openssl.org Thu May 7 18:03:39 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 7 May 2015 20:03:39 +0200 Subject: [openssl-dev] [openssl.org #3829] Bug Report In-Reply-To: References: Message-ID: Fixed on both master and 1.0.2 the other commit: - Log ----------------------------------------------------------------- commit 8dfe1e4dd27c21a0ccebbb97d9b6a3612e8d54ef Author: Viktor Dukhovni Date: Thu May 7 13:43:36 2015 -0400 Fix typo in valid_star Reviewed-by: Rich Salz From rt at openssl.org Thu May 7 21:07:15 2015 From: rt at openssl.org (Kaarle Ritvanen via RT) Date: Thu, 7 May 2015 23:07:15 +0200 Subject: [openssl-dev] [openssl.org #3529] [PATCHv2] ASN1 generation: allow bit strings ending with zero regardless of length In-Reply-To: <1431032088-26032-1-git-send-email-kaarle.ritvanen@datakunkku.fi> References: <1431032088-26032-1-git-send-email-kaarle.ritvanen@datakunkku.fi> Message-ID: New version of the patch, rebased against the master branch. --- crypto/asn1/a_bitstr.c | 12 +++++------- crypto/asn1/asn1_gen.c | 15 ++++++++++++++- include/openssl/asn1.h | 1 + 3 files changed, 20 insertions(+), 8 deletions(-) diff --git a/crypto/asn1/a_bitstr.c b/crypto/asn1/a_bitstr.c index 60b6e6d..3d77e1a 100644 --- a/crypto/asn1/a_bitstr.c +++ b/crypto/asn1/a_bitstr.c @@ -187,11 +187,12 @@ ASN1_BIT_STRING *c2i_ASN1_BIT_STRING(ASN1_BIT_STRING **a, */ int ASN1_BIT_STRING_set_bit(ASN1_BIT_STRING *a, int n, int value) { - int w, v, iv; + int w, b, v, iv; unsigned char *c; w = n / 8; - v = 1 << (7 - (n & 0x07)); + b = 7 - (n & 0x07); + v = 1 << b; iv = ~v; if (!value) v = 0; @@ -199,11 +200,10 @@ int ASN1_BIT_STRING_set_bit(ASN1_BIT_STRING *a, int n, int value) if (a == NULL) return 0; - a->flags &= ~(ASN1_STRING_FLAG_BITS_LEFT | 0x07); /* clear, set on write */ + if (a->length <= (w + 1)) + a->flags = (a->flags & ~0x07) | ASN1_STRING_FLAG_BITS_LEFT | b; if ((a->length < (w + 1)) || (a->data == NULL)) { - if (!value) - return (1); /* Don't need to set */ c = OPENSSL_realloc_clean(a->data, a->length, w + 1); if (c == NULL) { ASN1err(ASN1_F_ASN1_BIT_STRING_SET_BIT, ERR_R_MALLOC_FAILURE); @@ -215,8 +215,6 @@ int ASN1_BIT_STRING_set_bit(ASN1_BIT_STRING *a, int n, int value) a->length = w + 1; } a->data[w] = ((a->data[w]) & iv) | v; - while ((a->length > 0) && (a->data[a->length - 1] == 0)) - a->length--; return (1); } diff --git a/crypto/asn1/asn1_gen.c b/crypto/asn1/asn1_gen.c index 84d85e6..107f715 100644 --- a/crypto/asn1/asn1_gen.c +++ b/crypto/asn1/asn1_gen.c @@ -87,6 +87,8 @@ #define ASN1_GEN_FORMAT_HEX 3 /* List of bits */ #define ASN1_GEN_FORMAT_BITLIST 4 +/* Binary */ +#define ASN1_GEN_FORMAT_BINARY 5 struct tag_name_st { const char *strnam; @@ -383,6 +385,8 @@ static int asn1_cb(const char *elem, int len, void *bitstr) arg->format = ASN1_GEN_FORMAT_HEX; else if (strncmp(vstart, "BITLIST", 7) == 0) arg->format = ASN1_GEN_FORMAT_BITLIST; + else if (!strncmp(vstart, "BINARY", 6)) + arg->format = ASN1_GEN_FORMAT_BINARY; else { ASN1err(ASN1_F_ASN1_CB, ASN1_R_UNKNOWN_FORMAT); return -1; @@ -638,6 +642,7 @@ static ASN1_TYPE *asn1_str2type(const char *str, int format, int utype) long rdlen; int no_unused = 1; + int i; if (!(atmp = ASN1_TYPE_new())) { ASN1err(ASN1_F_ASN1_STR2TYPE, ERR_R_MALLOC_FAILURE); @@ -772,7 +777,15 @@ static ASN1_TYPE *asn1_str2type(const char *str, int format, int utype) goto bad_str; } no_unused = 0; - + } else if ((format == ASN1_GEN_FORMAT_BINARY) && (utype == V_ASN1_BIT_STRING)) { + for (i = 0; str[i]; i++) { + if (str[i] != '0' && str[i] != '1') { + ASN1err(ASN1_F_ASN1_STR2TYPE, ASN1_R_ILLEGAL_BINARY); + goto bad_str; + } + ASN1_BIT_STRING_set_bit(atmp->value.bit_string, i, str[i] - '0'); + } + no_unused = 0; } else { ASN1err(ASN1_F_ASN1_STR2TYPE, ASN1_R_ILLEGAL_BITSTRING_FORMAT); goto bad_form; diff --git a/include/openssl/asn1.h b/include/openssl/asn1.h index b1bcef7..462f66b 100644 --- a/include/openssl/asn1.h +++ b/include/openssl/asn1.h @@ -1066,6 +1066,7 @@ void ERR_load_ASN1_strings(void); # define ASN1_R_FIELD_MISSING 121 # define ASN1_R_FIRST_NUM_TOO_LARGE 122 # define ASN1_R_HEADER_TOO_LONG 123 +# define ASN1_R_ILLEGAL_BINARY 224 # define ASN1_R_ILLEGAL_BITSTRING_FORMAT 175 # define ASN1_R_ILLEGAL_BOOLEAN 176 # define ASN1_R_ILLEGAL_CHARACTERS 124 -- 2.1.0 From openssl-users at dukhovni.org Fri May 8 00:40:35 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 8 May 2015 00:40:35 +0000 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <1431043217.2505.3.camel@redhat.com> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> Message-ID: <20150508004035.GE17272@mournblade.imrryr.org> On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote: > There have been some conversations behind Red Hat doors about > improving the state of Kerberos/TLS in both standards and > implementations. Could we maybe have a broader conversation about how > to fix this situation? To be blunt, if you want better Kerberos support in TLS, the fix is to expand the TLS WG charter to explore new directions in TLS Kerberos support. Given all the current efforts on 1.3, this is not going to happen for quite some time. There's nothing that can be done in just OpenSSL, and the right immediate action is to drop support for the obsolete protocol. [ FWIW, Nico concurs. ] -- Viktor. From jaltman at secure-endpoints.com Fri May 8 01:28:34 2015 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 07 May 2015 21:28:34 -0400 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <20150508004035.GE17272@mournblade.imrryr.org> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> Message-ID: <554C1142.9090002@secure-endpoints.com> On 5/7/2015 8:40 PM, Viktor Dukhovni wrote: > On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote: > >> There have been some conversations behind Red Hat doors about >> improving the state of Kerberos/TLS in both standards and >> implementations. Could we maybe have a broader conversation about how >> to fix this situation? > > To be blunt, if you want better Kerberos support in TLS, the fix > is to expand the TLS WG charter to explore new directions in TLS > Kerberos support. Given all the current efforts on 1.3, this is > not going to happen for quite some time. > > There's nothing that can be done in just OpenSSL, and the right > immediate action is to drop support for the obsolete protocol. > > [ FWIW, Nico concurs. ] As do I and I am one of the individuals that pushed to get RFC 2712 passed the TLS WG and added to OpenSSL back in 1999. While Viktor is correct that GSS authentication used over TLS with appropriate channel bindings is a good option, it is not an option for everyone. It isn't easy to re-architect protocols that have been deployed for more than 15 years in production. There have been several efforts over the years to better integrate GSS and Kerberos into TLS. The approach that I prefer is one in which TLS relies upon GSS authentication to produce a shared secret key that is used to feed the TLS Pre-Shared Key (PSK) functionality. However that went nowhere. TLS is complicated enough and there were significant concerns that creating a GSS hole in the protocol would risk broader security and performance issues. SSH2 + GSS Key Exchange demonstrates how easy it should be to combine GSS Kerberos with a security protocol and remove the dependency on key management. I have often wondered if the real resistance to adding GSS to TLS is the negative impact it would have on the bottom lines of companies that sell server certificates. Regardless, the inability to improve the support in this area has left the those organizations that rely upon 2712 with the choice of use insecure protocols or re-implement the applications. I do not believe that any sane OS or application vendor can with a straight face continue to ship 2712 support. As such it should be removed from OpenSSL master. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4589 bytes Desc: S/MIME Cryptographic Signature URL: From matt at openssl.org Fri May 8 08:40:49 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 08 May 2015 09:40:49 +0100 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <554C1142.9090002@secure-endpoints.com> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> Message-ID: <554C7691.80906@openssl.org> On 08/05/15 02:28, Jeffrey Altman wrote: > Regardless, the inability to improve the support in this area has left > the those organizations that rely upon 2712 with the choice of use > insecure protocols or re-implement the applications. I do not believe > that any sane OS or application vendor can with a straight face continue > to ship 2712 support. As such it should be removed from OpenSSL master. I plan to start preparing the patches to remove it next week. Matt From rt at openssl.org Fri May 8 15:59:19 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Fri, 8 May 2015 17:59:19 +0200 Subject: [openssl-dev] [openssl.org #3840] [PATCH] Add missing NULL check in X509V3_parse_list() In-Reply-To: References: Message-ID: The return value of BUF_strdup is unchecked in X509V3_parse_list() the attached patch fixes the issue. --- Kurt Cancemi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-NULL-check-in-X509V3_parse_list.patch Type: text/x-patch Size: 758 bytes Desc: not available URL: From rt at openssl.org Fri May 8 15:59:36 2015 From: rt at openssl.org (Misaki.Miyashita via RT) Date: Fri, 8 May 2015 17:59:36 +0200 Subject: [openssl-dev] [openssl.org #3841] Uninitialized memory causes segmentation fault In-Reply-To: <554BC7D6.30103@oracle.com> References: <554BC7D6.30103@oracle.com> Message-ID: Hi, We encountered a segmentation fault in our engine code as EVP_CIPHER->cleanup() is called before EVP_CIPHER_CTX->cipher_data gets initialized by EVP_CIPHER->init(). This can be prevented if EVP_CIPHER_CTX->cipher_data is initialized with 0s after the allocation in EVP_CipherInit_ex(). Please refer to the following PR. PR#277 Uninitialized memory causes segmentation fault Thank you -- misaki -- Oracle Solaris Security - Austin, TX Principal Software Engineer From rt at openssl.org Fri May 8 16:00:26 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Fri, 8 May 2015 18:00:26 +0200 Subject: [openssl-dev] [openssl.org #3842] [PATCH] Add missing terminating NULL to speed_options table In-Reply-To: References: Message-ID: Add missing terminating NULL to speed_options table. This would cause memory corruption by opt_init() because it relies on the terminating NULL. --- Kurt Cancemi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-terminating-NULL-to-speed_options-table..patch Type: text/x-patch Size: 704 bytes Desc: not available URL: From rt at openssl.org Fri May 8 16:03:28 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Fri, 8 May 2015 18:03:28 +0200 Subject: [openssl-dev] [openssl.org #3842] [PATCH] Add missing terminating NULL to speed_options table In-Reply-To: References: Message-ID: Attached updated patch according to openssl style. --- Kurt Cancemi https://www.x64architecture.com On Thu, May 7, 2015 at 6:15 PM, Kurt Cancemi wrote: > Add missing terminating NULL to speed_options table. This would cause > memory corruption by opt_init() because it relies on the terminating > NULL. > > --- > Kurt Cancemi -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-Add-missing-terminating-NULL-to-speed_options-table.style.patch Type: text/x-patch Size: 702 bytes Desc: not available URL: From rt at openssl.org Fri May 8 16:05:12 2015 From: rt at openssl.org (Solar Designer via RT) Date: Fri, 8 May 2015 18:05:12 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <20150508005825.GA18666@openwall.com> References: <20150508005825.GA18666@openwall.com> Message-ID: Hi, Lei Zhang (re)discovered that OpenSSL 1.0.1* and below gets miscompiled, resulting in incorrect computation of at least SHA-1 hashes (and probably SHA-0, MD4, MD5) when it's compiled with icc for 64-bit Linux (x86_64 or mic), but not for Windows. The problem is already fixed in 1.0.2 and in LibreSSL. The problem is that OpenSSL uses the _lrotl() intrinsic to rotate 32-bit integers, whereas it is defined to operate on "unsigned long", which obviously is 64-bit on many platforms. Lei's report: http://www.openwall.com/lists/john-dev/2015/03/26/1 A previous report (from 2011): https://software.intel.com/en-us/articles/openssl-generates-incorrect-shamd5-value-if-built-with-icc-compiler I suggest that this be fixed for all currently supported branches of OpenSSL. For now, Lei switched to using LibreSSL in our John the Ripper -jumbo builds for Xeon Phi, but we'd like to (re-)include instructions for building with OpenSSL as well. Thanks, Alexander From rt at openssl.org Fri May 8 16:11:08 2015 From: rt at openssl.org (Bhupathi Sumanth via RT) Date: Fri, 8 May 2015 18:11:08 +0200 Subject: [openssl-dev] [openssl.org #3844] FW: regarding shared library for openssl -1.0.2a In-Reply-To: References: Message-ID: Hi all, I want cross compile openssl for arm-xilinx-linux-gnueabi-gcc platform .I have downloaded source code openssl-1.02a and I have looked options for for configure file. Arm-xilinx-linux-gnueabi is not found in list of os/compiler option .so I selected linux-armv4 and configure like this ./configure no-threads shared linux-armv4 --prefix=/home/sum/ --openssl=/home/sum/ Configuration is successful when I going for make itt has given me error stating that relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC libcrypto.a(armcap.o): error adding symbols: Bad value collect2: error: ld returned 1 exit status make[4]: *** [link_a.gnu] Error 1 make[4]: Leaving directory `/home/sumanth/SNTP/openssl-1.0.2a' make[3]: *** [do_linux-shared] Error 2 make[3]: Leaving directory `/home/sumanth/SNTP/openssl-1.0.2a' make[2]: *** [libcrypto.so.1.0.0] Error 2 make[2]: Leaving directory `/home/sumanth/SNTP/openssl-1.0.2a' make[1]: *** [shared] Error 2 make[1]: Leaving directory `/home/sumanth/SNTP/openssl-1.0.2a/crypto' make: *** [build_crypto] Error 1 please suggest a solution for this?under compiler options why arm-none-linux-gneabi support is not there? Regards sumanth ::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. ---------------------------------------------------------------------------------------------------------------------------------------------------- From rt at openssl.org Fri May 8 19:42:35 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 21:42:35 +0200 Subject: [openssl-dev] [openssl.org #838] REQ: Creating a BIO from a FILE* should retain (TEXT) access modes In-Reply-To: References: Message-ID: It's been ten years, we're not going to get around to this. Someone re-open (ideally with a patch) if they think it still needs to be fixed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 19:50:14 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 21:50:14 +0200 Subject: [openssl-dev] [openssl.org #270] API: certificate chain handling incomplete In-Reply-To: <3D768526.3040906@arcot.com> References: <3D768526.3040906@arcot.com> Message-ID: It's been more than a dozen years, we're clearly not going to get around to it. Closing. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 19:55:46 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 21:55:46 +0200 Subject: [openssl-dev] [openssl.org #448] [Fwd: Bug#176062: openssl: Expired certificates and recertification] In-Reply-To: <3E1ED182.1000105@uni-mainz.de> References: <3E1ED182.1000105@uni-mainz.de> Message-ID: It's been years and years and time to face facts: not going to happen unless someone sends a patch. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 19:56:34 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 21:56:34 +0200 Subject: [openssl-dev] [openssl.org #1019] renegotiation failure - bug report. In-Reply-To: References: Message-ID: We have no plans to fix renegotiation when client and server are sending asynchronously. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 20:58:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 22:58:01 +0200 Subject: [openssl-dev] [openssl.org #795] Uninitialized Variables, Prototype Mismatches, Portability In-Reply-To: References: Message-ID: We compile with various warning flags and believe all of these are addressed. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 21:00:37 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 23:00:37 +0200 Subject: [openssl-dev] [openssl.org #1181] [PATCH] adds RFC 3280 compatible mail attribute In-Reply-To: <42F1D213.1080407@cms.hu-berlin.de> References: <42F1D213.1080407@cms.hu-berlin.de> Message-ID: subjectAltName is the mechanism to use, and is supported. Other RDN types for email are not. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 21:11:04 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 23:11:04 +0200 Subject: [openssl-dev] [openssl.org #1956] [enhancement request] load_key in ts.c In-Reply-To: References: Message-ID: fixed some time ago, probably by steve. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 21:13:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 23:13:01 +0200 Subject: [openssl-dev] [openssl.org #2172] [BUG] Incorrect input checking in openssl enc In-Reply-To: <201002151829.42315.sebastien.luttringer@smartjog.com> References: <201002151829.42315.sebastien.luttringer@smartjog.com> Message-ID: yes there is a limit on the size of the passphrase. unlikely to fix this; old ticket. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Fri May 8 21:15:06 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 8 May 2015 23:15:06 +0200 Subject: [openssl-dev] [openssl.org #2150] make -n install DOES ACTUALLY INSTALL everything In-Reply-To: <16930.1264101271@dschgrazlin2.units.it> References: <16930.1264101271@dschgrazlin2.units.it> Message-ID: so they turn off the -n flag for some recurive makes. hard to justify that as proper behavior, although i understand why it's convenient. not a real defect for openssl. we are looking at other general make issues, too, but this one i am closing for now. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From npmccallum at redhat.com Fri May 8 21:17:29 2015 From: npmccallum at redhat.com (Nathaniel McCallum) Date: Fri, 08 May 2015 17:17:29 -0400 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <554C1142.9090002@secure-endpoints.com> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> Message-ID: <1431119849.2490.2.camel@redhat.com> On Thu, 2015-05-07 at 21:28 -0400, Jeffrey Altman wrote: > On 5/7/2015 8:40 PM, Viktor Dukhovni wrote: > > On Thu, May 07, 2015 at 08:00:17PM -0400, Nathaniel McCallum wrote: > > > > > There have been some conversations behind Red Hat doors about > > > improving the state of Kerberos/TLS in both standards and > > > implementations. Could we maybe have a broader conversation > > > about how > > > to fix this situation? > > > > To be blunt, if you want better Kerberos support in TLS, the fix > > is to expand the TLS WG charter to explore new directions in TLS > > Kerberos support. Given all the current efforts on 1.3, this is > > not going to happen for quite some time. > > > > There's nothing that can be done in just OpenSSL, and the right > > immediate action is to drop support for the obsolete protocol. > > > > [ FWIW, Nico concurs. ] > > As do I and I am one of the individuals that pushed to get RFC 2712 > passed the TLS WG and added to OpenSSL back in 1999. > > While Viktor is correct that GSS authentication used over TLS with > appropriate channel bindings is a good option, it is not an option > for > everyone. It isn't easy to re-architect protocols that have been > deployed for more than 15 years in production. > > There have been several efforts over the years to better integrate > GSS > and Kerberos into TLS. The approach that I prefer is one in which > TLS > relies upon GSS authentication to produce a shared secret key that is > used to feed the TLS Pre-Shared Key (PSK) functionality. However > that > went nowhere. TLS is complicated enough and there were significant > concerns that creating a GSS hole in the protocol would risk broader > security and performance issues. > > SSH2 + GSS Key Exchange demonstrates how easy it should be to combine > GSS Kerberos with a security protocol and remove the dependency on > key > management. I have often wondered if the real resistance to adding > GSS > to TLS is the negative impact it would have on the bottom lines of > companies that sell server certificates. > > Regardless, the inability to improve the support in this area has > left > the those organizations that rely upon 2712 with the choice of use > insecure protocols or re-implement the applications. I do not > believe > that any sane OS or application vendor can with a straight face > continue > to ship 2712 support. As such it should be removed from OpenSSL > master. I agree that the current situation is not sustainable. I was only hoping to start a conversation about how to improve the situation. For instance, there is this: http://tls-kdh.arpa2.net/ I don't see any reason this couldn't be expanded to do GSSAPI. But maybe this mailing list isn't the right place for such a discussion. Perhaps the right question to ask is how much interest there would be in improving this situation in the TLS WG and whether or not OpenSSL would have interest in implementing such a project. Nathaniel From jaltman at secure-endpoints.com Sat May 9 02:09:29 2015 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Fri, 08 May 2015 22:09:29 -0400 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <1431119849.2490.2.camel@redhat.com> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> Message-ID: <554D6C59.1050402@secure-endpoints.com> On 5/8/2015 5:17 PM, Nathaniel McCallum wrote: > > I agree that the current situation is not sustainable. I was only > hoping to start a conversation about how to improve the situation. > > For instance, there is this: http://tls-kdh.arpa2.net/ > > I don't see any reason this couldn't be expanded to do GSSAPI. I think that TLS-KDH is fundamentally flawed because it is tied to the Kerberos protocol. Most operating systems today support Kerberos but they do not support a stable standard Kerberos API because such a creature does not exist in the wild. If we want a TLS implementation to make use of Kerberos authentication on a broad range of operating systems that we must access Kerberos through GSS. Only by using GSS can userland TLS implementations hope to stack on top of the OS provided Kerberos in a portable way. > But maybe this mailing list isn't the right place for such a > discussion. > > Perhaps the right question to ask is how much interest there would be > in improving this situation in the TLS WG and whether or not OpenSSL > would have interest in implementing such a project. The IETF TLS WG and perhaps the IETF Kitten WG are the appropriate places to hold discussions. Or perhaps hold an IETF BOF first to explore the interest. The last time I was involved the work product was https://tools.ietf.org/html/draft-santesson-tls-gssapi-03 I still believe that is a reasonable approach. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4589 bytes Desc: S/MIME Cryptographic Signature URL: From nico at cryptonector.com Sat May 9 02:18:12 2015 From: nico at cryptonector.com (Nico Williams) Date: Fri, 8 May 2015 21:18:12 -0500 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <1431119849.2490.2.camel@redhat.com> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> Message-ID: <20150509021811.GD7287@localhost> On Fri, May 08, 2015 at 05:17:29PM -0400, Nathaniel McCallum wrote: > I agree that the current situation is not sustainable. I was only > hoping to start a conversation about how to improve the situation. RFC2712 uses Authenticator, which is an ASN.1 type quite clearly NOT intended for use outside RFC1510 because it isn't a PDU. RFC2712 unnecessarily constructed its own AP-REQ that's different from the RFC1510 (now 4120) AP-REQ. This is bad for a variety of reasons, not the least of which are complicating Kerberos APIs and/or RFC2712 implementations (which might have to parse out the Authenticator and Ticket from a plain AP-REQ). I also notice that the EncryptedPreMasterSecret is under-specified (is it a Kerberos EncryptedData? who knows?). RFC2712 could be replaced with a properly-done protocol that uses Kerberos in the full TLS handshake (i.e., not in session resumption). This would be the lowest-effort fix. A generic GSS-in-TLS extension would require much more energy (see below). > For instance, there is this: http://tls-kdh.arpa2.net/ Yes, it'd be nice to add PFS to the Kerberos AP exchange, and we just might get there, but adding Kerberos and/or GSS to TLS is a very different undertaking. > I don't see any reason this couldn't be expanded to do GSSAPI. Well, that's difficult because GSS has arbitrary round trips... You're not the first to want this, see for example here: https://tools.ietf.org/html/draft-santesson-tls-gssapi-01 https://tools.ietf.org/html/draft-williams-tls-app-sasl-opt-04 And more if you consider other efforts like False Start and look past GSS/SASL. Probably many more than I know of then... Two main design axis: 1) When does the GSS context token begin, and how is channel binding done. - no GSS mech negotiation, first GSS context token goes in TLS ClientHello; (channel binding done via MIC tokens or GSS_Pesudorandom() output exchanges) or (e.g., if the client needs to negotiate mechs) - TLS ClientHello carries client mechList, server announces a mech in its handshake message, first GSS context token goes in second client handshake flight with normal channel binding (Both options could be specified, with clients choosing as desired.) x 2) How many GSS context tokens can be exchanged and who is responsible for continuing past the traditional TLS handshake. - one round trip only or - arbitrary round trips continued by TLS or by the application The first order of business is to decide on whether or not to support multiple round trips (IMO we must; what's the point if not?). The second is to decide whether or not additional context token round trips are to be done by the application, both as to how they appear on the wire and how they appear in the API. The third is to decide whether GSS mechanism negotiation is supported, and whether it can be optimized away when it's not needed. The fourth is to decide whether SASL (with SASL/GS2 to get GSS) isn't better, since if we're going to spend a pair of flights in negotiation, we might as well let server-talks-first SASL mechs get a leg up on GSS. Remember, SASL can do GSS just fine via SASL/GS2 [RFC5801]. > But maybe this mailing list isn't the right place for such a > discussion. Well, TLS WG would be the right forum, but they are busy with TLS 1.3. Some of us could get together elsewhere, probably not here. > Perhaps the right question to ask is how much interest there would be > in improving this situation in the TLS WG and whether or not OpenSSL > would have interest in implementing such a project. My impression is: none, because TLS WG is too busy at this time, and in the past it has been very difficult to get the necessary level of implementor effort. Past performance is not always a predictor of future performance. It would help if GSS had better, less niche mechanisms. For example: if Kerberos had PKCROSS (based on DANE, say), that would help. Or if ABFAB went viral. But for now everyone in the TLS world is happy _enough_ with WebPKI for server (should be service, but hey) authentication and bearer tokens for user authentication. Part of the problem is that HTTP authentication schemes (whether in HTTP proper or not) have no real binding to TLS, and HTTP is basically a routable (and usually routed) protocol anyways, which complicates everything. But HTTPS is the main consumer of TLS. One might think that adding user authentication options to TLS would be desirable for HTTP applications, but again, the routing inherent to HTTP means that routing must pass along user authentication information, but this isn't always easy. And HTTP is stateless and so doesn't deal well with needing continuation of authentication exchanges, so bearer tokens it basically kinda has to be, so that better mechanisms lose their appeal. If the main consumer of GSS-in-TLS were to be something other than HTTP, well, great, but still, HTTPS is the biggest consumer (next is SMTP)... And it's easier then to think of GSS-in-TLS as optimizing *application* protocols with TLS by tagging some application data along in handshake messages -- there have been many proposals like this, and this is by far the most promising approach for special some applications (e.g., IMAP). But now we're talking about generic TLS extensions (to be used for GSS) rather than adding GSS support to TLS, and while that might make it easier to get this through, it also makes coding applications harder. I don't mean to sound pessimistic, much less to dissuade you. Rather, I want you to know what level of energy it will take to accomplish what you're after. Hopefully something does come of this. I'll be glad to help. Nico -- From nico at cryptonector.com Sat May 9 03:57:52 2015 From: nico at cryptonector.com (Nico Williams) Date: Fri, 8 May 2015 22:57:52 -0500 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <20150509021811.GD7287@localhost> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> <20150509021811.GD7287@localhost> Message-ID: <20150509035751.GF7287@localhost> I should have mentioned NPN and ALPN too. A TLS application could use ALPN to negotiate the use of a variant of the real application protocol, with the variant starting with a channel-bound GSS context token exchange. The ALPN approach can optimize the GSS mechanism negotiation, at the price of a cartesian explosion of {app protocols} x {GSS mechs}. A variant based on the same idea could avoid the cartesian explosion. But hey, TLS is the land of cartesian explosions; when in Rome... The ALPN approach would be my preference here. With TLS libraries implementing the GSS context exchange, naturally. The result would be roughly what you seem to have in mind. If we ask TLS WG, I strongly suspect that we'll be asked to look at ALPN first. I should add that I also would like to see the RFC4121 Kerberos GSS mechanism gain PFS, independently of TLS gaining GSS. Nico -- From ssx at av8n.com Sat May 9 05:57:10 2015 From: ssx at av8n.com (John Denker) Date: Fri, 08 May 2015 22:57:10 -0700 Subject: [openssl-dev] Kerberos In-Reply-To: <55487D88.7010909@openssl.org> References: <55487D88.7010909@openssl.org> Message-ID: <554DA1B6.6040502@av8n.com> On 05/05/2015 01:21 AM, Matt Caswell wrote: > I am considering removing Kerberos support from OpenSSL 1.1.0. There are > a number of problems with the functionality as it stands, and it seems > to me to be a very rarely used feature. I don't understand what it means to say the feature "seems" rarely used. Is there any actual evidence about the number and/or importance of uses? > I'm interested in hearing any > opinions on this (either for or against). Opinions are not a good substitute for actual evidence. This thread has revealed that some people on this list would prefer something else, but that leaves unanswered (and almost unasked) the question of whether Kerberos is actually being used. Personally I don't use it, but that does not come close to answering the question. A few moments of googling suggest that some people are using Kerberos in conjunction with openssl. For example: http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html > I plan to start preparing the patches to remove it next week. Why do we think that's worth the trouble? What evidence is there that removal won't cause problems? It's hard to prove a negative, and the recent discussions on this list don't even come close. I don't care about Kerberos directly, but it seems like a poor use of resources to worry about Kerberos while more pressing issues are left unaddressed. From openssl-users at dukhovni.org Sat May 9 06:14:46 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 9 May 2015 06:14:46 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <554DA1B6.6040502@av8n.com> References: <55487D88.7010909@openssl.org> <554DA1B6.6040502@av8n.com> Message-ID: <20150509061446.GO17272@mournblade.imrryr.org> On Fri, May 08, 2015 at 10:57:10PM -0700, John Denker wrote: > > I don't understand what it means to say the feature "seems" rarely used. > Is there any actual evidence about the number and/or importance of uses? We don't need to ask the original question. The current Kerberos support in OpenSSL SHOULD NOT be used, and support SHOULD be removed, even if there are current users. They can stay with whatever version of OpenSSL provides the feature at present, we won't confiscate the code from them. > For example: > > http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html This is not in fact a use of the Kerberos cipher-suites in TLS. Rather it is a use of Kerberos in which user passwords are replaced with PKI smartcards or similar. It uses OpenSSL's libcrypto for the PKI bits, but has nothing to do with TLS. > > I plan to start preparing the patches to remove it next week. > > Why do we think that's worth the trouble? This is unmaintained and largely unused code, whose functionality is obsolete. > > I don't care about Kerberos directly, but it seems like a poor use of > resources to worry about Kerberos while more pressing issues are left > unaddressed. Sorry, removing the code removes the cost of continuing to support that code (even poorly), and removes any latent security issues in that code. Since this code is conditionally compiled, removing it is rather easy. Just drop all the "#ifdef ... #endif" code blocks that support the obsolete Kerberos ciphersuites. -- Viktor. From deengert at gmail.com Sat May 9 12:21:32 2015 From: deengert at gmail.com (Douglas E Engert) Date: Sat, 09 May 2015 07:21:32 -0500 Subject: [openssl-dev] Kerberos In-Reply-To: <554DA1B6.6040502@av8n.com> References: <55487D88.7010909@openssl.org> <554DA1B6.6040502@av8n.com> Message-ID: <554DFBCC.3040302@gmail.com> On 5/9/2015 12:57 AM, John Denker wrote: > On 05/05/2015 01:21 AM, Matt Caswell wrote: > >> I am considering removing Kerberos support from OpenSSL 1.1.0. There are >> a number of problems with the functionality as it stands, and it seems >> to me to be a very rarely used feature. > > I don't understand what it means to say the > feature "seems" rarely used. Is there any > actual evidence about the number and/or > importance of uses? > >> I'm interested in hearing any >> opinions on this (either for or against). > > Opinions are not a good substitute for actual > evidence. > > This thread has revealed that some people on > this list would prefer something else, but > that leaves unanswered (and almost unasked) > the question of whether Kerberos is actually > being used. > > Personally I don't use it, but that does not > come close to answering the question. A few > moments of googling suggest that some people > are using Kerberos in conjunction with openssl. > For example: > http://linuxsoft.cern.ch/cern/slc61/i386/yum/updates/repoview/krb5-pkinit-openssl.html That refers to the use of the OpenSSL crypto libraries to provide PKI functions needed to support the PKINIT protocols. PKINIT uses PKI for a pre-authentication data element as part of the Kerberos AS-REQ. PKINIT is used by Windows Active Directory and unix versions of Kerberos for smart card login to the AD or KDC. https://tools.ietf.org/html/rfc4556 It has nothing to do with the SSL/TLS protocols using Kerberos. I too have never used the Kerberos with the SSL protocol. Time marches on, DES is deprecated and not used in Kerberos, SSL is being replaced by TLS, and these change have not been reflected in the standards used for the OpenSSL Kerberos code. I have worked with Jeff ALtman and Nico Williams in IETF working groups and they are the experts in the use of GSS and Kerberos. > >> I plan to start preparing the patches to remove it next week. > > Why do we think that's worth the trouble? > > What evidence is there that removal won't > cause problems? It's hard to prove a negative, > and the recent discussions on this list don't > even come close. > > I don't care about Kerberos directly, but it > seems like a poor use of resources to worry > about Kerberos while more pressing issues are > left unaddressed. Misuse of the older Kerberos code in OpenSSL with SSL is not as secure as one might think. Removing the code might be the best thing that could happen. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > . > -- Douglas E. Engert From rt at openssl.org Sat May 9 16:22:52 2015 From: rt at openssl.org (Benny Baumann via RT) Date: Sat, 9 May 2015 18:22:52 +0200 Subject: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID In-Reply-To: <554E2339.3070403@cacert.org> References: <554E2339.3070403@cacert.org> Message-ID: Hi, as the normal specification of cipher strings can be somewhat clumsy to use from time to time it would be nice if one could use the raw ID of a cipher (with all the usual operators): ALL:!0x00c012 Allow everything except TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA HIGH:-AES:+0x00c030 Allow all HIGH secure ciphers except AES, but explicitly include TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 AES256:-0xc030:+AES+GCM Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, if it's not in the AESGCM ciphers list. Additionally it would be awesome if one could simply use the names as they appear in the RFCs ;-) Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5449 bytes Desc: not available URL: From ssx at av8n.com Sat May 9 18:45:07 2015 From: ssx at av8n.com (John Denker) Date: Sat, 09 May 2015 11:45:07 -0700 Subject: [openssl-dev] Kerberos In-Reply-To: <554DFBCC.3040302@gmail.com> References: <55487D88.7010909@openssl.org> <554DA1B6.6040502@av8n.com> <554DFBCC.3040302@gmail.com> Message-ID: <554E55B3.3060000@av8n.com> On 05/09/2015 05:21 AM, Douglas E Engert wrote: > > Removing the code might be the best thing that could happen. It "might" be. That's hardly a ringing endorsement. > Misuse of the older Kerberos code in OpenSSL with SSL is not as > secure as one might think. That's not proof -- that's not even evidence that it is necessary to remove the code. More specifically, it is an awfully high-handed way to inform the users what we think is "best" for them. As previously mentioned in a different context, it is a bedrock principle of sound reasoning and sound planning that one should /Consider all the plausible scenarios./ So let's consider the following scenario: Rather than extirpating the code, we could simply add in a few instances of something like this: #error This feature is insecure, obsolete, unsupported, and vehemently deprecated. #warning This code will be removed in a future release. and leave it that way for a couple of Debian release cycles. That serves the purpose of communicating with the users, without being quite so high-handed. Also it would be good to communicate exactly what is being deprecated. All of Kerberos? Some particular combination of Kerberos+SSL???? In this scenario, users who wish to communicate a reply to us can do so, on a non-emergency basis. They can search for other ways of doing what needs to be done, on a non-emergency basis. From openssl-users at dukhovni.org Sat May 9 19:47:48 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 9 May 2015 19:47:48 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <554E55B3.3060000@av8n.com> References: <55487D88.7010909@openssl.org> <554DA1B6.6040502@av8n.com> <554DFBCC.3040302@gmail.com> <554E55B3.3060000@av8n.com> Message-ID: <20150509194747.GP17272@mournblade.imrryr.org> On Sat, May 09, 2015 at 11:45:07AM -0700, John Denker wrote: > > Misuse of the older Kerberos code in OpenSSL with SSL is not as > > secure as one might think. > > That's not proof -- that's not even evidence that it > is necessary to remove the code. More specifically, > it is an awfully high-handed way to inform the users > what we think is "best" for them. Nobody owes you such a proof. > Also it would be good to communicate exactly what is > being deprecated. All of Kerberos? Some particular > combination of Kerberos+SSL? OpenSSL cannot deprecate "all of Kerberos". Applications that use Kerberos can continue to do so whether the OpenSSL developers love it or hate it. OpenSSL developers can (and should) drop functionality that depends on Kerberos from the OpenSSL library. Specifically, we're proposing to drop support RFC 2712 TLS Kerberos ciphersuites. I don't know why you're so adamant when you clearly don't know what's under discussion. It is best to stop the sub-thread here. -- Viktor. From rsalz at akamai.com Sat May 9 19:57:45 2015 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 9 May 2015 19:57:45 +0000 Subject: [openssl-dev] Kerberos In-Reply-To: <554E55B3.3060000@av8n.com> References: <55487D88.7010909@openssl.org> <554DA1B6.6040502@av8n.com> <554DFBCC.3040302@gmail.com> <554E55B3.3060000@av8n.com> Message-ID: <0b5189d583d44fe4a41637efadf8b68b@usma1ex-dag1mb2.msg.corp.akamai.com> > As previously mentioned in a different context, it is a bedrock principle of > sound reasoning and sound planning that one should > /Consider all the plausible scenarios./ Sure, but they don't all get equal weight. We've posted on our mailing lists and asked for feedback. We can't do the transitive closure of everyone who uses openssl, it's too widespread. We have to trust that groups who prepare distributions for downstream know what their users are doing, etc. Many of them are on this list and have spoken up; including RH and Debian. > They can search for other ways of doing what needs to be done, on a non- > emergency basis. The algorithm is pretty simple: read the release notes, it will say "Kerberos support has been removed." If this is a problem, don't upgrade. I find the tenor and strength of your feelings here a little out of character. /r$ From doctor at doctor.nl2k.ab.ca Sun May 10 11:50:33 2015 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Sun, 10 May 2015 05:50:33 -0600 Subject: [openssl-dev] openssl 1.0.2 and openssl 1.1.0 Snapshots Message-ID: <20150510115033.GA19624@doctor.nl2k.ab.ca> What is happening lately? openssl 1.0.2 snapshots have do materialised properly in the last 2 days and now opensl 1.1.0 is flopping. 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 UK! Vote LDem on 7 May 2015!! From levitte at openssl.org Mon May 11 09:33:48 2015 From: levitte at openssl.org (Richard Levitte) Date: Mon, 11 May 2015 11:33:48 +0200 (CEST) Subject: [openssl-dev] openssl 1.0.2 and openssl 1.1.0 Snapshots In-Reply-To: <5550749D.3050006@openssl.org> References: <20150510115033.GA19624@doctor.nl2k.ab.ca> <5550749D.3050006@openssl.org> Message-ID: <20150511.113348.1027887211636246201.levitte@openssl.org> Hi, We had a disk that filled up during the weekend, the cause being a couple of runaway log. Cause fixed, logs cleaned away, that won't be the cause of a disk fill-up again. I will not try to recreate the flaky snapshots, and you may notice that today's snapshots are (as far as I can see) complete. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ doctor> From: The Doctor doctor> doctor> What is happening lately? doctor> doctor> openssl 1.0.2 snapshots have do materialised properly in the last 2 days doctor> and now opensl 1.1.0 is flopping. Please fix. From rt at openssl.org Mon May 11 10:05:15 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 11 May 2015 12:05:15 +0200 Subject: [openssl-dev] [openssl.org #3818] [BUG] dovecot imap-login segfault when running nmap -sV In-Reply-To: <5538B641.1010606@xinu.at> References: <5538B641.1010606@xinu.at> Message-ID: This patch has now been applied to the main repo, so closing this ticket. Matt From rt at openssl.org Mon May 11 11:13:04 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 11 May 2015 13:13:04 +0200 Subject: [openssl-dev] [openssl.org #3842] [PATCH] Add missing terminating NULL to speed_options table In-Reply-To: References: Message-ID: Patch applied. Many thanks. Closing ticket. Matt From rt at openssl.org Mon May 11 11:24:05 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Mon, 11 May 2015 13:24:05 +0200 Subject: [openssl-dev] [openssl.org #3840] [PATCH] Add missing NULL check in X509V3_parse_list() In-Reply-To: References: Message-ID: Patch applied. Many thanks. Closing ticket. Matt From rt at openssl.org Mon May 11 11:48:31 2015 From: rt at openssl.org (Hubert Kario via RT) Date: Mon, 11 May 2015 13:48:31 +0200 Subject: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID In-Reply-To: <1884306.XCHsJ6LJUA@pintsize.usersys.redhat.com> References: <554E2339.3070403@cacert.org> <1884306.XCHsJ6LJUA@pintsize.usersys.redhat.com> Message-ID: On Saturday 09 May 2015 18:22:52 Benny Baumann via RT wrote: > Hi, > > as the normal specification of cipher strings can be somewhat clumsy to > use from time to time it would be nice if one could use the raw ID of a > cipher (with all the usual operators): > > ALL:!0x00c012 > Allow everything except TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA > > HIGH:-AES:+0x00c030 > Allow all HIGH secure ciphers except AES, but explicitly include > TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 "+" operator doesn't add a cipher, it moves matching ones to end of list > AES256:-0xc030:+AES+GCM > Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, > if it's not in the AESGCM ciphers list. again, you're describing what would happen with AES256:-0xc030:AES+GCM > Additionally it would be awesome if one could simply use the names as > they appear in the RFCs ;-) that would make the strings longer, wouldn't it? :) master has support for printing the IETF/IANA names, see -stdname options to ciphers subcommand... -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon May 11 14:39:16 2015 From: rt at openssl.org (Rich Salz via RT) Date: Mon, 11 May 2015 16:39:16 +0200 Subject: [openssl-dev] [openssl.org #1207] [PATCH] SSL compression methods free function In-Reply-To: <20050922011120.13031.qmail@web32511.mail.mud.yahoo.com> References: <20050922011120.13031.qmail@web32511.mail.mud.yahoo.com> Message-ID: fixed in commit db7b5e0d768485d9c7f8d3eaa8f28d2f254e20d6 on 28 feb 2014 -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From nico at cryptonector.com Mon May 11 16:25:33 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 11 May 2015 11:25:33 -0500 Subject: [openssl-dev] Replacing RFC2712 (was Re: Kerberos) In-Reply-To: <20150509035751.GF7287@localhost> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost> Message-ID: <20150511162532.GH7287@localhost> On Fri, May 08, 2015 at 10:57:52PM -0500, Nico Williams wrote: > I should have mentioned NPN and ALPN too. > [...] A few more details: - If you don't want to depend on server certs, use anon-(EC)DH ciphersuites. Clients and servers must reject TLS connections using such a ciphersuite but not using a GSS-authenticated application protocol. - The protocol MUST use GSS channel binding to TLS. - Use SASL/GS2 instead of plain GSS and you get to use an authzid (optional) and you get a builtin authorization status result message at no extra cost, and all while still using GSS. You get to optimize only the mechanism negotiation, and you get TLS w/ Kerberos (and others) and without PKIX (if you don't want it). See RFCs 7301, 5801, 5056, and 5929 (but note that the TLS session hash extension is required). Nico -- From openssl-users at dukhovni.org Mon May 11 16:42:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 11 May 2015 16:42:49 +0000 Subject: [openssl-dev] Replacing RFC2712 (was Re: Kerberos) In-Reply-To: <20150511162532.GH7287@localhost> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost> Message-ID: <20150511164249.GX17272@mournblade.imrryr.org> On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: > - If you don't want to depend on server certs, use anon-(EC)DH > ciphersuites. > > Clients and servers must reject[*] TLS connections using such a > ciphersuite but not using a GSS-authenticated application protocol. [*] Except when employing unauthenticated encrypted communication to mitigate passive monitoring (oportunistic security). -- Viktor. From nico at cryptonector.com Mon May 11 18:52:19 2015 From: nico at cryptonector.com (Nico Williams) Date: Mon, 11 May 2015 13:52:19 -0500 Subject: [openssl-dev] [openssl-users] Replacing RFC2712 (was Re: Kerberos) In-Reply-To: <20150511164249.GX17272@mournblade.imrryr.org> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <1431119849.2490.2.camel@redhat.com> <20150509021811.GD7287@localhost> <20150509035751.GF7287@localhost> <20150511162532.GH7287@localhost> <20150511164249.GX17272@mournblade.imrryr.org> Message-ID: <20150511185218.GI7287@localhost> On Mon, May 11, 2015 at 04:42:49PM +0000, Viktor Dukhovni wrote: > On Mon, May 11, 2015 at 11:25:33AM -0500, Nico Williams wrote: > > > - If you don't want to depend on server certs, use anon-(EC)DH > > ciphersuites. > > > > Clients and servers must reject[*] TLS connections using such a > > ciphersuite but not using a GSS-authenticated application protocol. > > [*] Except when employing unauthenticated encrypted communication > to mitigate passive monitoring (oportunistic security). As this would be replacing RFC2712, it's not opportunistic to begin with :) From rt at openssl.org Tue May 12 07:17:46 2015 From: rt at openssl.org (Benny Baumann via RT) Date: Tue, 12 May 2015 09:17:46 +0200 Subject: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID In-Reply-To: <5551A8FC.7030903@cacert.org> References: <554E2339.3070403@cacert.org> <1884306.XCHsJ6LJUA@pintsize.usersys.redhat.com> <5551A8FC.7030903@cacert.org> Message-ID: Hi, Am 11.05.2015 um 13:48 schrieb Hubert Kario via RT: > On Saturday 09 May 2015 18:22:52 Benny Baumann via RT wrote: >> Hi, >> >> as the normal specification of cipher strings can be somewhat clumsy to >> use from time to time it would be nice if one could use the raw ID of a >> cipher (with all the usual operators): >> >> ALL:!0x00c012 >> Allow everything except TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA >> >> HIGH:-AES:+0x00c030 >> Allow all HIGH secure ciphers except AES, but explicitly include >> TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 > > "+" operator doesn't add a cipher, it moves matching ones to end of list > This explains why GnuTLS and OpenSSL prodeuce vastly different results here ;-) Good to know. Wouldn't have ">" been a better choice than? ;-) >> AES256:-0xc030:+AES+GCM >> Allow AES256, but (soft-)exclude TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384, >> if it's not in the AESGCM ciphers list. > > again, you're describing what would happen with > AES256:-0xc030:AES+GCM > >> Additionally it would be awesome if one could simply use the names as >> they appear in the RFCs ;-) > > that would make the strings longer, wouldn't it? :) > Yes, but much more easily to compare with the RFCs which ciphers are to be selected. It's not as if you are writing such strings all the time. > master has support for printing the IETF/IANA names, see -stdname options to > ciphers subcommand... > Why would -stdname include -verbose? Does this work in reverse yet? Regards, BenBE. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5449 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue May 12 07:42:27 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 12 May 2015 07:42:27 +0000 Subject: [openssl-dev] [openssl.org #3845] Feature Request: Allow specification of ciphers by raw cipher ID In-Reply-To: References: <554E2339.3070403@cacert.org> <1884306.XCHsJ6LJUA@pintsize.usersys.redhat.com> Message-ID: <20150512074226.GJ17272@mournblade.imrryr.org> On Mon, May 11, 2015 at 01:48:31PM +0200, Hubert Kario via RT wrote: > master has support for printing the IETF/IANA names, see -stdname options to > ciphers subcommand... That flag seems to be subject to conditional compilation: #ifndef OPENSSL_NO_SSL_TRACE if (stdname) { const char *nm = SSL_CIPHER_standard_name(c); if (nm == NULL) nm = "UNKNOWN"; BIO_printf(bio_out, "%s - ", nm); } #endif not sure why. In particular it does nothing in my build, because OPENSSL_NO_SSL_TRACE apears to be set (by default?). -- Viktor. From rt at openssl.org Tue May 12 16:52:02 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 12 May 2015 18:52:02 +0200 Subject: [openssl-dev] [openssl.org #2561] Memory leak with SSL built-in compressions In-Reply-To: References: Message-ID: fixed by steve H. See also ticket 1207, which will be closed when we update the docs. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Tue May 12 17:53:12 2015 From: rt at openssl.org (h15234@mailas.com via RT) Date: Tue, 12 May 2015 19:53:12 +0200 Subject: [openssl-dev] [openssl.org #3846] [bug] openssl 1.0.2 shared build's linking is not consistent - bin and libs linked to different libcrypto.so's In-Reply-To: <1431450636.2064718.266914545.31CE9676@webmail.messagingengine.com> References: <1431450636.2064718.266914545.31CE9676@webmail.messagingengine.com> Message-ID: trying to build a library self-consistent instance of openssl 1.0.2 on linux/64. Setting *FLAGS & rpath, although the openssl binary links correctly against its own {libcrypto,libssl}.so, the libssl.so links against *system*, not its own, libcrypto. I've tried a bunch of combinations of *FLAGS. Always the same result. The current env/result is: cd ./openssl-1.0.2 export SHARED_LDFLAGS="-L/usr/local/sslTEST/lib64 -Wl,-rpath,/usr/local/sslTEST/lib64 -lssl -lcrypto" export LDFLAGS=${SHARED_LDFLAGS} export LIBDEPS=${SHARED_LDFLAGS} ./config \ --openssldir=/usr/local/sslTEST \ --libdir=lib64 \ threads shared zlib \ enable-ec_nistp_64_gcc_128 \ no-idea \ no-ssl2 \ no-rc5 \ no-mdc2 \ no-hw \ no-ec2m \ enable-rfc3779 make depend make make install There are no apparent errors in the build output. The build results in /usr/local/sslTEST/bin/openssl version OpenSSL 1.0.2 22 Jan 2015 ldd \ /usr/local/sslTEST/bin/openssl \ /usr/local/sslTEST/lib64/libssl.so.1.0.0 \ /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 /usr/local/sslTEST/bin/openssl: linux-vdso.so.1 (0x00007ffefffd7000) libssl.so.1.0.0 => /usr/local/sslTEST/lib64/libssl.so.1.0.0 (0x00007f93cbe0e000) !! libcrypto.so.1.0.0 => /usr/local/sslTEST/lib64/libcrypto.so.1.0.0 (0x00007f93cb9ce000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f93cb77f000) libz.so.1 => /lib64/libz.so.1 (0x00007f93cb569000) libc.so.6 => /lib64/libc.so.6 (0x00007f93cb1c1000) /lib64/ld-linux-x86-64.so.2 (0x00007f93cc07a000) /usr/local/sslTEST/lib64/libssl.so.1.0.0: linux-vdso.so.1 (0x00007ffd01636000) !! libcrypto.so.1.0.0 => /lib64/libcrypto.so.1.0.0 (0x00007ff4abf33000) libdl.so.2 => /lib64/libdl.so.2 (0x00007ff4abd2f000) libz.so.1 => /lib64/libz.so.1 (0x00007ff4abb18000) libc.so.6 => /lib64/libc.so.6 (0x00007ff4ab771000) /lib64/ld-linux-x86-64.so.2 (0x00007ff4ac60d000) /usr/local/sslTEST/lib64/libcrypto.so.1.0.0: linux-vdso.so.1 (0x00007ffe1f55d000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9a10f46000) libz.so.1 => /lib64/libz.so.1 (0x00007f9a10d30000) libc.so.6 => /lib64/libc.so.6 (0x00007f9a10988000) /lib64/ld-linux-x86-64.so.2 (0x00007f9a115d5000) where you can see the different libcrypto's are linked. a workaround is to just ignore it -- and fix the link AFTER the build's done. Noting On Tue, Apr 7, 2015, at 07:06 PM, Jeffrey Walton wrote: > As far as I know, you only need an RPATH on Linux (OS X and Android > are a different story). After the build, since there's no proper RPATH for the libssl.so with any combination of FLAGs that I've been able to figure out, ldd libssl.so.1.0.0 | egrep "ssl|crypto" libcrypto.so.1.0.0 => /lib/libcrypto.so.1.0.0 (0x00007f55e46c0000) readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath" (empty) For anyone actually interested this does the trick patchelf --set-rpath "/path/to/ssl/lib" --force-rpath libssl.so.1.0.0 readelf --dynamic libssl.so.1.0.0 | egrep -i "rpath|runpath" 0x000000000000000f (RPATH) Library rpath: [/path/to/ssl/lib] ldd libssl.so | egrep "ssl|crypto" libcrypto.so.1.0.0 => /path/to/ssl/lib/libcrypto.so.1.0.0 (0x00007f476b4fc000) From rt at openssl.org Wed May 13 08:14:46 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Wed, 13 May 2015 10:14:46 +0200 Subject: [openssl-dev] [openssl.org #3847] [PATCH] Fix the heap corruption in libeay32!OBJ_add_object In-Reply-To: References: Message-ID: Hello, Original 'sizeof(ADDED_OBJ)' was replaced with 'sizeof(*ao)'. However, they return different sizes. Therefore as the result heap gets corrupted and at some point later debug version of malloc() detects the corruption. Issue reproduces with either enabling CRT debug heap or Application Verifier's full-page heap. Thank you, Gunnar Kudrjavets -------------- next part -------------- >From 888ffbfda8f6949b06c792390c245c03e800fc05 Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Tue, 12 May 2015 15:44:45 -0700 Subject: [PATCH] Fix the heap corruption in libeay32!OBJ_add_object. Original 'sizeof(ADDED_OBJ)' was replaced with 'sizeof(*ao)'. However, they return different sizes. Therefore as the result heap gets corrupted and at some point later debug version of malloc() detects the corruption. On x86 we can observe that as follows: sizeof(*ao) == 4 sizeof(*ao[0]) == sizeof(ADDED_OBJ) == 8 Issue reproduces with either enabling CRT debug heap or Application Verifier's full-page heap. Basic debugging data from the moment the corruption is first detected: 0:000:x86> | . 0 id: 283c create name: openssl.exe 0:000:x86> kcn # 00 MSVCR120D!_heap_alloc_dbg_impl 01 MSVCR120D!_nh_malloc_dbg_impl 02 MSVCR120D!_nh_malloc_dbg 03 MSVCR120D!malloc 04 LIBEAY32!default_malloc_ex 05 LIBEAY32!CRYPTO_malloc 06 LIBEAY32!lh_insert 07 LIBEAY32!OBJ_add_object 08 LIBEAY32!OBJ_create 09 openssl!add_oid_section 0a openssl!req_main 0b openssl!do_cmd 0c openssl!main 0d openssl!__tmainCRTStartup 0e openssl!mainCRTStartup 0f KERNEL32!BaseThreadInitThunk 10 ntdll_77d60000!__RtlUserThreadStart 11 ntdll_77d60000!_RtlUserThreadStart --- crypto/objects/obj_dat.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/crypto/objects/obj_dat.c b/crypto/objects/obj_dat.c index 991a1b7..3df7ff2 100644 --- a/crypto/objects/obj_dat.c +++ b/crypto/objects/obj_dat.c @@ -255,16 +255,16 @@ int OBJ_add_object(const ASN1_OBJECT *obj) return (0); if ((o = OBJ_dup(obj)) == NULL) goto err; - if ((ao[ADDED_NID] = OPENSSL_malloc(sizeof(*ao))) == NULL) + if ((ao[ADDED_NID] = OPENSSL_malloc(sizeof(*ao[0]))) == NULL) goto err2; if ((o->length != 0) && (obj->data != NULL)) - if ((ao[ADDED_DATA] = OPENSSL_malloc(sizeof(*ao))) == NULL) + if ((ao[ADDED_DATA] = OPENSSL_malloc(sizeof(*ao[0]))) == NULL) goto err2; if (o->sn != NULL) - if ((ao[ADDED_SNAME] = OPENSSL_malloc(sizeof(*ao))) == NULL) + if ((ao[ADDED_SNAME] = OPENSSL_malloc(sizeof(*ao[0]))) == NULL) goto err2; if (o->ln != NULL) - if ((ao[ADDED_LNAME] = OPENSSL_malloc(sizeof(*ao))) == NULL) + if ((ao[ADDED_LNAME] = OPENSSL_malloc(sizeof(*ao[0]))) == NULL) goto err2; for (i = ADDED_DATA; i <= ADDED_NID; i++) { -- 1.9.5.msysgit.1 From rt at openssl.org Wed May 13 08:27:14 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 13 May 2015 10:27:14 +0200 Subject: [openssl-dev] [openssl.org #3847] [PATCH] Fix the heap corruption in libeay32!OBJ_add_object In-Reply-To: References: Message-ID: Patch applied in commit 56d88027f026afd97ddf4e501f98437ca9819bfb. Many thanks. Matt From rt at openssl.org Wed May 13 10:33:29 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 13 May 2015 12:33:29 +0200 Subject: [openssl-dev] [openssl.org #2958] Bug report: dtls handshake loops after 'certificate verify' packet loss In-Reply-To: References: Message-ID: This has been fixed in commit a0bd649336 on master, and similar commits for 1.0.2 and 1.0.1. Many thanks for your report. Matt From hgb at ifi.uio.no Wed May 13 11:25:59 2015 From: hgb at ifi.uio.no (Henrik Grindal Bakken) Date: Wed, 13 May 2015 13:25:59 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 Message-ID: <87617wpvlk.fsf@zakalwe.freeside.no> Hi. I have an application that generates Diffie-Hellman key pairs based on some precomputed primes. In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives valgrind errors (while still working). The error only occurs on x86_64, and it does not occur on 1024 bit DH. I've attached the source code of the small application. All it does is generate a DH key pair using fixed primes. I'm not really sure where the primes come from, but this is used for H.235 (video conferencing call setup), and I think the primes are standardized. Output here: Using the native openssl on the box (1.0.1e): $ gcc -o dh-1.0.1 dh.c -lcrypto $ valgrind ./dh-1.0.1 ==4730== Memcheck, a memory error detector ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==4730== Command: ./dh-1.0.1 ==4730== ==4730== ==4730== HEAP SUMMARY: ==4730== in use at exit: 416 bytes in 6 blocks ==4730== total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated ==4730== ==4730== LEAK SUMMARY: ==4730== definitely lost: 0 bytes in 0 blocks ==4730== indirectly lost: 0 bytes in 0 blocks ==4730== possibly lost: 0 bytes in 0 blocks ==4730== still reachable: 416 bytes in 6 blocks ==4730== suppressed: 0 bytes in 0 blocks ==4730== Rerun with --leak-check=full to see details of leaked memory ==4730== ==4730== For counts of detected and suppressed errors, rerun with: -v ==4730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) I've also built myself a 1.0.2 build, using './config -DPURIFY shared' (purify to remove other valgrind warnings that would come when reading uninitialized data). $ gcc -o dh-1.0.2 -L~/src/thirdparty/openssl -isystem ~/src/thirdparty/openssl/include dh.c -lcrypto $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 ==14854== Memcheck, a memory error detector ==14854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==14854== Command: ./dh-1.0.2 ==14854== ==14854== Invalid read of size 2 ==14854== at 0x4F09198: bn_get_bits5 (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4F32B47: generate_key (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) ==14854== Address 0x581d77f is 255 bytes inside a block of size 256 alloc'd ==14854== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==14854== by 0x4E9DF62: CRYPTO_malloc (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4EFCAA7: bn_expand_internal (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4EFCFA4: bn_expand2 (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4EFD39F: BN_bin2bn (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4F010FA: BN_rand (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x4F32B0E: generate_key (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) ==14854== ==14854== ==14854== HEAP SUMMARY: ==14854== in use at exit: 416 bytes in 6 blocks ==14854== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated ==14854== ==14854== LEAK SUMMARY: ==14854== definitely lost: 0 bytes in 0 blocks ==14854== indirectly lost: 0 bytes in 0 blocks ==14854== possibly lost: 0 bytes in 0 blocks ==14854== still reachable: 416 bytes in 6 blocks ==14854== suppressed: 0 bytes in 0 blocks ==14854== Rerun with --leak-check=full to see details of leaked memory ==14854== ==14854== For counts of detected and suppressed errors, rerun with: -v ==14854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) Then, same openssl version but with 1024 bit DH: $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 1024 ==14730== Memcheck, a memory error detector ==14730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. ==14730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info ==14730== Command: ./dh-1.0.2 1024 ==14730== ==14730== ==14730== HEAP SUMMARY: ==14730== in use at exit: 416 bytes in 6 blocks ==14730== total heap usage: 112 allocs, 106 frees, 14,472 bytes allocated ==14730== ==14730== LEAK SUMMARY: ==14730== definitely lost: 0 bytes in 0 blocks ==14730== indirectly lost: 0 bytes in 0 blocks ==14730== possibly lost: 0 bytes in 0 blocks ==14730== still reachable: 416 bytes in 6 blocks ==14730== suppressed: 0 bytes in 0 blocks ==14730== Rerun with --leak-check=full to see details of leaked memory ==14730== ==14730== For counts of detected and suppressed errors, rerun with: -v ==14730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: dh.c URL: -------------- next part -------------- -- Henrik Grindal Bakken PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 From foleyj at cisco.com Wed May 13 13:44:22 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 13 May 2015 09:44:22 -0400 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <87617wpvlk.fsf@zakalwe.freeside.no> References: <87617wpvlk.fsf@zakalwe.freeside.no> Message-ID: <55535536.6050403@cisco.com> If you add the --show-reachable option to valgrind, you can see where the leaks originate. They appear to be in the ex_data code (see below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f as well as 1.0.2a. ==18173== HEAP SUMMARY: ==18173== in use at exit: 416 bytes in 6 blocks ==18173== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated ==18173== ==18173== 24 bytes in 1 blocks are still reachable in loss record 1 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x40AFCB: def_get_class (ex_data.c:321) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== 24 bytes in 1 blocks are still reachable in loss record 2 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x425063: lh_insert (lhash.c:191) ==18173== by 0x40AFF9: def_get_class (ex_data.c:333) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== 32 bytes in 1 blocks are still reachable in loss record 3 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x42434B: sk_new_null (stack.c:162) ==18173== by 0x40AFE1: def_get_class (ex_data.c:325) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== 32 bytes in 1 blocks are still reachable in loss record 4 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x424367: sk_new_null (stack.c:164) ==18173== by 0x40AFE1: def_get_class (ex_data.c:325) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== 128 bytes in 1 blocks are still reachable in loss record 5 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x424C5D: lh_new (lhash.c:122) ==18173== by 0x40B054: def_get_class (ex_data.c:279) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== 176 bytes in 1 blocks are still reachable in loss record 6 of 6 ==18173== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==18173== by 0x4092E7: CRYPTO_malloc (mem.c:342) ==18173== by 0x424C3D: lh_new (lhash.c:120) ==18173== by 0x40B054: def_get_class (ex_data.c:279) ==18173== by 0x40B21A: int_new_ex_data (ex_data.c:421) ==18173== by 0x404D11: DH_new (dh_lib.c:169) ==18173== by 0x401B66: main (dhh.c:63) ==18173== ==18173== LEAK SUMMARY: ==18173== definitely lost: 0 bytes in 0 blocks ==18173== indirectly lost: 0 bytes in 0 blocks ==18173== possibly lost: 0 bytes in 0 blocks ==18173== still reachable: 416 bytes in 6 blocks ==18173== suppressed: 0 bytes in 0 blocks On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote: > Hi. I have an application that generates Diffie-Hellman key pairs based > on some precomputed primes. > > In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives > valgrind errors (while still working). > > The error only occurs on x86_64, and it does not occur on 1024 bit DH. > > I've attached the source code of the small application. All it does is > generate a DH key pair using fixed primes. I'm not really sure where > the primes come from, but this is used for H.235 (video conferencing > call setup), and I think the primes are standardized. > > Output here: > > Using the native openssl on the box (1.0.1e): > $ gcc -o dh-1.0.1 dh.c -lcrypto > $ valgrind ./dh-1.0.1 > ==4730== Memcheck, a memory error detector > ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==4730== Command: ./dh-1.0.1 > ==4730== > ==4730== > ==4730== HEAP SUMMARY: > ==4730== in use at exit: 416 bytes in 6 blocks > ==4730== total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated > ==4730== > ==4730== LEAK SUMMARY: > ==4730== definitely lost: 0 bytes in 0 blocks > ==4730== indirectly lost: 0 bytes in 0 blocks > ==4730== possibly lost: 0 bytes in 0 blocks > ==4730== still reachable: 416 bytes in 6 blocks > ==4730== suppressed: 0 bytes in 0 blocks > ==4730== Rerun with --leak-check=full to see details of leaked memory > ==4730== > ==4730== For counts of detected and suppressed errors, rerun with: -v > ==4730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > > I've also built myself a 1.0.2 build, using './config -DPURIFY shared' > (purify to remove other valgrind warnings that would come when reading > uninitialized data). > > $ gcc -o dh-1.0.2 -L~/src/thirdparty/openssl -isystem > ~/src/thirdparty/openssl/include dh.c -lcrypto > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 > ==14854== Memcheck, a memory error detector > ==14854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14854== Command: ./dh-1.0.2 > ==14854== > ==14854== Invalid read of size 2 > ==14854== at 0x4F09198: bn_get_bits5 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B47: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== Address 0x581d77f is 255 bytes inside a block of size 256 alloc'd > ==14854== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14854== by 0x4E9DF62: CRYPTO_malloc (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCAA7: bn_expand_internal (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCFA4: bn_expand2 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFD39F: BN_bin2bn (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F010FA: BN_rand (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B0E: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== > ==14854== > ==14854== HEAP SUMMARY: > ==14854== in use at exit: 416 bytes in 6 blocks > ==14854== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated > ==14854== > ==14854== LEAK SUMMARY: > ==14854== definitely lost: 0 bytes in 0 blocks > ==14854== indirectly lost: 0 bytes in 0 blocks > ==14854== possibly lost: 0 bytes in 0 blocks > ==14854== still reachable: 416 bytes in 6 blocks > ==14854== suppressed: 0 bytes in 0 blocks > ==14854== Rerun with --leak-check=full to see details of leaked memory > ==14854== > ==14854== For counts of detected and suppressed errors, rerun with: -v > ==14854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) > > Then, same openssl version but with 1024 bit DH: > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 1024 > ==14730== Memcheck, a memory error detector > ==14730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14730== Command: ./dh-1.0.2 1024 > ==14730== > ==14730== > ==14730== HEAP SUMMARY: > ==14730== in use at exit: 416 bytes in 6 blocks > ==14730== total heap usage: 112 allocs, 106 frees, 14,472 bytes allocated > ==14730== > ==14730== LEAK SUMMARY: > ==14730== definitely lost: 0 bytes in 0 blocks > ==14730== indirectly lost: 0 bytes in 0 blocks > ==14730== possibly lost: 0 bytes in 0 blocks > ==14730== still reachable: 416 bytes in 6 blocks > ==14730== suppressed: 0 bytes in 0 blocks > ==14730== Rerun with --leak-check=full to see details of leaked memory > ==14730== > ==14730== For counts of detected and suppressed errors, rerun with: -v > ==14730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgb at ifi.uio.no Wed May 13 14:13:26 2015 From: hgb at ifi.uio.no (Henrik Grindal Bakken) Date: Wed, 13 May 2015 16:13:26 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <55535536.6050403@cisco.com> (John Foley's message of "Wed, 13 May 2015 09:44:22 -0400") References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> Message-ID: <87bnhoo9a1.fsf@zakalwe.freeside.no> John Foley writes: > If you add the --show-reachable option to valgrind, you can see where > the leaks originate. They appear to be in the ex_data code (see > below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f > as well as 1.0.2a. Ah, I forgot to mention. I'm not concerned about the leak, but the invalid read that's in 1.0.2 only. This one: >> ==14854== Invalid read of size 2 >> ==14854== at 0x4F09198: bn_get_bits5 (in >> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >> ==14854== by 0x4F32B47: generate_key (in >> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >> ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) -- Henrik Grindal Bakken PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 From foleyj at cisco.com Wed May 13 14:04:53 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 13 May 2015 10:04:53 -0400 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <87617wpvlk.fsf@zakalwe.freeside.no> References: <87617wpvlk.fsf@zakalwe.freeside.no> Message-ID: <55535A05.3030608@cisco.com> Upon further investigation, it looks like the problem is in your sample code. You need to invoke CRYPTO_cleanup_all_ex_data() before terminating your program. On 05/13/2015 07:25 AM, Henrik Grindal Bakken wrote: > Hi. I have an application that generates Diffie-Hellman key pairs based > on some precomputed primes. > > In 1.0.1 (and earlier) this works just fine, while in 1.0.2 it gives > valgrind errors (while still working). > > The error only occurs on x86_64, and it does not occur on 1024 bit DH. > > I've attached the source code of the small application. All it does is > generate a DH key pair using fixed primes. I'm not really sure where > the primes come from, but this is used for H.235 (video conferencing > call setup), and I think the primes are standardized. > > Output here: > > Using the native openssl on the box (1.0.1e): > $ gcc -o dh-1.0.1 dh.c -lcrypto > $ valgrind ./dh-1.0.1 > ==4730== Memcheck, a memory error detector > ==4730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==4730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==4730== Command: ./dh-1.0.1 > ==4730== > ==4730== > ==4730== HEAP SUMMARY: > ==4730== in use at exit: 416 bytes in 6 blocks > ==4730== total heap usage: 115 allocs, 109 frees, 31,224 bytes allocated > ==4730== > ==4730== LEAK SUMMARY: > ==4730== definitely lost: 0 bytes in 0 blocks > ==4730== indirectly lost: 0 bytes in 0 blocks > ==4730== possibly lost: 0 bytes in 0 blocks > ==4730== still reachable: 416 bytes in 6 blocks > ==4730== suppressed: 0 bytes in 0 blocks > ==4730== Rerun with --leak-check=full to see details of leaked memory > ==4730== > ==4730== For counts of detected and suppressed errors, rerun with: -v > ==4730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > > I've also built myself a 1.0.2 build, using './config -DPURIFY shared' > (purify to remove other valgrind warnings that would come when reading > uninitialized data). > > $ gcc -o dh-1.0.2 -L~/src/thirdparty/openssl -isystem > ~/src/thirdparty/openssl/include dh.c -lcrypto > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 > ==14854== Memcheck, a memory error detector > ==14854== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14854== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14854== Command: ./dh-1.0.2 > ==14854== > ==14854== Invalid read of size 2 > ==14854== at 0x4F09198: bn_get_bits5 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B47: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== Address 0x581d77f is 255 bytes inside a block of size 256 alloc'd > ==14854== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==14854== by 0x4E9DF62: CRYPTO_malloc (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCAA7: bn_expand_internal (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFCFA4: bn_expand2 (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4EFD39F: BN_bin2bn (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F010FA: BN_rand (in /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x4F32B0E: generate_key (in > /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) > ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > ==14854== > ==14854== > ==14854== HEAP SUMMARY: > ==14854== in use at exit: 416 bytes in 6 blocks > ==14854== total heap usage: 112 allocs, 106 frees, 21,000 bytes allocated > ==14854== > ==14854== LEAK SUMMARY: > ==14854== definitely lost: 0 bytes in 0 blocks > ==14854== indirectly lost: 0 bytes in 0 blocks > ==14854== possibly lost: 0 bytes in 0 blocks > ==14854== still reachable: 416 bytes in 6 blocks > ==14854== suppressed: 0 bytes in 0 blocks > ==14854== Rerun with --leak-check=full to see details of leaked memory > ==14854== > ==14854== For counts of detected and suppressed errors, rerun with: -v > ==14854== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) > > Then, same openssl version but with 1024 bit DH: > $ LD_LIBRARY_PATH=~/src/thirdparty/openssl valgrind ./dh-1.0.2 1024 > ==14730== Memcheck, a memory error detector > ==14730== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. > ==14730== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info > ==14730== Command: ./dh-1.0.2 1024 > ==14730== > ==14730== > ==14730== HEAP SUMMARY: > ==14730== in use at exit: 416 bytes in 6 blocks > ==14730== total heap usage: 112 allocs, 106 frees, 14,472 bytes allocated > ==14730== > ==14730== LEAK SUMMARY: > ==14730== definitely lost: 0 bytes in 0 blocks > ==14730== indirectly lost: 0 bytes in 0 blocks > ==14730== possibly lost: 0 bytes in 0 blocks > ==14730== still reachable: 416 bytes in 6 blocks > ==14730== suppressed: 0 bytes in 0 blocks > ==14730== Rerun with --leak-check=full to see details of leaked memory > ==14730== > ==14730== For counts of detected and suppressed errors, rerun with: -v > ==14730== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2) > > > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed May 13 14:19:24 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 13 May 2015 15:19:24 +0100 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <554C7691.80906@openssl.org> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <554C7691.80906@openssl.org> Message-ID: <55535D6C.4060109@openssl.org> On 08/05/15 09:40, Matt Caswell wrote: > > > On 08/05/15 02:28, Jeffrey Altman wrote: > >> Regardless, the inability to improve the support in this area has left >> the those organizations that rely upon 2712 with the choice of use >> insecure protocols or re-implement the applications. I do not believe >> that any sane OS or application vendor can with a straight face continue >> to ship 2712 support. As such it should be removed from OpenSSL master. > > I plan to start preparing the patches to remove it next week. FYI, these patches have now been applied to master. Matt From rt at openssl.org Wed May 13 14:35:11 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 13 May 2015 16:35:11 +0200 Subject: [openssl-dev] [openssl.org #3816] Call of memcmp with null pointers in obj_cmp() In-Reply-To: <20150419181719.38c214d9@pc1.fritz.box> References: <20150419181719.38c214d9@pc1.fritz.box> Message-ID: Patch applied. Many thanks. Matt From foleyj at cisco.com Wed May 13 14:46:07 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 13 May 2015 10:46:07 -0400 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <87bnhoo9a1.fsf@zakalwe.freeside.no> References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> Message-ID: <555363AF.8000403@cisco.com> Sorry for misinterpreting your question, my mistake. I was able to replicate the error. It looks like the invalid read is in code that's compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and 1.0.2, there are quite a few changes. My guess is this was introduced in ec9cc70f72454b8d4a84247c86159613cee83b81. On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: > John Foley writes: > >> If you add the --show-reachable option to valgrind, you can see where >> the leaks originate. They appear to be in the ex_data code (see >> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >> as well as 1.0.2a. > Ah, I forgot to mention. I'm not concerned about the leak, but the > invalid read that's in 1.0.2 only. > > This one: > >>> ==14854== Invalid read of size 2 >>> ==14854== at 0x4F09198: bn_get_bits5 (in >>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>> ==14854== by 0x4F32B47: generate_key (in >>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>> ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) From rt at openssl.org Wed May 13 16:58:45 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 13 May 2015 18:58:45 +0200 Subject: [openssl-dev] [openssl.org #3801] need NULL check in CMAC_CTX_free In-Reply-To: References: Message-ID: OpenSSL_0_9_8-stable 155ca14 Add NULL checks from master OpenSSL_1_0_0-stable 690d040 Add NULL checks from master OpenSSL_1_0_1-stable 76b49a8 Add NULL checks from master OpenSSL_1_0_2-stable f34b095 Add NULL checks from master commit f34b095fab1569d093b639bfcc9a77d6020148ff Author: Rich Salz Date: Tue May 12 11:49:32 2015 -0400 Add NULL checks from master The big "don't check for NULL" cleanup requires backporting some of the lowest-level functions to actually do nothing if NULL is given. This will make it easier to backport fixes to release branches, where master assumes those lower-level functions are "safe" This commit addresses those tickets: 3798 3799 3801. Reviewed-by: Matt Caswell -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From rt at openssl.org Wed May 13 17:07:15 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 13 May 2015 19:07:15 +0200 Subject: [openssl-dev] [openssl.org #3841] Uninitialized memory causes segmentation fault In-Reply-To: <554BC7D6.30103@oracle.com> References: <554BC7D6.30103@oracle.com> Message-ID: Fixed in master. Note that existing code can use the EVP_CTRL_INIT ctrl operation to initialise cipher_data. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From foleyj at cisco.com Wed May 13 17:19:40 2015 From: foleyj at cisco.com (John Foley) Date: Wed, 13 May 2015 13:19:40 -0400 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <555363AF.8000403@cisco.com> References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> Message-ID: <555387AC.90708@cisco.com> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind error. But this isn't a valid fix since bn_get_bits5 no longer returns the correct data. My assembly skills are near nil. Maybe someone else can propose a valid fix. Having said this, this does show the problem appears to be due to the movzwl reading past the end of the buffer by a byte. Given the data allocated on the heap is likely surrounded by guard bytes, this is likely a benign read outside the buffer. But it should still be fixed. On 05/13/2015 10:46 AM, John Foley wrote: > Sorry for misinterpreting your question, my mistake. I was able to > replicate the error. It looks like the invalid read is in code that's > compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the > X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and > 1.0.2, there are quite a few changes. My guess is this was introduced > in ec9cc70f72454b8d4a84247c86159613cee83b81. > > > > > On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: >> John Foley writes: >> >>> If you add the --show-reachable option to valgrind, you can see where >>> the leaks originate. They appear to be in the ex_data code (see >>> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >>> as well as 1.0.2a. >> Ah, I forgot to mention. I'm not concerned about the leak, but the >> invalid read that's in 1.0.2 only. >> >> This one: >> >>>> ==14854== Invalid read of size 2 >>>> ==14854== at 0x4F09198: bn_get_bits5 (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854== by 0x4F32B47: generate_key (in >>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>> ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > From rt at openssl.org Wed May 13 17:44:24 2015 From: rt at openssl.org (Gunnar Kudrjavets via RT) Date: Wed, 13 May 2015 19:44:24 +0200 Subject: [openssl-dev] [openssl.org #3848] [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods() In-Reply-To: References: Message-ID: Hello, Currently 'apps_shutdown()' in 'openssl.c' isn't freeing the compression methods. This is causing the CRT debug heap (and I assume various other tools) to indicate a memory leak. Though OS will free all the resources when user-mode application exits, it's better to do this explicitly inside 'apps_shutdown()'. As a bonus this change also helps to reach the clean state where debug heap is happy :-) Thank you, Gunnar Kudrjavets -------------- next part -------------- >From 108f2ef97d866d3750aac0dbe91cffe68e8b5181 Mon Sep 17 00:00:00 2001 From: Gunnar Kudrjavets Date: Wed, 13 May 2015 09:25:02 -0700 Subject: [PATCH] Fix memory leak caused by not calling SSL_COMP_free_compression_methods() Currently 'apps_shutdown()' in 'openssl.c' isn't freeing the compression methods. This is causing the CRT debug heap (and I assume various other tools) to indicate a memory leak. Though OS will free all the resources when user-mode application exits, it's better to do this explicitly inside 'apps_shutdown()'. As a bonus this change also helps to reach the clean state where debug heap is happy :-) CRT debug heap indicating that there's a leak: Detected memory leaks! Dumping objects -> {3375} normal block at 0x0AE76FE8, 16 bytes long. Data: < > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 {3374} normal block at 0x079A2FE8, 20 bytes long. Data: < o > 00 00 00 00 E8 6F E7 0A 00 00 00 00 04 00 00 00 Object dump complete. Stack trace pointing to the allocation which causes the leak: 0:000> | . 0 id: 84c create name: openssl.exe 0:000> kcn # 00 MSVCR120D!_heap_alloc_dbg_impl 01 MSVCR120D!_nh_malloc_dbg_impl 02 MSVCR120D!_nh_malloc_dbg 03 MSVCR120D!malloc 04 LIBEAY32!default_malloc_ex 05 LIBEAY32!CRYPTO_malloc 06 LIBEAY32!sk_new 07 SSLEAY32!load_builtin_compressions 08 SSLEAY32!SSL_COMP_get_compression_methods 09 SSLEAY32!SSL_library_init 0a openssl!apps_startup 0b openssl!main 0c openssl!__tmainCRTStartup 0d openssl!mainCRTStartup 0e KERNEL32!BaseThreadInitThunk 0f ntdll!__RtlUserThreadStart 10 ntdll!_RtlUserThreadStart --- apps/openssl.c | 1 + 1 file changed, 1 insertion(+) diff --git a/apps/openssl.c b/apps/openssl.c index fa3b683..952eaa4 100644 --- a/apps/openssl.c +++ b/apps/openssl.c @@ -188,6 +188,7 @@ static void apps_shutdown() CONF_modules_unload(1); #ifndef OPENSSL_NO_COMP COMP_zlib_cleanup(); + SSL_COMP_free_compression_methods(); #endif OBJ_cleanup(); EVP_cleanup(); -- 1.9.5.msysgit.1 From rt at openssl.org Wed May 13 18:39:43 2015 From: rt at openssl.org (Rich Salz via RT) Date: Wed, 13 May 2015 20:39:43 +0200 Subject: [openssl-dev] [openssl.org #1369] BUG Openssl executable 0.9.8a (Unix) fails when setuid/setgid In-Reply-To: <001a01c6ba24$179668c0$4001a8c0@psycho3> References: <001a01c6ba24$179668c0$4001a8c0@psycho3> Message-ID: commit b6d3cb543c2e91aa6820cde637db55ad1cee525f Author: Rich Salz Date: Mon May 4 07:52:27 2015 -0400 RT1369: don't do "helpful" access check. Don't do access check on destination directory; it breaks when euid/egid is different from real uid/gid. Reviewed-by: Richard Levitte Signed-off-by: Rich Salz -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From kurt at x64architecture.com Wed May 13 19:32:57 2015 From: kurt at x64architecture.com (Kurt Cancemi) Date: Wed, 13 May 2015 15:32:57 -0400 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <555387AC.90708@cisco.com> References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> Message-ID: Could this be the issue your seeing? It was fixed in boringssl I think. https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4 https://boringssl-review.googlesource.com/#/c/1393/ --- Kurt Cancemi https://www.x64architecture.com On Wed, May 13, 2015 at 1:19 PM, John Foley wrote: > Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind > error. But this isn't a valid fix since bn_get_bits5 no longer returns > the correct data. My assembly skills are near nil. Maybe someone else > can propose a valid fix. > > Having said this, this does show the problem appears to be due to the > movzwl reading past the end of the buffer by a byte. Given the data > allocated on the heap is likely surrounded by guard bytes, this is > likely a benign read outside the buffer. But it should still be fixed. > > > > On 05/13/2015 10:46 AM, John Foley wrote: >> Sorry for misinterpreting your question, my mistake. I was able to >> replicate the error. It looks like the invalid read is in code that's >> compiled in when OPENSSL_BN_ASM_MONT5 is set, which is only for the >> X86_64 target. Looking at the diff of x86_64-mont5.pl between 1.0.1 and >> 1.0.2, there are quite a few changes. My guess is this was introduced >> in ec9cc70f72454b8d4a84247c86159613cee83b81. >> >> >> >> >> On 05/13/2015 10:13 AM, Henrik Grindal Bakken wrote: >>> John Foley writes: >>> >>>> If you add the --show-reachable option to valgrind, you can see where >>>> the leaks originate. They appear to be in the ex_data code (see >>>> below). As a side note, I see 416 bytes lost when using OpenSSL 1.0.1f >>>> as well as 1.0.2a. >>> Ah, I forgot to mention. I'm not concerned about the leak, but the >>> invalid read that's in 1.0.2 only. >>> >>> This one: >>> >>>>> ==14854== Invalid read of size 2 >>>>> ==14854== at 0x4F09198: bn_get_bits5 (in >>>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>>> ==14854== by 0x4F32B47: generate_key (in >>>>> /home/henribak/src/thirdparty/openssl/libcrypto.so.1.0.0) >>>>> ==14854== by 0x400A30: main (in /home/henribak/tmp/dh-1.0.2) >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed May 13 22:55:57 2015 From: rt at openssl.org (=?UTF-8?B?Sm/Do28gUmVpcw==?= via RT) Date: Thu, 14 May 2015 00:55:57 +0200 Subject: [openssl-dev] [openssl.org #3849] [BUG] openssl s_client delays on Windows In-Reply-To: <1431543142517.27559@janeasystems.com> References: <1431543142517.27559@janeasystems.com> Message-ID: OpenSSL version: 1.0.2a after applying the patch from http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3464 OS: Windows (tested on Windows 2012 r2 64 bit and Windows 7 64 bit) openssl s_client introduces 2 delays of 1 second when closing the connection, clearly visible when running echo | openssl.exe s_client -connect google.com:443 -debug The openssl.exe was compiled from source after applying the patch from http://rt.openssl.org/Ticket/Display.html?user=guest&pass=guest&id=3464 These delays do not happen in Unix and Cygwin. A similar delay of 1 second is also introduced at start, when displaying the message "Loading 'screen' into random state". From rt at openssl.org Thu May 14 11:17:25 2015 From: rt at openssl.org (Gueron, Shay via RT) Date: Thu, 14 May 2015 13:17:25 +0200 Subject: [openssl-dev] [openssl.org #3850] [PATCH] Improved performance Multi Block CBC-SHA1 and CBC-SHA256 In-Reply-To: <3DE91BD01FD68540858FC917201D9B9939C0DD1D@hasmsx107.ger.corp.intel.com> References: <3DE91BD01FD68540858FC917201D9B9939C0DD1D@hasmsx107.ger.corp.intel.com> Message-ID: Hello all, This patch is a contribution to OpenSSL. It concerns the Multi Block (MB) CBC SHA1/SHA256 implementations (the function "tls1_1_multi_block_encrypt" in "e_aes_cbc_hmac_sha1.c" and "e_aes_cbc_hmac_sha256.c"). The patch addresses a slow derivation of the multiple random IV's for the CBC encryption (~12,000 Cycles on architecture Codename Haswell (HSW), 11,500 Cycles on architecture Codename Broadwell (BDW) ). This multiple IV's derivation impacts the performance gains from the parallelized encryption (and hashing). The new code extracts (only) 16 bytes with a Rand-bytes invocation, which are used as an auxiliary key, and then generates the required number of pseudorandom IV's by applying the decryption primitive. The effect is speedup on multi-block aes-128-cbc-hmac-sha*, and it is more pronounced for the shorter buffers (8192 bytes is the shortest length reported by openssl speed utility). Results: speedup (patch over current) for 8192 bytes size block CBC-SHA1 CBC-SHA256 HSW: 1.59x 1.36x BDW: 1.53x 1.33x Developers and authors: *************************************************************************** Shay Gueron (1, 2), Regev Shemy (2), Tal Uliel (2) (1) University of Haifa, Israel (2) Intel Corporation, Israel Development Center, Haifa, Israel *************************************************************************** --------------------------------------------------------------------- Intel Israel (74) Limited This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. -------------- next part -------------- A non-text attachment was scrubbed... Name: MB_IV_Patch_V01.patch Type: application/octet-stream Size: 14423 bytes Desc: not available URL: From jaltman at secure-endpoints.com Thu May 14 14:14:34 2015 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Thu, 14 May 2015 10:14:34 -0400 Subject: [openssl-dev] [openssl-users] Kerberos In-Reply-To: <55535D6C.4060109@openssl.org> References: <55487D88.7010909@openssl.org> <1431043217.2505.3.camel@redhat.com> <20150508004035.GE17272@mournblade.imrryr.org> <554C1142.9090002@secure-endpoints.com> <554C7691.80906@openssl.org> <55535D6C.4060109@openssl.org> Message-ID: <5554ADCA.4070902@secure-endpoints.com> On 5/13/2015 10:19 AM, Matt Caswell wrote: > > > On 08/05/15 09:40, Matt Caswell wrote: >> >> >> On 08/05/15 02:28, Jeffrey Altman wrote: >> >>> Regardless, the inability to improve the support in this area has left >>> the those organizations that rely upon 2712 with the choice of use >>> insecure protocols or re-implement the applications. I do not believe >>> that any sane OS or application vendor can with a straight face continue >>> to ship 2712 support. As such it should be removed from OpenSSL master. >> >> I plan to start preparing the patches to remove it next week. > > FYI, these patches have now been applied to master. > > Matt Thank you. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4589 bytes Desc: S/MIME Cryptographic Signature URL: From animesdas at gmail.com Fri May 15 11:47:13 2015 From: animesdas at gmail.com (Animesh Das) Date: Fri, 15 May 2015 17:17:13 +0530 Subject: [openssl-dev] Adding a new Engine to OpenSSL Message-ID: Hi, I have a new hardware crypto engine. The device can be accessed from user space application opening the device like "/dev/mydevice". There are also some IOCTLs which can be used from user space. I want to add that device as one of the engines of OpenSSL so that the encryption/decryption process can be offloaded to that device. I have new to OpenSSL. Could you please help me giving ideas/steps to add that engine in OpenSSL. Thanks Animesh Das -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri May 15 12:53:00 2015 From: matt at openssl.org (Matt Caswell) Date: Fri, 15 May 2015 13:53:00 +0100 Subject: [openssl-dev] Adding a new Engine to OpenSSL In-Reply-To: References: Message-ID: <5555EC2C.8000508@openssl.org> On 15/05/15 12:47, Animesh Das wrote: > Hi, > > I have a new hardware crypto engine. The device can be accessed from > user space application opening the device like "/dev/mydevice". There > are also some IOCTLs which can be used from user space. I want to add > that device as one of the engines of OpenSSL so that the > encryption/decryption process can be offloaded to that device. > > I have new to OpenSSL. Could you please help me giving ideas/steps to > add that engine in OpenSSL. Take a look at: demos/engines/rsaref/rsaref.c Matt From dwmw2 at infradead.org Fri May 15 16:48:49 2015 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 15 May 2015 17:48:49 +0100 Subject: [openssl-dev] Adding a new Engine to OpenSSL In-Reply-To: References: Message-ID: <1431708529.4727.8.camel@infradead.org> On Fri, 2015-05-15 at 17:17 +0530, Animesh Das wrote: > > I have a new hardware crypto engine. The device can be accessed > from user space application opening the device like > "/dev/mydevice". There are also some IOCTLs which can be used from > user space. I want to add that device as one of the engines of > OpenSSL so that the encryption/decryption process can be offloaded > to that device. > > I have new to OpenSSL. Could you please help me giving ideas/steps > to add that engine in OpenSSL. My first inclination is to say "don't". Make it a PKCS#11 provider instead, and let OpenSSL use it through engine_pkcs11. (OpenSSL really ought to gain first-class support for PKCS#11 too, FWIW). --?dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5691 bytes Desc: not available URL: From rt at openssl.org Sat May 16 03:21:49 2015 From: rt at openssl.org (Gola, Shailender K via RT) Date: Sat, 16 May 2015 05:21:49 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: Message-ID: I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac (this is also true in all other version which support SHA2 and TLS1/1.1/1.2, i.e. 0.9.8zf) client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac All platforms are using openssl 1.0.2a. There are no issues connecting to/from other platforms except to server running on Solaris. /home/v316509>cat /etc/release Solaris 10 11/06 s10s_u3wos_10 SPARC Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. Use is subject to license terms. Assembled 14 November 2006 /home/v316509>uname -a SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Any help will be appreciated. Shailender Gola Verizon Telecom From hgb at ifi.uio.no Sat May 16 18:56:03 2015 From: hgb at ifi.uio.no (Henrik Grindal Bakken) Date: Sat, 16 May 2015 20:56:03 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: (Kurt Cancemi's message of "Wed, 13 May 2015 15:32:57 -0400") References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> Message-ID: <877fs8nygs.fsf@zakalwe.freeside.no> Kurt Cancemi writes: > Could this be the issue your seeing? It was fixed in boringssl I think. > https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4 > https://boringssl-review.googlesource.com/#/c/1393/ I haven't looked at the code (not much of an x86 assembler programmer...), but from the boringssl description, it sounds very much like the same thing. No big surprise, of course, as it shows up very quickly with valgrind. -- Henrik Grindal Bakken PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 From kurt at x64architecture.com Sun May 17 19:13:13 2015 From: kurt at x64architecture.com (Kurt Cancemi) Date: Sun, 17 May 2015 15:13:13 -0400 Subject: [openssl-dev] [question] Useless NULL check or Missing NULL check? Message-ID: Hello, If anyone from the openssl dev team can answer this question about the openssl code: In ssl_lib.c in SSL_shutdown(), s->handshake_func is compared against 0 (inferring that s != NULL) and then there is a NULL check that (s != NULL) which the compiler optimizes out because (s) is inferred to not be NULL because of the check (s->handshake_func == 0). So is there supposed to be a NULL check before the check (s->handshake_func == 0) or no? Note: This behavior was changed in commit b31b04 in 1999. --- Kurt Cancemi https://www.x64architecture.com From rt at openssl.org Sun May 17 20:06:02 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Sun, 17 May 2015 22:06:02 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: References: Message-ID: Found by the https://github.com/xiw/stack tool and then I checked the generated asm (gcc and clang) to confirm. In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true because the compiler optimizes out the tmp_ulong value to true because (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) a logical right-shift overflow. The commit "don't write beyond buffer " (c237de0) added this check. --- Kurt Cancemi https://www.x64architecture.com From matt at openssl.org Mon May 18 07:49:59 2015 From: matt at openssl.org (Matt Caswell) Date: Mon, 18 May 2015 08:49:59 +0100 Subject: [openssl-dev] [question] Useless NULL check or Missing NULL check? In-Reply-To: References: Message-ID: <555999A7.1010002@openssl.org> On 17/05/15 20:13, Kurt Cancemi wrote: > Hello, > > If anyone from the openssl dev team can answer this question about the > openssl code: > > In ssl_lib.c in SSL_shutdown(), s->handshake_func is compared against > 0 (inferring that s != NULL) and then there is a NULL check that (s > != NULL) which the compiler optimizes out because (s) is inferred to > not be NULL because of the check (s->handshake_func == 0). > > So is there supposed to be a NULL check before the check > (s->handshake_func == 0) or no? > > Note: This behavior was changed in commit b31b04 in 1999. IMO almost all SSL_* functions require that you pass a valid SSL object otherwise you will probably get a crash. I see no reason why SSL_shutdown() should be any different, therefore I'd say the NULL check is superfluous. Matt From rt at openssl.org Mon May 18 15:44:58 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 18 May 2015 17:44:58 +0200 Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface In-Reply-To: <555A08F0.8030508@openssl.org> References: <555A08F0.8030508@openssl.org> Message-ID: Poly1305 implementations can be classified by amount of significant bits in words making up multi-precision values involved, or in other words base of numerical representation, e.g. base 2^64, base 2^32, base 2^26. It's not obvious that single specific base would be optimal choice for all platforms, rather contrary. Attached code provides pair of reference C implementations, base 2^64 and base 2^32, and at assembly level utilizes mixture of bases depending on processor code is currently executed on. The choices are discussed in commentary sections (if not obvious). For example, as it turns out, on most recent x86_64 platforms scalar integer-only base 2^64 implementation is actually best choice for processing single or small amount of input blocks. It even turned to be best choice for some of them, most notably from Atom family. As result it's argued that SSE2 implementation can be omitted on x86_64, because it provides improvement only on old processors, too old to care about (well, one can probably still argue in favor of Westmere, but luckily performance improvement is least on it). On related note, given AVX results, one can say that if not for Bulldozer, one could have argued in favor of omitting even AVX. The too-old-to-care-about card is used even to dismiss 32-bit FP implementation. It's a bit tricky, because even though reported SSE2 results are better than FP, it doesn't necessarily hold true for single block (because in SIMD case we effectively calculate more and discard unused data). "Not necessarily" means you'll measure both ways. But as in most interesting cases, contemporary Intel i[357], it's actually no gain, FP implementation is omitted, too much additional complexity for too little gain. Especially if we take into account additional pre-computation and conversion costs. Another thing that is distinctly different in suggested code is that I don't attempt to process sub-block lengths in assembly. These, sub-block lengths, are handled in C instead. > (I hope I'm doing this right) > > These are my Chacha implementations for reference, x86, SSE2, SSSE3, XOP, > AVX, and AVX2, and Poly1305 implementations for reference, SSE2, AVX, and > AVX2 for both 32 and 64 bits. (djb's floating point poly1305 is used for 32 > bits). I do things a bit differently with the assembler code to make > supporting multiple versions easier, I don't know if it is too non-standard > or not. Everything is as fast as possible, so hopefully some or all of it > can be used to fill things out, or give you ideas on how to surpass it. Thank you very much! Trouble with this submission is that lack of annotations (commentary and symbolic names for register variables) makes it prohibitively hard to unravel the ideas. Instead I wonder if you could have a look at attached code and tell what you think. Side note about surpassing. Two things to keep in mind. First, objective is always "all-round" performance on multiple platforms, so that if there is some optimization that benefits one processor, it's weighted against other processors. I mean if it harms other processors significantly, then optimization is omitted (or isolated to dedicated code path). Secondly, question is not how fast does it go in absolute terms, but how far is it from theoretical estimate in every specific case (based on front-end throughput, port availability, latencies, critical path lengths, etc.) and of course why. In this context it's interesting to consider AVX result on current Intel processors. Indeed, note that Bulldozer managed in less than 1 cpb, while contemporary Intel AVX-capable processors in ~1.15. But Intel processors are architecturally capable of achieving higher instruction-per-cycle ratio, so that result at least should not be worse than Bulldozer's. Is it subtle port availability limitation? Some anomaly in scheduling? It remains to be seen... More coming in. Cheers. -------------- next part -------------- A non-text attachment was scrubbed... Name: poly1305.c Type: text/x-csrc Size: 23872 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: poly1305-x86.pl Type: application/x-perl Size: 49967 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: poly1305-x86_64.pl Type: application/x-perl Size: 43196 bytes Desc: not available URL: From rt at openssl.org Mon May 18 20:41:05 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 18 May 2015 22:41:05 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: <555A4E56.7080900@openssl.org> References: <555A4E56.7080900@openssl.org> Message-ID: > Found by the https://github.com/xiw/stack tool and then I checked the > generated asm (gcc and clang) to confirm. > > In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true > because the compiler optimizes out the tmp_ulong value to true because > (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) > a logical right-shift overflow. What's right-shift overflow? In either case, are you sure about it being optimized away because it always evaluates to true? Thing is that if tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean check for d0 alone would actually produce same outcome, wouldn't it? From rt at openssl.org Mon May 18 20:54:42 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 18 May 2015 22:54:42 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: <555A518A.4030101@openssl.org> References: <555A518A.4030101@openssl.org> Message-ID: > I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > > (this is also true in all other version which support SHA2 and TLS1/1.1/1.2, i.e. 0.9.8zf) > > client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac > > All platforms are using openssl 1.0.2a. Including SPARC Solaris one? Is it correctly understood? If so, you probably have compiled it yourself. In such case, which compiler and next question would be how do we know it's not a compiler bug? Or in other words question is if you can confirm that problem persists even if you drop optimization level [when compiling OpenSSL]. > There are no issues connecting to/from other platforms except to server running on Solaris. > > /home/v316509>cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > /home/v316509>uname -a > SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Provide even output from 'openssl version -a'. From wiml at omnigroup.com Mon May 18 21:11:20 2015 From: wiml at omnigroup.com (Wim Lewis) Date: Mon, 18 May 2015 14:11:20 -0700 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: References: <555A4E56.7080900@openssl.org> Message-ID: <6EFBC9A9-6C80-4182-AB59-DDA20D3EE442@omnigroup.com> On May 18, 2015, at 1:41 PM, Andy Polyakov via RT wrote: >> Found by the https://github.com/xiw/stack tool and then I checked the >> generated asm (gcc and clang) to confirm. >> >> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >> because the compiler optimizes out the tmp_ulong value to true because >> (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) >> a logical right-shift overflow. > > What's right-shift overflow? In either case, are you sure about it being > optimized away because it always evaluates to true? Thing is that if > tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean > check for d0 alone would actually produce same outcome, wouldn't it? Right-shifting by *equal to* or more than the width of the word produces undefined results in C (just like left-shifting); one expects that it produces zero, but the language spec says it?s undefined. Presumably, clang is taking advantage of the undefined behavior to eliminate the check: it notices that if, in this case, an excessive right shift always returns a nonzero value (which is allowed), then it can produce smaller code. (From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section 6.5.7: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." See also e.g.: http://blog.regehr.org/archives/213 ) I agree that the test for tmp_ulong being nonzero is redundant. And the shift overflow presumably only happens when d0 is zero anyway, so the undefined behavior can't affect the output. But it might make sense to move the right-shift into the if() as well. Given the commit message was "don't write beyond buffer", though, I think there was possibly intended to be a different test there that makes more sense? From rt at openssl.org Mon May 18 21:20:45 2015 From: rt at openssl.org (Wim Lewis via RT) Date: Mon, 18 May 2015 23:20:45 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: <6EFBC9A9-6C80-4182-AB59-DDA20D3EE442@omnigroup.com> References: <555A4E56.7080900@openssl.org> <6EFBC9A9-6C80-4182-AB59-DDA20D3EE442@omnigroup.com> Message-ID: On May 18, 2015, at 1:41 PM, Andy Polyakov via RT wrote: >> Found by the https://github.com/xiw/stack tool and then I checked the >> generated asm (gcc and clang) to confirm. >> >> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >> because the compiler optimizes out the tmp_ulong value to true because >> (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) >> a logical right-shift overflow. > > What's right-shift overflow? In either case, are you sure about it being > optimized away because it always evaluates to true? Thing is that if > tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean > check for d0 alone would actually produce same outcome, wouldn't it? Right-shifting by *equal to* or more than the width of the word produces undefined results in C (just like left-shifting); one expects that it produces zero, but the language spec says it?s undefined. Presumably, clang is taking advantage of the undefined behavior to eliminate the check: it notices that if, in this case, an excessive right shift always returns a nonzero value (which is allowed), then it can produce smaller code. (From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section 6.5.7: "If the value of the right operand is negative or is greater than or equal to the width of the promoted left operand, the behavior is undefined." See also e.g.: http://blog.regehr.org/archives/213 ) I agree that the test for tmp_ulong being nonzero is redundant. And the shift overflow presumably only happens when d0 is zero anyway, so the undefined behavior can't affect the output. But it might make sense to move the right-shift into the if() as well. Given the commit message was "don't write beyond buffer", though, I think there was possibly intended to be a different test there that makes more sense? From quanah at zimbra.com Mon May 18 21:32:14 2015 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Mon, 18 May 2015 14:32:14 -0700 Subject: [openssl-dev] deadlock issue with OpenSSL 1.0.1j Message-ID: <22BAFCF8B929B9A55F527DCF@[192.168.1.9]> We've been seeing a problem with openssl deadlocking in the 1.0.1j release that didn't occur in previous releases. I've looked over the change log fixes for the k, l, and m releases, but I haven't seen anything that appears to resolve a deadlock problem. Does anyone know of such an issue that was released since 1.0.1j? Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Mon May 18 22:01:26 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 19 May 2015 00:01:26 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: <555A6128.4010703@openssl.org> References: <555A4E56.7080900@openssl.org> <6EFBC9A9-6C80-4182-AB59-DDA20D3EE442@omnigroup.com> <555A6128.4010703@openssl.org> Message-ID: >>> Found by the https://github.com/xiw/stack tool and then I checked the >>> generated asm (gcc and clang) to confirm. >>> >>> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >>> because the compiler optimizes out the tmp_ulong value to true because >>> (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) >>> a logical right-shift overflow. >> What's right-shift overflow? In either case, are you sure about it being >> optimized away because it always evaluates to true? Thing is that if >> tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean >> check for d0 alone would actually produce same outcome, wouldn't it? > > Right-shifting by *equal to* or more than the width of the word produces undefined results in C (just like left-shifting); one expects that it produces zero, but the language spec says it?s undefined. I understand that. I don't understand why would one call it *overflow*. > Presumably, clang is taking advantage of the undefined behavior to eliminate the check: it notices that if, in this case, an excessive right shift always returns a nonzero value (which is allowed), then it can produce smaller code. Well, in this case the only excessive case is shift by word width, which in practice, i.e. on contemporary processors, means no change at all. In more general case it's shift by modulo word width. I mean shift by 65 is equivalent to shift by 1. This is not an excuse for relying on this in code that is supposed to be portable! Just clarification. It should be noted that this doesn't really affect original question, i.e. the assertion that check for d0 alone should be sufficient. > (From http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf section 6.5.7: "If the value of the right operand is negative or is > greater than or equal to the width of the promoted left operand, the behavior is undefined." See also e.g.: http://blog.regehr.org/archives/213 ) > > I agree that the test for tmp_ulong being nonzero is redundant. And the shift overflow presumably only happens when d0 is zero anyway, so the undefined behavior can't affect the output. But it might make sense to move the right-shift into the if() as well. In other words original if (d0) z[n + 1] ^= zz >> d1; should have been sufficient. > Given the commit message was "don't write beyond buffer", though, I think there was possibly intended to be a different test there that makes more sense? Right, it appears that it needs closer look. On it... From appro at openssl.org Mon May 18 22:13:29 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 19 May 2015 00:13:29 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> Message-ID: <555A6409.4040508@openssl.org> I'm looking into it and have a quick note. > Could this be the issue your seeing? It was fixed in boringssl I think. > https://boringssl.googlesource.com/boringssl/+/bf681a40d6142edfa44a27dc0d6e07e0c37865a4 > https://boringssl-review.googlesource.com/#/c/1393/ The reason for why that solution is not acceptable for OpenSSL is that it implies that target is little-endian and can sustain unaligned reference. It's appropriate to make such assumptions in platform-specific code such as assembly, but not in general case. It works in BoringSSL, because they limit themselves to such platforms. From shailender.gola at verizon.com Mon May 18 22:45:56 2015 From: shailender.gola at verizon.com (Gola, Shailender K) Date: Mon, 18 May 2015 18:45:56 -0400 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> Message-ID: Thanks for the timely response... below is version we are using. I also must point out that we are currently using 0.9.8g for several years, I tried to upgrade to .9.8zf, and several 1.0.x versions and had the same error. The "./Configure solaris-x86-cc" was used to install openssl. Also below is 0.9.8g version which is in use currently. This is the version with issue (also 0.9.8zf and several 1.0.x has same errors) /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> This is the version in use with no issues : /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Monday, May 18, 2015 4:55 PM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad > record mac > > (this is also true in all other version which support SHA2 and > TLS1/1.1/1.2, i.e. 0.9.8zf) > > client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 > alert bad record mac > > All platforms are using openssl 1.0.2a. Including SPARC Solaris one? Is it correctly understood? If so, you probably have compiled it yourself. In such case, which compiler and next question would be how do we know it's not a compiler bug? Or in other words question is if you can confirm that problem persists even if you drop optimization level [when compiling OpenSSL]. > There are no issues connecting to/from other platforms except to server running on Solaris. > > /home/v316509>cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > /home/v316509>uname -a > SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Provide even output from 'openssl version -a'. From rt at openssl.org Mon May 18 22:57:08 2015 From: rt at openssl.org (Gola, Shailender K via RT) Date: Tue, 19 May 2015 00:57:08 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> Message-ID: Thanks for the timely response... below is version we are using. I also must point out that we are currently using 0.9.8g for several years, I tried to upgrade to .9.8zf, and several 1.0.x versions and had the same error. The "./Configure solaris-x86-cc" was used to install openssl. Also below is 0.9.8g version which is in use currently. This is the version with issue (also 0.9.8zf and several 1.0.x has same errors) /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> This is the version in use with no issues : /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Monday, May 18, 2015 4:55 PM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad > record mac > > (this is also true in all other version which support SHA2 and > TLS1/1.1/1.2, i.e. 0.9.8zf) > > client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 > alert bad record mac > > All platforms are using openssl 1.0.2a. Including SPARC Solaris one? Is it correctly understood? If so, you probably have compiled it yourself. In such case, which compiler and next question would be how do we know it's not a compiler bug? Or in other words question is if you can confirm that problem persists even if you drop optimization level [when compiling OpenSSL]. > There are no issues connecting to/from other platforms except to server running on Solaris. > > /home/v316509>cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > /home/v316509>uname -a > SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Provide even output from 'openssl version -a'. From gwang at litespeedtech.com Mon May 18 22:58:35 2015 From: gwang at litespeedtech.com (George Wang) Date: Mon, 18 May 2015 18:58:35 -0400 Subject: [openssl-dev] bug in openssl 1.0.2a, s3_pkt.c ssl3_write_bytes() Message-ID: <555A6E9B.3010406@litespeedtech.com> Hi, Have to send it again. I have posted it to google group, did not get any response. below is the bug report. --------------- It is likely the code change between 1.0.1m and 1.0.2a in s3_pkt.c ssl3_write_bytes() introduces a bug. We got similar core dumps from both LiteSpeed Enterprise Web Server and OpenLiteSpeed when OpenSSL 1.0.2a is used. Below is an example from related call stack backtrace: #0 0x00000034e06897cb in memcpy () from /lib64/libc.so.6 #1 0x00000000005efbde in do_ssl3_write (s=0x36938a0, type=23, buf=0x7fff96fc2830 "=server.xxxxxxxxx.com", len=16384, create_empty_fragment=0) at s3_pkt.c:1005 #2 0x00000000005ef690 in ssl3_write_bytes (s=0x36938a0, type=23, buf_=0x7fff96fba830, len=332) at s3_pkt.c:819 #3 0x0000000000633a1c in ssl3_write (s=0x36938a0, buf=0x7fff96fba830, len=332) at s3_lib.c:4399 #4 0x00000000006051fb in SSL_write (s=0x36938a0, buf=0x7fff96fba830, num=332) at ssl_lib.c:1046 #5 0x000000000052ce78 in SSLConnection::write (this=0x2e0d1c8, pBuf=0x7fff96fba830 "HTTP/1.1 200 OK\r\nCache-Control: public, max-age=2592000\r\nExpires: Sun, 31 May 2015 03:40:08 GMT\r\nETag: \"272eb-52dd9559-8cbab174726a68a6\"\r\nLast-Modified: Mon, 20 Jan 2014 21:30:01 GMT\r\nContent-Type: im"..., len=332) at /home/gwang/release/litespeed/src/sslpp/sslconnection.cpp:139 The problem is in ssl3_write_bytes(), local variables: (gdb) up #2 0x00000000005ef690 in ssl3_write_bytes (s=0x36938a0, type=23, buf_=0x7fff96fba830, len=332) at s3_pkt.c:819 819 in s3_pkt.c (gdb) info local buf = 0x7fff96fba830 "HTTP/1.1 200 OK\r\nCache-Control: public, max-age=2592000\r\nExpires: Sun, 31 May 2015 03:40:08 GMT\r\nETag: \"272eb-52dd9559-8cbab174726a68a6\"\r\nLast-Modified: Mon, 20 Jan 2014 21:30:01 GMT\r\nContent-Type: im"... tot = 32768 n = 4294934860 nw = 16384 max_send_fragment = 16384 wb = 0x36faa28 i = 16384 (gdb) print s->s3->wnum $1 = 0 (gdb) print *wb $2 = {buf = 0x3952da0 " \002\224\027\003\001@ =server.xxxxxxxxx.com", len = 16472, offset = 3, left = 0} (gdb) print *s->s3 $3 = {flags = 1, delay_buf_pop_ret = 0, read_sequence = "\000\000\000\000\000\000\000\v", read_mac_secret_size = 20, read_mac_secret = "\266\v\346\331+\341\223\065?Zo6'=\302q\347\031K", '\000' , write_sequence = "\000\000\000\000\000\000\000\026", write_mac_secret_size = 20, write_mac_secret = "\245\351?x\373\026S\274j\177\242\334?\204\226\360S\263", '\000' , server_random = "\277a\006S\000zU\214\243\337\373\070>z\205S\222`\245pZ\222WW\226\021\025\345\377\252\065\213", client_random = "UB\365\224\222 at zL\353\312\347tO\270\350_\346X?\214!\212Z\251P\310?\365\232\n*", need_empty_fragments = 0, empty_fragment_done = 1, init_extra = 1, rbuf = {buf = 0x0, len = 33096, offset = 792, left = 0}, wbuf = {buf = 0x3952da0 " \002\224\027\003\001@ =server.xxxxxxxxx.com", len = 16472, offset = 3, left = 0}, rrec = {type = 23, length = 0, off = 0, data = 0x2ae5aa8 "GET /files/cache/1c90376361dd83f4e4778af84377185a.jpg HTTP/1.1\r\nHost: www.xxxxxxxxxxxx.com\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.59.10 (KHTML, like Gecko) Versi"..., input = 0x2ae5aa8 "GET /files/cache/1c90376361dd83f4e4778af84377185a.jpg HTTP/1.1\r\nHost: www.xxxxxxxxxxxx.com\r\nUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.59.10 (KHTML, like Gecko) Versi"..., comp = 0x0, epoch = 0, seq_num = "\000\000\000\000\000\000\000"}, wrec = {type = 23, length = 16384, off = 0, data = 0x3952da8 "=server.xxxxxxxxx.com", input = 0x7fff96fc2830 "=server.xxxxxxxxx.com", comp = 0x0, epoch = 0, seq_num = "\000\000\000\000\000\000\000"}, alert_fragment = "\000", alert_fragment_len = 0, handshake_fragment = "\000\000\000", handshake_fragment_len = 0, wnum = 0, wpend_tot = 16384, wpend_type = 23, wpend_ret = 16384, wpend_buf = 0x7fff96fbe830 "\223)\374\226\377\177", handshake_buffer = 0x0, handshake_dgst = 0x36d5f60, change_cipher_spec = 0, warn_alert = 0, fatal_alert = 0, alert_dispatch = 0, send_alert = "\000", renegotiate = 0, total_renegotiations = 0, num_renegotiations = 0, in_read_app_data = 0, client_opaque_prf_input = 0x0, client_opaque_prf_input_len = 0, server_opaque_prf_input = 0x0, server_opaque_prf_input_len = 0, tmp = {cert_verify_md = '\000' , finish_md = "?\343c\271?\224N\373g\256", '\000' , finish_md_len = 12, peer_finish_md = "\022\221\257\371\231\f\324%\317:\342,", '\000' , peer_finish_md_len = 12, message_size = 12, message_type = 20, new_cipher = 0xb8a440, dh = 0x0, ecdh = 0x0, next_state = 8640, reuse_message = 0, cert_req = 0, ctype_num = 0, ctype = "\000\000\000\000\000\000\000\000", ca_names = 0x0, use_rsa_tmp = 0, key_block_length = 0, key_block = 0x0, new_sym_enc = 0xb8c4a0, new_hash = 0x0, new_mac_pkey_type = 855, new_mac_secret_size = 20, new_compression = 0x0, cert_request = 0}, previous_client_finished = "\022\221\257\371\231\f\324%\317:\342,", '\000' , previous_client_finished_len = 12 '\f', previous_server_finished = "?\343c\271?\224N\373g\256", '\000' , previous_server_finished_len = 12 '\f', send_connection_binding = 0, next_proto_neg_seen = 0, is_probably_safari = 1 '\001', alpn_selected = 0x0, alpn_selected_len = 0} The variable causing problem is tot = 32768 tot should be less than "len", while, len = 332 analyzing the code change between 1.0.1m and 1.0.2a, the following code should be the source of the problem, /* * first check if there is a SSL3_BUFFER still being written out. This * will happen with non blocking IO */ if (wb->left != 0) { i = ssl3_write_pending(s, type, &buf[tot], s->s3->wpend_tot); if (i <= 0) { /* XXX should we ssl3_release_write_buffer if i<0? */ s->s3->wnum = tot; return i; } tot += i; /* this might be last fragment */ } looks like ssl3_write_pending() return 16384, increase "tot" value by 16384, made it greater than "len", end up causing "n = 4294934860". It only happens when there are pending data flushed. 1.0.1m code does not have the logic to flush pending data. I hope someone really know how it should work can help to fix this. 1.0.2a is not very stable, we see some other strange behaviors as well. We use 1.0.2a because we want to have ALPN for our HTTP/2 implementation, but looks like we may have to fallback to 1.0.1m, or looking into something else if we have to have ALPN. Best regards, George Wang From rt at openssl.org Mon May 18 23:49:21 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Tue, 19 May 2015 01:49:21 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: References: <555A4E56.7080900@openssl.org> <6EFBC9A9-6C80-4182-AB59-DDA20D3EE442@omnigroup.com> <555A6128.4010703@openssl.org> Message-ID: >>>> Found by the https://github.com/xiw/stack tool and then I checked the >>>> generated asm (gcc and clang) to confirm. >>>> >>>> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >>>> because the compiler optimizes out the tmp_ulong value to true because >>>> (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) >>>> a logical right-shift overflow. >>> What's right-shift overflow? In either case, are you sure about it being >>> optimized away because it always evaluates to true? Thing is that if >>> tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean >>> check for d0 alone would actually produce same outcome, wouldn't it? >> >> Right-shifting by *equal to* or more than the width of the word produces undefined results in C (just like left-shifting); one expects that it produces zero, but the language spec says it?s undefined. > > I understand that. I don't understand why would one call it *overflow*. Now that I took a look at the tools source, it probably wasn't an overflow the tool just detected that the shr instruction was changed and for whatever reason calls it an overflow no mater the change, I should have taken a look at the tools source first. But the original commits intention should be checked out. From appro at openssl.org Tue May 19 07:49:52 2015 From: appro at openssl.org (Andy Polyakov) Date: Tue, 19 May 2015 09:49:52 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <555387AC.90708@cisco.com> References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> Message-ID: <555AEB20.1000009@openssl.org> > Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind > error. But this isn't a valid fix since bn_get_bits5 no longer returns > the correct data. My assembly skills are near nil. Maybe someone else > can propose a valid fix. > > Having said this, this does show the problem appears to be due to the > movzwl reading past the end of the buffer by a byte. Correct. > Given the data > allocated on the heap is likely surrounded by guard bytes, this is > likely a benign read outside the buffer. Correct. > But it should still be fixed. Test attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: mont5.diff Type: text/x-patch Size: 571 bytes Desc: not available URL: From rt at openssl.org Tue May 19 08:13:15 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 19 May 2015 10:13:15 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: <555AF092.6020808@openssl.org> References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> Message-ID: > Thanks for the timely response... below is version we are using. I > also must point out that we are currently using 0.9.8g for several > years, I tried to upgrade to .9.8zf, and several 1.0.x versions and > had the same error. The "./Configure solaris-x86-cc" was used to > install openssl. But the question was about SPARC... Anyway. Once again, 1st question in situation like that is if we are dealing with compiler bug. To answer it you should drop optimization level and see if problem persists. > Also below is 0.9.8g version which is in use > currently. > > This is the version with issue (also 0.9.8zf and several 1.0.x has > same errors) > > /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a > OpenSSL 1.0.2a 19 Mar 2015 > built on: reproducible build, date unspecified > platform: solaris-sparcv9-cc > options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) > compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM > OPENSSLDIR: "/usr/local/ssl" > /home/v316509/ssl/openssl-1.0.2a/apps> > > > This is the version in use with no issues : > > /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a > OpenSSL 0.9.8g 19 Oct 2007 > built on: Mon May 18 18:14:46 EDT 2015 > platform: solaris-x86-cc > options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) > compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa > OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" Objective also is to pinpoint the problem to specific algorithm on specific platform. Mentioning two distinct platforms running different versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things clearer. You have to present evidence that directly supports given assumption, i.e. that 1.0.2 fails on SPARC. As for identifying algorithm. You can do so by playing with -cipher option to openssl s_client. Well, one can specify it even with s_server, but s_client is more practical for obvious reasons. From hgb at ifi.uio.no Tue May 19 08:34:30 2015 From: hgb at ifi.uio.no (Henrik Grindal Bakken) Date: Tue, 19 May 2015 10:34:30 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <555AEB20.1000009@openssl.org> (Andy Polyakov's message of "Tue, 19 May 2015 09:49:52 +0200") References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> <555AEB20.1000009@openssl.org> Message-ID: Andy Polyakov writes: >> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind >> error. But this isn't a valid fix since bn_get_bits5 no longer returns >> the correct data. My assembly skills are near nil. Maybe someone else >> can propose a valid fix. >> >> Having said this, this does show the problem appears to be due to the >> movzwl reading past the end of the buffer by a byte. > > Correct. > >> Given the data allocated on the heap is likely surrounded by guard >> bytes, this is likely a benign read outside the buffer. > > Correct. > >> But it should still be fixed. > > Test attached. This patches fixed the valgrind errors for me. -- Henrik Grindal Bakken PGP ID: 8D436E52 Fingerprint: 131D 9590 F0CF 47EF 7963 02AF 9236 D25A 8D43 6E52 From matt at openssl.org Tue May 19 10:45:40 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 May 2015 11:45:40 +0100 Subject: [openssl-dev] bug in openssl 1.0.2a, s3_pkt.c ssl3_write_bytes() In-Reply-To: <555A6E9B.3010406@litespeedtech.com> References: <555A6E9B.3010406@litespeedtech.com> Message-ID: <555B1454.1030305@openssl.org> On 18/05/15 23:58, George Wang wrote: > The variable causing problem is > > tot = 32768 > > tot should be less than "len", while, len = 332 > > analyzing the code change between 1.0.1m and 1.0.2a, the following code > should be the source of the problem, > > /* > * first check if there is a SSL3_BUFFER still being written out. This > * will happen with non blocking IO > */ > if (wb->left != 0) { > i = ssl3_write_pending(s, type, &buf[tot], s->s3->wpend_tot); > if (i <= 0) { > /* XXX should we ssl3_release_write_buffer if i<0? */ > s->s3->wnum = tot; > return i; > } > tot += i; /* this might be last fragment */ > } > > > looks like ssl3_write_pending() return 16384, increase "tot" value by > 16384, made it greater than "len", end up causing "n = 4294934860". > > It only happens when there are pending data flushed. 1.0.1m code does > not have the logic to flush pending data. >From a user application perspective application data is being written using SSL_write(). That ultimately gets passed down to this function, ssl3_write_bytes(), where |buf| is the pointer to the user buffer and |len| is the length of that buffer. It may be that the length of the application data is too long to fit into a single TLS record, and therefore we may have to split that data up. The variable |tot| holds the amount of data that we have successfully written out so far in complete records. The current record being written is held in an SSL3_BUFFER structure, and it is that current buffer that ssl3_write_pending() is trying to write out. Of course with non-blocking IO at some point during the attempt to write out data we may not be able to (i.e. where the write would block in blocking IO). In that instance ssl3_write_pending() returns a value <=0 and control is returned to the user application. The user application (at some later point) is expected to call SSL_write() again with exactly the *same* arguments as the previous call, i.e. the same |buf| and the same value for |len|. The function ssl3_write_pending() only actually has two possible types of return. It can return <=0 to indicate an error (which can also mean that a non-blocking IO attempt would normally block), or it can return the length of the pending data in the SSL3_BUFFER that it successfully wrote out. This value is |s->s3->wpend_ret| which (for the purposes of this discussion) always holds the same value as |s->s3->wpend_tot|. When we return from the call to ssl3_write_pending() we add the amount of data we wrote out to |tot|. If in the call to ssl3_write_bytes() we discover that |wb->left != 0| this means we are being called again after a previous call to SSL_write() would have blocked, i.e. there is data still in the SSL3_BUFFER to be written out. Therefore we call ssl3_write_pending() to write out that data. We do some sanity checks along the way though. First here: if (len < tot) { SSLerr(SSL_F_SSL3_WRITE_BYTES, SSL_R_BAD_LENGTH); return (-1); } It should never be the case that we have written out more data than the length of the application buffer passed in the call to SSL_write(). If we have then something has gone wrong....almost certainly the application has changed the value of |len| in the retry attempt. Next there is this check within ssl3_write_pending(): if ((s->s3->wpend_tot > (int)len) || ((s->s3->wpend_buf != buf) && !(s->mode & SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER)) || (s->s3->wpend_type != type)) { SSLerr(SSL_F_SSL3_WRITE_PENDING, SSL_R_BAD_WRITE_RETRY); return (-1); } So this checks that the amount of data in the SSL3_BUFFER |s->s3->wpend_tot| isn't greater than the length of the application buffer left to write out. Again if this check fails then something has gone wrong....also probably because the application has changed the value of |len| in the retry attempt. The other checks are similar...we check that the application hasn't changed its buffer location. The final check is to ensure that the type of data hasn't changed (e.g. we've got handshake data in the SSL3_BUFFER, but now we're trying to write application data). If any of these sanity checks fail then we get an SSL_R_BAD_WRITE_RETRY error returned. *But* it looks like there is a bug here. The value of |len| in this last set of checks is the third argument passed to ssl3_write_pending(). It is supposed to represent the amount of application data that is in the application buffer still to be written out. Our call to ssl3_write_pending() looks like this: i = ssl3_write_pending(s, type, &buf[tot], s->s3->wpend_tot); What we are actually passing is |s->s3->wpend_tot|. This is the amount of data pending in the SSL3_BUFFER structure! It probably should look like this: i = ssl3_write_pending(s, type, &buf[tot], len - tot); Due to this problem it means that the sanity check for the length of data in ssl3_write_pending() always passes. So, in the event that the application calls SSL_write() again when it should be passing the same values again, but instead passes a much reduced value for |len|, then our sanity checks will not detect this issue. The result will be that the return from ssl3_write_pending() will be too large and hence tot will end up > len...eventually leading to a crash. The attached patch for 1.0.2a corrects this issue. Please could you try it out and see if it resolves your issue. *If* all of the above is what is happening in your case *then* what this means is that there is a second bug here, probably in the application code, which means that SSL_write() is being called with different arguments in a retry attempt. Most likely a previous call to SSL_write() has failed to detect the error return and act on it accordingly. If that's the case then hopefully this patch will help you track down where it is occurring. > > I hope someone really know how it should work can help to fix this. > > 1.0.2a is not very stable, we see some other strange behaviors as well. I'd be interested to know what other issues you are encountering. Possibly they are related? Hope that helps. Let me know how you get on, Matt -------------- next part -------------- A non-text attachment was scrubbed... Name: bad-write-retry.patch Type: text/x-patch Size: 1324 bytes Desc: not available URL: From rt at openssl.org Tue May 19 11:48:36 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 19 May 2015 13:48:36 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: <555B2101.8000202@openssl.org> References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> <555B2101.8000202@openssl.org> Message-ID: > Objective also is to pinpoint the problem to specific algorithm on > specific platform. Mentioning two distinct platforms running different > versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things > clearer. You have to present evidence that directly supports given > assumption, i.e. that 1.0.2 fails on SPARC. Or course you probably mean to say that this is evidence that SHA2 appears to be broken on SPARC. In order to make trouble-shooting more structured it's appropriate to double-check and confirm this by testing different s_client -cipher against s_server running on SPARC. Then to spare time one can drop optimization level only for affected module by manually removing corresponding .o, modifying CFLAG in top Makefile and re-running make. This way only couple of files will be recompiled so you don't have to wait for complete build (which is rather slow on SPARC). In other words, identify algorithm first, then experiment with compiler optimization levels. From rt at openssl.org Tue May 19 14:24:04 2015 From: rt at openssl.org (Gola, Shailender K via RT) Date: Tue, 19 May 2015 16:24:04 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> <555B2101.8000202@openssl.org> Message-ID: I am reattaching previous communication for reference. 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see attachment 2 showing " platform: solaris-x86-cc " (which I had done before as well)... and executed the program, resulting in same ssl errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac) 3) It is entirely possible that we may not be installing 1.0.2a correctly, for the system (please see attachment 1) for 32 bit, if so, please advise. 4) to your comment about "SHA2 may be broken" for newer version, sorry if I mislead you. Our purpose for upgrade was, as I stated originally, to be able to support SHA2 and TLS1.1/1.2. But with the newer version is producing errors (mentioned in #2 above) regardless of any types of certs used, SHA2 and otherwise. 5) as suggested by you, I have already installed openssl dropping optimization by altering openssl Makefile, along with dropping asm, compression, threads, etc . In the meanwhile I will repeat the tests dropping optimization from openssl and from the server program and will let you know. But if you think of any other scenario which might help in resolving the issue, please let me know. Thanks Shailender ========= attachment 1 ========= /home/v316509>system SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240System = SunOS Node = uittqda1 Release = 5.10 KernelID = Generic_148888-05 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 /home/v316509>cd /home/v316509/ssl/openssl-1.0.2a/apps /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps>cd /home/v336761/openssl/openssl-0.9.8g/apps /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" /home/v336761/openssl/openssl-0.9.8g/apps> ========= attachment 2 ========= /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-x86-cc options: bn(64,32) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -xarch=generic -O -Xa OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Tuesday, May 19, 2015 7:49 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > Objective also is to pinpoint the problem to specific algorithm on > specific platform. Mentioning two distinct platforms running different > versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make > things clearer. You have to present evidence that directly supports > given assumption, i.e. that 1.0.2 fails on SPARC. Or course you probably mean to say that this is evidence that SHA2 appears to be broken on SPARC. In order to make trouble-shooting more structured it's appropriate to double-check and confirm this by testing different s_client -cipher against s_server running on SPARC. Then to spare time one can drop optimization level only for affected module by manually removing corresponding .o, modifying CFLAG in top Makefile and re-running make. This way only couple of files will be recompiled so you don't have to wait for complete build (which is rather slow on SPARC). In other words, identify algorithm first, then experiment with compiler optimization levels. ======== Thanks for the timely response... below is version we are using. I also must point out that we are currently using 0.9.8g for several years, I tried to upgrade to .9.8zf, and several 1.0.x versions and had the same error. The "./Configure solaris-x86-cc" was used to install openssl. Also below is 0.9.8g version which is in use currently. This is the version with issue (also 0.9.8zf and several 1.0.x has same errors) /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> This is the version in use with no issues : /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Monday, May 18, 2015 4:55 PM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad > record mac > > (this is also true in all other version which support SHA2 and > TLS1/1.1/1.2, i.e. 0.9.8zf) > > client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 > alert bad record mac > > All platforms are using openssl 1.0.2a. Including SPARC Solaris one? Is it correctly understood? If so, you probably have compiled it yourself. In such case, which compiler and next question would be how do we know it's not a compiler bug? Or in other words question is if you can confirm that problem persists even if you drop optimization level [when compiling OpenSSL]. > There are no issues connecting to/from other platforms except to server running on Solaris. > > /home/v316509>cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > /home/v316509>uname -a > SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Provide even output from 'openssl version -a'. From shailender.gola at verizon.com Tue May 19 14:22:31 2015 From: shailender.gola at verizon.com (Gola, Shailender K) Date: Tue, 19 May 2015 10:22:31 -0400 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> <555B2101.8000202@openssl.org> Message-ID: I am reattaching previous communication for reference. 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see attachment 2 showing " platform: solaris-x86-cc " (which I had done before as well)... and executed the program, resulting in same ssl errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac) 3) It is entirely possible that we may not be installing 1.0.2a correctly, for the system (please see attachment 1) for 32 bit, if so, please advise. 4) to your comment about "SHA2 may be broken" for newer version, sorry if I mislead you. Our purpose for upgrade was, as I stated originally, to be able to support SHA2 and TLS1.1/1.2. But with the newer version is producing errors (mentioned in #2 above) regardless of any types of certs used, SHA2 and otherwise. 5) as suggested by you, I have already installed openssl dropping optimization by altering openssl Makefile, along with dropping asm, compression, threads, etc . In the meanwhile I will repeat the tests dropping optimization from openssl and from the server program and will let you know. But if you think of any other scenario which might help in resolving the issue, please let me know. Thanks Shailender ========= attachment 1 ========= /home/v316509>system SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240System = SunOS Node = uittqda1 Release = 5.10 KernelID = Generic_148888-05 Machine = sun4u BusType = Serial = Users = OEM# = 0 Origin# = 1 NumCPU = 2 /home/v316509>cd /home/v316509/ssl/openssl-1.0.2a/apps /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps>cd /home/v336761/openssl/openssl-0.9.8g/apps /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" /home/v336761/openssl/openssl-0.9.8g/apps> ========= attachment 2 ========= /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-x86-cc options: bn(64,32) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -xarch=generic -O -Xa OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Tuesday, May 19, 2015 7:49 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > Objective also is to pinpoint the problem to specific algorithm on > specific platform. Mentioning two distinct platforms running different > versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make > things clearer. You have to present evidence that directly supports > given assumption, i.e. that 1.0.2 fails on SPARC. Or course you probably mean to say that this is evidence that SHA2 appears to be broken on SPARC. In order to make trouble-shooting more structured it's appropriate to double-check and confirm this by testing different s_client -cipher against s_server running on SPARC. Then to spare time one can drop optimization level only for affected module by manually removing corresponding .o, modifying CFLAG in top Makefile and re-running make. This way only couple of files will be recompiled so you don't have to wait for complete build (which is rather slow on SPARC). In other words, identify algorithm first, then experiment with compiler optimization levels. ======== Thanks for the timely response... below is version we are using. I also must point out that we are currently using 0.9.8g for several years, I tried to upgrade to .9.8zf, and several 1.0.x versions and had the same error. The "./Configure solaris-x86-cc" was used to install openssl. Also below is 0.9.8g version which is in use currently. This is the version with issue (also 0.9.8zf and several 1.0.x has same errors) /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified platform: solaris-sparcv9-cc options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) blowfish(ptr) compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM OPENSSLDIR: "/usr/local/ssl" /home/v316509/ssl/openssl-1.0.2a/apps> This is the version in use with no issues : /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 platform: solaris-x86-cc options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) idea(int) blowfish(ptr) compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -fast -O -Xa OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Monday, May 18, 2015 4:55 PM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > I am getting following error connecting to a server running on Solaris 10 only from other platform (Linux, HP, Windows). Connection is dropped by Solaris server after 1408F119 error. > > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad > record mac > > (this is also true in all other version which support SHA2 and > TLS1/1.1/1.2, i.e. 0.9.8zf) > > client side gets : error:140943FC:SSL routines:ssl3_read_bytes:sslv3 > alert bad record mac > > All platforms are using openssl 1.0.2a. Including SPARC Solaris one? Is it correctly understood? If so, you probably have compiled it yourself. In such case, which compiler and next question would be how do we know it's not a compiler bug? Or in other words question is if you can confirm that problem persists even if you drop optimization level [when compiling OpenSSL]. > There are no issues connecting to/from other platforms except to server running on Solaris. > > /home/v316509>cat /etc/release > Solaris 10 11/06 s10s_u3wos_10 SPARC > Copyright 2006 Sun Microsystems, Inc. All Rights Reserved. > Use is subject to license terms. > Assembled 14 November 2006 > > /home/v316509>uname -a > SunOS uittqda1 5.10 Generic_148888-05 sun4u sparc SUNW,Sun-Fire-V240 Provide even output from 'openssl version -a'. From shailender.gola at verizon.com Tue May 19 14:52:30 2015 From: shailender.gola at verizon.com (Gola, Shailender K) Date: Tue, 19 May 2015 10:52:30 -0400 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> Message-ID: Saw this one after responding to the later one..... I have already tried using gcc instead cc to rule out compiler bug but only on server program. I will install openssl using gcc and dropping optimization. Will also verify that server/client programs are not optimized. Thanks Shailender -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Tuesday, May 19, 2015 4:13 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > Thanks for the timely response... below is version we are using. I > also must point out that we are currently using 0.9.8g for several > years, I tried to upgrade to .9.8zf, and several 1.0.x versions and > had the same error. The "./Configure solaris-x86-cc" was used to > install openssl. But the question was about SPARC... Anyway. Once again, 1st question in situation like that is if we are dealing with compiler bug. To answer it you should drop optimization level and see if problem persists. > Also below is 0.9.8g version which is in use currently. > > This is the version with issue (also 0.9.8zf and several 1.0.x has > same errors) > > /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL > 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified > platform: solaris-sparcv9-cc > options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) > blowfish(ptr) > compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 > -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DGHASH_ASM > OPENSSLDIR: "/usr/local/ssl" > /home/v316509/ssl/openssl-1.0.2a/apps> > > > This is the version in use with no issues : > > /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL > 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 > platform: solaris-x86-cc > options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) > idea(int) blowfish(ptr) > compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H > -fast -O -Xa > OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" Objective also is to pinpoint the problem to specific algorithm on specific platform. Mentioning two distinct platforms running different versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things clearer. You have to present evidence that directly supports given assumption, i.e. that 1.0.2 fails on SPARC. As for identifying algorithm. You can do so by playing with -cipher option to openssl s_client. Well, one can specify it even with s_server, but s_client is more practical for obvious reasons. From rt at openssl.org Tue May 19 14:52:54 2015 From: rt at openssl.org (Gola, Shailender K via RT) Date: Tue, 19 May 2015 16:52:54 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555AF092.6020808@openssl.org> Message-ID: Saw this one after responding to the later one..... I have already tried using gcc instead cc to rule out compiler bug but only on server program. I will install openssl using gcc and dropping optimization. Will also verify that server/client programs are not optimized. Thanks Shailender -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Tuesday, May 19, 2015 4:13 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > Thanks for the timely response... below is version we are using. I > also must point out that we are currently using 0.9.8g for several > years, I tried to upgrade to .9.8zf, and several 1.0.x versions and > had the same error. The "./Configure solaris-x86-cc" was used to > install openssl. But the question was about SPARC... Anyway. Once again, 1st question in situation like that is if we are dealing with compiler bug. To answer it you should drop optimization level and see if problem persists. > Also below is 0.9.8g version which is in use currently. > > This is the version with issue (also 0.9.8zf and several 1.0.x has > same errors) > > /home/v316509/ssl/openssl-1.0.2a/apps>./openssl version -a OpenSSL > 1.0.2a 19 Mar 2015 built on: reproducible build, date unspecified > platform: solaris-sparcv9-cc > options: bn(64,32) rc4(ptr,char) des(ptr,risc1,16,long) idea(int) > blowfish(ptr) > compiler: cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT > -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 > -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DGHASH_ASM > OPENSSLDIR: "/usr/local/ssl" > /home/v316509/ssl/openssl-1.0.2a/apps> > > > This is the version in use with no issues : > > /home/v336761/openssl/openssl-0.9.8g/apps>./openssl version -a OpenSSL > 0.9.8g 19 Oct 2007 built on: Mon May 18 18:14:46 EDT 2015 > platform: solaris-x86-cc > options: bn(64,32) md2(int) rc4(ptr,char) des(ptr,cisc,16,long) > idea(int) blowfish(ptr) > compiler: cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H > -fast -O -Xa > OPENSSLDIR: "/home/v336761/openssl/openssl-0.9.8g" Objective also is to pinpoint the problem to specific algorithm on specific platform. Mentioning two distinct platforms running different versions, like SPARC running 1.0.2 and x86 0.9.8g, does not make things clearer. You have to present evidence that directly supports given assumption, i.e. that 1.0.2 fails on SPARC. As for identifying algorithm. You can do so by playing with -cipher option to openssl s_client. Well, one can specify it even with s_server, but s_client is more practical for obvious reasons. From sdaoden at yandex.com Tue May 19 15:28:43 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 19 May 2015 17:28:43 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction Message-ID: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> Hello, i've just read on the Lynx list about compilation error because of a missing SSLv23_method() and indeed [1] says it is deprecated and a new TLS_client_method() is to be used instead. Now i've searched on Gmane but i couldn't find just any word. (Let's just hope that there will be TLS v1.4, .5...) So well, now i've updated [master] and see indeed commit [32ec415] stating Also, SSLv23_method and SSLv23_server_method have been replaced with TLS_method and TLS_server_method respectively. The old SSLv23* names still exist as macros pointing at the new name, although they are deprecated. Looking at the diff it seems that OPENSSL_USE_DEPRECATED is required to get the names. [1] https://www.openssl.org/docs/ssl/SSL_CTX_new.html Since my last v1.1.0 compile check was against an installation (got and) made on March 19th with OPENSSL_VERSION_NUMBER EQ 0x10100000L i would like to know how i can code my software to be (also future) compatible with OpenSSL. I would ask on @users but are no longer subscribed there. (Also i think this is such a drastic change that it is worth a note here.) Can someone please shed any light on this, please? Thank you! --steffen From matt at openssl.org Tue May 19 16:03:12 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 May 2015 17:03:12 +0100 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> Message-ID: <555B5EC0.4030505@openssl.org> On 19/05/15 16:28, Steffen Nurpmeso wrote: > Hello, > i've just read on the Lynx list about compilation error because of > a missing SSLv23_method() and indeed [1] says it is deprecated and > a new TLS_client_method() is to be used instead. Now i've > searched on Gmane but i couldn't find just any word. (Let's just > hope that there will be TLS v1.4, .5...) So well, now i've > updated [master] and see indeed commit [32ec415] stating > > Also, SSLv23_method and SSLv23_server_method have been replaced > with TLS_method and TLS_server_method respectively. The old > SSLv23* names still exist as macros pointing at the new name, > although they are deprecated. > > Looking at the diff it seems that OPENSSL_USE_DEPRECATED is > required to get the names. > > [1] https://www.openssl.org/docs/ssl/SSL_CTX_new.html > > Since my last v1.1.0 compile check was against an installation > (got and) made on March 19th with OPENSSL_VERSION_NUMBER EQ > 0x10100000L i would like to know how i can code my software to be > (also future) compatible with OpenSSL. > I would ask on @users but are no longer subscribed there. (Also > i think this is such a drastic change that it is worth a note > here.) > Can someone please shed any light on this, please? > Thank you! I just posted the following to lynx-dev: On 19/05/15 15:04, Thorsten Glaser wrote: > Gisle Vanem dixit: > >> +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L) > > No. The change is not a property of the version number. > I have OpenSSL 0.9.7 (plus patches?) without SSLv{2,3}. > > Index: HTTP.c > =================================================================== > RCS file: /cvs/src/gnu/usr.bin/lynx/WWW/Library/Implementation/HTTP.c,v > retrieving revision 1.26 > retrieving revision 1.27 > diff -u -p -r1.26 -r1.27 > --- HTTP.c 13 Mar 2014 04:46:43 -0000 1.26 > +++ HTTP.c 4 Jan 2015 22:24:27 -0000 1.27 > @@ -124,7 +124,11 @@ SSL *HTGetSSLHandle(void) > ssl_opts &= ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS; > #endif > SSLeay_add_ssl_algorithms(); > +#if defined(OPENSSL_NO_SSL2) && defined(OPENSSL_NO_SSL3) > + ssl_ctx = SSL_CTX_new(TLSv1_client_method()); > +#else > ssl_ctx = SSL_CTX_new(SSLv23_client_method()); > +#endif > SSL_CTX_set_options(ssl_ctx, ssl_opts); > SSL_CTX_set_default_verify_paths(ssl_ctx); > SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_PEER, HTSSLCallback); > > This should do the trick. This is not correct. Despite their name the SSLv23_*method() functions have nothing to do with the availability of SSLv2 or SSLv3. What these functions do is negotiate with the peer the highest available SSL/TLS protocol version available. The name is as it is for historic reasons. This is a very common confusion and is the main reason why these names have been deprecated in the latest dev version of OpenSSL. The OP suggested this: +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L) + ssl_ctx = SSL_CTX_new(TLSv1_client_method()); +#else ssl_ctx = SSL_CTX_new(SSLv23_client_method()); +#endif This is not quite correct either. TLSv1_client_method() will force TLS1.0 only. This is the correct approach: +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L) + ssl_ctx = SSL_CTX_new(TLS_client_method()); +#else ssl_ctx = SSL_CTX_new(SSLv23_client_method()); +#endif Alternatively you can continue to use the old SSLv23_client_method() name - but if you do so you will have to enable deprecated functions. Matt From gvanem at yahoo.no Tue May 19 16:33:19 2015 From: gvanem at yahoo.no (Gisle Vanem) Date: Tue, 19 May 2015 18:33:19 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <555B5EC0.4030505@openssl.org> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> Message-ID: <555B65CF.909@yahoo.no> Matt Caswell wrote: > I just posted the following to lynx-dev: I didn't get that post. > The OP suggested this: > > +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L) > + ssl_ctx = SSL_CTX_new(TLSv1_client_method()); > +#else > ssl_ctx = SSL_CTX_new(SSLv23_client_method()); > +#endif > > This is not quite correct either. TLSv1_client_method() will force > TLS1.0 only. This is the correct approach: > > +#if (OPENSSL_VERSION_NUMBER >= 0x10100000L) > + ssl_ctx = SSL_CTX_new(TLS_client_method()); > +#else > ssl_ctx = SSL_CTX_new(SSLv23_client_method()); > +#endif Okay, this was better. The command: lynx https://www.ssllabs.com/ssltest/viewMyClient.html now gives: Protocol Features Protocols TLS 1.2 Yes TLS 1.1 Yes* TLS 1.0 Yes* SSL 3 Yes* SSL 2 No -- --gv From kurt at roeckx.be Tue May 19 16:40:38 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 19 May 2015 18:40:38 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <555B5EC0.4030505@openssl.org> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> Message-ID: <20150519164037.GA16489@roeckx.be> On Tue, May 19, 2015 at 05:03:12PM +0100, Matt Caswell wrote: > > > > No. The change is not a property of the version number. > > I have OpenSSL 0.9.7 (plus patches...) without SSLv{2,3}. > > > > Index: HTTP.c > > =================================================================== > > RCS file: /cvs/src/gnu/usr.bin/lynx/WWW/Library/Implementation/HTTP.c,v > > retrieving revision 1.26 > > retrieving revision 1.27 > > diff -u -p -r1.26 -r1.27 > > --- HTTP.c 13 Mar 2014 04:46:43 -0000 1.26 > > +++ HTTP.c 4 Jan 2015 22:24:27 -0000 1.27 > > @@ -124,7 +124,11 @@ SSL *HTGetSSLHandle(void) > > ssl_opts &= ~SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS; > > #endif > > SSLeay_add_ssl_algorithms(); > > +#if defined(OPENSSL_NO_SSL2) && defined(OPENSSL_NO_SSL3) > > + ssl_ctx = SSL_CTX_new(TLSv1_client_method()); > > +#else > > ssl_ctx = SSL_CTX_new(SSLv23_client_method()); > > +#endif > > SSL_CTX_set_options(ssl_ctx, ssl_opts); > > SSL_CTX_set_default_verify_paths(ssl_ctx); > > SSL_CTX_set_verify(ssl_ctx, SSL_VERIFY_PEER, HTSSLCallback); > > > > This should do the trick. > > This is not correct. And because of this confusion I want to remove things like TLSv1_client_method(). I think that we should just provide the SSLv23_client_method define without the need to enable something, and I guess I missed something during the review in that case. Kurt From sdaoden at yandex.com Tue May 19 17:34:11 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 19 May 2015 19:34:11 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519164037.GA16489@roeckx.be> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> Message-ID: <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> Kurt Roeckx wrote: |I think that we should just provide the SSLv23_client_method define |without the need to enable something, and I guess I missed |something during the review in that case. Thanks for the clarification. --steffen From sdaoden at yandex.com Tue May 19 18:03:05 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Tue, 19 May 2015 20:03:05 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> Message-ID: <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> Steffen Nurpmeso wrote: |Kurt Roeckx wrote: ||I think that we should just provide the SSLv23_client_method define ||without the need to enable something, and I guess I missed ||something during the review in that case. | |Thanks for the clarification. Ehm, one more nit: in order to be able to compile [master] i need this patch (tests like it fwiw): diff --git a/crypto/comp/comp_lcl.h b/crypto/comp/comp_lcl.h index f1ec8d5..1360f56 100644 --- a/crypto/comp/comp_lcl.h +++ b/crypto/comp/comp_lcl.h @@ -71,4 +71,5 @@ struct comp_ctx_st { unsigned long compress_out; unsigned long expand_in; unsigned long expand_out; + CRYPTO_EX_DATA ex_data; }; From rt at openssl.org Tue May 19 18:59:18 2015 From: rt at openssl.org (Ghetolay via RT) Date: Tue, 19 May 2015 20:59:18 +0200 Subject: [openssl-dev] [openssl.org #3853] Indirect CRL issuer (issuer outside cert's chain) In-Reply-To: References: Message-ID: Version: 1.0.1f to 1.0.2a OS: Linux/Ubuntu (not relevant) Type: enhancement request Hello, First here is the setup I'm confronted with (not mine just have to work with it) : Root CA | ------------------------------- / \ Root CRL Signing CA | | | ---------------- --------------- / \ / \ CRL Intermediate CA ... Cert Intermediate CA ... | | CRL... Cert... Root CA and Root CRL Signing CA have same DN also both Intermediate CA have same DN. Both crl and cert have the same origin point as trusted CA so this setup seems to be compliant with RFC5280. But when I wanted to to verify a cert with -check_crl I got errors like "unable to get certificate CRL" and "unable to get local issuer certificate" depending on the openssl version and if crl was part of -CAfile or was set with -CRLfile. In all case -CAfile was a concatenation of at least all CA's (Root CA, Root CRL Signing CA and both Intermediate CA). The only way I was able to get verify working was using latest openssl version as such : openssl verify -CAfile="Cert Intermediate CA|Root CA" -untrusted="CRL Intermediate CA|Root CRL Signing CA" -extended_crl -crl_check -CRLfile ... But this seem more like a workaround I don't think crl related CA's should be on the untrusted chain. As per my understanding the untrusted chain should contain intermediate cert, this is the first chain checked to find certificate's issuer. After some digging (on the latest source) I found out the problem come from crl_akid_check() because this function will try to find the crl issuer on the previously established certificate chain. On this setup neither "Root CRL Signing CA" nor "CRL Intermediate CA" will ever be part of the certificate chain. crl_akid_check() is then never able to find the crl issuer and fail (except with the workaround explain earlier). So as a quick fix/POC I changed the function as follow : static void crl_akid_check(..) static void crl_akid_check(..) { { [...] [...] int cidx = ctx->error_depth; int cidx = ctx->error_depth; if (cidx != sk_X509_num(ctx->chain) - 1) if (cidx != sk_X509_num(ctx->chain) - 1) cidx++; cidx++; crl_issuer = sk_X509_value(ctx->chain, cidx); crl_issuer = sk_X509_value(ctx->chain, cidx); if (X509_check_akid(crl_issuer, crl->akid) == X509_V_OK) { if (X509_check_akid(crl_issuer, crl->akid) == X509_V_OK) { [...] [...] } } *STACK_OF(X509)* certs = ctx->lookup_certs(ctx, cnm);* for (cidx++; cidx < sk_X509_num(ctx->chain); cidx++){ for *(i=0; i < sk_X509_num(certs); i++)*{ [...] [...] } } [...] [..] } } Basically I'm looking for a corresponding issuer into all trusted cert instead of just inside the certificate chain. With this little modification I'm now able to verify my certificates. As I said it's just a demonstration, if we go that way we should probably create a crl_chain and change accordingly check_revocation(), check_cert(), check_crl()... I'm not familiar with openssl code but it seems there is already a notion of crl_chain on check_crl_path() and check_crl_chain() but theses functions aren't called until we check the AKID so maybe we should just build an independent crl_chain sooner (when we look for crl's issuer ?). Well like I said I'm not familiar with openssl code so I would like your feedback before going further :) I don't know if I'm allowed to share the certificates and it didn't seem necessary for the understanding but if you need them I could ask or at least share the text output. P.S.: I was about to prettify diagram and code but I wasn't sure if html was supported so I kept it plain text. Should I open an issue/pull request on github ? Ghetolay. From kurt at roeckx.be Tue May 19 19:08:54 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 19 May 2015 21:08:54 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> Message-ID: <20150519190854.GA2085@roeckx.be> On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote: > Steffen Nurpmeso wrote: > |Kurt Roeckx wrote: > ||I think that we should just provide the SSLv23_client_method define > ||without the need to enable something, and I guess I missed > ||something during the review in that case. > | > |Thanks for the clarification. > > Ehm, one more nit: in order to be able to compile [master] i need > this patch (tests like it fwiw): It builds fine for me. Can you give the error where it fails to build? Kurt From rt at openssl.org Tue May 19 20:04:34 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 19 May 2015 22:04:34 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: <555B9746.4020502@openssl.org> References: <555A4E56.7080900@openssl.org> <555A6128.4010703@openssl.org> <555B9746.4020502@openssl.org> Message-ID: >>>>> Found by the https://github.com/xiw/stack tool and then I checked the >>>>> generated asm (gcc and clang) to confirm. >>>>> >>>>> In the check "if (d0 && tmp_ulong)" tmp_ulong always evaluates to true >>>>> because the compiler optimizes out the tmp_ulong value to true because >>>>> (tmp_ulong = zz >> d1;) zz >> d1 has according to the compiler (LLVM) >>>>> a logical right-shift overflow. >>>> ... are you sure about it being >>>> optimized away because it always evaluates to true? Thing is that if >>>> tmp_ulong is 0, then xor-ing with it won't have effect on result. I mean >>>> check for d0 alone would actually produce same outcome, wouldn't it? > > ... the original > commits intention should be checked > out. The commit intention is actually sane. This kind of brings us back to question why was it optimized away? BTW, which compiler version is it and what are your optimization flags? I can't reproduce the problem with clang 3.6 and -O3. I mean I don't see that check for tmp_ulong is optimized away. In either case, as intention is sane, the only possible modification would be if (d0 && (tmp_ulong = zz >> d1)) So that right shift is not attempted if d0 is zero. From matt at openssl.org Tue May 19 22:26:10 2015 From: matt at openssl.org (Matt Caswell) Date: Tue, 19 May 2015 23:26:10 +0100 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519164037.GA16489@roeckx.be> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> Message-ID: <555BB882.9010407@openssl.org> On 19/05/15 17:40, Kurt Roeckx wrote: > I think that we should just provide the SSLv23_client_method define > without the need to enable something, and I guess I missed > something during the review in that case. The reason you need to enable something is that SSLv23_client_method is now deprecated. If you want it to "just work" then you would need to un-deprecate it. That's ok but it has the disadvantage that the old name will then stick around indefinitely and quite probably will be used even for new code. Matt From andrejs.igumenovs at gmail.com Wed May 20 00:04:49 2015 From: andrejs.igumenovs at gmail.com (Andrejs Igumenovs) Date: Wed, 20 May 2015 03:04:49 +0300 Subject: [openssl-dev] Test coverage report + small patch In-Reply-To: References: <85c07c75d69041628d53297930aae042@usma1ex-dag1mb4.msg.corp.akamai.com> Message-ID: <068DBBF1-3EF6-470E-8C39-00B04702985B@gmail.com> Hi Harri, > We've compared the code coverage of the tests between the 1.0.2a release > and today's master state: it rose from 28.1% to 29.6%! I believe you did that by using your internal commercial product by Froglogic? Any good free software alternative out there? Thanks, - Andrejs > On 04.05.2015, at 18:02, Harri Porten wrote: > > Hi Rich, > > On Fri, 1 May 2015, Salz, Rich wrote: > >> I am curious to see what the numbers look like from, say, yesterday compared to, roughly, early next week. > > We've compared the code coverage of the tests between the 1.0.2a release > and today's master state: it rose from 28.1% to 29.6%! > > And as you predicted the code simplifications might be responsible: the > number of decision points went down from 70192 to 67845. Which is good. > Provided that the software still does the same thing as before ;) > >> We are well into a huge overall edit that turns code like > If (p) free(p) >> Into >> free(p); >> And not just for free, but for several dozen OpenSSL functions. This will probably remove a couple of thousand decision points. The code certainly looks much simpler. > > Drilling down into the file changes of the last two weeks one can see > cases of the if()/free() simplification happening in untested code > however: > http://www.opencoverage.net/projects/openssl-diff/index_html/source_33.html > I'm not blaming anyone for that, though. Just pointing out the risk of > potentially unnoticed regressions. > > Harri. > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Wed May 20 03:19:39 2015 From: rt at openssl.org (Kurt Cancemi via RT) Date: Wed, 20 May 2015 05:19:39 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: References: <555A4E56.7080900@openssl.org> <555B9746.4020502@openssl.org> Message-ID: I don't think its optimizing it out I agree with you, but your suggested change resolved the error so Wim was right about it being undefined behaviour, and the tool which uses clang 3.4 was warning us about that. I added my own debugging statement and ran ectest and it is indeed undefined behaviour (though it doesn't matter much as the results not used as WIm stated) before your patch: printf("DBG: zz=" BN_DEC_FMT1 " d0=%d\n", zz, d0); Example Output line (before your patch): DBG: zz=1 d0=1 (UB) Output line (after your patch): DBG: zz=89619874872 d0=7 On Tue, May 19, 2015 at 4:04 PM, Andy Polyakov via RT wrote: > > The commit intention is actually sane. This kind of brings us back to > question why was it optimized away? BTW, which compiler version is it > and what are your optimization flags? I can't reproduce the problem with > clang 3.6 and -O3. I mean I don't see that check for tmp_ulong is > optimized away. In either case, as intention is sane, the only possible > modification would be > > if (d0 && (tmp_ulong = zz >> d1)) > > So that right shift is not attempted if d0 is zero. > > From mancha1 at zoho.com Wed May 20 08:01:11 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 20 May 2015 08:01:11 +0000 (UTC) Subject: [openssl-dev] Weak DH and the Logjam Message-ID: Given Adrien et al. recent paper [1] together with their proof-of-concept attacks against 512-bit DH groups [2], it might be a good time to resurrect a discussion Daniel Kahn Gillmor has brought up in the past. Namely, whether it makes sense for OpenSSL to reject DH groups smaller than some minimum (1024 bits or more). Currently, client implementations built on OpenSSL will happily accept small DH groups from a peer (e.g. 16-bit DH group [3]). [1] https://weakdh.org/imperfect-forward-secrecy.pdf [2] https://weakdh.org/logjam.html [3] openssl s_client -connect demo.cmrg.net:443 < /dev/null --mancha PS My understanding is Google Chrome will soon be rejecting all DH groups smaller than 1024 bits. From mancha1 at zoho.com Wed May 20 07:22:57 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 20 May 2015 07:22:57 +0000 Subject: [openssl-dev] Weak DH and the Logjam Message-ID: <20150520072257.GA8559@zoho.com> Given Adrien et al. recent paper [1] together with their proof-of-concept attacks against 512-bit DH groups [2], it might be a good time to resurrect a discussion Daniel Kahn Gillmor has brought up in the past. Namely, whether it makes sense for OpenSSL to reject DH groups smaller than some minimum. Say, 1024 bits or more. Currently, a client implementation built on OpenSSL will happily accept small DH groups from a peer (e.g. 16-bit DH group [3]). [1] https://weakdh.org/imperfect-forward-secrecy.pdf [2] https://weakdh.org/logjam.html [3] openssl s_client -connect demo.cmrg.net:443 < /dev/null --mancha PS My understanding is Google Chrome will soon be rejecting all DH groups smaller than 1024 bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Wed May 20 07:11:42 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 20 May 2015 07:11:42 +0000 Subject: [openssl-dev] Weak DH and the Logjam Message-ID: <20150520071142.GA19073@zoho.com> Hello. Given Adrien et al. recent paper [1] together with their proof-of-concept attacks against 512-bit DH groups [2], it might be a good time to resurrect a discussion Daniel Kahn Gillmor has started here in the past. Namely, whether it makes sense for OpenSSL to reject DH groups smaller than some minimum. Say, 1024 bits (or more). Currently, a client implementation built on OpenSSL will happily accept small DH groups from a peer (e.g. 16-bit DH group [3]). [1] https://weakdh.org/imperfect-forward-secrecy.pdf [2] https://weakdh.org/logjam.html [3] openssl s_client -connect demo.cmrg.net:443 < /dev/null --mancha PS My understanding is Google Chrome will soon be rejecting all DH groups smaller than 1024 bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Wed May 20 09:14:38 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 11:14:38 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: <555C5075.9080108@openssl.org> References: <555A518A.4030101@openssl.org> <555B2101.8000202@openssl.org> <555C5075.9080108@openssl.org> Message-ID: > 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" Attachment 1 indicates that you execute on SPARC. At the same time you keep mentioning configuration for solaris-x86-cc. In normal situation it's interpreted as two platforms. > 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see attachment 2 showing " platform: solaris-x86-cc " (which I had done before as well)... and executed the program, resulting in same ssl errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac) If you force x86 configuration on SPARC, no guarantees can be provided. Even if it happens to work in some particular case. It just makes no sense to spend time thinking about it. From sdaoden at yandex.com Wed May 20 09:31:23 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Wed, 20 May 2015 11:31:23 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150519190854.GA2085@roeckx.be> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> <20150519190854.GA2085@roeckx.be> Message-ID: <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> Kurt Roeckx wrote: |On Tue, May 19, 2015 at 08:03:05PM +0200, Steffen Nurpmeso wrote: |> Steffen Nurpmeso wrote: |>|Kurt Roeckx wrote: |>||I think that we should just provide the SSLv23_client_method define |>||without the need to enable something, and I guess I missed |>||something during the review in that case. |>| |>|Thanks for the clarification. |> |> Ehm, one more nit: in order to be able to compile [master] i need |> this patch (tests like it fwiw): | |It builds fine for me. Can you give the error where it fails to |build? I never claimed the patch was correct, i still got c_zlib.c:113:5: warning: excess elements in struct initializer NULL, ^~~~ But understandably i wanted to adjust for upcoming 1.1.0 changes asap (you seem to encourage people using [master] for this purpose if i recall correctly) and then there was (i say ?Ciao!? here) c_zlib.c:113:5: warning: excess elements in struct initializer NULL, ^~~~ /usr/include/stdio.h:84:14: note: expanded from macro 'NULL' #define NULL __DARWIN_NULL ^~~~~~~~~~~~~ /usr/include/sys/_types.h:91:23: note: expanded from macro '__DARWIN_NULL' #define __DARWIN_NULL ((void *)0) ^~~~~~~~~~~ c_zlib.c:203:57: error: no member named 'ex_data' in 'struct comp_ctx_st' CRYPTO_new_ex_data(CRYPTO_EX_INDEX_COMP, ctx, &ctx->ex_data); ~~~ ^ c_zlib.c:204:30: error: no member named 'ex_data' in 'struct comp_ctx_st' CRYPTO_set_ex_data(&ctx->ex_data, zlib_stateful_ex_idx, state); ~~~ ^ c_zlib.c:214:55: error: no member named 'ex_data' in 'struct comp_ctx_st' (struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data, ~~~ ^ c_zlib.c:219:58: error: no member named 'ex_data' in 'struct comp_ctx_st' CRYPTO_free_ex_data(CRYPTO_EX_INDEX_COMP, ctx, &ctx->ex_data); ~~~ ^ c_zlib.c:228:55: error: no member named 'ex_data' in 'struct comp_ctx_st' (struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data, ~~~ ^ c_zlib.c:257:55: error: no member named 'ex_data' in 'struct comp_ctx_st' (struct zlib_state *)CRYPTO_get_ex_data(&ctx->ex_data, ~~~ ^ 1 warning and 6 errors generated. make[2]: *** [c_zlib.o] Error 1 make[1]: *** [subdirs] Error 1 make: *** [build_crypto] Error 1 ?2[steffen at sherwood openssl.git]$ gl1 --steffen From rsalz at akamai.com Wed May 20 09:39:32 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 May 2015 09:39:32 +0000 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> <20150519190854.GA2085@roeckx.be> <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> Message-ID: <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> > c_zlib.c:113:5: warning: excess elements in struct initializer > NULL, > ^~~~ Are you sure you have an accurate copy of master? The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 as part of making the COMP structures opaque. From rt at openssl.org Wed May 20 09:41:18 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 11:41:18 +0200 Subject: [openssl-dev] [openssl.org #3844] FW: regarding shared library for openssl -1.0.2a In-Reply-To: <555C56B1.5050106@openssl.org> References: <555C56B1.5050106@openssl.org> Message-ID: > Hi all, > I want cross compile openssl for arm-xilinx-linux-gnueabi-gcc platform .I have downloaded source code openssl-1.02a and I have looked options for > for configure file. Arm-xilinx-linux-gnueabi is not found in list of os/compiler option .so I selected linux-armv4 and configure like this > ./configure no-threads shared linux-armv4 --prefix=/home/sum/ --openssl=/home/sum/ Normally cross-compiler toolchain is prefixed, e.g. compiler is called arm-linux-gnueabi-gcc. To cross-compile you are expected to pass --cross-compile-prefix as additional argument to ./Configure, for mentioned example --cross-compile-prefix=arm-linux-gnueabi-, or set CROSS_COMPILE environment variable prior ./Configure. > Configuration is successful when I going for make itt has given me error stating that > > relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC > libcrypto.a(armcap.o): error adding symbols: Bad value Well, if right target compiler was called and with right flag, i.e. with -fPIC as directed by linux-armv4 config line, then it's likely between you and your system vendor. I mean there is nothing we can do about your compiler. It might happen that it was not the first attempt to configure and compile in that directory, so that there is remote possibility that file was originally compiled without -fPIC and then wasn't recompiled. In this case 'make clean' or just starting over would solve the problem. > under compiler options why arm-none-linux-gneabi support is not there? Because it's unfeasible to create all possible configurations. Instead single processor-specific is supported that allows for customization at Configure command line. From sdaoden at yandex.com Wed May 20 10:00:29 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Wed, 20 May 2015 12:00:29 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <555BB882.9010407@openssl.org> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <555BB882.9010407@openssl.org> Message-ID: <20150520100029.7WckD7kajZ1P%sdaoden@yandex.com> Matt Caswell wrote: |On 19/05/15 17:40, Kurt Roeckx wrote: |> I think that we should just provide the SSLv23_client_method define |> without the need to enable something, and I guess I missed |> something during the review in that case. | |The reason you need to enable something is that SSLv23_client_method is |now deprecated. If you want it to "just work" then you would need to |un-deprecate it. That's ok but it has the disadvantage that the old name |will then stick around indefinitely and quite probably will be used even |for new code. It seems to me you should introduce a multiple-step deprecation scheme. But this function series in particular is documented as "effectively the way to go" in a very famous book that is so old that it now can be downloaded for free, and i'd expect that almost all software projects use it: turning it off overnight seems to be a bad decision to me. While here, so let me add my opinion, and that is that it would possibly be better to allow NULL or (maybe better) (a) special (*)-1(,2,3) constant(s) arguments to SSL_CTX_new() instead of replacing SSLv23_(client_)?method() with a different protocol-multiplexer. E.g,, SSL_CTX_new(SSL_METHOD_ANY) or the like. I'd expect that the actual protocol limitation is done via _set_options() or SSL_CONF_CTX_cmd() later on anyway, just as documented. --steffen From sdaoden at yandex.com Wed May 20 10:11:35 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Wed, 20 May 2015 12:11:35 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> <20150519190854.GA2085@roeckx.be> <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <20150520101135.f-G1QfOrjCrQ%sdaoden@yandex.com> "Salz, Rich" wrote: |> c_zlib.c:113:5: warning: excess elements in struct initializer |> NULL, |> ^~~~ | |Are you sure you have an accurate copy of master? | |The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 \ |as part of making the COMP structures opaque. That was the commit i had blamed as the culprit, yes. :) ?Hasta la victoria siempre! --steffen From gvanem at yahoo.no Wed May 20 10:18:35 2015 From: gvanem at yahoo.no (Gisle Vanem) Date: Wed, 20 May 2015 12:18:35 +0200 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> <20150519190854.GA2085@roeckx.be> <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <555C5F7B.9070401@yahoo.no> Salz, Rich wrote: >> c_zlib.c:113:5: warning: excess elements in struct initializer >> NULL, >> ^~~~ > > Are you sure you have an accurate copy of master? > > The EX_DATA was removed in 9a555706a3fb8f6622e1049ab510a12f4e1bc6a2 as part of making the COMP structures opaque. He's right, the c_zlib.c is broken if you compile with '-DZLIB' (and not '-DZLIB_SHARED'): crypto/comp/c_zlib.c(115) : error C2078: too many initializers crypto/comp/c_zlib.c(203) : error C2039: 'ex_data' : is not a member of 'comp_ctx_st' f:\mingw32\src\inet\crypto\openssl\crypto\comp\comp_lcl.h(68) : see declaration of 'comp_ctx_st' crypto/comp/c_zlib.c(203) : error C2198: 'CRYPTO_new_ex_data' : too few arguments for call Try it and see for yourself. -- --gv From rt at openssl.org Wed May 20 10:55:10 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 12:55:10 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <555C6801.6000005@openssl.org> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> Message-ID: Hi, For reference. icc was not cared for for quite some time. Initially it was possible for me, by then university employee, to use it, but then they changes terms and it became impossible for me to maintain it. But I've just noticed they provide some starter version of something, I'll see... > Lei Zhang (re)discovered that OpenSSL 1.0.1* and below gets miscompiled, > resulting in incorrect computation of at least SHA-1 hashes (and probably > SHA-0, MD4, MD5) when it's compiled with icc for 64-bit Linux (x86_64 or > mic), but not for Windows. The problem is already fixed in 1.0.2 and in > LibreSSL. > > The problem is that OpenSSL uses the _lrotl() intrinsic to rotate 32-bit > integers, whereas it is defined to operate on "unsigned long", which > obviously is 64-bit on many platforms. > > Lei's report: > > http://www.openwall.com/lists/john-dev/2015/03/26/1 > > A previous report (from 2011): > > https://software.intel.com/en-us/articles/openssl-generates-incorrect-shamd5-value-if-built-with-icc-compiler > > I suggest that this be fixed for all currently supported branches of > OpenSSL. For now, Lei switched to using LibreSSL in our John the Ripper > -jumbo builds for Xeon Phi, but we'd like to (re-)include instructions > for building with OpenSSL as well. But linux-x86_64-icc is not present in and was never supported in pre-1.0.2. So you ought to provide custom line. This remark doesn't mean that fix can't be backported, but out of curiosity, what's your config line? Is assembly engaged? If so, how fast is it? Or is it so that you count on compiler to produce vector code that would process multiple inputs in parallel with SIMD? On related note. What's Xeon Phi in this context? I mean are we talking about Knights Corner (that features own compatible-with-nothing SIMD instruction set) or Knights Landing (that features AVX512)? If latter, it might be interesting to extend multi-block SHA support(*), which should allow to achieve pretty cool results (with vector rotate and ternary logic instructions, not to mention 16 lanes:-). [As for "interesting". It's possible but not really interesting in Knights Corner case, because effort is too specific, just a single obscure and hardly available CPU, while AVX512 is planned even for other processors so that code will be reusable.] (*) BTW, did you try existing one? From rsalz at akamai.com Wed May 20 10:56:03 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 20 May 2015 10:56:03 +0000 Subject: [openssl-dev] On SSLv23_method() drop and TLS_method() introduction In-Reply-To: <555C5F7B.9070401@yahoo.no> References: <20150519152843.g6Nq2_sNfl3m%sdaoden@yandex.com> <555B5EC0.4030505@openssl.org> <20150519164037.GA16489@roeckx.be> <20150519173411.Eype6Adilk-j%sdaoden@yandex.com> <20150519180305.gfokMA-_AH-W%sdaoden@yandex.com> <20150519190854.GA2085@roeckx.be> <20150520093123.LnE1yXgacEsP%sdaoden@yandex.com> <2495f4ce7ee946ec97da7b8b5d9100f3@ustx2ex-dag1mb2.msg.corp.akamai.com> <555C5F7B.9070401@yahoo.no> Message-ID: > He's right, the c_zlib.c is broken if you compile with '-DZLIB' > (and not '-DZLIB_SHARED'): Ah. Thanks, now I get it. The attached patch seems to fix the build, but exposes a possible memory leak; ssltest fails. I won't get a chance to look at this until next week, in case anyone wants to look at it early. -------------- next part -------------- A non-text attachment was scrubbed... Name: comp.patch Type: application/octet-stream Size: 3831 bytes Desc: comp.patch URL: From rt at openssl.org Wed May 20 11:46:10 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 13:46:10 +0200 Subject: [openssl-dev] [openssl.org #3827] Suspicious valgrind report In-Reply-To: <555C73FB.9030607@openssl.org> References: <20150430122146.Horde.Lotz3X-92h3MLB371p-qgA1@sirzooro.prohost.pl> <555C73FB.9030607@openssl.org> Message-ID: Hi, > I build OpenSSL 1.0.1m on Linux/RedHat with -DPURIFY option and tried > to analyze my app using Valgrind. Thanks to -DPURIFY most warnings > about uninitialized memory are gone, but not all. Remaining ones share > common signature - uninitialized memory comes from stack allocation in > aesni_cbc_encrypt(): > > ==8922== Conditional jump or move depends on uninitialised value(s) > ==8922== [cut but cut, various places in my app] > ==8922== Uninitialised value was created by a stack allocation > ==8922== at 0x566D77: aesni_cbc_encrypt (in /path/myapp) > > I did not check if this is real bug or unpurified place. Please take a > look on this and fix it. This was discussed in detail RT#3622, http://rt.openssl.org/Ticket/Display.html?id=3622&user=guest&pass=guest, and even RT#2862. Ticket is being closed as duplicate. From rt at openssl.org Wed May 20 12:11:20 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 14:11:20 +0200 Subject: [openssl-dev] [openssl.org #3576] Speed up AES-256 key expansion by 1.9x In-Reply-To: <555C79DF.3000604@openssl.org> References: <555C79DF.3000604@openssl.org> Message-ID: >> I actually have improved implementation (well, it's not actually a *lot* >> better, can't be made a *lot* better because of aesenclast latency, but >> it should get better on processors with lower latency) for all key >> lengths. > > Awesome! :) > >> Bottom line is that specific submission is dismissed, and as there is >> interest I can proceed committing my code. > > Thanks, This was committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=23f6eec71dbd472044db7dc854599f1de14a1f48. From rt at openssl.org Wed May 20 12:14:06 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 14:14:06 +0200 Subject: [openssl-dev] [openssl.org #3554] [PATCH] aesni-x86_64.pl: zeroize registers, Win64 ABI fix In-Reply-To: <555C7A86.1060808@openssl.org> References: <555C7A86.1060808@openssl.org> Message-ID: >>> All internal exports: Zeroize XMM registers that may contain secret >>> data before returning. (At 4x pxors per cycle, the overhead is >>> negligible.) This was committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=23f6eec71dbd472044db7dc854599f1de14a1f48 From rt at openssl.org Wed May 20 12:20:39 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 14:20:39 +0200 Subject: [openssl-dev] [openssl.org #3541] [PATCH] BN_nist_mod_521 fails on Windows ARM In-Reply-To: <555C7C0F.9050009@openssl.org> References: <5421CED7.1090101@openssl.org> <5421DF97.2060405@openssl.org> <555C7C0F.9050009@openssl.org> Message-ID: > With the change suggested, the tests do succeed. This was committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=8b07c005fe006044d0e4a795421447deca3c9f2c and http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=323154be3326a329f768958e9229585a84985747. From rt at openssl.org Wed May 20 12:24:29 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 14:24:29 +0200 Subject: [openssl-dev] [openssl.org #3474] selected processor does not support ARM mode `mrrc p15, 1, r0, r1, c14' In-Reply-To: <555C7CF5.8020808@openssl.org> References: <20140724172716.GA2821@roeckx.be> <555C7CF5.8020808@openssl.org> Message-ID: > With 1.0.2 beta 2 I'm seeing the following error: > gcc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -D_FORTIFY_SOURCE=2 -Wl,-z,relro -Wa,--noexecstack -Wall -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -c -c -o armv4cpuid.o armv4cpuid.S > armv4cpuid.S: Assembler messages: > armv4cpuid.S:17: Error: selected processor does not support ARM mode `mrrc p15,1,r0,r1,c14' > make[2]: *** [armv4cpuid.o] Error 1 > > That is on Debian's armel port, which is using the EABI with a minimum requirement of v4t. > > I don't see that error on the armhf port which requires at least a v7. This was addressed prior 1.0.2 release. From rt at openssl.org Wed May 20 12:53:02 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Wed, 20 May 2015 14:53:02 +0200 Subject: [openssl-dev] [openssl.org #3688] Bug report; OpenSSL 1.0.2; Solaris 11.0; Sparc T4; evp_test core dumps In-Reply-To: <555C83A6.3090105@openssl.org> References: <1423475793.19595.198.camel@rydra.dev.top> <555C83A6.3090105@openssl.org> Message-ID: >>> I am building openssl 1.0.2 on a number of platforms, and I am > having >>> problems on a virtual Solaris 11.0 machine running on a Sparc T4. >>> The code builds fine, but the evp_test core dumps. Here are the last >>> lines of output from the command (test/evp_test test/evptests.txt): >>> >>> Testing cipher id-aes256-CCM(encrypt/decrypt) >>> ... >>> zsh: segmentation fault (core dumped) ./test/evp_test test/evptests.txt >> >> It's rather incredible that this slipped through. I've run the test many >> times and 1.0.2 actually passes the test at the moment of this writing. >> Well, I'm running on Linux, but it's circumstantial that it worked. >> Verify that attached patch solves the problem. > > Hello, > > I applied the patch and rebuilt everything, and now all tests pass on > the T4 machine (and T2). This was committed as [part of] http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=bdc985b133a69186c5edba4ba703b400a02325ee From hkario at redhat.com Wed May 20 13:14:07 2015 From: hkario at redhat.com (Hubert Kario) Date: Wed, 20 May 2015 15:14:07 +0200 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150520071142.GA19073@zoho.com> References: <20150520071142.GA19073@zoho.com> Message-ID: <1868731.0skjHVYuHO@pintsize.usersys.redhat.com> On Wednesday 20 May 2015 07:11:42 mancha wrote: > Hello. > > Given Adrien et al. recent paper [1] together with their > proof-of-concept attacks against 512-bit DH groups [2], it might be a > good time to resurrect a discussion Daniel Kahn Gillmor has started > here in the past. > > Namely, whether it makes sense for OpenSSL to reject DH groups smaller > than some minimum. Say, 1024 bits (or more). Currently, a client > implementation built on OpenSSL will happily accept small DH groups from > a peer (e.g. 16-bit DH group [3]). > > [1] https://weakdh.org/imperfect-forward-secrecy.pdf > [2] https://weakdh.org/logjam.html > [3] openssl s_client -connect demo.cmrg.net:443 < /dev/null > > --mancha > > PS My understanding is Google Chrome will soon be rejecting all DH > groups smaller than 1024 bits. I think it should be user configurable (preferably using a config file, as environment variables are cleared by daemons. Firstly, if you need to interoperate with Java 6, you'll need to accept 768 bit DH. Secondly, some people may be uncomfortable with accepting 1024 bit DH. Thirdly, hardcoding a 1024 bit minimum just pushes the problem forward, to time when 1024 can be broken as easily as 512 bit is now, but then the target servers won't be ones that enable export grade DHE but vanilla Apache 2.2 servers and others like it. -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From kurt at roeckx.be Wed May 20 17:17:43 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 20 May 2015 19:17:43 +0200 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150520071142.GA19073@zoho.com> References: <20150520071142.GA19073@zoho.com> Message-ID: <20150520171742.GA13196@roeckx.be> On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote: > Hello. > > Given Adrien et al. recent paper [1] together with their > proof-of-concept attacks against 512-bit DH groups [2], it might be a > good time to resurrect a discussion Daniel Kahn Gillmor has started > here in the past. Please see http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ Kurt From mancha1 at zoho.com Wed May 20 20:58:54 2015 From: mancha1 at zoho.com (mancha) Date: Wed, 20 May 2015 20:58:54 +0000 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150520171742.GA13196@roeckx.be> References: <20150520071142.GA19073@zoho.com> <20150520171742.GA13196@roeckx.be> Message-ID: <20150520205854.GB8836@zoho.com> On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote: > On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote: > > Hello. > > > > Given Adrien et al. recent paper [1] together with their > > proof-of-concept attacks against 512-bit DH groups [2], it might be > > a good time to resurrect a discussion Daniel Kahn Gillmor has > > started here in the past. > > Please see > http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > > Kurt Hi Kurt. Thanks for the link and congrats to EK for a well-written blog. A few questions... 1. On ECC: Did I correctly understand that starting with 1.0.2b, OpenSSL clients will only include secp256r1, secp384r1, and secp521r1 on the prime side and sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 on the binary side in supported elliptic curves extensions? Will OpenSSL consider making this change in 1.0.1 as well? 2. On FF DH: Is it possible for OpenSSL to provide a tentative timeline for its planned transition (no minimum -> 768-bit min -> 1024-bit min)? Right now the move to 1024-bit is slated for "soon" but tentative dates are likely more effective prods for sites (and others) using Jurassic modp's. Cheers. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From shailender.gola at verizon.com Wed May 20 21:09:36 2015 From: shailender.gola at verizon.com (Gola, Shailender K) Date: Wed, 20 May 2015 17:09:36 -0400 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555B2101.8000202@openssl.org> <555C5075.9080108@openssl.org> Message-ID: I ran some more tests, the issue seems to be optimization not platform types... when I removed -xO[n] from CFLAG, something (either cc or openssl compile set up) turned back on optimization at -xO3 level and I got this warning " cc: Warning: Optimizer level changed from 0 to 3 to support dependence based transformations." Since while using cc I was unable to force stop optimization, I used gcc and edited Makefile to remove optimization flag. It compiled with no alteration to optimization and the problem went away. Thanks for your help. Shailender Gola Verizon Telecom -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Wednesday, May 20, 2015 5:15 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" Attachment 1 indicates that you execute on SPARC. At the same time you keep mentioning configuration for solaris-x86-cc. In normal situation it's interpreted as two platforms. > 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see > attachment 2 showing " platform: solaris-x86-cc " (which I had done > before as well)... and executed the program, resulting in same ssl > errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept > problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption > failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: > SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert > bad record mac) If you force x86 configuration on SPARC, no guarantees can be provided. Even if it happens to work in some particular case. It just makes no sense to spend time thinking about it. From rt at openssl.org Wed May 20 21:10:22 2015 From: rt at openssl.org (Gola, Shailender K via RT) Date: Wed, 20 May 2015 23:10:22 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: References: <555A518A.4030101@openssl.org> <555C5075.9080108@openssl.org> Message-ID: I ran some more tests, the issue seems to be optimization not platform types... when I removed -xO[n] from CFLAG, something (either cc or openssl compile set up) turned back on optimization at -xO3 level and I got this warning " cc: Warning: Optimizer level changed from 0 to 3 to support dependence based transformations." Since while using cc I was unable to force stop optimization, I used gcc and edited Makefile to remove optimization flag. It compiled with no alteration to optimization and the problem went away. Thanks for your help. Shailender Gola Verizon Telecom -----Original Message----- From: Andy Polyakov via RT [mailto:rt at openssl.org] Sent: Wednesday, May 20, 2015 5:15 AM To: Gola, Shailender K Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac > 1) They are "not" two different platforms, merely same command executed for 2 different versions of openssl.. please see attachment 1 below. It is possible that 1.0.2a was configured use config where openssl picked defaults and 0.9.8g was build using "./Configure solaris-x86-cc" Attachment 1 indicates that you execute on SPARC. At the same time you keep mentioning configuration for solaris-x86-cc. In normal situation it's interpreted as two platforms. > 2) I rebuilt 1.0.2a using "./Configure solaris-x86-cc" please see > attachment 2 showing " platform: solaris-x86-cc " (which I had done > before as well)... and executed the program, resulting in same ssl > errors on server side (05-19 09:48:44.427 SSLERR: SSL_connect/accept > problem > error:1408F119:SSL routines:SSL3_GET_RECORD:decryption > failed or bad record), and on client side (05-19 09:48:44.444 SSLERR: > SSL_connect > error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert > bad record mac) If you force x86 configuration on SPARC, no guarantees can be provided. Even if it happens to work in some particular case. It just makes no sense to spend time thinking about it. From kurt at roeckx.be Wed May 20 21:31:00 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Wed, 20 May 2015 23:31:00 +0200 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150520205854.GB8836@zoho.com> References: <20150520071142.GA19073@zoho.com> <20150520171742.GA13196@roeckx.be> <20150520205854.GB8836@zoho.com> Message-ID: <20150520213100.GA32299@roeckx.be> On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote: > On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote: > > On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote: > > > Hello. > > > > > > Given Adrien et al. recent paper [1] together with their > > > proof-of-concept attacks against 512-bit DH groups [2], it might be > > > a good time to resurrect a discussion Daniel Kahn Gillmor has > > > started here in the past. > > > > Please see > > http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > > > > > Kurt > > Hi Kurt. Thanks for the link and congrats to EK for a well-written blog. > > A few questions... > > 1. On ECC: > > Did I correctly understand that starting with 1.0.2b, OpenSSL clients > will only include secp256r1, secp384r1, and secp521r1 on the prime side > and sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 on > the binary side in supported elliptic curves extensions? It also has the 3 brainpool curves and secp256k1. It looks like this: /* The client's default curves / the server's 'auto' curves. */ static const unsigned char eccurves_auto[] = { /* Prefer P-256 which has the fastest and most secure implementations. */ 0, 23, /* secp256r1 (23) */ /* Other >= 256-bit prime curves. */ 0, 25, /* secp521r1 (25) */ 0, 28, /* brainpool512r1 (28) */ 0, 27, /* brainpoolP384r1 (27) */ 0, 24, /* secp384r1 (24) */ 0, 26, /* brainpoolP256r1 (26) */ 0, 22, /* secp256k1 (22) */ /* >= 256-bit binary curves. */ 0, 14, /* sect571r1 (14) */ 0, 13, /* sect571k1 (13) */ 0, 11, /* sect409k1 (11) */ 0, 12, /* sect409r1 (12) */ 0, 9, /* sect283k1 (9) */ 0, 10, /* sect283r1 (10) */ }; > Will OpenSSL consider making this change in 1.0.1 as well? 1.0.1 doesn't support the auto ecdh, so we at least can't do exactly the same there. But maybe we should also update the default used by the client? > 2. On FF DH: > > Is it possible for OpenSSL to provide a tentative timeline for its > planned transition (no minimum -> 768-bit min -> 1024-bit min)? Right > now the move to 1024-bit is slated for "soon" but tentative dates are > likely more effective prods for sites (and others) using Jurassic > modp's. We haven't set any dates for anything yet. But the 768 minimum requirement is currently in the various branches in git. Master even has had 1024 as default for a while. Kurt From chris.hillsec at gmail.com Thu May 21 01:41:57 2015 From: chris.hillsec at gmail.com (Chris Hill) Date: Wed, 20 May 2015 21:41:57 -0400 Subject: [openssl-dev] Logjam clarification Message-ID: Folks, can you pls confirm that none of the below ciphers are affected by this bug? From my understanding, only ciphers containing DH or DHE would be affected. TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62) TLS_RSA_EXPORT1024_WITH_RC4_56_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_RSA_WITH_DES_CBC_SHA The above are weak, no argument there, but just want to ensure these are not vulnerable to this newly published bug. Thanks all! Chris. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mancha1 at zoho.com Thu May 21 03:29:23 2015 From: mancha1 at zoho.com (mancha) Date: Thu, 21 May 2015 03:29:23 +0000 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150520213100.GA32299@roeckx.be> References: <20150520071142.GA19073@zoho.com> <20150520171742.GA13196@roeckx.be> <20150520205854.GB8836@zoho.com> <20150520213100.GA32299@roeckx.be> Message-ID: <20150521032923.GA18213@zoho.com> On Wed, May 20, 2015 at 11:31:00PM +0200, Kurt Roeckx wrote: > On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote: > > On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote: > > > On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote: > > > > Hello. > > > > > > > > Given Adrien et al. recent paper [1] together with their > > > > proof-of-concept attacks against 512-bit DH groups [2], it might > > > > be a good time to resurrect a discussion Daniel Kahn Gillmor has > > > > started here in the past. > > > > > > Please see > > > http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > > > > > > > > Kurt > > > > Hi Kurt. Thanks for the link and congrats to EK for a well-written > > blog. > > > > A few questions... > > > > 1. On ECC: > > > > Did I correctly understand that starting with 1.0.2b, OpenSSL > > clients will only include secp256r1, secp384r1, and secp521r1 on the > > prime side and sect283k1, sect283r1, sect409k1, sect409r1, > > sect571k1, sect571r1 on the binary side in supported elliptic curves > > extensions? > > It also has the 3 brainpool curves and secp256k1. Yep, forgot about the addition of brainpool curves in 1.0.2. > > Will OpenSSL consider making this change in 1.0.1 as well? > > 1.0.1 doesn't support the auto ecdh, so we at least can't do exactly > the same there. But maybe we should also update the default used by > the client? The following pull request for 1.0.1-stable removes elliptic curves that provide less than the equivalent of 128 bits of symmetric key security from the list clients announce via supported elliptic curves extensions. https://github.com/openssl/openssl/pull/288 --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Thu May 21 05:53:50 2015 From: rt at openssl.org (Tobias Firnges via RT) Date: Thu, 21 May 2015 07:53:50 +0200 Subject: [openssl-dev] [openssl.org #3715] Resolved: Possible bug in openssl 64 bit version In-Reply-To: References: , Message-ID: Hello, can you please let me know what version it was fixed and also what exactly was the issue? Thank you in advance. > Subject: [openssl.org #3715] Resolved: Possible bug in openssl 64 bit version > From: rt at openssl.org > To: tobias_firnges at hotmail.com > Date: Wed, 20 May 2015 14:48:07 +0200 > > According to our records, your request has been resolved. If you have any > further questions or concerns, please respond to this message. From meissner at suse.de Thu May 21 06:49:24 2015 From: meissner at suse.de (Marcus Meissner) Date: Thu, 21 May 2015 08:49:24 +0200 Subject: [openssl-dev] Logjam clarification In-Reply-To: References: Message-ID: <20150521064924.GC12032@suse.de> On Wed, May 20, 2015 at 09:41:57PM -0400, Chris Hill wrote: > Folks, can you pls confirm that none of the below ciphers are affected by > this bug? From my understanding, only ciphers containing DH or DHE would be > affected. > > TLS_RSA_EXPORT1024_WITH_DES_CBC_SHA (0x62) > TLS_RSA_EXPORT1024_WITH_RC4_56_SHA > TLS_RSA_EXPORT_WITH_RC4_40_MD5 > TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 > TLS_RSA_WITH_DES_CBC_SHA > > The above are weak, no argument there, but just want to ensure these are > not vulnerable to this newly published bug. These have no forward secrecy at all, so technically they are not affected by the DH Logjam problem. But well, they should not be used anymore anyway. CIao, Marcus From matt at openssl.org Thu May 21 07:09:29 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 21 May 2015 08:09:29 +0100 Subject: [openssl-dev] [openssl.org #3715] Resolved: Possible bug in openssl 64 bit version In-Reply-To: References: , Message-ID: <555D84A9.1080007@openssl.org> On 21/05/15 06:53, Tobias Firnges via RT wrote: > Hello, can you please let me know what version it was fixed and also what exactly was the issue? Thank you in advance. Please see Peter's and Andy's notes in the RT ticket (which you should have received an email copy of???) https://rt.openssl.org/Ticket/Display.html?id=3715&user=guest&pass=guest Matt From rt at openssl.org Thu May 21 07:33:22 2015 From: rt at openssl.org (kolAflash@kolahilft.de via RT) Date: Thu, 21 May 2015 09:33:22 +0200 Subject: [openssl-dev] [openssl.org #3854] openssl.cnf in openssl-1.0.1m still uses default_bits=1024 In-Reply-To: <2533734.QspX2uaRnp@gaston.colazone> References: <2533734.QspX2uaRnp@gaston.colazone> Message-ID: Hi! I just read about the Logjam attack to Diffie-Hellman. https://weakdh.org/imperfect-forward-secrecy.pdf | We provide new estimates for the computational resources necessary | to compute discrete logarithms in groups of these sizes, concluding | that 768-bit groups are within range of academic teams, and | 1024-bit groups may plausibly be within range of state-level | attackers. (in German) http://www.heise.de/newsticker/meldung/Logjam-Attacke-Verschluesselung-von-zehntausenden-Servern-gefaehrdet-2657502.html openssl-1.0.1m still comes with default_bits = 1024 in apps/openssl.cnf (in the source tar-archive). Looks like openssl-1.0.2a has been upgraded to at least 2048. Did you consider to raising openssl-1.0.1m up to 1024 bits too? Additionally I found some more places with less than 2048 in the openssl-1.0.1m source tar-archive. But I'm not sure if those values may not be relevant or just for testing purposes: ./test/P2ss.cnf:10:default_bits = 1024 ./test/CAtsa.cnf:54:default_bits = 1024 ./test/P1ss.cnf:10:default_bits = 1024 ./test/test.cnf:59:default_bits = 1024 ./apps/openssl-vms.cnf:106:default_bits = 1024 ./apps/openssl.cnf:106:default_bits = 1024 ./crypto/conf/ssleay.cnf:15:default_bits = 512 ./crypto/conf/ssleay.cnf:19:default_bits = 512 ./crypto/conf/ssleay.cnf:51:default_bits = 512 ./doc/apps/req.pod:534: default_bits = 1024 ./doc/apps/req.pod:575: default_bits = 1024 ./doc/ssleay.txt:6935:default_bits = 512 # default number of bits to use. openssl-1.0.2a.tar.gz looks similar: ./test/P2ss.cnf:10:default_bits = 1024 ./test/CAtsa.cnf:54:default_bits = 1024 ./test/P1ss.cnf:10:default_bits = 1024 ./test/test.cnf:59:default_bits = 1024 ./crypto/conf/ssleay.cnf:15:default_bits = 512 ./crypto/conf/ssleay.cnf:19:default_bits = 512 ./crypto/conf/ssleay.cnf:51:default_bits = 512 ./doc/apps/req.pod:534: default_bits = 1024 ./doc/apps/req.pod:575: default_bits = 1024 ./doc/ssleay.txt:6935:default_bits = 512 # default number of bits to use. Kind regards, kolAflash -- E-Mail: kolAflash at kolahilft.de PGP key: 0xD83C3408 http://misc.kolahilft.de/pgp/kolAflash_0xD83C3408.asc https://en.wikipedia.org/wiki/Pretty_Good_Privacy https://de.wikipedia.org/wiki/OpenPGP Chat via Jabber/XMPP: kolAflash at jabber.ccc.de https://en.wikipedia.org/wiki/XMPP https://de.wikipedia.org/wiki/XMPP From rt at openssl.org Thu May 21 07:33:41 2015 From: rt at openssl.org (Anvesh Vagiri via RT) Date: Thu, 21 May 2015 09:33:41 +0200 Subject: [openssl-dev] [openssl.org #3855] Fix for TLS1.2 handshake error In-Reply-To: References: Message-ID: Hi, Since the upgrade to openssl 1.0.1e, i could see failures in ssl handshake. I found that as the below commit mentions about a workaround about trying to use the flags OPENSSL_MAX_TLS1_2_CIPHER_LENGTH and OPENSSL_NO_TLS1_2_CLIENT . For me the second flag finally worked and disabling TLS 1.2 fixed the issue. But im looking for a permanent fix instead of this workaround. Was there a complete fix done for this issue. https://github.com/openssl/openssl/commit/89bd25eb26bbc2ebceb4cd892e7453337804820c Thanks, Anvesh From rt at openssl.org Thu May 21 16:53:01 2015 From: rt at openssl.org (russell.webb@intel.com via RT) Date: Thu, 21 May 2015 18:53:01 +0200 Subject: [openssl-dev] [openssl.org #3856] [PATCH] Fix memory leaks in test code In-Reply-To: <1432223660-30551-1-git-send-email-russell.webb@intel.com> References: <1432223660-30551-1-git-send-email-russell.webb@intel.com> Message-ID: From: Russell Webb Several tests were not properly cleaning up everything on process exit, which prevented 'make test' from succeeding when running with address sanitizer enabled. Fix the tests to properly free all resources. Note that this was found with gcc version 6.0 and was not observed using gcc 4.9.2. Signed-off-by: Russell Webb --- test/bntest.c | 1 + test/hmactest.c | 3 +++ test/srptest.c | 1 + 3 files changed, 5 insertions(+) diff --git a/test/bntest.c b/test/bntest.c index 1ce6db1..891db62 100644 --- a/test/bntest.c +++ b/test/bntest.c @@ -1100,6 +1100,7 @@ int test_mod_exp_mont5(BIO *bp, BN_CTX *ctx) fprintf(stderr, "Modular exponentiation test failed!\n"); return 0; } + BN_MONT_CTX_free(mont); BN_free(a); BN_free(p); BN_free(m); diff --git a/test/hmactest.c b/test/hmactest.c index 13344d6..3b01598 100644 --- a/test/hmactest.c +++ b/test/hmactest.c @@ -188,6 +188,7 @@ int main(int argc, char *argv[]) } printf("test 4 ok\n"); test5: + HMAC_CTX_cleanup(&ctx); HMAC_CTX_init(&ctx); if (HMAC_Init_ex(&ctx, test[4].key, test[4].key_len, NULL, NULL)) { printf("Should fail to initialise HMAC with empty MD (test 5)\n"); @@ -272,6 +273,7 @@ test5: printf("test 5 ok\n"); } test6: + HMAC_CTX_cleanup(&ctx); HMAC_CTX_init(&ctx); if (!HMAC_Init_ex(&ctx, test[7].key, test[7].key_len, EVP_sha1(), NULL)) { printf("Failed to initialise HMAC (test 6)\n"); @@ -302,6 +304,7 @@ test6: printf("test 6 ok\n"); } end: + HMAC_CTX_cleanup(&ctx); EXIT(err); } diff --git a/test/srptest.c b/test/srptest.c index 1d463cd..8075218 100644 --- a/test/srptest.c +++ b/test/srptest.c @@ -148,6 +148,7 @@ int main(int argc, char **argv) ERR_remove_thread_state(NULL); ERR_free_strings(); CRYPTO_mem_leaks(bio_err); + BIO_free(bio_err); return 0; } -- 2.1.0 From rt at openssl.org Thu May 21 17:16:23 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 21 May 2015 19:16:23 +0200 Subject: [openssl-dev] [openssl.org #3855] Fix for TLS1.2 handshake error In-Reply-To: <20150521171600.GA23622@roeckx.be> References: <20150521171600.GA23622@roeckx.be> Message-ID: On Thu, May 21, 2015 at 09:33:41AM +0200, Anvesh Vagiri via RT wrote: > Hi, > > Since the upgrade to openssl 1.0.1e, i could see failures in ssl handshake. > I found that as the below commit mentions about a workaround about trying > to use the flags OPENSSL_MAX_TLS1_2_CIPHER_LENGTH and OPENSSL_NO_TLS1_2_CLIENT > . > > For me the second flag finally worked and disabling TLS 1.2 fixed the > issue. But im looking for a permanent fix instead of this workaround. Was > there a complete fix done for this issue. The fix is to fix the other end, some firewall or ssl accelerator. This is not a bug in OpenSSL, this is a workaround for other broken products. If you're trying to connect to a public web site, the following URL might be able to tell what's wrong with the other side: https://www.ssllabs.com/ssltest/ It's most likely version intolerant, since the first define didn't help. You probably also only get a TLS 1.0 connection and not even a 1.1 connection. Kurt From rt at openssl.org Fri May 22 09:18:17 2015 From: rt at openssl.org (Quanah Gibson-Mount via RT) Date: Fri, 22 May 2015 11:18:17 +0200 Subject: [openssl-dev] [openssl.org #3857] hash files for validating source are incorrectly formed In-Reply-To: References: Message-ID: The hash files (md5, sha1) for validating downloaded source are not correclty formed, breaking the check (-c) function: wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz wget https://www.openssl.org/source/openssl-1.0.1m.tar.gz.sha1 build at c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c openssl-1.0.1m.tar.gz.sha1 sha1sum: openssl-1.0.1m.tar.gz.sha1: no properly formatted SHA1 checksum lines found build at c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat openssl-1.0.1m.tar.gz.sha1 4ccaf6e505529652f9fdafa01d1d8300bd9f3179 Now, to have it correctly formatted: build at c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum openssl-1.0.1m.tar.gz > openssl-1.0.1m.tar.gz.sha1 build at c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ cat openssl-1.0.1m.tar.gz.sha1 4ccaf6e505529652f9fdafa01d1d8300bd9f3179 openssl-1.0.1m.tar.gz build at c7test:~/p4/zimbra/main/ThirdParty/openssl/src$ sha1sum -c openssl-1.0.1m.tar.gz.sha1 openssl-1.0.1m.tar.gz: OK --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration From rt at openssl.org Fri May 22 09:28:00 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 22 May 2015 11:28:00 +0200 Subject: [openssl-dev] [openssl.org #2801] Lost alert if client receives bad hello in dtls1_read_bytes In-Reply-To: <1335271116.3314.5.camel@drobecek> References: <1335271116.3314.5.camel@drobecek> Message-ID: Patch applied. Many thanks. Matt From naynjain at in.ibm.com Fri May 22 10:11:09 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Fri, 22 May 2015 15:41:09 +0530 Subject: [openssl-dev] What key length is used for DHE by default ? Message-ID: Hi, With the latest logjam attack, as I was trying to verify if my server (lighttpd) accepts DHE_xxx ciphers, I saw that it accepted and I didn't do any configuration setting done for DH parameters explicitly. But I couldn't verify what is the key length did it use by default 512/1024/2048 ? Eg. the one it negotiated was DHE-RSA-AES128-SHA256 and for TLSv1.2 protocol ? Will the key length be different for different protocols like SSLv3/TLSv1.0/TLSv1.1/TLSv1.2? If yes , then what for each of them. Thanks & Regards, Nayna Jain -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Fri May 22 10:57:43 2015 From: hkario at redhat.com (Hubert Kario) Date: Fri, 22 May 2015 12:57:43 +0200 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: References: Message-ID: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> On Friday 22 May 2015 15:41:09 Nayna Jain wrote: > Hi, > > With the latest logjam attack, as I was trying to verify if my server > (lighttpd) accepts DHE_xxx ciphers, I saw that it accepted and I didn't > do any configuration setting done for DH parameters explicitly. There's no default in OpenSSL, applications need to set the DH parameters themselves. > But I couldn't verify what is the key length did it use by default > 512/1024/2048 ? openssl s_client -connect hostname:443 -cipher EDH /dev/null | grep 'Server Temp Key' > Will the key length be different for different protocols like > SSLv3/TLSv1.0/TLSv1.1/TLSv1.2? If yes , then what for each of them. no, it will be the same for all protocols -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From naynjain at in.ibm.com Fri May 22 15:48:19 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Fri, 22 May 2015 21:18:19 +0530 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> References: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> Message-ID: Hi Hubert, Thanks.. I tried the command you mentioned i.e. openssl s_client -connect hostname:443 -cipher EDH /dev/null | grep 'Server Temp Key' But it didn't output anything. Thanks & Regards, Nayna Jain From: Hubert Kario To: openssl-dev at openssl.org Cc: Nayna Jain/India/IBM at IBMIN, OpenSSL Users List Date: 05/22/2015 04:28 PM Subject: Re: [openssl-dev] What key length is used for DHE by default ? On Friday 22 May 2015 15:41:09 Nayna Jain wrote: > Hi, > > With the latest logjam attack, as I was trying to verify if my server > (lighttpd) accepts DHE_xxx ciphers, I saw that it accepted and I didn't > do any configuration setting done for DH parameters explicitly. There's no default in OpenSSL, applications need to set the DH parameters themselves. > But I couldn't verify what is the key length did it use by default > 512/1024/2048 ? openssl s_client -connect hostname:443 -cipher EDH /dev/null | grep 'Server Temp Key' > Will the key length be different for different protocols like > SSLv3/TLSv1.0/TLSv1.1/TLSv1.2? If yes , then what for each of them. no, it will be the same for all protocols -- Regards, Hubert Kario Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic [attachment "signature.asc" deleted by Nayna Jain/India/IBM] -------------- 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 rsalz at akamai.com Fri May 22 16:00:28 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 22 May 2015 16:00:28 +0000 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: References: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> Message-ID: <690ec6867c7240a6adcf33c5394ade66@ustx2ex-dag1mb2.msg.corp.akamai.com> Did you follow the full instructions - using a 1.0.2 openssl client? The blog posting is pretty clear. https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From naynjain at in.ibm.com Fri May 22 16:32:06 2015 From: naynjain at in.ibm.com (Nayna Jain) Date: Fri, 22 May 2015 22:02:06 +0530 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: <690ec6867c7240a6adcf33c5394ade66@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> <690ec6867c7240a6adcf33c5394ade66@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: Ok, I think this is what I didn't know. I was using openssl 1.0.1g client. I still didn't have openssl 1.0.2 . Thanks.. Thanks & Regards, Nayna Jain From: "Salz, Rich" To: "openssl-dev at openssl.org" Date: 05/22/2015 09:31 PM Subject: Re: [openssl-dev] What key length is used for DHE by default ? Sent by: "openssl-dev" Did you follow the full instructions ? using a 1.0.2 openssl client? The blog posting is pretty clear. https://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- 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 rainer.jung at kippdata.de Fri May 22 16:43:28 2015 From: rainer.jung at kippdata.de (Rainer Jung) Date: Fri, 22 May 2015 18:43:28 +0200 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: References: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> <690ec6867c7240a6adcf33c5394ade66@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: <555F5CB0.3040405@kippdata.de> Am 22.05.2015 um 18:32 schrieb Nayna Jain: > Ok, I think this is what I didn't know. I was using openssl 1.0.1g client. > > I still didn't have openssl 1.0.2 . If it were trivial I think showing the temp key size would be a welcome backport to 1.0.1 before the next release. It is very useful in light of logjam but many people are not yet at 1.0.2. Of course they wont get the latest 1.0.1 immediately, but distros have a chance to backport. Regards, Rainer From rt at openssl.org Fri May 22 18:28:53 2015 From: rt at openssl.org (Billy Brumley via RT) Date: Fri, 22 May 2015 20:28:53 +0200 Subject: [openssl-dev] [openssl.org #3858] [PATCH] fix copy paste error in ec_GF2m function prototypes In-Reply-To: References: Message-ID: Just removes some duplication in the header file. Patch attached. BBB -------------- next part -------------- A non-text attachment was scrubbed... Name: ec_lcl.patch Type: text/x-patch Size: 1153 bytes Desc: not available URL: From rt at openssl.org Fri May 22 20:58:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 22 May 2015 22:58:01 +0200 Subject: [openssl-dev] [openssl.org #266] Resolved: [PATCH] Proposed proxy client functionality in s_client References: Message-ID: According to our records, your request has been resolved. If you have any further questions or concerns, please respond to this message. From rt at openssl.org Fri May 22 20:58:01 2015 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 22 May 2015 22:58:01 +0200 Subject: [openssl-dev] [openssl.org #266] [PATCH] Proposed proxy client functionality in s_client In-Reply-To: <20020903153348.A67070@deejai2.mch.fsc.net> References: <20020903153348.A67070@deejai2.mch.fsc.net> Message-ID: Thanks for your patience ;) This will be in the next release of openssl; it is checked into master. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From de.techno at gmail.com Sat May 23 03:48:16 2015 From: de.techno at gmail.com (dE) Date: Sat, 23 May 2015 09:18:16 +0530 Subject: [openssl-dev] X11 forwarding not working. Message-ID: <555FF880.7050704@gmail.com> Hi! I'm having a difficult time getting X11 forwarding to work. Since I've read the docs completely about this, this must be an SSH bug which is likely because I'm using Gentoo as the SSH server. When trying to forward X11 connections, I get X11 connection rejected because of wrong authentication. kwrite: cannot connect to X server XXXXXXXXX:10.0 Using command ssh -Y -p 1111 -4 -i testkey test at 127.0.0.1 I'm not using any X11 library build with ipv6 support. I tried building the relevant library (after seeing the dependency of the X11 application) with ipv6 support, but it was of no help. Of course first I did not use -4. In the server, I've tried disabling ipv6 support. The following exists in sshd_config -- X11UseLocalhost no X11Forwarding yes I've tried xhost + on the client and the server (although it wont help on the server). Thank you for any assistance. From jeremy.farrell at oracle.com Sat May 23 07:49:15 2015 From: jeremy.farrell at oracle.com (Jeremy Farrell) Date: Sat, 23 May 2015 08:49:15 +0100 Subject: [openssl-dev] X11 forwarding not working. In-Reply-To: <555FF880.7050704@gmail.com> References: <555FF880.7050704@gmail.com> Message-ID: <556030FB.8090505@oracle.com> You presumably meant to send this to a mailing list which discusses ssh. You sent it to openssl-dev which is the list for discussing development of the the OpenSSL project, nothing to do with ssh. Regards, jjf On 23/05/2015 04:48, dE wrote: > Hi! > > I'm having a difficult time getting X11 forwarding to work. > > Since I've read the docs completely about this, this must be an SSH > bug which is likely because I'm using Gentoo as the SSH server. > > When trying to forward X11 connections, I get > > X11 connection rejected because of wrong authentication. > kwrite: cannot connect to X server XXXXXXXXX:10.0 > > Using command > > ssh -Y -p 1111 -4 -i testkey test at 127.0.0.1 > > I'm not using any X11 library build with ipv6 support. I tried > building the relevant library (after seeing the dependency of the X11 > application) with ipv6 support, but it was of no help. > > Of course first I did not use -4. > > In the server, I've tried disabling ipv6 support. > > The following exists in sshd_config -- > X11UseLocalhost no > X11Forwarding yes > > I've tried xhost + on the client and the server (although it wont help > on the server). > > Thank you for any assistance. > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- J. J. Farrell w: +44 161 493 4838 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat May 23 08:34:47 2015 From: rt at openssl.org (Khem Raj via RT) Date: Sat, 23 May 2015 10:34:47 +0200 Subject: [openssl-dev] [openssl.org #3859] [PATCH] Define GCC_VERSION macro to cover upto gcc-5 In-Reply-To: <1432324049-12896-1-git-send-email-raj.khem@gmail.com> References: <1432324049-12896-1-git-send-email-raj.khem@gmail.com> Message-ID: Current check is limited to gcc 4 with minor versions but when we use gcc 5.1, then minor version check fails with current setup and we end up with build errors like | In file included from bn_div.c:62:0: | bn_div.c: In function 'BN_div': | bn_lcl.h:311:9: error: impossible constraint in 'asm' | asm ("dmultu %2,%3" \ | ^ | bn_div.c:402:13: note: in expansion of macro 'BN_UMULT_LOHI' | BN_UMULT_LOHI(t2l, t2h, d1, q); | ^ | : recipe for target 'bn_div.o' failed | make[2]: *** [bn_div.o] Error 1 Signed-off-by: Khem Raj --- crypto/bn/bn_lcl.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/crypto/bn/bn_lcl.h b/crypto/bn/bn_lcl.h index 196df7e..e801ba7 100644 --- a/crypto/bn/bn_lcl.h +++ b/crypto/bn/bn_lcl.h @@ -118,6 +118,9 @@ extern "C" { #endif +#define GCC_VERSION (__GNUC__ * 10000 \ + + __GNUC_MINOR__ * 100 \ + + __GNUC_PATCHLEVEL__) /*- * Bignum consistency macros * There is one "API" macro, bn_fix_top(), for stripping leading zeroes from @@ -443,7 +446,7 @@ unsigned __int64 _umul128(unsigned __int64 a, unsigned __int64 b, # endif # elif defined(__mips) && (defined(SIXTY_FOUR_BIT) || defined(SIXTY_FOUR_BIT_LONG)) # if defined(__GNUC__) && __GNUC__>=2 -# if __GNUC__>=4 && __GNUC_MINOR__>=4 +# if GCC_VERSION > 40400 /* "h" constraint is no more since 4.4 */ # define BN_UMULT_HIGH(a,b) (((__uint128_t)(a)*(b))>>64) # define BN_UMULT_LOHI(low,high,a,b) ({ \ -- 2.1.4 From de.techno at gmail.com Sat May 23 16:53:42 2015 From: de.techno at gmail.com (dE) Date: Sat, 23 May 2015 22:23:42 +0530 Subject: [openssl-dev] X11 forwarding not working. In-Reply-To: <556030FB.8090505@oracle.com> References: <555FF880.7050704@gmail.com> <556030FB.8090505@oracle.com> Message-ID: <5560B096.2060503@gmail.com> On 05/23/15 13:19, Jeremy Farrell wrote: > You presumably meant to send this to a mailing list which discusses > ssh. You sent it to openssl-dev which is the list for discussing > development of the the OpenSSL project, nothing to do with ssh. > > Regards, > jjf > > On 23/05/2015 04:48, dE wrote: >> Hi! >> >> I'm having a difficult time getting X11 forwarding to work. >> >> Since I've read the docs completely about this, this must be an SSH >> bug which is likely because I'm using Gentoo as the SSH server. >> >> When trying to forward X11 connections, I get >> >> X11 connection rejected because of wrong authentication. >> kwrite: cannot connect to X server XXXXXXXXX:10.0 >> >> Using command >> >> ssh -Y -p 1111 -4 -i testkey test at 127.0.0.1 >> >> I'm not using any X11 library build with ipv6 support. I tried >> building the relevant library (after seeing the dependency of the X11 >> application) with ipv6 support, but it was of no help. >> >> Of course first I did not use -4. >> >> In the server, I've tried disabling ipv6 support. >> >> The following exists in sshd_config -- >> X11UseLocalhost no >> X11Forwarding yes >> >> I've tried xhost + on the client and the server (although it wont >> help on the server). >> >> Thank you for any assistance. >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > -- > J. J. Farrell > w: +44 161 493 4838 > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev Ok. Sorry about that. Last time it was the the other way around. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mancha1 at zoho.com Sat May 23 21:11:20 2015 From: mancha1 at zoho.com (mancha) Date: Sat, 23 May 2015 21:11:20 +0000 Subject: [openssl-dev] Weak DH and the Logjam In-Reply-To: <20150521032923.GA18213@zoho.com> References: <20150520071142.GA19073@zoho.com> <20150520171742.GA13196@roeckx.be> <20150520205854.GB8836@zoho.com> <20150520213100.GA32299@roeckx.be> <20150521032923.GA18213@zoho.com> Message-ID: <20150523211120.GA8515@zoho.com> On Thu, May 21, 2015 at 03:29:23AM +0000, mancha wrote: > On Wed, May 20, 2015 at 11:31:00PM +0200, Kurt Roeckx wrote: > > On Wed, May 20, 2015 at 08:58:54PM +0000, mancha wrote: > > > On Wed, May 20, 2015 at 07:17:43PM +0200, Kurt Roeckx wrote: > > > > On Wed, May 20, 2015 at 07:11:42AM +0000, mancha wrote: > > > > > Hello. > > > > > > > > > > Given Adrien et al. recent paper [1] together with their > > > > > proof-of-concept attacks against 512-bit DH groups [2], it > > > > > might be a good time to resurrect a discussion Daniel Kahn > > > > > Gillmor has started here in the past. > > > > > > > > Please see > > > > http://www.openssl.org/blog/blog/2015/05/20/logjam-freak-upcoming-changes/ > > > > > > > > > > > > Kurt > > > > > > Hi Kurt. Thanks for the link and congrats to EK for a well-written > > > blog. > > > > > > A few questions... > > > > > > 1. On ECC: > > > > > > Did I correctly understand that starting with 1.0.2b, OpenSSL > > > clients will only include secp256r1, secp384r1, and secp521r1 on > > > the prime side and sect283k1, sect283r1, sect409k1, sect409r1, > > > sect571k1, sect571r1 on the binary side in supported elliptic > > > curves extensions? > > > > It also has the 3 brainpool curves and secp256k1. > > Yep, forgot about the addition of brainpool curves in 1.0.2. > > > > Will OpenSSL consider making this change in 1.0.1 as well? > > > > 1.0.1 doesn't support the auto ecdh, so we at least can't do exactly > > the same there. But maybe we should also update the default used by > > the client? > > The following pull request for 1.0.1-stable removes elliptic curves > that provide less than the equivalent of 128 bits of symmetric key > security from the list clients announce via supported elliptic curves > extensions. > > https://github.com/openssl/openssl/pull/288 > Commit now mentions changes in CHANGES. New pull request is #290. https://github.com/openssl/openssl/issues/290 --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From mancha1 at zoho.com Sat May 23 22:15:27 2015 From: mancha1 at zoho.com (mancha) Date: Sat, 23 May 2015 22:15:27 +0000 Subject: [openssl-dev] What key length is used for DHE by default ? In-Reply-To: <555F5CB0.3040405@kippdata.de> References: <1615689.S1BsVcJ9Gg@pintsize.usersys.redhat.com> <690ec6867c7240a6adcf33c5394ade66@ustx2ex-dag1mb2.msg.corp.akamai.com> <555F5CB0.3040405@kippdata.de> Message-ID: <20150523221527.GB8515@zoho.com> On Fri, May 22, 2015 at 06:43:28PM +0200, Rainer Jung wrote: > Am 22.05.2015 um 18:32 schrieb Nayna Jain: > >Ok, I think this is what I didn't know. I was using openssl 1.0.1g > >client. I still didn't have openssl 1.0.2 . > > If it were trivial I think showing the temp key size would be a > welcome backport to 1.0.1 before the next release. It is very useful > in light of logjam but many people are not yet at 1.0.2. Of course > they wont get the latest 1.0.1 immediately, but distros have a chance > to backport. > > Regards, > > Rainer Hi Rainer (and devs). I had already done this for personal consumption. When I saw your email I decided to make a pull request (devs, for your consideration): https://github.com/openssl/openssl/pull/291 If you'd like to patch OpenSSL 1.0.1m immediately, grab my patch (https://github.com/mancha1/openssl/commit/a59f22520bb5.patch), remove the first hunk (to CHANGES), and apply it. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Sun May 24 07:10:00 2015 From: rt at openssl.org (Solar Designer via RT) Date: Sun, 24 May 2015 09:10:00 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <20150524070919.GE18510@openwall.com> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <20150524070919.GE18510@openwall.com> Message-ID: Hi Andy, Thank you for your reply! I am CC'ing Lei on mine. On Wed, May 20, 2015 at 12:55:10PM +0200, Andy Polyakov via RT wrote: > For reference. icc was not cared for for quite some time. Initially it > was possible for me, by then university employee, to use it, but then > they changes terms and it became impossible for me to maintain it. But > I've just noticed they provide some starter version of something, I'll > see... Yes, this might be usable for you: https://software.intel.com/en-us/qualify-for-free-software/opensourcecontributor "Intel provides select Intel Software Development Products at no cost to qualified open source contributors who are working on open source projects compliant with the Open Source Initiative (OSI)." > But linux-x86_64-icc is not present in and was never supported in > pre-1.0.2. Oh, I didn't realize that. Like I mentioned, we're actually building with icc for MIC. When we build with icc for x86_64 host, we typically simply link against the distro's gcc-built OpenSSL, so didn't run into this issue ourselves until we started building for MIC and thus had to make our own OpenSSL build with icc. (Indeed, I've been building OpenSSL from source on many other occasions, and as part of a distro too, but that's not with icc and unrelated to JtR project.) > So you ought to provide custom line. This remark doesn't mean > that fix can't be backported, but out of curiosity, what's your config > line? Currently, Lei put this into JtR -jumbo README-MIC: Build LibreSSL (version 2.1.6): $ cd libressl-2.1.6 $ ./configure CC="icc -mmic" --host=k1om-linux --prefix=$MIC $ make && make install The previous instructions were: Build OpenSSL (version 1.0.0q): $ cd openssl-1.0.0q $ patch Configure < $JOHN/src/unused/openssl.patch $ ./Configure linux-mic shared --prefix=$MIC $ make && make install I'm not sure what was in $JOHN/src/unused/openssl.patch - I guess it had to add linux-mic support. Lei, please reply to all. > Is assembly engaged? If so, how fast is it? Or is it so that you > count on compiler to produce vector code that would process multiple > inputs in parallel with SIMD? We're using OpenSSL (or LibreSSL) as an easy but slower option, replacing it with our own SIMD code right in JtR tree whenever we can and where this makes sense. So we're not trying to optimize OpenSSL's code. It remains scalar and unmodified, and our use of it is just to have things working where we do not have optimized code yet or where we prefer simpler rather than faster code (such as for some lightweight precomputation in some rare cases where this makes sense). This varies by crypto primitive, but overall we currently have SIMD intrinsics code for MMX, SSE2+/AVX, XOP, AVX2, MIC/AVX-512, and for bitslice DES also for AltiVec and NEON. One thing for which we still use OpenSSL's code in performance-critical manner is SSH key passphrase cracking (which involves RSA). There are probably many more examples like this, but this is a prominent one that comes to mind. There must be a lot of room for optimization here. As to compiler auto-vectorization - no, we are not relying on it. > On related note. What's Xeon Phi in this context? I mean are we talking > about Knights Corner Unfortunately, yes. BTW, you're welcome to play with it if you like: http://openwall.info/wiki/HPC/Village > (that features own compatible-with-nothing SIMD instruction set) Yes, but at source code level many intrinsics match AVX-512. So we use it as a way to prepare for AVX-512. In many cases, it's just a recompile away. There are some notable exceptions to this, though - in fact, you happened to list some below. > or Knights Landing (that features AVX512)? If latter, > it might be interesting to extend multi-block SHA support(*), which > should allow to achieve pretty cool results (with vector rotate and > ternary logic instructions, not to mention 16 lanes:-). [As for > "interesting". It's possible but not really interesting in Knights > Corner case, because effort is too specific, just a single obscure and > hardly available CPU, while AVX512 is planned even for other processors > so that code will be reusable.] This will take some #ifdef's to provide vector rotates as a macro when building for MIC and to use the ternary logic intrinsics only when building for true AVX-512 - nasty, but I think reasonable. For now, we're simply using the common subset between MIC and AVX-512: https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/src/pseudo_intrinsics.h https://github.com/magnumripper/JohnTheRipper/blob/bleeding-jumbo/src/sse-intrinsics.c > (*) BTW, did you try existing one? No, totally missed it! Found it now, good work! $ find -name 'sha*-mb*' ./crypto/sha/asm/sha256-mb-x86_64.pl ./crypto/sha/asm/sha1-mb-x86_64.pl How is an application using OpenSSL supposed to access this functionality? Is there documentation? So far, I only found uses in OpenSSL's own e_aes_cbc_hmac_sha*.c and no export of these symbols. You could want to add optional use of XOP there - rotates and vcmov. For SHA-1, F() is just one vcmov and H() is vcmov/andnot/xor (see sse-intrinsics.c above). For SHA-2, we use: #define Maj(x,y,z) vcmov(x, y, vxor(z, y)) #define Ch(x,y,z) vcmov(y, z, x) We're also experimenting with instruction interleaving. Sometimes, especially when running only 1 thread/core (such as on cheaper Intel CPUs without HT, or when there's no thread-level parallelism in the application - not our case, though), it's optimal to interleave several SIMD computations, for even wider virtual SIMD vectors than the CPU supports natively. e.g. for MD5 on AVX (64-bit builds only, since need 16 registers for interleaving), we currently interleave 3 of those (so 12 MD5's in parallel per thread). Is it OK that we went quite off-topic on this RT issue? Alexander From rt at openssl.org Sun May 24 11:09:03 2015 From: rt at openssl.org (Rainer Jung via RT) Date: Sun, 24 May 2015 13:09:03 +0200 Subject: [openssl-dev] [openssl.org #3860] Some Sparc build configurations for gcc use deprecated -mv8 In-Reply-To: <5561716C.6070507@kippdata.de> References: <5561716C.6070507@kippdata.de> Message-ID: Some build configurations for gcc on Sparc use the outdated gcc switch -mv8. The switch was deprecated at least back for gcc 2.95.2 in October 1999 ([1][2]). GCC 4 does no longer support the -mv8 switch but instead now you have to use the switch that was already preferred for version 2.95.2: -mcpu=v8 ([3]). Please replace all occurrences of "-mv8" in Configure (Release branches) resp. Configurations/10-main.conf (master) with -mcpu=v8. Thanks, Rainer [1] https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_2.html#SEC19 [2] http://www.gnu.org/software/gcc/releases.html [3] https://gcc.gnu.org/gcc-4.0/changes.html From rt at openssl.org Sun May 24 13:36:12 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 24 May 2015 15:36:12 +0200 Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface In-Reply-To: <5561D3B3.1060506@openssl.org> References: <555A08F0.8030508@openssl.org> <5561D3B3.1060506@openssl.org> Message-ID: > More coming in. Here are preliminary results for 32- and 64-bit ARM. "Preliminary" means that they are incomplete and subject to change. But in a sense they underpin some of the points in previous post, both in message itself and source code commentary. Consider 32-bit results. First column is assembly results for base 2^32 integer-only code in comparison to compiler-generate code. Second column is my result for NEON, and last column are results for Andrew Moon's NEON implementation, both are base 2^26. # IALU/gcc-4.4 NEON poly1305-opt # # Cortex-A5 6.30/+130% 2.96 4.90 # Cortex-A8 6.25/+115% 2.40 2.36 # Cortex-A9 5.10/+95% 2.56 2.25 # Cortex-A15 3.79/+85% 1.30 1.53 # Snapdragon S4 5.70/+100% 1.48 7.58(?) As mentioned earlier goal is "all-round" performance, i.e. near-optimal performance across *range* of platforms. Judging from Cortex-A9 result I have some room for improvement, hopefully it will benefit all processors. As for (?). It's not clear why poly1305-opt has performed so poorly on Snapdragon S4, it might happen that it failed to opt for NEON for some reason. I have no possibility to verify, because it's somebody else's mobile phone. Here are some results for base 2^64 integer-only implementation on 64-bit ARM, and base 2^26 32-bit NEON results. Latter means that I haven't ventured to NEON on 64-bit ARM yet, but as performance would be virtually same (because NEON instruction set capabilities are essentially same and it would be same base), we can use it to compare and assess options. # IALU gcc-4.9 gcc-4.7 NEON poly1305-opt # # Cortex-A53 2.72 4.16 9.09 1.57 2.52 # Cortex-A57 2.70 2.89 6.46 1.30 1.46 # Denver 1.45 2.09 5.63 1.50 1.34 IALU vs. compiler-generated code basically tells the reason why we program assembly, doesn't it? I mean if you compare assembly and gcc-4.9 on Cortex-A57, you'd probably say that assembly doesn't make sense. But if you look at remaining results, you'll see that you are kind of left to compiler's mercy and it's not that "mighty" in every situation. These results also confirm concern in commentary session in poly1305.c about base 2^64 not being optimal for every 64-bit case. Indeed, gcc-4.7 base 2^64 results are actually worse that base 2^32. Well, to be honest I was actually referring more to instruction set capabilities, but it can be extended to even to compiler. From rt at openssl.org Sun May 24 15:04:20 2015 From: rt at openssl.org (Lei Zhang via RT) Date: Sun, 24 May 2015 17:04:20 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <6565AFBC-FC27-4716-A790-3FDF4A6BFEC8@gmail.com> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <20150524070919.GE18510@openwall.com> <6565AFBC-FC27-4716-A790-3FDF4A6BFEC8@gmail.com> Message-ID: > On May 24, 2015, at 3:09 PM, Solar Designer wrote: > >> So you ought to provide custom line. This remark doesn't mean >> that fix can't be backported, but out of curiosity, what's your config >> line? > > Currently, Lei put this into JtR -jumbo README-MIC: > > Build LibreSSL (version 2.1.6): > $ cd libressl-2.1.6 > $ ./configure CC="icc -mmic" --host=k1om-linux --prefix=$MIC > $ make && make install > > The previous instructions were: > > Build OpenSSL (version 1.0.0q): > $ cd openssl-1.0.0q > $ patch Configure < $JOHN/src/unused/openssl.patch > $ ./Configure linux-mic shared --prefix=$MIC > $ make && make install > > I'm not sure what was in $JOHN/src/unused/openssl.patch - I guess it had > to add linux-mic support. Lei, please reply to all. Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64". >From the original patch: (...) "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", (...) Lei From dixoncx at gmail.com Sun May 24 15:22:01 2015 From: dixoncx at gmail.com (Dixon Xavier) Date: Sun, 24 May 2015 20:52:01 +0530 Subject: [openssl-dev] OpenSSL for windows with /fixed flag Message-ID: Hi, Going by the description in links: http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visual-Studio-2010-fails-self-tests-td36372.html http://mailing.openssl.dev.narkive.com/HfYeReuA/fips-module-1-2-build-with-visual-studio-2010-fails-self-tests I understand that adding /fixed flag for linker has resolved the 'FIPS selftest failure issues' when OpenSSL is built for 32-bit mode in VS 2010. I would like to understand why the same change (adding /fixed) is *not* required in case of OpenSSL 64-bit builds. Regards, Dixon Xavier From steve at openssl.org Sun May 24 16:42:09 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Sun, 24 May 2015 16:42:09 +0000 Subject: [openssl-dev] OpenSSL for windows with /fixed flag In-Reply-To: References: Message-ID: <20150524164209.GA2891@openssl.org> On Sun, May 24, 2015, Dixon Xavier wrote: > Hi, > > Going by the description in links: > http://openssl.6102.n7.nabble.com/FIPS-Module-1-2-build-with-Visual-Studio-2010-fails-self-tests-td36372.html > http://mailing.openssl.dev.narkive.com/HfYeReuA/fips-module-1-2-build-with-visual-studio-2010-fails-self-tests > > I understand that adding /fixed flag for linker has resolved the 'FIPS > selftest failure issues' when OpenSSL is built for 32-bit mode in VS > 2010. > > I would like to understand why the same change (adding /fixed) is > *not* required in case of OpenSSL 64-bit builds. > The integrity test performs an in core hash. If a DLL gets relocated to an address other than the original location then the hashes will be different and the test will fail. For 64 bits Windows builds (and other platforms whether 32 or 64 bits) the compilers can be persuaded to output position independent code so the data hashed is independent of the load address. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From wjongenelen at temporaldefense.com Sun May 24 17:07:17 2015 From: wjongenelen at temporaldefense.com (will jongenelen) Date: Sun, 24 May 2015 10:07:17 -0700 Subject: [openssl-dev] Getting started question. Message-ID: <000001d09644$170f5e10$452e1a30$@temporaldefense.com> Hello, I want to add OpenSSL to my Cortex M3 bare metal platform. I am using a Keil IDE and I am having trouble configuring a library to support this environment. Any suggestions would be most appreciated. Thanks for your time! Best regards Will -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sun May 24 19:45:50 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 24 May 2015 21:45:50 +0200 Subject: [openssl-dev] [openssl.org #3852] bn_gfm2.c: in BN_GF2m_mod_arr() a check is optimized out In-Reply-To: <55622A2C.1080200@openssl.org> References: <555A4E56.7080900@openssl.org> <555B9746.4020502@openssl.org> <55622A2C.1080200@openssl.org> Message-ID: > I don't think its optimizing it out I agree with you, but your > suggested change resolved the error so Wim was right about it being > undefined behaviour, and the tool which uses clang 3.4 was warning us > about that. > I added my own debugging statement and ran ectest and it is indeed > undefined behaviour (though it doesn't matter much as the results not > used as WIm stated) before your patch: > > printf("DBG: zz=" BN_DEC_FMT1 " d0=%d\n", zz, d0); > Example Output line (before your patch): > DBG: zz=1 d0=1 (UB) > Output line (after your patch): > DBG: zz=89619874872 d0=7 > > > On Tue, May 19, 2015 at 4:04 PM, Andy Polyakov via RT wrote: >> The commit intention is actually sane. This kind of brings us back to >> question why was it optimized away? BTW, which compiler version is it >> and what are your optimization flags? I can't reproduce the problem with >> clang 3.6 and -O3. I mean I don't see that check for tmp_ulong is >> optimized away. In either case, as intention is sane, the only possible >> modification would be >> >> if (d0 && (tmp_ulong = zz >> d1)) >> >> So that right shift is not attempted if d0 is zero. Committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commit;h=86e5d1e32b2d702a5fc777e612cd746e790098ef. From rt at openssl.org Sun May 24 19:59:04 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sun, 24 May 2015 21:59:04 +0200 Subject: [openssl-dev] [openssl.org #3851] bug report; error:1408F119:SSL routines:SSL3_GET_RECORD:decryption failed or bad record mac In-Reply-To: <55622D6F.3030002@openssl.org> References: <555A518A.4030101@openssl.org> <555C5075.9080108@openssl.org> <55622D6F.3030002@openssl.org> Message-ID: > I ran some more tests, the issue seems to be optimization not platform types... If non-matching platform config happens to work, it's a party trick, not support matter. > when I removed -xO[n] from CFLAG, something (either cc or openssl compile set up) turned back on optimization at -xO3 level and I got this warning " cc: Warning: Optimizer level changed from 0 to 3 to support dependence based transformations." > > Since while using cc I was unable to force stop optimization, I used gcc and edited Makefile to remove optimization flag. It compiled with no alteration to optimization and the problem went away. As it appears to be compiler problem, the case is being dismissed as non-OpenSSL issue. But one could still point out that it likely means that compiler is not cared for in sense that it's not like Sun compiler is known to be pathologically/inherently broken, bugs do get fixed and it wouldn't be surprising if latest compiler patch/revision works. From appro at openssl.org Sun May 24 20:03:19 2015 From: appro at openssl.org (Andy Polyakov) Date: Sun, 24 May 2015 22:03:19 +0200 Subject: [openssl-dev] Question about valgrind error in DH in 1.0.2 In-Reply-To: <555AEB20.1000009@openssl.org> References: <87617wpvlk.fsf@zakalwe.freeside.no> <55535536.6050403@cisco.com> <87bnhoo9a1.fsf@zakalwe.freeside.no> <555363AF.8000403@cisco.com> <555387AC.90708@cisco.com> <555AEB20.1000009@openssl.org> Message-ID: <55622E87.70504@openssl.org> >> Changing the movzwl to movzbl in bn_get_bits5 eliminates the valgrind >> error. But this isn't a valid fix since bn_get_bits5 no longer returns >> the correct data. My assembly skills are near nil. Maybe someone else >> can propose a valid fix. >> >> Having said this, this does show the problem appears to be due to the >> movzwl reading past the end of the buffer by a byte. > > Correct. > >> Given the data >> allocated on the heap is likely surrounded by guard bytes, this is >> likely a benign read outside the buffer. > > Correct. > >> But it should still be fixed. > > Test attached. Committed as http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=69567687b0b7ed67831c17a010f4d46dfd059aef From rt at openssl.org Mon May 25 09:55:53 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 11:55:53 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <5562F19A.5050602@openssl.org> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <20150524070919.GE18510@openwall.com> <5562F19A.5050602@openssl.org> Message-ID: Hi, Thanks for tips and pointers. As for getting off-topic, I'm the one to blame anyway. So I'm going to strip most of message and comment on points that still might be of public interest. >> (*) BTW, did you try existing [multi-block SHA]? > > No, totally missed it! Found it now, good work! > > $ find -name 'sha*-mb*' > ./crypto/sha/asm/sha256-mb-x86_64.pl > ./crypto/sha/asm/sha1-mb-x86_64.pl > > How is an application using OpenSSL supposed to access this > functionality? Is there documentation? So far, I only found uses in > OpenSSL's own e_aes_cbc_hmac_sha*.c and no export of these symbols. Well, you have to admit that it's a bit too special to provide general-purpose interface to it. Which is why application-specific interface is provided instead, TLS-oriented one in e_aes_cbc_hmac_sha*.c. Mention of multi-block SHA was not really "go ahead and use it" kind, but rather "is it interesting?" with implied "if it is interesting, then we can discuss how to interface your application to it". Note that it's even possible to take those modules out of OpenSSL context... > You could want to add optional use of XOP there - rotates and vcmov. > For SHA-1, F() is just one vcmov and H() is vcmov/andnot/xor (see > sse-intrinsics.c above). For SHA-2, we use: > > #define Maj(x,y,z) vcmov(x, y, vxor(z, y)) > #define Ch(x,y,z) vcmov(y, z, x) As for XOP. Motto is to provide near-optimal performance with minimum code. That means that if some processor-specific optimization provides just little improvement, then it's likely to be omitted. I don't recall attempting XOP specifically in multi-block SHA256, but it was attempted in SHA1 and it wasn't impressive. I even recall XOP-rotates delivering worse performance in some case. It likely was some instruction alignment issue (at least I ran into some anomaly with ChaCha code when merely flipping order of instruction input arguments affected performance). Another case of XOP omission is plain SHA256. Point there is that execution is dominated by scalar part and reducing number of vector instruction has no effect whatsoever. Anyway, XOP is considered, but so far was not found "worthy". But it makes sense to double-check specifically multi-block SHA256... > We're also experimenting with instruction interleaving. Sometimes, > especially when running only 1 thread/core (such as on cheaper Intel > CPUs without HT, or when there's no thread-level parallelism in the > application - not our case, though), it's optimal to interleave several > SIMD computations, for even wider virtual SIMD vectors than the CPU > supports natively. e.g. for MD5 on AVX (64-bit builds only, since need > 16 registers for interleaving), we currently interleave 3 of those (so > 12 MD5's in parallel per thread). It's not uncommon that cryptographic algorithms have short dependency chains and consequently limited ILP, instruction-level parallelism. But then processors have limited resources too, and question is if those resources are sufficient to sustain the algorithmic IPL. Or rather vice versa, if processor has more resources than ILP, then resources will run underutilized. And naturally only then it makes sense to interleave instructions. Processor resources can be characterized by IPC, instructions per cycle, limit, and maximum possible improvement would be IPC/ILP. But one should remember that IPC is not just amount of execution ports, for example 4 on Haswell. Some instructions are port-specific and if algorithm uses such instructions a lot, you'll be limited by that port. Anyway, MD5 is known for its low IPL and it does make sense to interleave it (with itself or other algorithm). This doesn't apply to SHA. It has higher ILP and no contemporary processor has capacity to fully utilize this parallelism. Actually it's a bit worse in practice, because thing about multi-block is that it's limited by shifts, which are port-specific. This is why you observe virtually no difference among "desktop/server" processors. As for 4 Haswell ports. Of the 4 only 3 can execute vector instructions. So that absolutely best results can be achieved when you mix scalar integer-only and vector instructions, e.g. in addition to MD5 on AVX, mix in even scalar "thread". Well, gain would have to be divided by ratio between how many blocks vector part processes vs. how many blocks scalar parts adds. So gain would be too little to care about. So it's more of a fun fact in the context. From rt at openssl.org Mon May 25 10:01:27 2015 From: rt at openssl.org (rt@openssl.org via RT) Date: Mon, 25 May 2015 12:01:27 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <5562F2EE.5020801@openssl.org> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <20150524070919.GE18510@openwall.com> <6565AFBC-FC27-4716-A790-3FDF4A6BFEC8@gmail.com> <5562F2EE.5020801@openssl.org> Message-ID: > Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64". > > From the original patch: > > (...) > "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", > +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", > (...) But what prevents you from 'env CC=icc ./Configure linux-generic64 -mmic'? Or same with linux-x86_64? Can you confirm if './Configure linux-x86_64-icc -mmic' works in 1.0.2? From rt at openssl.org Mon May 25 10:59:21 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 12:59:21 +0200 Subject: [openssl-dev] [openssl.org #3819] make openssl-1.0.2a failed on Solaris 10 i86pc In-Reply-To: <55630084.7060509@openssl.org> References: <55630084.7060509@openssl.org> Message-ID: Hi, > I am not able to build openssl-1.02.a on Solaris 10: > > # uname -a > SunOS corona 5.10 Generic_150401-23 i86pc i386 i86pc Solaris > > # ./Configure solaris-x86-gcc --openssldir=/usr/local/openssl-1.0.2a shared > ? > Configured for solaris-x86-gcc. > > # make > > gcc -I. -I.. -I../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS > -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -O3 -fomit-frame-pointer > -march=pentium -Wall -DL_ENDIAN -DOPENSSL_NO_INLINE_ASM > -DOPENSSL_BN_ASM_PART_WORDS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DRMD160_ASM -DAES_ASM -DVPAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -c -o > x86cpuid.o x86cpuid.s > Assembler: x86cpuid.s > "x86cpuid.s", line 158 : Illegal subtraction in ... > "OPENSSL_ia32cap_P - .L009PIC_me_up" > make[1]: *** [x86cpuid.o] Error 1 > make[1]: Leaving directory > `/export/home/borut/admin/openssl/openssl-1.0.2a/crypto' > make: *** [build_crypto] Error 1 > # > > > Any idea how to fix this? Well, we have to rely on working tool-chain, and specifically assembler, but fixing broken one is beyond our capacity. Actually beyond anybody's capacity on such old system as SunOS 5.10. Catch there is that it's likely that your gcc is compiled to use vendor assembler, so that advice to upgrade assembler is not helpful. Having said this configuring with no-asm should help to avoid assembler. But it costs a lot of performance, see if attached patch solves the problem... -------------- next part -------------- A non-text attachment was scrubbed... Name: solaris-x86-gcc.diff Type: text/x-patch Size: 1043 bytes Desc: not available URL: From rt at openssl.org Mon May 25 11:23:56 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 13:23:56 +0200 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: <55630640.5070504@openssl.org> References: <55630640.5070504@openssl.org> Message-ID: Hi, > I got a problem building openssl 1.0.2a on SUSE. > > Platform: >> uname -a > > Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 > x86_64 x86_64 x86_64 GNU/Linux > > > Compiler: > >> gcc -v > Using built-in specs. > Target: x86_64-suse-linux > Configured with: ../configure --prefix=/usr --infodir=/usr/share/info > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > --enable-languages=c,c++,objc,fortran,obj-c++,java,ada > --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 > --enable-ssp --disable-libssp --with-bugurl= > http://bugs.opensuse.org/ > --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap > --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit > --enable-libstdcxx-allocator=new --disable-libstdcxx-pch > --enable-version-specific-runtime-libs --program-suffix=-4.3 > --enable-linux-futex --without-system-libunwind --with-cpu=generic > --build=x86_64-suse-linux > Thread model: posix > gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) > > Error message: > > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC > -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D > OPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_AS > M -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > ghash-x86_64.s: Assembler messages: > ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq > $17,%xmm2,%xmm0,%xmm1' > ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq > $0,%xmm2,%xmm0,%xmm0' > ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm3,%xmm3' > ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq > $17,%xmm2,%xmm0,%xmm1' > ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq > $0,%xmm2,%xmm0,%xmm0' > ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm3,%xmm3' > ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > $0,%xmm6,%xmm14,%xmm0' What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on your system? From rt at openssl.org Mon May 25 11:38:18 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 13:38:18 +0200 Subject: [openssl-dev] [openssl.org #3811] [BUG REPORT] - Missing register name in aes-x86_64.s In-Reply-To: <5563099E.8070401@openssl.org> References: <2416E52E-9F03-488A-AC99-5B56B7BE03E0@macports.org> <5563099E.8070401@openssl.org> Message-ID: Hi, > The suggested fix for #3759: [PATCH] crypto: use bigint in x86-64 perl addresses some issues but not all issues with the generation of the asm from the perl scripts. Using the provided patch, one still fails with: > > /usr/bin/perl asm/aes-x86_64.pl macosx > aes-x86_64.s > /opt/local/bin/gcc-apple-4.2 -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -c -o aes-x86_64.o aes-x86_64.s > aes-x86_64.s:1383:missing or invalid immediate expression `' taken as 0 > aes-x86_64.s:1383:suffix or operands invalid for `mov' > aes-x86_64.s:1544:missing or invalid immediate expression `' taken as 0 > aes-x86_64.s:1544:suffix or operands invalid for `mov' I can't reproduce the problem. And expected values in lines in question are not big at all. What is common there is that there is division that obviously mistreated on your system. Can you try/confirm if enclosing it to backticks does the trick? I mean question is what happens if you replace occurrences of 240/8 with `240/8`? From rt at openssl.org Mon May 25 12:34:06 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 14:34:06 +0200 Subject: [openssl-dev] [openssl.org #3804] BUG: OpenSSL 1.0.2 Solaris 32 bit build is broken In-Reply-To: <556316B2.7070709@openssl.org> References: <556316B2.7070709@openssl.org> Message-ID: Hi, > I have an application that runs quite happily using OpenSSL 1.0.1h on Solaris 32 bit. I want to upgrade but neither 1.0.2 nor 1.0.2a work. > > Solaris 10 > Solaris Studio 12.4 > > Make test log attached. > > 1 When building 1.0.2 using > > ./Configure solaris-sparcv9-cc no-shared -m32 -xcode=pic32 -xldscope=hidden > > openssl s_client crashes on start: > > -bash-3.00$ ./openssl s_client -connect eos.es.cpth.ie:4250 > Segmentation Fault (core dumped) > -bash-3.00$ pstack core > core 'core' of 468: ./openssl s_client -connect eos.es.cpth.ie:4250 > 000e9ce8 sha1_block_data_order (2ed490, 2ed4ec, 4, ffbfebc0, ffbfebc4, 44) + 8 Well, combining no-shared and -xcode=pic32 results in ambiguity in the very beginning of this and few other subroutines. For code to be compiled as position-independent __PIC__ macro is required to be defined, but I don't think passing -xcode=pic32 cuts it. Question is what is your objective? I mean why is it such contradicting mixture of no-shared and pic options? If the goal is to build static library that can be later linked into another shared library, then I'd suggest no-shared -KPIC, which supposedly can be followed by -xcode=pic32 -xlscope=hidden. Keyword here is that -KPIC ought to pre-define __PIC__. If it doesn't, then complement it with -DOPENSSL_PIC, i.e. './Configure solaris-sparcv9-cc no-shared -KPIC -DOPENSSL_PIC ...' > 2 So I then rebuilt adding no-asm flag. It manages to connect but negotiation fails with an error: > > 4280581268:error:140943FC:SSL routines:ssl3_read_bytes:sslv3 alert bad record mac:s3_pkt.c:1456:SSL alert number 20 > 4280581268:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177: > > This is against the server that is still running 1.0.1h and can be successfully connected with openssl s_client built with 1.0.1h. > > The 64 bit build seems to work perfectly. The 32 bit builds that we use on Windows and Linux also work perfectly. > > 1.0.2a build fails in the same way. gcc build fails in the same way. So what you are saying is that everything works, but 32-bit SPARC 1.0.2 build and it doesn't matter if it's compiled with vendor compiler or gcc. H-m-m-m... Did you run 'make clean' in between? Thing is that normal reaction in such situation is to suspect compiler bug, but two compilers are highly unlikely to share bug. So try 'make clean' in between tries, or better yet, try builds in separate directories. If both still fail, play with -cipher option to identify faulty algorithm... From beldmit at gmail.com Mon May 25 13:52:25 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 25 May 2015 16:52:25 +0300 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: References: <55630640.5070504@openssl.org> Message-ID: Dear Andy, On Mon, May 25, 2015 at 2:23 PM, Andy Polyakov via RT wrote: > Hi, > > > I got a problem building openssl 1.0.2a on SUSE. > > > > Platform: > >> uname -a > > > > Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 > > x86_64 x86_64 x86_64 GNU/Linux > > > > > > Compiler: > > > >> gcc -v > > Using built-in specs. > > Target: x86_64-suse-linux > > Configured with: ../configure --prefix=/usr --infodir=/usr/share/info > > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > > --enable-languages=c,c++,objc,fortran,obj-c++,java,ada > > --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 > > --enable-ssp --disable-libssp --with-bugurl= > > http://bugs.opensuse.org/ > > --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap > > --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit > > --enable-libstdcxx-allocator=new --disable-libstdcxx-pch > > --enable-version-specific-runtime-libs --program-suffix=-4.3 > > --enable-linux-futex --without-system-libunwind --with-cpu=generic > > --build=x86_64-suse-linux > > Thread model: posix > > gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) > > > > Error message: > > > > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC > > -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > > -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D > > OPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_AS > > M -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > > ghash-x86_64.s: Assembler messages: > > ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq > > $17,%xmm2,%xmm0,%xmm1' > > ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq > > $0,%xmm2,%xmm0,%xmm0' > > ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm3,%xmm3' > > ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq > > $17,%xmm2,%xmm0,%xmm1' > > ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq > > $0,%xmm2,%xmm0,%xmm0' > > ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm3,%xmm3' > > ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm14,%xmm0' > > What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on > your system? > > > $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-14.el5 20061020 -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon May 25 13:52:52 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Mon, 25 May 2015 15:52:52 +0200 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: References: <55630640.5070504@openssl.org> Message-ID: Dear Andy, On Mon, May 25, 2015 at 2:23 PM, Andy Polyakov via RT wrote: > Hi, > > > I got a problem building openssl 1.0.2a on SUSE. > > > > Platform: > >> uname -a > > > > Linux b-sles11-64 2.6.27.19-5-default #1 SMP 2009-02-28 04:40:21 +0100 > > x86_64 x86_64 x86_64 GNU/Linux > > > > > > Compiler: > > > >> gcc -v > > Using built-in specs. > > Target: x86_64-suse-linux > > Configured with: ../configure --prefix=/usr --infodir=/usr/share/info > > --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 > > --enable-languages=c,c++,objc,fortran,obj-c++,java,ada > > --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 > > --enable-ssp --disable-libssp --with-bugurl= > > http://bugs.opensuse.org/ > > --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap > > --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit > > --enable-libstdcxx-allocator=new --disable-libstdcxx-pch > > --enable-version-specific-runtime-libs --program-suffix=-4.3 > > --enable-linux-futex --without-system-libunwind --with-cpu=generic > > --build=x86_64-suse-linux > > Thread model: posix > > gcc version 4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) > > > > Error message: > > > > gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC > > -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > > -DHAVE_DLFCN_H -g -m64 -DL_ENDIAN -O3 -Wall -D > > OPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 > > -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM > > -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_AS > > M -DGHASH_ASM -DECP_NISTZ256_ASM -c -o ghash-x86_64.o ghash-x86_64.s > > ghash-x86_64.s: Assembler messages: > > ghash-x86_64.s:1281: Error: no such instruction: `vpclmulqdq > > $17,%xmm2,%xmm0,%xmm1' > > ghash-x86_64.s:1282: Error: no such instruction: `vpclmulqdq > > $0,%xmm2,%xmm0,%xmm0' > > ghash-x86_64.s:1283: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm3,%xmm3' > > ghash-x86_64.s:1312: Error: no such instruction: `vpclmulqdq > > $17,%xmm2,%xmm0,%xmm1' > > ghash-x86_64.s:1313: Error: no such instruction: `vpclmulqdq > > $0,%xmm2,%xmm0,%xmm0' > > ghash-x86_64.s:1314: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm3,%xmm3' > > ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > > $0,%xmm6,%xmm14,%xmm0' > > What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on > your system? > > > $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using BFD version 2.17.50.0.6-14.el5 20061020 -- SY, Dmitry Belyavsky From rt at openssl.org Mon May 25 14:13:49 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 16:13:49 +0200 Subject: [openssl-dev] [openssl.org #3795] OS X is using LD_LIBRARY_PATH, and not DYLD_LIBRARY_PATH in Master In-Reply-To: <55632E12.9090702@openssl.org> References: <55632E12.9090702@openssl.org> Message-ID: Hi, > I'm working with Master on OS X. I tried to add a build configuration > of Clang and its sanitizers. I think I got the Darwin and OS X > specific stuff included in the CONF file (see below). > > During link, it appears LD_LIBRARY_PATH is used rather than > DYLD_LIBRARY_PATH. On OS X, DYLD_LIBRARY_PATH should be used. See > https://developer.apple.com/library/mac/documentation/Darwin/Reference/ManPages/man1/dyld.1.html. Formally you contradict yourself :-) Indeed, you first assert that LD_LIBRARY_PATH is *used* and then refer to page that says that it's *not* *used* :-) But jokes aside. Question is not actually which variable is set, but what effect does any specific one have. And answer in this case is none. Then next question is what is it that doesn't work. Yes, one can argue that setting variable that has no effect is not elegant, but it doesn't answer the question. But before you answer it, you should argue in favour of omitting MacOS X-specific lflags and shared_* flags (might be unused in this particular case), see darwin-common template. And what prevents you from specifying -fsanitize=this-n-that as additional argument to Configure darwin64-x64_64-cc? From rt at openssl.org Mon May 25 14:26:15 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 16:26:15 +0200 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: <556330FA.3020006@openssl.org> References: <55630640.5070504@openssl.org> <556330FA.3020006@openssl.org> Message-ID: >>> ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq >>> $0,%xmm6,%xmm14,%xmm0' >> >> What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on >> your system? >> >> >> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null > GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using > BFD version 2.17.50.0.6-14.el5 20061020 Meaning that check for minimum of 2.19 around line 93 in modes/asm/ghash-x86_64.pl has miserably failed. I can't reproduce the problem by placing fake as on my PATH... It appears that you are on your own here. Is it possible that .s file was generated on another system in previous attempt to build? Can you confirm that problem actually persists with fresh download? From rt at openssl.org Mon May 25 14:42:38 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 16:42:38 +0200 Subject: [openssl-dev] [openssl.org #3794] Missing symbols for padlock_aes_block during link in Master In-Reply-To: <556334D2.8090404@openssl.org> References: <556334D2.8090404@openssl.org> Message-ID: > I'm trying to run OpenSSL Master through Clang's sanitizers. Below is > from 99-clang-sanitizer.conf (this is my fumbling). > > $ make > making all in crypto... > Undefined symbols for architecture x86_64: > "_padlock_aes_block", referenced from: > _padlock_ofb_cipher in libcrypto.a(e_padlock.o) > _padlock_cfb_cipher in libcrypto.a(e_padlock.o) It appears that explicit no-asm is required to disable padlock. I mean can you confirm that configuring with explicit no-asm, even though you don't have asm modules in *your* config, does the trick? From rt at openssl.org Mon May 25 15:26:30 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 17:26:30 +0200 Subject: [openssl-dev] [openssl.org #3792] OpenSSL debug build lacks -Og In-Reply-To: <55633F1A.3000306@openssl.org> References: <55633F1A.3000306@openssl.org> Message-ID: > This is for OpenSSL 1.0.2. > > -Og was added to GCC to allow one to use optimizations that don't > disturb a debug session. As I understand it, it acts like like -O1 (to > perform some basic analysis) without losing symbol information (i.e., > "optimized out" under the debugger). See > https://gcc.gnu.org/onlinedocs/gcc-4.9.2/gcc/Optimize-Options.html#Optimize-Options. > > -g3 includes the maximum debug information, including symbolic defines. > > The debug build configuration setting for GCC uses -O0 and it lacks -g3: > > "gcc" => { > cc => "gcc", > cflags => "", > debug_cflags => "-O0 -g", > release_cflags => "-O3", > thread_cflag => "(unknown)", > bn_ops => "BN_LLONG", > }, > > For debug builds, perhaps it would be a good idea to use -g3, and -Og > when available from GCC. You have to accept that availability of any particular option doesn't qualify for its immediate inclusion to config. Configs are rather least common denominators for everybody than whatever you can find on your command prompt today. It's more appropriate to argue in favour of having option to override defaults with additional flags at config phase, e.g. ./config -Og. Currently config lines take precedence, but it can be changed if it's argued for. For reference, I myself is for prioritizing user-supplied options. From rt at openssl.org Mon May 25 15:40:07 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 17:40:07 +0200 Subject: [openssl-dev] [openssl.org #3791] Problems configuring for OSX 10.8.5 (x86_64) In-Reply-To: <5563424E.4010308@openssl.org> References: <5563424E.4010308@openssl.org> Message-ID: > This issue has kind of been with the project for so long its just kind > of accepted.... > > But its 2015 and all Apple hardware is x86_64. Its been that way for > quite a few years. Also, there's really no reason to (1) default to > darwin-i386 and (2) not recognize darwin-x86_64. > > I suggest that darwin-x86_64 become the default, and configure to > recognize darwin-x86_64. > > ********** > > $ ./config darwin-x86_64 Since when did it work to pass something like that to ./config? You must mean ./Configure , no? Then x86_64 Darwin is supported, but as darwin64-x86_64-cc. Or do you mean that you find "64" in "darwin64" objectionable? Then you probably should say that, not suggest examples that never worked... But defaulting to 64-bit is rather sensible. I note that 'uname -p' seems to return x86_64 now, unlike earlier i386. Yes, even on 64-bit systems, which can also be detected by examining sysctl -n hw.optional.x86_64. Do you have idea when it changed? In your opinion is it sensible to use it to determine default? From rt at openssl.org Mon May 25 15:45:46 2015 From: rt at openssl.org (Lei Zhang via RT) Date: Mon, 25 May 2015 17:45:46 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <20150524070919.GE18510@openwall.com> <6565AFBC-FC27-4716-A790-3FDF4A6BFEC8@gmail.com> <5562F2EE.5020801@openssl.org> <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> Message-ID: > On May 25, 2015, at 6:01 PM, Andy Polyakov wrote: > >> Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64". >> >> From the original patch: >> >> (...) >> "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >> +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >> (...) > > But what prevents you from 'env CC=icc ./Configure linux-generic64 > -mmic'? Or same with linux-x86_64? Can you confirm if './Configure > linux-x86_64-icc -mmic' works in 1.0.2? 'CC="icc -mmic" ./Configure shared linux-generic64' works in 1.0.0. It's better than modifying Configure. I just didn't think of it. But it doesn't work in 1.0.2, getting some link error: ../libcrypto.so: undefined reference to `rc4_md5_enc' And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. Lei From rt at openssl.org Mon May 25 15:53:23 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 17:53:23 +0200 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: <5563456F.2000007@openssl.org> References: <1427720548359.36445@caviumnetworks.com> <5563456F.2000007@openssl.org> Message-ID: Hi, > This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. Well, objective is not to collect as many exotic config lines as possible, but rather more generic ones that we are ready to support and make them flexible enough to be reusable in more specific contexts. For example in this case what prevents you from using ./Configure linux-generic32 --cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32 and ./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu- Or better yet ./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- and ./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- and take advantage of assembly support? From rt at openssl.org Mon May 25 16:02:00 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Mon, 25 May 2015 18:02:00 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <5563476F.2000102@openssl.org> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <6565AFBC-FC27-4716-A790-3FDF4A6BFEC8@gmail.com> <5562F2EE.5020801@openssl.org> <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> <5563476F.2000102@openssl.org> Message-ID: >>> Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64". >>> >>> From the original patch: >>> >>> (...) >>> "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >>> +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >>> (...) >> >> But what prevents you from 'env CC=icc ./Configure linux-generic64 >> -mmic'? Or same with linux-x86_64? Can you confirm if './Configure >> linux-x86_64-icc -mmic' works in 1.0.2? > > 'CC="icc -mmic" ./Configure shared linux-generic64' works in 1.0.0. It's better than modifying Configure. I just didn't think of it. > > But it doesn't work in 1.0.2, getting some link error: > ../libcrypto.so: undefined reference to `rc4_md5_enc' Yes, similar issue was reported in another context and it will be resolved. Meanwhile could you pass explicit no-asm to confirm that it's in *general* viable option for you. > And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. But all x86_64 modules feature run-time switch, when processor capabilities are detected [with cpuid] and code that can't be executed on any particular processor won't execute. Or do you mean that fails to *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? But I recall that there is cpuid... From beldmit at gmail.com Mon May 25 19:40:32 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Mon, 25 May 2015 22:40:32 +0300 Subject: [openssl-dev] GOST89 cipher control command Message-ID: Hello Openssl team, GOST89 cipher algorithm seems to be the only cipher algorithm supporting more than one sets of S-boxes. Current implementation of the GOST89 cipher provided by the ccgost engine does not allow to specify usage of particular S-boxes for a particular EVP_CIPHER_CTX instance. If I understand correctly, the only way to do it is to specify a ctrl-command and implement it in the engine. Is it OK to reuse EVP_CTRL_INIT ctrl command for this purpose or it will be better to add a special value for this? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Mon May 25 20:02:00 2015 From: rt at openssl.org (Hanno Boeck via RT) Date: Mon, 25 May 2015 22:02:00 +0200 Subject: [openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req In-Reply-To: <20150525151824.7ff7fc8f@pc1> References: <20150525151824.7ff7fc8f@pc1> Message-ID: The code in apps/req.c will use the variable out for both the key and the csr outfile. This causes a memory leak because if both a private key and a csr is written the variable is re-used without freeing it. See attached patch. (This could also be fixed by using a different var for both files, could be considered more consistent, but I decided to use a less invasive patch that just needs to add a single line.) Please apply patch. -- Hanno B?ck http://hboeck.de/ mail/jabber: hanno at hboeck.de GPG: BBB51E42 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-leakfixes-req.diff Type: text/x-patch Size: 249 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From rt at openssl.org Mon May 25 20:02:21 2015 From: rt at openssl.org (Dr. Martin P.J. Zinser via RT) Date: Mon, 25 May 2015 22:02:21 +0200 Subject: [openssl-dev] [openssl.org #3862] Patch: Compiler messages on OpenVMS In-Reply-To: <2080123.kl6UnqMCD0@voyager> References: <2080123.kl6UnqMCD0@voyager> Message-ID: Hello, I've just build OpenSSL 1.0.2a on OpenVMS 8.3 (Alpha) HP C V 7.3 The build (and test) went very smooth, with just three minor complaints by the compiler: Compiling The BIO Library Files. (LIBRARY,LIB) bio_lib.c bio_cb.c ... bss_dgram.c if (timeleft.tv_sec < 0) { ............^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "timeleft.tv_sec" is being compared with a relational operator to a constant whose v alue is not greater than zero. This might not be what you intended. at line number 313 in file PUBLIC$ROOT: [UTIL.LIBS.OPENSSL102.CRYPTO.BIO]BSS_DGRAM.C;1 ... Building The SYS$DISK:[-.ALPHA.EXE.SSL]SSL_LIBSSL32.OLB Library. s2_meth.c s2_srvr.c ... t1_lib.c if (size <= 0 || ((len = data[0])) != (size - 1)) { ................^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "size" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 2085 in file PUBLIC$ROOT:[UTIL.LIBS.OPENSSL102.SSL]T1_LIB.C;1 ... Compiling The ccgost Library Files. (ENGINES) e_gost_err gost2001_keyx gost2001 gost89 gost94_keyx if (*outlen <= 0) { ........^ %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "*outlen" is being compared with a relational operator to a constant whose value is not greater than zero. This might not be what you intended. at line number 178 in file PUBLIC$ROOT: [UTIL.LIBS.OPENSSL102.ENGINES.CCGOST]GOST94_KEYX.C;1 As can be easily seen, all three complaints are of the same type. They also can be easily cured by explicitly casting the the questionable parameters to (signed) int. The diff below shows the modifications. As a crosscheck I've applied them on Linux system (openSUSE 13.2, Kernel 3.16.7, GCC 4.8.3, GLIBC 2.19), which compiled and passed all tests succesfully (same as before the patch). I'd be obliged if you'd consider this change for inclusion in a future version of OpenSSL. Greetings, Martin diff -c crypto/bio/bss_dgram.c crypto/bio/bss_dgram.c.orig *** crypto/bio/bss_dgram.c 2015-05-25 17:00:19.000000000 +0200 --- crypto/bio/bss_dgram.c.orig 2015-05-25 18:19:45.203792595 +0200 *************** *** 310,316 **** timeleft.tv_usec += 1000000; } ! if ((int)timeleft.tv_sec < 0) { timeleft.tv_sec = 0; timeleft.tv_usec = 1; } --- 310,316 ---- timeleft.tv_usec += 1000000; } ! if (timeleft.tv_sec < 0) { timeleft.tv_sec = 0; timeleft.tv_usec = 1; } diff -c ssl/t1_lib.c ssl/t1_lib.c.orig *** ssl/t1_lib.c 2015-05-25 17:29:57.000000000 +0200 --- ssl/t1_lib.c.orig 2015-05-25 18:43:23.249543083 +0200 *************** *** 2082,2088 **** } # ifndef OPENSSL_NO_SRP else if (type == TLSEXT_TYPE_srp) { ! if ((int)size <= 0 || ((len = data[0])) != (size - 1)) { *al = SSL_AD_DECODE_ERROR; return 0; } --- 2082,2088 ---- } # ifndef OPENSSL_NO_SRP else if (type == TLSEXT_TYPE_srp) { ! if (size <= 0 || ((len = data[0])) != (size - 1)) { *al = SSL_AD_DECODE_ERROR; return 0; } diff -c engines/ccgost/gost94_keyx.c engines/ccgost/gost94_keyx.c.orig *** engines/ccgost/gost94_keyx.c 2015-05-25 17:30:59.000000000 +0200 --- engines/ccgost/gost94_keyx.c.orig 2015-05-25 18:45:02.725271382 +0200 *************** *** 175,181 **** ASN1_OBJECT_free(gkt->key_agreement_info->cipher); gkt->key_agreement_info->cipher = OBJ_nid2obj(param->nid); *outlen = i2d_GOST_KEY_TRANSPORT(gkt, out ? &out : NULL); ! if ((int)(*outlen) <= 0) { GOSTerr(GOST_F_PKEY_GOST94CP_ENCRYPT, GOST_R_ERROR_PACKING_KEY_TRANSPORT_INFO); goto err; --- 175,181 ---- ASN1_OBJECT_free(gkt->key_agreement_info->cipher); gkt->key_agreement_info->cipher = OBJ_nid2obj(param->nid); *outlen = i2d_GOST_KEY_TRANSPORT(gkt, out ? &out : NULL); ! if (*outlen <= 0) { GOSTerr(GOST_F_PKEY_GOST94CP_ENCRYPT, GOST_R_ERROR_PACKING_KEY_TRANSPORT_INFO); goto err; From sms at antinode.info Mon May 25 20:44:43 2015 From: sms at antinode.info (Steven M. Schweda) Date: Mon, 25 May 2015 15:44:43 -0500 (CDT) Subject: [openssl-dev] [openssl.org #3862] Patch: Compiler messages on OpenVMS Message-ID: <15052515444351_20200496@antinode.info> From: "Dr. Martin P.J. Zinser via RT" > The build (and test) went very smooth, Nice to hear. I haven't tried anything lately. > with just three minor complaints by the > compiler: > [...] > bss_dgram.c > [...] > t1_lib.c > [...] > gost94_keyx > [...] > As can be easily seen, all three complaints are of the same type. They also > can be easily cured by explicitly casting the the questionable parameters to > (signed) int. > [...] I've been ignoring those three informational ("-I-") messages for a long time. The (my) worry about such type-casting was that it might generate worse complaints on a system where casting a 64-bit size_t or time_t to int would be seen as losing data. If the cure is not really worse than the disease, then such type casting would be fine with me, but if it goes bad in 2038 (when a signed 32-bit time goes negative), then I'm for continuing to (try to) ignore them. For sufficiently modern C compilers (which not everyone has), one could add: /WARNINGS = DISABLE = QUESTCOMPARE to the CC commands to suppress them, but I 've grown to think of these three complaints as old friends, and would almost hate to see them go, especially if disabling them would blind us to similar new ones which might be more significant. One could define a system-specific macro to do the type-casting (or not), but it's not clear that the improvement would justify the added clutter. My brain's empty now. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From rt at openssl.org Mon May 25 21:43:01 2015 From: rt at openssl.org (sms@antinode.info via RT) Date: Mon, 25 May 2015 23:43:01 +0200 Subject: [openssl-dev] [openssl.org #3862] Patch: Compiler messages on OpenVMS In-Reply-To: <15052515444351_20200496@antinode.info> References: <15052515444351_20200496@antinode.info> Message-ID: From: "Dr. Martin P.J. Zinser via RT" > The build (and test) went very smooth, Nice to hear. I haven't tried anything lately. > with just three minor complaints by the > compiler: > [...] > bss_dgram.c > [...] > t1_lib.c > [...] > gost94_keyx > [...] > As can be easily seen, all three complaints are of the same type. They also > can be easily cured by explicitly casting the the questionable parameters to > (signed) int. > [...] I've been ignoring those three informational ("-I-") messages for a long time. The (my) worry about such type-casting was that it might generate worse complaints on a system where casting a 64-bit size_t or time_t to int would be seen as losing data. If the cure is not really worse than the disease, then such type casting would be fine with me, but if it goes bad in 2038 (when a signed 32-bit time goes negative), then I'm for continuing to (try to) ignore them. For sufficiently modern C compilers (which not everyone has), one could add: /WARNINGS = DISABLE = QUESTCOMPARE to the CC commands to suppress them, but I 've grown to think of these three complaints as old friends, and would almost hate to see them go, especially if disabling them would blind us to similar new ones which might be more significant. One could define a system-specific macro to do the type-casting (or not), but it's not clear that the improvement would justify the added clutter. My brain's empty now. ------------------------------------------------------------------------ Steven M. Schweda sms at antinode-info 382 South Warwick Street (+1) 651-699-9818 Saint Paul MN 55105-2547 From rt at openssl.org Mon May 25 23:15:40 2015 From: rt at openssl.org (Rich Salz via RT) Date: Tue, 26 May 2015 01:15:40 +0200 Subject: [openssl-dev] [openssl.org #3861] [patch] Fix memory leak in req In-Reply-To: <20150525151824.7ff7fc8f@pc1> References: <20150525151824.7ff7fc8f@pc1> Message-ID: commit cf89a80e25b79ae0e6004e4a2509bf656fb59168 Author: Hanno Bck Date: Mon May 25 16:18:07 2015 -0400 RT3861: Mem/bio leak in req command The "out" variable is used for both key and csr. Close it after writing the first one so it can be re-used when writing the other. Signed-off-by: Rich Salz Reviewed-by: Tim Hudson From rt at openssl.org Tue May 26 01:14:47 2015 From: rt at openssl.org (Lei Zhang via RT) Date: Tue, 26 May 2015 03:14:47 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <5562F2EE.5020801@openssl.org> <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> <5563476F.2000102@openssl.org> <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> Message-ID: > On May 26, 2015, at 12:01 AM, Andy Polyakov wrote: > >>>> Yes, I added a new target "linux-mic" into Configure, which is slightly modified from "linux-generic64". >>>> >>>> From the original patch: >>>> >>>> (...) >>>> "linux-generic64","gcc:-DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >>>> +"linux-mic","icc:-mmic -DTERMIO -O3 -Wall::-D_REENTRANT::-ldl:SIXTY_FOUR_BIT_LONG RC4_CHAR RC4_CHUNK DES_INT DES_UNROLL BF_PTR:${no_asm}:dlfcn:linux-shared:-fPIC::.so.\$(SHLIB_MAJOR).\$(SHLIB_MINOR)", >>>> (...) >>> >>> But what prevents you from 'env CC=icc ./Configure linux-generic64 >>> -mmic'? Or same with linux-x86_64? Can you confirm if './Configure >>> linux-x86_64-icc -mmic' works in 1.0.2? >> >> 'CC="icc -mmic" ./Configure shared linux-generic64' works in 1.0.0. It's better than modifying Configure. I just didn't think of it. >> >> But it doesn't work in 1.0.2, getting some link error: >> ../libcrypto.so: undefined reference to `rc4_md5_enc' > > Yes, similar issue was reported in another context and it will be > resolved. Meanwhile could you pass explicit no-asm to confirm that it's > in *general* viable option for you. > >> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. > > But all x86_64 modules feature run-time switch, when processor > capabilities are detected [with cpuid] and code that can't be executed > on any particular processor won't execute. Or do you mean that fails to > *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? > But I recall that there is cpuid... It fails to compile with -mmic: x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' (...) Here 'pxor' is a MMX instruction, but MIC doesn't support MMX. MIC has its own 512-bit SIMD instruction set, which is not backward-compatible like AVX512. Lei From rt at openssl.org Tue May 26 08:57:39 2015 From: rt at openssl.org (rt@openssl.org via RT) Date: Tue, 26 May 2015 10:57:39 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <5564357A.3020600@openssl.org> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> <5563476F.2000102@openssl.org> <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> <5564357A.3020600@openssl.org> Message-ID: >>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. >> >> But all x86_64 modules feature run-time switch, when processor >> capabilities are detected [with cpuid] and code that can't be executed >> on any particular processor won't execute. Or do you mean that fails to >> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? >> But I recall that there is cpuid... > > It fails to compile with -mmic: > x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' I see, thanks. In other words, as it turns out my suggestion about run-time switch does not apply in this case, because minimum of SSE2 is actually *assumed* for x86_64 platform. And this doesn't hold true for Knights Corner. But it does hold true for Knights Landing, doesn't it? I see no point in attempting to accommodate assembler support for Knights Corner (too rare processor) and would appreciate if you could confirm if following works with 1.0.2: ./Configure linux-x86_64-icc no-asm -mmic BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are open for security fixes only. From rt at openssl.org Tue May 26 09:57:35 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Tue, 26 May 2015 11:57:35 +0200 Subject: [openssl-dev] [openssl.org #3862] Patch: Compiler messages on OpenVMS In-Reply-To: <2080123.kl6UnqMCD0@voyager> References: <2080123.kl6UnqMCD0@voyager> Message-ID: On Mon May 25 22:02:21 2015, zinser at zinser.no-ip.info wrote: > Hello, > > I've just build OpenSSL 1.0.2a on > > OpenVMS 8.3 (Alpha) > HP C V 7.3 > > The build (and test) went very smooth, with just three minor > complaints by the > compiler: > > Compiling The BIO Library Files. (LIBRARY,LIB) > bio_lib.c > bio_cb.c > ... > bss_dgram.c > > if (timeleft.tv_sec < 0) { > ............^ > %CC-I-QUESTCOMPARE, In this statement, the unsigned expression > "timeleft.tv_sec" is being compared with a relational operator to a > constant > whose v > alue is not greater than zero. This might not be what you intended. > at line number 313 in file PUBLIC$ROOT: > [UTIL.LIBS.OPENSSL102.CRYPTO.BIO]BSS_DGRAM.C;1 > > ... > Building The SYS$DISK:[-.ALPHA.EXE.SSL]SSL_LIBSSL32.OLB Library. > s2_meth.c > s2_srvr.c > ... > t1_lib.c > > if (size <= 0 || ((len = data[0])) != (size - 1)) { > ................^ > %CC-I-QUESTCOMPARE, In this statement, the unsigned expression "size" > is being > compared with a relational operator to a constant whose value is not > greater than zero. This might not be what you intended. > at line number 2085 in file > PUBLIC$ROOT:[UTIL.LIBS.OPENSSL102.SSL]T1_LIB.C;1 > > ... > Compiling The ccgost Library Files. (ENGINES) > e_gost_err > gost2001_keyx > gost2001 > gost89 > gost94_keyx > > if (*outlen <= 0) { > ........^ > %CC-I-QUESTCOMPARE, In this statement, the unsigned expression > "*outlen" is > being compared with a relational operator to a constant whose value is > not greater than zero. This might not be what you intended. > at line number 178 in file PUBLIC$ROOT: > [UTIL.LIBS.OPENSSL102.ENGINES.CCGOST]GOST94_KEYX.C;1 > > > As can be easily seen, all three complaints are of the same type. They > also > can be easily cured by explicitly casting the the questionable > parameters to > (signed) int. Casting will make the warnings go away but doesn't solve the underlying issues - it just hides them. Taking each of the three warnings in turn: 1) It seems the tv_sec element of struct timeval is unsigned on VMS whilst on most other platforms it is signed. The logic used to calculate timeouts takes one time away from the other and then tests to see if the result is negative. This is likely to cause problems on VMS. I think the correct solution here is to rewrite the timeout logic to not rely on negative values (which is a straight forward change). 2) In the second issue the size of the SRP extension is checked to see if it is <= 0. This value is extracted from the incoming packet and can never be negative and indeed is held in an unsigned variable. Testing for < 0 is nonsensical. Therefore the correct change here is just to check |size == 0|. 3) The GOST engine issue is in the handling of the return value from an "i2d" function. These functions can return a negative value on error. However the GOST engine is storing the result in an *unsigned* variable and *then* testing if it is negative. This is obviously going to cause problems if that function ever fails. I think the correct solution here is to store the result in a temporary signed int first and then handle any error conditions. I have pushed fixes for all of the above. Thanks for your report, Matt From rt at openssl.org Tue May 26 14:35:25 2015 From: rt at openssl.org (Lei Zhang via RT) Date: Tue, 26 May 2015 16:35:25 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <158F5C50-F4A6-4785-9D3D-E797FABF4860@gmail.com> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <5563476F.2000102@openssl.org> <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> <5564357A.3020600@openssl.org> <158F5C50-F4A6-4785-9D3D-E797FABF4860@gmail.com> Message-ID: > On May 26, 2015, at 4:57 PM, Andy Polyakov wrote: > >>>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. >>> >>> But all x86_64 modules feature run-time switch, when processor >>> capabilities are detected [with cpuid] and code that can't be executed >>> on any particular processor won't execute. Or do you mean that fails to >>> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? >>> But I recall that there is cpuid... >> >> It fails to compile with -mmic: >> x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' > > I see, thanks. In other words, as it turns out my suggestion about > run-time switch does not apply in this case, because minimum of SSE2 is > actually *assumed* for x86_64 platform. And this doesn't hold true for > Knights Corner. But it does hold true for Knights Landing, doesn't it? Yes, Knights Landing supposedly implements AVX512, which is backward compatible with older SIMD instructions. > I see no point in attempting to accommodate assembler support for Knights > Corner (too rare processor) and would appreciate if you could confirm if > following works with 1.0.2: > > ./Configure linux-x86_64-icc no-asm -mmic Yes, it works. Solar, should I update JtR's READ-MIC to switch back to using OpenSSL? BTW, I'm not sure if switching between OpenSSL and LibreSSL would cause performance variation. Lei From rt at openssl.org Tue May 26 15:51:30 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 17:51:30 +0200 Subject: [openssl-dev] [openssl.org #3722] Patch to add -preserve_dates option to x509 app In-Reply-To: <53F31728-58F2-479B-BD9C-0C945C4DA69A@akamai.com> References: <6E812714-8E5A-48FD-9506-E258A3EB28B0@akamai.com> <53F31728-58F2-479B-BD9C-0C945C4DA69A@akamai.com> Message-ID: Hello All, We have an updated patch for this. Github link: https://github.com/akamai/openssl/commit/e3909f5dc3ce841515cbe925a0d5138664a0c41c -------------- next part -------------- A non-text attachment was scrubbed... Name: 0006-Add-preserve-dates-to-x509-app.patch Type: application/octet-stream Size: 6313 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue May 26 15:42:14 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 17:42:14 +0200 Subject: [openssl-dev] [openssl.org #3729] Patch to add support for iovec-based IO in OpenSSL In-Reply-To: <068B2EAF-7258-401C-8B66-1F04611352BD@akamai.com> References: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> <068B2EAF-7258-401C-8B66-1F04611352BD@akamai.com> Message-ID: Hello again: We have an updated patch for this. Github link: https://github.com/akamai/openssl/commit/17431369cce8e4cd01f6f236fb2d6a75c8c79aef -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Add-iovec-based-I-O-routines.patch Type: application/octet-stream Size: 42784 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue May 26 15:46:20 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 17:46:20 +0200 Subject: [openssl-dev] [openssl.org #3724] Patch/Feature to add asynchronous processing for some operations In-Reply-To: References: <81070344-6715-47E7-9BE6-F007FE307535@akamai.com> Message-ID: Hello All: We have an updated patch for this. Github link: https://github.com/akamai/openssl/commit/33081aea3b86852c676e3715745aa7c295a34150 -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-asynchronous-event-processing.patch Type: application/octet-stream Size: 72723 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Tue May 26 15:41:45 2015 From: tshort at akamai.com (Short, Todd) Date: Tue, 26 May 2015 15:41:45 +0000 Subject: [openssl-dev] [openssl.org #3729] Patch to add support for iovec-based IO in OpenSSL In-Reply-To: References: <82A0649D-764B-4716-945C-04A50AA4CB67@akamai.com> Message-ID: <068B2EAF-7258-401C-8B66-1F04611352BD@akamai.com> Hello again: We have an updated patch for this. Github link: https://github.com/akamai/openssl/commit/17431369cce8e4cd01f6f236fb2d6a75c8c79aef -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0009-Add-iovec-based-I-O-routines.patch Type: application/octet-stream Size: 42784 bytes Desc: 0009-Add-iovec-based-I-O-routines.patch URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue May 26 18:06:16 2015 From: rt at openssl.org (Billy Brumley via RT) Date: Tue, 26 May 2015 20:06:16 +0200 Subject: [openssl-dev] [openssl.org #3863] [PATCH] ECC: Add missing NULL check. Set a flag. In-Reply-To: References: Message-ID: Set point->Z_is_one flag after setting point->Z to one. Also check BIGNUM for NULL before passing it to get_affine_coordinates. BBB -------------- next part -------------- A non-text attachment was scrubbed... Name: ecc.patch Type: text/x-patch Size: 1096 bytes Desc: not available URL: From rt at openssl.org Tue May 26 18:06:21 2015 From: rt at openssl.org (Hidalgo Eguiagaray, Rafael via RT) Date: Tue, 26 May 2015 20:06:21 +0200 Subject: [openssl-dev] [openssl.org #3864] OS390 Bug: Make fails In-Reply-To: References: Message-ID: Make Output (tail ): >>> Makefile: line 206: Defined macro CLEARENV=TOP= && unset TOP $${LIB+LIB} $${LIBS+LIBS} $${INCLUDE+INCLUDE} $${INCLUDES+INCLUDES} $${DIR+DIR} $${DIRS+DIRS} $${SRC+SRC} $${LIBSRC+LIBSRC} $${LIBOBJ+LIBOBJ} $${ALL+ALL} $${EXHEADER+EXHEADER} $${HEADER+HEADER} $${GENERAL+GENERAL} $${CFLAGS+CFLAGS} $${ASFLAGS+ASFLAGS} $${AFLAGS+AFLAGS} $${LDCMD+LDCMD} $${LDFLAGS+LDFLAGS} $${SCRIPTS+SCRIPTS} $${SHAREDCMD+SHAREDCMD} $${SHAREDFLAGS+SHAREDFLAGS} $${SHARED_LIB+SHARED_LIB} $${LIBEXTRAS+LIBEXTRAS} >>> Makefile: line 242: Defined macro BUILDENV=PLATFORM='$(PLATFORM)' PROCESSOR='$(PROCESSOR)' CC='$(CC)' CFLAG='$(CFLAG)' AS='$(CC)' ASFLAG='$(CFLAG) -c' AR='$(AR)' NM='$(NM)' RANLIB='$(RANLIB)' CROSS_COMPILE='$(CROSS_COMPILE)' PERL='$(PERL)' ENGDIRS='$(ENGDIRS)' SDIRS='$(SDIRS)' LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' INSTALL_PREFIX='$(INSTALL_PREFIX)' INSTALLTOP='$(INSTALLTOP)' OPENSSLDIR='$(OPENSSLDIR)' LIBDIR='$(LIBDIR)' MAKEDEPEND='$$$${TOP}/util/domd $$$${TOP} -MD $(MAKEDEPPROG)' DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)' MAKEDEPPROG='$(MAKEDEPPROG)' SHARED_LDFLAGS='$(SHARED_LDFLAGS)' KRB5_INCLUDES='$(KRB5_INCLUDES)' LIBKRB5='$(LIBKRB5)' ZLIB_INCLUDE='$(ZLIB_INCLUDE)' LIBZLIB='$(LIBZLIB)' EXE_EXT='$(EXE_EXT)' SHARED_LIBS='$(SHARED_LIBS)' SHLIB_EXT='$(SHLIB_EXT)' SHLIB_TARGET='$(SHLIB_TARGET)' PEX_LIBS='$(P EX_LIBS)' EX_LIBS='$(EX_LIBS)' CPUID_OBJ='$(CPUID_OBJ)' BN_ASM='$(BN_ASM)' EC_ASM='$(EC_ASM)' DES_ENC='$(DES_ENC)' AES_ENC='$(AES_ENC)' CMLL_ENC='$(CMLL_ENC)' BF_ENC='$(BF_ENC)' CAST_ENC='$(CAST_ENC)' RC4_ENC='$(RC4_ENC)' RC5_ENC='$(RC5_ENC)' SHA1_ASM_OBJ='$(SHA1_ASM_OBJ)' MD5_ASM_OBJ='$(MD5_ASM_OBJ)' RMD160_ASM_OBJ='$(RMD160_ASM_OBJ)' WP_ASM_OBJ='$(WP_ASM_OBJ)' MODES_ASM_OBJ='$(MODES_ASM_OBJ)' ENGINES_ASM_OBJ='$(ENGINES_ASM_OBJ)' PERLASM_SCHEME='$(PERLASM_SCHEME)' FIPSLIBDIR='${FIPSLIBDIR}' FIPSDIR='${FIPSDIR}' FIPSCANLIB="$${FIPSCANLIB:-$(FIPSCANLIB)}" THIS=$${THIS:-$@} MAKEFILE=Makefile MAKEOVERRIDES= >>> Makefile: line 264: Defined macro BUILD_CMD=if [ -d "$$dir" ]; then ( cd $$dir && echo "making $$target in $$dir..." && $(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target ) || exit 1; fi >>> Makefile: line 266: Defined macro RECURSIVE_BUILD_CMD=for dir in $(DIRS); do $(BUILD_CMD); done >>> Makefile: line 267: Defined macro BUILD_ONE_CMD=if expr " $(DIRS) " : ".* $$dir " >/dev/null 2>&1; then $(BUILD_CMD); fi make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in target list make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in target list make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-O] in target list make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-DB_ENDIAN] in target list make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-DCHARSET_EBCDIC] in target list make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-DNO_SYS_PARAM_H] in target list >>> Defined macro INCDEPTH=0 make: Error -- FSUM8229 Incomplete rule recipe group detected Operating System : OS3090-Unix == zOS 1.13 Open SSL 1.02a, from openssl-1.0.2a.tar untared with : pax -rf openssl-1.0.2a.tar -ofrom=ISO8859-1,to=IBM-1047 ________________________________ Este correo electr?nico y, en su caso, cualquier fichero anexo al mismo, contiene informaci?n de car?cter confidencial exclusivamente dirigida a su destinatario o destinatarios. Si no es vd. el destinatario indicado, queda notificado que la lectura, utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida en virtud de la legislaci?n vigente. En el caso de haber recibido este correo electr?nico por error, se ruega notificar inmediatamente esta circunstancia mediante reenv?o a la direcci?n electr?nica del remitente. Evite imprimir este mensaje si no es estrictamente necesario. This email and any file attached to it (when applicable) contain(s) confidential information that is exclusively addressed to its recipient(s). If you are not the indicated recipient, you are informed that reading, using, disseminating and/or copying it without authorisation is forbidden in accordance with the legislation in effect. If you have received this email by mistake, please immediately notify the sender of the situation by resending it to their email address. Avoid printing this message if it is not absolutely necessary. From rt at openssl.org Tue May 26 18:56:10 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 20:56:10 +0200 Subject: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option In-Reply-To: References: Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add DISALLOW_RENEGOTIATION option Add support to disallow renegotiation in openssl The bit definition may need to change when pulled. Github link: https://github.com/akamai/openssl/commit/fcab621995d55d8873a02a96d5a8157f38469ebb And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0010-Add-DISALLOW_RENEGOTIATION-option.patch Type: application/octet-stream Size: 4182 bytes Desc: not available URL: -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Tue May 26 19:08:53 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 21:08:53 +0200 Subject: [openssl-dev] [openssl.org #3866] [PATCH] Support for vc10 build In-Reply-To: <9A890B1C-7D47-452A-8DAB-83D78D197CB5@akamai.com> References: <9A890B1C-7D47-452A-8DAB-83D78D197CB5@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Support for vc10 build Includes some changes for VC9 and VC7 compiles as well Github link: https://github.com/akamai/openssl/commit/dcd470b6ab92b8e2661872de298de78de1b5057b And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0011-Support-for-vc10-build.patch Type: application/octet-stream Size: 1632 bytes Desc: not available URL: From rt at openssl.org Tue May 26 19:08:58 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 21:08:58 +0200 Subject: [openssl-dev] [openssl.org #3867] [PATCH] Support Multiple CA certs in ocsp app In-Reply-To: <354E18FD-A686-405A-8F9E-A002BEB0B04D@akamai.com> References: <354E18FD-A686-405A-8F9E-A002BEB0B04D@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Support Multiple CA certs in ocsp app Add the ability to read multiple CA certs from a single file in the ocsp app. Github link: https://github.com/akamai/openssl/commit/7f5ed141fef8509b589b5a5601f0ec2bf5e08faf And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0012-Support-Multiple-CA-certs-in-ocsp-app.patch Type: application/octet-stream Size: 5021 bytes Desc: not available URL: -------------- next part -------------- From rt at openssl.org Tue May 26 19:09:03 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 21:09:03 +0200 Subject: [openssl-dev] [openssl.org #3868] [PATCH] Add SSL_get0_peer_certificate() In-Reply-To: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> References: <865493D4-E0A4-433C-99D4-7B73984DF58D@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add SSL_get0_peer_certificate() Add SSL_get0_peer_certificate() function which just returns the pointer to the certificate; SSL_get_peer_certificate() increments the references Github link: https://github.com/akamai/openssl/commit/83ec5c0d576f6d38ed84b914038e052b525d6828 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0013-Add-SSL_get0_peer_certificate.patch Type: application/octet-stream Size: 1751 bytes Desc: not available URL: From rt at openssl.org Tue May 26 20:29:51 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 22:29:51 +0200 Subject: [openssl-dev] [openssl.org #3869] [PATCH] Add shared session lists in SSL_CTX In-Reply-To: References: Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add shared session lists in SSL_CTX Support for shared session lists via SSL_CTX_share_session_cache(). Added locking during the sharing and cleanup. Github link: https://github.com/akamai/openssl/commit/fe1e4ac33a89e9176af0b645eafc2aaec5fc2266 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0014-Add-shared-session-lists-in-SSL_CTX.patch Type: application/octet-stream Size: 8242 bytes Desc: not available URL: From rt at openssl.org Tue May 26 20:29:53 2015 From: rt at openssl.org (Short, Todd via RT) Date: Tue, 26 May 2015 22:29:53 +0200 Subject: [openssl-dev] [openssl.org #3870] [PATCH] Async TLSEXT servername support. In-Reply-To: References: Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Async TLSEXT servername support. Adds support for processing the servername TLSEXT asynchronously, using the SSL_WANT_EVENT mechanism (RT 3724). Github link: https://github.com/akamai/openssl/commit/0205cc4eee7084e65a69995293ad584f7da21fa9 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." -------------- next part -------------- A non-text attachment was scrubbed... Name: 0015-Async-TLSEXT-servername-support.patch Type: application/octet-stream Size: 12049 bytes Desc: not available URL: From rt at openssl.org Tue May 26 20:42:17 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 26 May 2015 22:42:17 +0200 Subject: [openssl-dev] [openssl.org #3860] Some Sparc build configurations for gcc use deprecated -mv8 In-Reply-To: <5564DA9C.6020108@openssl.org> References: <5561716C.6070507@kippdata.de> <5564DA9C.6020108@openssl.org> Message-ID: Hi, > Some build configurations for gcc on Sparc use the outdated gcc switch -mv8. > > The switch was deprecated at least back for gcc 2.95.2 in October 1999 > ([1][2]). GCC 4 does no longer support the -mv8 switch but instead now > you have to use the switch that was already preferred for version > 2.95.2: -mcpu=v8 ([3]). > > Please replace all occurrences of "-mv8" in Configure (Release branches) > resp. Configurations/10-main.conf (master) with -mcpu=v8. > > Thanks, > > Rainer > > [1] https://gcc.gnu.org/onlinedocs/gcc-2.95.2/gcc_2.html#SEC19 > [2] http://www.gnu.org/software/gcc/releases.html > [3] https://gcc.gnu.org/gcc-4.0/changes.html Applied to master, 1.0.2 and 1.0.1. Thanks. From rt at openssl.org Tue May 26 20:44:40 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 26 May 2015 22:44:40 +0200 Subject: [openssl-dev] [openssl.org #3859] [PATCH] Define GCC_VERSION macro to cover upto gcc-5 In-Reply-To: <5564DB2F.5070001@openssl.org> References: <1432324049-12896-1-git-send-email-raj.khem@gmail.com> <5564DB2F.5070001@openssl.org> Message-ID: Hi, > Current check is limited to gcc 4 with minor versions > but when we use gcc 5.1, then minor version check fails > with current setup and we end up with build errors like > > | In file included from bn_div.c:62:0: > | bn_div.c: In function 'BN_div': > | bn_lcl.h:311:9: error: impossible constraint in 'asm' > | asm ("dmultu %2,%3" \ > | ^ > | bn_div.c:402:13: note: in expansion of macro 'BN_UMULT_LOHI' > | BN_UMULT_LOHI(t2l, t2h, d1, q); > | ^ > | : recipe for target 'bn_div.o' failed > | make[2]: *** [bn_div.o] Error 1 Addressed in http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=60c268b21ac81cc6b1af5c5470282a613b96f6fd Thank you for report. From rt at openssl.org Tue May 26 20:46:31 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Tue, 26 May 2015 22:46:31 +0200 Subject: [openssl-dev] [openssl.org #3858] [PATCH] fix copy paste error in ec_GF2m function prototypes In-Reply-To: <5564DB9E.50608@openssl.org> References: <5564DB9E.50608@openssl.org> Message-ID: Hi, > Just removes some duplication in the header file. Patch attached. Applied, thanks for report. From raysatiro at yahoo.com Wed May 27 04:41:12 2015 From: raysatiro at yahoo.com (Ray Satiro) Date: Wed, 27 May 2015 00:41:12 -0400 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> Message-ID: <55654AE8.8050808@yahoo.com> On 3/16/2015 5:45 AM, Kai Engert via RT wrote: > Thank you very much for your work on this issue! > In my testing so far, it works as requested. > > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 > stable branch, and the test suite succeeeds. > > Will you consider to add this enhancement in a feature release on the > 1.0.2 branch? I second this. It looks like this is also discussed in bug #2634 where it was considered an enhancement and therefore will not be in 1.0.2. It seems more like a bug fix to me though. If OpenSSL can complete the chain it should. What would be the disadvantage of doing so? I work on the cURL project and I've encountered this problem twice in the last month. The first time was a reporter mentioned an issue connecting to Apache git-wip-us.apache.org. That looks to be the VeriSign issue discussed in #2634. The server at the time had sent the old intermediate "VeriSign Class 3 Public Primary Certification Authority - G5" signed by "Class 3 Public Primary Certification Authority" (VeriSign root legacy) which is no longer included in the Mozilla bundle. The bundle does include the newer "VeriSign Class 3 Public Primary Certification Authority - G5" (now a root) but OpenSSL didn't use it to complete the chain. It looks like the Apache team fixed the issue [1] by removing the old VeriSign intermediate. But by doing that clients with an older bundle can no longer connect. The second time just this evening, I'm investigating a reported latency issue (unrelated) with mediafire.com. Its server sends 6 intermediate certificates and one of the intermediates (actually 2 if you count the dupe) is a legacy intermediate that is now a root. "thawte Primary Root CA" sent by the server is signed by "Thawte Premium Server CA" (thawte root legacy) which is no longer included in the Mozilla bundle. The bundle does include the newer "thawte Primary Root CA" (now a root) and, same as above, OpenSSL didn't use it to complete the chain. Internet Explorer and Firefox handled both verifications correctly, as one would expect. I understand you may consider the behavior in OpenSSL < 1.1.0 to be correct but the end result here is that those clients with the newer bundles are going to fail verify unable to get issuer. There is a compatible issuer in the bundle. I don't know of any other examples but I can imagine as legacy certificates are removed the issue could persist. [1]: https://issues.apache.org/jira/browse/INFRA-9605 From rt at openssl.org Wed May 27 04:41:52 2015 From: rt at openssl.org (Ray Satiro via RT) Date: Wed, 27 May 2015 06:41:52 +0200 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <55654AE8.8050808@yahoo.com> References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> <55654AE8.8050808@yahoo.com> Message-ID: On 3/16/2015 5:45 AM, Kai Engert via RT wrote: > Thank you very much for your work on this issue! > In my testing so far, it works as requested. > > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 > stable branch, and the test suite succeeeds. > > Will you consider to add this enhancement in a feature release on the > 1.0.2 branch? I second this. It looks like this is also discussed in bug #2634 where it was considered an enhancement and therefore will not be in 1.0.2. It seems more like a bug fix to me though. If OpenSSL can complete the chain it should. What would be the disadvantage of doing so? I work on the cURL project and I've encountered this problem twice in the last month. The first time was a reporter mentioned an issue connecting to Apache git-wip-us.apache.org. That looks to be the VeriSign issue discussed in #2634. The server at the time had sent the old intermediate "VeriSign Class 3 Public Primary Certification Authority - G5" signed by "Class 3 Public Primary Certification Authority" (VeriSign root legacy) which is no longer included in the Mozilla bundle. The bundle does include the newer "VeriSign Class 3 Public Primary Certification Authority - G5" (now a root) but OpenSSL didn't use it to complete the chain. It looks like the Apache team fixed the issue [1] by removing the old VeriSign intermediate. But by doing that clients with an older bundle can no longer connect. The second time just this evening, I'm investigating a reported latency issue (unrelated) with mediafire.com. Its server sends 6 intermediate certificates and one of the intermediates (actually 2 if you count the dupe) is a legacy intermediate that is now a root. "thawte Primary Root CA" sent by the server is signed by "Thawte Premium Server CA" (thawte root legacy) which is no longer included in the Mozilla bundle. The bundle does include the newer "thawte Primary Root CA" (now a root) and, same as above, OpenSSL didn't use it to complete the chain. Internet Explorer and Firefox handled both verifications correctly, as one would expect. I understand you may consider the behavior in OpenSSL < 1.1.0 to be correct but the end result here is that those clients with the newer bundles are going to fail verify unable to get issuer. There is a compatible issuer in the bundle. I don't know of any other examples but I can imagine as legacy certificates are removed the issue could persist. [1]: https://issues.apache.org/jira/browse/INFRA-9605 From rt at openssl.org Wed May 27 08:21:47 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Wed, 27 May 2015 10:21:47 +0200 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> <55654AE8.8050808@yahoo.com> Message-ID: On Wed May 27 06:41:51 2015, raysatiro at yahoo.com wrote: > On 3/16/2015 5:45 AM, Kai Engert via RT wrote: > > Thank you very much for your work on this issue! > > In my testing so far, it works as requested. > > > > I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 > > stable branch, and the test suite succeeeds. > > > > Will you consider to add this enhancement in a feature release on the > > 1.0.2 branch? > > I second this. It looks like this is also discussed in bug #2634 where > it was considered an enhancement and therefore will not be in 1.0.2. It > seems more like a bug fix to me though. If OpenSSL can complete the > chain it should. What would be the disadvantage of doing so? This issue is now being treated as a bug fix and the fix was already applied to the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2 release). A backport for 1.0.1 also exists but has not yet hit the repo. Matt From beldmit at gmail.com Wed May 27 08:39:08 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 27 May 2015 11:39:08 +0300 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: References: <55630640.5070504@openssl.org> <556330FA.3020006@openssl.org> Message-ID: Dear Andy, On Mon, May 25, 2015 at 5:26 PM, Andy Polyakov via RT wrote: > >>> ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > >>> $0,%xmm6,%xmm14,%xmm0' > >> > >> What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on > >> your system? > >> > >> > >> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null > > GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using > > BFD version 2.17.50.0.6-14.el5 20061020 > > Meaning that check for minimum of 2.19 around line 93 in > modes/asm/ghash-x86_64.pl has miserably failed. I can't reproduce the > problem by placing fake as on my PATH... It appears that you are on your > own here. Is it possible that .s file was generated on another system in > previous attempt to build? Can you confirm that problem actually > persists with fresh download? > > > After upgrade to sles11 sp3the bug stopped to appear. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed May 27 08:39:40 2015 From: rt at openssl.org (Dmitry Belyavsky via RT) Date: Wed, 27 May 2015 10:39:40 +0200 Subject: [openssl-dev] [openssl.org #3813] Fwd: Error building openssl on SUSE In-Reply-To: References: <556330FA.3020006@openssl.org> Message-ID: Dear Andy, On Mon, May 25, 2015 at 5:26 PM, Andy Polyakov via RT wrote: > >>> ghash-x86_64.s:1383: Error: no such instruction: `vpclmulqdq > >>> $0,%xmm6,%xmm14,%xmm0' > >> > >> What does 'gcc -Wa,-v -c -o /dev/null -x assembler /dev/null' print on > >> your system? > >> > >> > >> $ gcc -Wa,-v -c -o /dev/null -x assembler /dev/null > > GNU assembler version 2.17.50.0.6-14.el5 (x86_64-redhat-linux) using > > BFD version 2.17.50.0.6-14.el5 20061020 > > Meaning that check for minimum of 2.19 around line 93 in > modes/asm/ghash-x86_64.pl has miserably failed. I can't reproduce the > problem by placing fake as on my PATH... It appears that you are on your > own here. Is it possible that .s file was generated on another system in > previous attempt to build? Can you confirm that problem actually > persists with fresh download? > > > After upgrade to sles11 sp3the bug stopped to appear. Thank you! -- SY, Dmitry Belyavsky From janjust at nikhef.nl Wed May 27 08:55:53 2015 From: janjust at nikhef.nl (Jan Just Keijser) Date: Wed, 27 May 2015 10:55:53 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <0E87F73F-2D63-44DE-87ED-3EC6D4541ADF@gmail.com> <5563476F.2000102@openssl.org> <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> <5564357A.3020600@openssl.org> Message-ID: <55658699.9090900@nikhef.nl> Hi, rt at openssl.org via RT wrote: >>>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. >>>> >>> But all x86_64 modules feature run-time switch, when processor >>> capabilities are detected [with cpuid] and code that can't be executed >>> on any particular processor won't execute. Or do you mean that fails to >>> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? >>> But I recall that there is cpuid... >>> >> It fails to compile with -mmic: >> x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' >> > > I see, thanks. In other words, as it turns out my suggestion about > run-time switch does not apply in this case, because minimum of SSE2 is > actually *assumed* for x86_64 platform. And this doesn't hold true for > Knights Corner. But it does hold true for Knights Landing, doesn't it? I > see no point in attempting to accommodate assembler support for Knights > Corner (too rare processor) and would appreciate if you could confirm if > following works with 1.0.2: > > ./Configure linux-x86_64-icc no-asm -mmic > > BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are > open for security fixes only. > > I can confirm that a clean build of openssl 1.0.2a using the above ./Configure line works for me. The resulting binary runs without issues. JJK From rt at openssl.org Wed May 27 09:32:13 2015 From: rt at openssl.org (Jan Just Keijser via RT) Date: Wed, 27 May 2015 11:32:13 +0200 Subject: [openssl-dev] [openssl.org #3843] OpenSSL 1.0.1* and below: incorrect use of _lrotl() In-Reply-To: <55658699.9090900@nikhef.nl> References: <20150508005825.GA18666@openwall.com> <555C6801.6000005@openssl.org> <5563476F.2000102@openssl.org> <226252F0-CBA3-4D51-ADE6-FA6A438D9882@gmail.com> <5564357A.3020600@openssl.org> <55658699.9090900@nikhef.nl> Message-ID: Hi, rt at openssl.org via RT wrote: >>>> And linux-x86_64 won't work here, since it uses some instructions not supported by MIC. >>>> >>> But all x86_64 modules feature run-time switch, when processor >>> capabilities are detected [with cpuid] and code that can't be executed >>> on any particular processor won't execute. Or do you mean that fails to >>> *compile* it with -mmic? Or do you mean that cpuid doesn't work on mic? >>> But I recall that there is cpuid... >>> >> It fails to compile with -mmic: >> x86_64cpuid.s:165: Error: `pxor' is not supported on `k1om' >> > > I see, thanks. In other words, as it turns out my suggestion about > run-time switch does not apply in this case, because minimum of SSE2 is > actually *assumed* for x86_64 platform. And this doesn't hold true for > Knights Corner. But it does hold true for Knights Landing, doesn't it? I > see no point in attempting to accommodate assembler support for Knights > Corner (too rare processor) and would appreciate if you could confirm if > following works with 1.0.2: > > ./Configure linux-x86_64-icc no-asm -mmic > > BTW, _lrotl fix is applied to 1.0.1, but not earlier versions, which are > open for security fixes only. > > I can confirm that a clean build of openssl 1.0.2a using the above ./Configure line works for me. The resulting binary runs without issues. JJK From rt at openssl.org Wed May 27 11:58:25 2015 From: rt at openssl.org (Peter Dettman via RT) Date: Wed, 27 May 2015 13:58:25 +0200 Subject: [openssl-dev] [openssl.org #3871] Patch for latest git master to fix crypto/ec build errors (OSX) In-Reply-To: <55656DAE.2000407@bouncycastle.org> References: <55656DAE.2000407@bouncycastle.org> Message-ID: Hi, Building latest master from github on OSX Yosemite (10.10.3) with: Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) configured using: ./Configure darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 I needed a few changes in crypto/ec to get things working; see attached patch. There's a couple of outright misspellings fixed, and changes to silence some warnings related to memset arguments (I'm not really sure if the code was wrong before). Regards, Pete Dettman -------------- next part -------------- diff --git a/crypto/ec/ecp_nistp224.c b/crypto/ec/ecp_nistp224.c index 0e40db4..febfcab 100644 --- a/crypto/ec/ecp_nistp224.c +++ b/crypto/ec/ecp_nistp224.c @@ -1070,7 +1070,7 @@ static void select_point(const u64 idx, unsigned int size, unsigned i, j; limb *outlimbs = &out[0][0]; - memset(out 0, sizeof(out)); + memset(out, 0, sizeof(*out) * 3); for (i = 0; i < size; i++) { const limb *inlimbs = &pre_comp[i][0][0]; u64 mask = i ^ idx; diff --git a/crypto/ec/ecp_nistp256.c b/crypto/ec/ecp_nistp256.c index b4cd24d..110984b 100644 --- a/crypto/ec/ecp_nistp256.c +++ b/crypto/ec/ecp_nistp256.c @@ -1625,7 +1625,7 @@ static void select_point(const u64 idx, unsigned int size, unsigned i, j; u64 *outlimbs = &out[0][0]; - memset(out, 0, sizeof(out)); + memset(out, 0, sizeof(*out) * 3); for (i = 0; i < size; i++) { const u64 *inlimbs = (u64 *)&pre_comp[i][0][0]; diff --git a/crypto/ec/ecp_nistp521.c b/crypto/ec/ecp_nistp521.c index 6e572f1..a5d7360 100644 --- a/crypto/ec/ecp_nistp521.c +++ b/crypto/ec/ecp_nistp521.c @@ -1471,7 +1471,7 @@ static void select_point(const limb idx, unsigned int size, unsigned i, j; limb *outlimbs = &out[0][0]; - memset(out, 0, sizeof(out)); + memset(out, 0, sizeof(*out) * 3); for (i = 0; i < size; i++) { const limb *inlimbs = &pre_comp[i][0][0]; @@ -1906,7 +1906,7 @@ int ec_GFp_nistp521_points_mul(const EC_GROUP *group, EC_POINT *r, pre_comp = OPENSSL_malloc(sizeof(*pre_comp) * num_points); if (mixed) tmp_felems = - OPENSSL_malloc(sizeof(*tmp_felemts) * (num_points * 17 + 1)); + OPENSSL_malloc(sizeof(*tmp_felems) * (num_points * 17 + 1)); if ((secrets == NULL) || (pre_comp == NULL) || (mixed && (tmp_felems == NULL))) { ECerr(EC_F_EC_GFP_NISTP521_POINTS_MUL, ERR_R_MALLOC_FAILURE); @@ -1918,7 +1918,7 @@ int ec_GFp_nistp521_points_mul(const EC_GROUP *group, EC_POINT *r, * i.e., they contribute nothing to the linear combination */ memset(secrets, 0, sizeof(*secrets) * num_points); - memset(pre_comp, 0, sizseof(*pre_comp) * num_points); + memset(pre_comp, 0, sizeof(*pre_comp) * num_points); for (i = 0; i < num_points; ++i) { if (i == num) /* From rt at openssl.org Wed May 27 11:58:48 2015 From: rt at openssl.org (Sergey Agievich via RT) Date: Wed, 27 May 2015 13:58:48 +0200 Subject: [openssl-dev] [openssl.org #3872] EVP_PKEY_asn1_set_item In-Reply-To: References: Message-ID: Hello, Please find file attached: EVP_PKEY_asn1_set_item.patch. This is a patch to allow setting item_verify and item_sign handlers in the internal structure evp_pkey_asn1_method_st (see crypto/asn1/asn1_locl.h). These handlers are called when a signature is encountered requiring special handling. For example, item_verify and item_sign are used in the implementation of RSA-PSS (see crypto/rsa/rsa_ameth.c) to deal with X509_ALGOR mirror-ASN.1 type. Currently OpenSSL doesn't provide write access to item_verify and item_sign fields from external engines and special handling for non-standard signature algorithms is impossible. Type of request: enhancement request. Version of OpenSSL: 1.0.2a. Operating system: doesn't matter. Affected files: crypto/evp/evp.h crypto/asn1/ameth_lib.c Patch created using the command: diff -rupN openssl-1.0.2a/ openssl-1.0.2a-EVP_PKEY_asn1_set_item/ > EVP_PKEY_asn1_set_item.patch To apply pach use following command in current OpenSSL root dev. directory: patch -p1 -l -u -b -i EVP_PKEY_asn1_set_item.patch Sergey Agievich Belarusian State University -------------- next part -------------- A non-text attachment was scrubbed... Name: EVP_PKEY_asn1_set_item.patch Type: text/x-patch Size: 2838 bytes Desc: not available URL: From pbellino at mrv.com Wed May 27 12:48:59 2015 From: pbellino at mrv.com (Philip Bellino) Date: Wed, 27 May 2015 12:48:59 +0000 Subject: [openssl-dev] FIPSs validation questions Message-ID: Hello, First, I apologize for posting to the "dev" group, but my email to the "users" group doesn't seem to get posted. We use OpenSSL-1.0.2a and FIPS 2.0.9 and have questions we need to answer in conjunction with the FIPS validation process. One question is whether SHA1 accepts NULL (zero-length) messages? I couldn't find anything on the OpenSSL wiki so I thought I'd ask here. Also, another questions is whether the AES CTR counter source is internal or external? Any information would be appreciated. Thanks, Phil MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed May 27 20:32:32 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 27 May 2015 22:32:32 +0200 Subject: [openssl-dev] [openssl.org #3873] [PATCH] Add traffic counters In-Reply-To: <38061981-5F00-4E0E-85CC-5FFAD7F29A92@akamai.com> References: <38061981-5F00-4E0E-85CC-5FFAD7F29A92@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add traffic counters Add data counters to SSL structure bytes_written and bytes_read Includes SSL_get_byte_counters() API. Github link: https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0016-Add-traffic-counters.patch Type: application/octet-stream Size: 4174 bytes Desc: not available URL: From rt at openssl.org Wed May 27 20:32:34 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 27 May 2015 22:32:34 +0200 Subject: [openssl-dev] [openssl.org #3874] [PATCH] Add certificate verify data to SSL struct In-Reply-To: <0734FE78-5086-4625-9CAC-DCA7DB6E59B8@akamai.com> References: <0734FE78-5086-4625-9CAC-DCA7DB6E59B8@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add certificate verify data to SSL struct Add app_verify_callback and app_verify_arg to the SSL structure and add SSL_SESSION_set_verify_result() API. The values are copied from the SSL_CTX into the SSL. There is also an SSL_set_cert_verify_callback() API. Github link: https://github.com/akamai/openssl/commit/a7d729491c2dacd4dae01eb49e1ca3ff797133ff And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0017-Add-certificate-verify-data-to-SSL-struct.patch Type: application/octet-stream Size: 4134 bytes Desc: not available URL: From rt at openssl.org Wed May 27 20:32:44 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 27 May 2015 22:32:44 +0200 Subject: [openssl-dev] [openssl.org #3875] [PATCH] Add external X509_STORE to SSL_CTX In-Reply-To: <007C934D-7A2C-47A2-94B2-B681EED65F4E@akamai.com> References: <007C934D-7A2C-47A2-94B2-B681EED65F4E@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add external X509_STORE to SSL_CTX Add SSL_CTX_set_cert_store_ref() API to add an external X509_STORE to an SSL_CTX. (There is no get API). Github link: https://github.com/akamai/openssl/commit/517559c8637cda3750b39017685742590f1b692e And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0018-Add-external-X509_STORE-to-SSL_CTX.patch Type: application/octet-stream Size: 1778 bytes Desc: not available URL: From rt at openssl.org Wed May 27 20:32:56 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 27 May 2015 22:32:56 +0200 Subject: [openssl-dev] [openssl.org #3877] [PATCH] Add X509 OCSP error codes and messages In-Reply-To: <58EBF137-9CC7-4CCE-9E07-A5049AB84C5F@akamai.com> References: <58EBF137-9CC7-4CCE-9E07-A5049AB84C5F@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add X509 OCSP error codes and messages Github link: https://github.com/akamai/openssl/commit/6a4a5ae2cca42c5143d82b2fd5520c1c64724d4f And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0020-Add-X509-OCSP-error-codes-and-messages.patch Type: application/octet-stream Size: 1934 bytes Desc: not available URL: From rt at openssl.org Wed May 27 20:32:45 2015 From: rt at openssl.org (Short, Todd via RT) Date: Wed, 27 May 2015 22:32:45 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Do not complain if config file not found Remove warning when OpenSSL config file can't be found Github link: https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0019-Do-not-complain-if-config-file-not-found.patch Type: application/octet-stream Size: 976 bytes Desc: not available URL: From rt at openssl.org Wed May 27 21:49:21 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Wed, 27 May 2015 23:49:21 +0200 Subject: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option In-Reply-To: <87mw0phf29.fsf@alice.fifthhorseman.net> References: <87mw0phf29.fsf@alice.fifthhorseman.net> Message-ID: On Tue 2015-05-26 14:56:10 -0400, Short, Todd via RT wrote: > This is a change that Akamai has made to its implementation of OpenSSL. > > Version: master branch > Description: Add DISALLOW_RENEGOTIATION option > > Add support to disallow renegotiation in openssl > The bit definition may need to change when pulled. Thanks for these patches, Todd! It would be great if patches which add new configuration options also were to update the documentation. It looks like this changeset would want to also provide patches for: doc/ssl/SSL_CTX_set_options.pod doc/apps/s_server.pod --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 948 bytes Desc: not available URL: From rt at openssl.org Wed May 27 22:12:38 2015 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 28 May 2015 00:12:38 +0200 Subject: [openssl-dev] [openssl.org #3865] [Patch] Add DISALLOW_RENEGOTIATION option In-Reply-To: <29E11571-2DFD-417B-B9F8-BF52531FDD65@akamai.com> References: , <87mw0phf29.fsf@alice.fifthhorseman.net> <29E11571-2DFD-417B-B9F8-BF52531FDD65@akamai.com> Message-ID: Hi Daniel: I don't disagree. These patches were made by Akamai employees over the years, and we are finally able to contribute to them. They are of varying quality when it comes to documentation (usually based on the original author of the patch). -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 27, 2015, at 5:43 PM, Daniel Kahn Gillmor wrote: > >> On Tue 2015-05-26 14:56:10 -0400, Short, Todd via RT wrote: >> This is a change that Akamai has made to its implementation of OpenSSL. >> >> Version: master branch >> Description: Add DISALLOW_RENEGOTIATION option >> >> Add support to disallow renegotiation in openssl >> The bit definition may need to change when pulled. > > Thanks for these patches, Todd! > > It would be great if patches which add new configuration options also > were to update the documentation. It looks like this changeset would > want to also provide patches for: > > doc/ssl/SSL_CTX_set_options.pod > doc/apps/s_server.pod > > --dkg From rt at openssl.org Wed May 27 22:40:03 2015 From: rt at openssl.org (Daniel Kahn Gillmor via RT) Date: Thu, 28 May 2015 00:40:03 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <87bnh5hcgz.fsf@alice.fifthhorseman.net> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> <87bnh5hcgz.fsf@alice.fifthhorseman.net> Message-ID: On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote: > This is a change that Akamai has made to its implementation of OpenSSL. > > Version: master branch > Description: Do not complain if config file not found > > Remove warning when OpenSSL config file can't be found > > Github link: > https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996 Why? Is this warning no longer relevant? --dkg From tshort at akamai.com Wed May 27 22:48:16 2015 From: tshort at akamai.com (Short, Todd) Date: Wed, 27 May 2015 22:48:16 +0000 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> <87bnh5hcgz.fsf@alice.fifthhorseman.net>, Message-ID: <7D00A318-1EAD-46B9-89BC-17DD54DA82D8@akamai.com> I'll let the original author (Rich Salz, cc'd), explain. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 27, 2015, at 6:40 PM, Daniel Kahn Gillmor via RT wrote: > >> On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote: >> >> This is a change that Akamai has made to its implementation of OpenSSL. >> >> Version: master branch >> Description: Do not complain if config file not found >> >> Remove warning when OpenSSL config file can't be found >> >> Github link: >> https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996 > > Why? Is this warning no longer relevant? > > --dkg > > From rt at openssl.org Wed May 27 22:48:49 2015 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 28 May 2015 00:48:49 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <7D00A318-1EAD-46B9-89BC-17DD54DA82D8@akamai.com> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> <87bnh5hcgz.fsf@alice.fifthhorseman.net>, <7D00A318-1EAD-46B9-89BC-17DD54DA82D8@akamai.com> Message-ID: I'll let the original author (Rich Salz, cc'd), explain. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 27, 2015, at 6:40 PM, Daniel Kahn Gillmor via RT wrote: > >> On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote: >> >> This is a change that Akamai has made to its implementation of OpenSSL. >> >> Version: master branch >> Description: Do not complain if config file not found >> >> Remove warning when OpenSSL config file can't be found >> >> Github link: >> https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996 > > Why? Is this warning no longer relevant? > > --dkg > > From dkg at fifthhorseman.net Wed May 27 22:39:24 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 27 May 2015 18:39:24 -0400 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> Message-ID: <87bnh5hcgz.fsf@alice.fifthhorseman.net> On Wed 2015-05-27 16:32:45 -0400, Short, Todd via RT wrote: > This is a change that Akamai has made to its implementation of OpenSSL. > > Version: master branch > Description: Do not complain if config file not found > > Remove warning when OpenSSL config file can't be found > > Github link: > https://github.com/akamai/openssl/commit/48ad3880d3247063098d1d2b0aa4e362c4b9d996 Why? Is this warning no longer relevant? --dkg From rt at openssl.org Thu May 28 00:44:11 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 28 May 2015 02:44:11 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> Message-ID: Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org From abramov at bpcbt.com Thu May 28 07:00:18 2015 From: abramov at bpcbt.com (Pavel Abramov) Date: Thu, 28 May 2015 10:00:18 +0300 Subject: [openssl-dev] [openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt) In-Reply-To: <5565CFF4.8060903@wisemo.com> References: <5565CFF4.8060903@wisemo.com>, Message-ID: thanks! Unfortunately there is no pkcs11 wrapper for this device. There are a few commands implementing RSA operations (generate keyPair, PreMaster decrypt) and I have to use them to perform server-side SSL handshake. OpenSC looks very interesting for my task. Pavel ----- "openssl-users" : ----- Re: [openssl-users] External hardware for SSL handshake (overriding PreMasterSecret decrypt) On 27/05/2015 15:26, Pavel Abramov wrote: Hi, I have a task to use external Security Module to perform RSA functions in my WEB-server (nginx/httpd using OpenSSL for HTTPS). The goal is to store Server private key components and establish SSL Handshake using Hardware module. It is not an SSL hardware accelerator. This device has proprietary API (binary protocol over TCP/UDP, a few commands like "generate RSA key pair", "premaster decrypt using key#123"). What is the easiest way to do it? Will be very grateful for keywords/advices. Should I write my ENGINE ? Or is there any other way? I need only 2 functions to perform using hardware: - RSA key generation (private component will be saved in hardware module) - PreMaster decrypt from client during SSL handshake How to override only these 2 functions? ------------------------------- If there is a generic engine wrapping pkcs11 or a similar API, it may or may not be easier to implement (or reuse if already provided) a hardware specific pkcs11 (or similar) driver. I am unsure if there is or is not a well maintained pkcs11 engine for OpenSSL, either in the OpenSSL project or elsewhere.? Maybe the opensc project has one, but I don't know if that would be general or specific to opensc pkcs11 drivers. Keywords to search for: pkcs11, pkcs11 engine, opensc project, openssl engine. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. ?http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. ?Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded _______________________________________________ openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From animesdas at gmail.com Thu May 28 11:24:28 2015 From: animesdas at gmail.com (Animesh Das) Date: Thu, 28 May 2015 16:54:28 +0530 Subject: [openssl-dev] Adding a new Engine to OpenSSL In-Reply-To: <1431708529.4727.8.camel@infradead.org> References: <1431708529.4727.8.camel@infradead.org> Message-ID: My understanding is as there are some similarities between my device and cryptodev device, i may follow the cryptodev. Is it right? If we want to take reference from any other engine iam not getting any similarity between my engine and any one from already implemented. If i go through with pkcs11 then please suggest any url or share any documents which will help me as i am new to this. Thanks Animesh Das On 15 May 2015 22:18, "David Woodhouse" wrote: > On Fri, 2015-05-15 at 17:17 +0530, Animesh Das wrote: > > > > I have a new hardware crypto engine. The device can be accessed > > from user space application opening the device like > > "/dev/mydevice". There are also some IOCTLs which can be used from > > user space. I want to add that device as one of the engines of > > OpenSSL so that the encryption/decryption process can be offloaded > > to that device. > > > > I have new to OpenSSL. Could you please help me giving ideas/steps > > to add that engine in OpenSSL. > > My first inclination is to say "don't". > > Make it a PKCS#11 provider instead, and let OpenSSL use it through > engine_pkcs11. > > (OpenSSL really ought to gain first-class support for PKCS#11 too, > FWIW). > > -- dwmw2 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu May 28 12:19:14 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 28 May 2015 12:19:14 +0000 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From tshort at akamai.com Thu May 28 12:25:53 2015 From: tshort at akamai.com (Short, Todd) Date: Thu, 28 May 2015 12:25:53 +0000 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> Message-ID: The parameters in the configuration file, in general, apply only to certificate operations. The openssl application does way more than certificate operations, and seeing a warning for a configuration file that has no impact on the operation being performed is annoying. Rather than completely remove the warning, I would instead suggest that the warning only be issued for certain commands that may use parameters from the configuration file. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL > wrote: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com > Cc: openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu May 28 12:33:18 2015 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 28 May 2015 12:33:18 +0000 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: Message-ID: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1FAB@LLE2K10-MBX01.mitll.ad.local> Todd, I agree. Have the warning only where it matters (but have it there). From: Short, Todd [mailto:tshort at akamai.com] Sent: Thursday, May 28, 2015 08:25 AM To: Blumenthal, Uri - 0553 - MITLL Cc: rt at openssl.org ; openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found The parameters in the configuration file, in general, apply only to certificate operations. The openssl application does way more than certificate operations, and seeing a warning for a configuration file that has no impact on the operation being performed is annoying. Rather than completely remove the warning, I would instead suggest that the warning only be issued for certain commands that may use parameters from the configuration file. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL > wrote: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com > Cc: openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu May 28 12:36:28 2015 From: rt at openssl.org (Short, Todd via RT) Date: Thu, 28 May 2015 14:36:28 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> Message-ID: The parameters in the configuration file, in general, apply only to certificate operations. The openssl application does way more than certificate operations, and seeing a warning for a configuration file that has no impact on the operation being performed is annoying. Rather than completely remove the warning, I would instead suggest that the warning only be issued for certain commands that may use parameters from the configuration file. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL > wrote: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com > Cc: openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu May 28 12:43:53 2015 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Thu, 28 May 2015 14:43:53 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1FAB@LLE2K10-MBX01.mitll.ad.local> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1FAB@LLE2K10-MBX01.mitll.ad.local> Message-ID: Todd, I agree. Have the warning only where it matters (but have it there). From: Short, Todd [mailto:tshort at akamai.com] Sent: Thursday, May 28, 2015 08:25 AM To: Blumenthal, Uri - 0553 - MITLL Cc: rt at openssl.org ; openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found The parameters in the configuration file, in general, apply only to certificate operations. The openssl application does way more than certificate operations, and seeing a warning for a configuration file that has no impact on the operation being performed is annoying. Rather than completely remove the warning, I would instead suggest that the warning only be issued for certain commands that may use parameters from the configuration file. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet." On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL > wrote: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com > Cc: openssl-dev at openssl.org > Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From a.yousar at informatik.hu-berlin.de Thu May 28 12:31:05 2015 From: a.yousar at informatik.hu-berlin.de (Ann) Date: Thu, 28 May 2015 14:31:05 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> Message-ID: <55670A89.5000903@informatik.hu-berlin.de> If the environment variable OPENSSL_CNF points to non-existing file a warning seems also being informative. /Ann. Am 28.05.2015 um 14:25 schrieb Short, Todd: > > The parameters in the configuration file, in general, apply only to > certificate operations. The openssl application does way more than > certificate operations, and seeing a warning for a configuration file > that has no impact on the operation being performed is annoying. > Rather than completely remove the warning, I would instead suggest > that the warning only be issued for certain commands that may use > parameters from the configuration file. > > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet." > >> On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL >> > wrote: >> >> If I want and expect openssl to use a config file, and it did not >> find it - it's darn useful for me to be informed of that fact by >> openssl. >> >> >> ----- Original Message ----- >> From: Rich Salz via RT [mailto:rt at openssl.org] >> Sent: Wednesday, May 27, 2015 08:44 PM >> To: tshort at akamai.com > > >> Cc: openssl-dev at openssl.org >> > >> Subject: [openssl-dev] [openssl.org #3876] >> [PATCH] Do not complain if configfile not found >> >> Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. >> It should either error+exit or not complain. >> >> I can be convinced the current behavior is useful. >> -- >> Rich Salz, OpenSSL dev team; rsalz at openssl.org >> >> _______________________________________________ >> openssl-dev mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev >> > > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu May 28 12:46:38 2015 From: rt at openssl.org (Blumenthal, Uri - 0553 - MITLL via RT) Date: Thu, 28 May 2015 14:46:38 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> Message-ID: If I want and expect openssl to use a config file, and it did not find it - it's darn useful for me to be informed of that fact by openssl. ----- Original Message ----- From: Rich Salz via RT [mailto:rt at openssl.org] Sent: Wednesday, May 27, 2015 08:44 PM To: tshort at akamai.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. It should either error+exit or not complain. I can be convinced the current behavior is useful. -- Rich Salz, OpenSSL dev team; rsalz at openssl.org _______________________________________________ openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu May 28 15:18:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 28 May 2015 17:18:34 +0200 Subject: [openssl-dev] [openssl.org #3631] Bug in the binary search in OBJ_bsearch_ex_ in obj_dat.c (1.0.1j) In-Reply-To: References: <983952505.96653.1418387394375.JavaMail.open-xchange@patina.store> <54944D6F.2070308@jojema.de> Message-ID: I'm rejecting this ticket on the base that it's aged and that it seems to be a misunderstanding of what arguments OBJ_bsearch_ex_ should be called with. Since you aren't calling it directly but have made changes in the rest of the OpenSSL source, maybe you should have a look at those changes first. If it isn't there, it's possible there is a fault in the OpenSSL code that calls OBJ_bsearch_ex_, but I fail to find it. If you do find such faults, please create a new ticket. Cheers, Richard On Fri Dec 19 17:08:28 2014, matthias.mucha at jojema.de wrote: > No, i commented out the RSA encrypt routines and several other things > that i can't/don't use. This resulted in a smaller array to search, > which led me to this problem. > > I know it's no problem if you use OpenSSL the normal way. I don't call > it from my code. My code only calls methods available in the OpenSSL > API. > > Am 17.12.2014 14:51, schrieb Richard Levitte via RT: > > Are you using OBJ_bsearch_ex_ directly from your code? It seems to > me that you > > have misunderstood how it works. size is the size of one element of > your array, > > num is the number of elements. The actual size of the array (in > bytes) should > > then be size*num, and you need to make sure that it is. > > > > I would, however, recommend that you don't call this function > directly, and > > instead use the macro OBJ_bsearch_ex, which will calculate the > element size > > properly for you, given a type that you give it. > > > > On Fri Dec 12 17:52:07 2014, matthias.mucha at jojema.de wrote: > >> Hello, > >> > >> I strapped down OpenSSL 1.0.1j to only the PEM to RSA, BIO and RSA > >> public > >> decrypt functions. So a bug in the binary search in appeared: > >> > >> Current code: > >> > >> const void *OBJ_bsearch_ex_(const void *key, const void *base_, int > >> num, > >> int size, > >> int (*cmp)(const void *, const void *), > >> int flags) > >> { > >> const char *base=base_; > >> int l,h,i=0,c=0; > >> const char *p = NULL; > >> > >> if (num == 0) return(NULL); > >> l=0; > >> h=num; > >> while (l < h) > >> { > >> i=(l+h)/2; > >> p= &(base[i*size]); > >> c=(*cmp)(key,p); > >> if (c < 0) > >> h=i; > >> else if (c > 0) > >> l=i+1; > >> else > >> break; > >> } > >> > >> > >> [...] > >> > >> My case: size = 4 > >> num = 4 > >> > >> In the first round i evaluates to 2 which can not be divided by > size > >> and lets p > >> escape the frame for the pointers, which results in a segfault. > >> > >> General case: > >> > >> This will fail for every case where num < (size * 2) > >> > >> > >> My fix: > >> > >> const void *OBJ_bsearch_ex_(const void *key, const void *base_, int > >> num, > >> int size, > >> int (*cmp)(const void *, const void *), > >> int flags) > >> { > >> const char *base=base_; > >> int l,h,i=0,c=0; > >> const char *p = NULL; > >> > >> if (num == 0) return(NULL); > >> if (num < size*2) { > >> while(i >> { > >> p=&(base[i*size]); > >> c=(*cmp)(key,p); > >> if (!c) break; > >> else ++i; > >> } > >> } > >> else { > >> l=0; > >> h=num; > >> while (l < h) > >> { > >> i=(l+h)/2; > >> p= &(base[i*size]); > >> c=(*cmp)(key,p); > >> if (c < 0) > >> h=i; > >> else if (c > 0) > >> l=i+1; > >> else > >> break; > >> } > >> } > >> > >> [...] > >> > >> Regards > >> > >> Matthias Mucha > >> > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- Richard Levitte levitte at openssl.org From rt at openssl.org Thu May 28 15:41:34 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 28 May 2015 17:41:34 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> Message-ID: On Thu May 28 02:44:11 2015, rsalz wrote: > Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. > It should either error+exit or not complain. > > I can be convinced the current behavior is useful. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org The current behavior is useful with the commands that actually use the configuration file. Those are ca, req, srp and ts, and except for req, they're all loading the default config file on their own, completely ignoring the fact that openssl.c:main() has already done so. My suggestion is, at least for 1.1 (but I don't see why this can't be ported down to 1.0.2 and 1.0.1) remove the config loading code from openssl.c:main() and add the same code in req.c as you can find in ts.c or srp.c... possibly refactoring that code into a helper function in apps.c. -- Richard Levitte levitte at openssl.org From rt at openssl.org Thu May 28 16:02:28 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Thu, 28 May 2015 18:02:28 +0200 Subject: [openssl-dev] [openssl.org #3877] [PATCH] Add X509 OCSP error codes and messages In-Reply-To: <58EBF137-9CC7-4CCE-9E07-A5049AB84C5F@akamai.com> References: <58EBF137-9CC7-4CCE-9E07-A5049AB84C5F@akamai.com> Message-ID: On Wed May 27 22:32:56 2015, tshort at akamai.com wrote: > Hello OpenSSL Org: > > This is a change that Akamai has made to its > implementation of OpenSSL. > > Version: master branch > Description: Add > X509 OCSP error codes and messages > > Github link: > https://github.com/akamai/openssl/commit/6a4a5ae2cca42c5143d82b2fd5520c1c64724d4f > And attachment. > > Thank you. > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet.? I'd very much like to know where this is used. Perhaps some other ticket that I haven't discovered yet. Please elaborate. -- Richard Levitte levitte at openssl.org From rt at openssl.org Thu May 28 16:07:40 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 28 May 2015 18:07:40 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <9e6d5ee85fb3486aa4cdb2ae3ebbdb87@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> <9e6d5ee85fb3486aa4cdb2ae3ebbdb87@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > My suggestion is, at least for 1.1 (but I don't see why this can't be ported > down to 1.0.2 and 1.0.1) remove the config loading code from > openssl.c:main() and add the same code in req.c as you can find in ts.c or > srp.c... possibly refactoring that code into a helper function in apps.c. Yes, we agree. At least for master; see how painful the cherry-pick back would be. From rt at openssl.org Thu May 28 21:08:22 2015 From: rt at openssl.org (Robert Frohl via RT) Date: Thu, 28 May 2015 23:08:22 +0200 Subject: [openssl-dev] [openssl.org #3878] [DOC] add documentation for SSL_CTX_clear_extra_chain_certs In-Reply-To: <45D7A9E73441C949B737387EB8B1D14299F7B936@de-wie-exch3b.green.sophos> References: <45D7A9E73441C949B737387EB8B1D14299F7B936@de-wie-exch3b.green.sophos> Message-ID: Please add documentation for SSL_CTX_clear_extra_chain_certs to the man pages and mention it's existence in SSL_CTX_add_extra_chain_cert. From rt at openssl.org Thu May 28 21:56:44 2015 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 28 May 2015 23:56:44 +0200 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> References: <1078792A-9F7F-4E78-823A-F4AD21A185FD@akamai.com> Message-ID: fixed on master: commit cc01d21756cc9c79231ef21039782c5fe42008a2 Author: Rich Salz Date: Thu May 28 13:52:55 2015 -0400 RT3876: Only load config when needed Create app_load_config(), a routine to load config file. Remove the "always load config" from the main app. Change the places that used to load config to call the new common routine. Reviewed-by: Richard Levitte From scott.k.mitch1 at gmail.com Thu May 28 23:20:29 2015 From: scott.k.mitch1 at gmail.com (Scott Mitchell) Date: Thu, 28 May 2015 16:20:29 -0700 Subject: [openssl-dev] ALPN RFC compliance Message-ID: The ALPN RFC [1] states: In the event that the server supports no protocols that the client advertises, then the server SHALL respond with a fatal "no_application_protocol" alert. [2] This functionality is not yet implemented in OpenSSL. Now that HTTP/2 has be published as a RFC [3], and due to HTTP/2's dependency on ALPN, it may be good to revisit the issue. The NPN specification is less specific about what to do in the event of no matching protocols, but the OpenSSL implementation also does not support failing the handshake. NPN may be a lower priority than ALPN but it would be nice to support consistent (as possible) behavior for the two extensions. This issue was originally raised on github [4]. [1] https://tools.ietf.org/html/rfc7301 [2] https://tools.ietf.org/html/rfc7301#section-3.2 [3] https://tools.ietf.org/html/rfc7540 [4] https://github.com/openssl/openssl/issues/188 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ohtsu at iij.ad.jp Fri May 29 02:42:25 2015 From: ohtsu at iij.ad.jp (Shigeki Ohtsu) Date: Fri, 29 May 2015 11:42:25 +0900 Subject: [openssl-dev] ALPN RFC compliance In-Reply-To: References: Message-ID: <5567D211.2050905@iij.ad.jp> I submitted a patch to support no_application_protocol alert on ALPN about a year ago. http://rt.openssl.org/Ticket/Display.html?id=3463 But no one replied me yet. On 2015/05/29 8:20, Scott Mitchell wrote: > The ALPN RFC [1] states: > > In the event that the server supports no protocols that the client > advertises, then the server SHALL respond with a fatal > "no_application_protocol" alert. [2] > > This functionality is not yet implemented in OpenSSL. Now that HTTP/2 > has be published as a RFC [3], and due to HTTP/2's dependency on ALPN, > it may be good to revisit the issue. The NPN specification is less > specific about what to do in the event of no matching protocols, but > the OpenSSL implementation also does not support failing the > handshake. NPN may be a lower priority than ALPN but it would be nice > to support consistent (as possible) behavior for the two extensions. > > This issue was originally raised on github [4]. > > [1] https://tools.ietf.org/html/rfc7301 > [2] https://tools.ietf.org/html/rfc7301#section-3.2 > [3] https://tools.ietf.org/html/rfc7540 > [4] https://github.com/openssl/openssl/issues/188 > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From raysatiro at yahoo.com Fri May 29 03:40:16 2015 From: raysatiro at yahoo.com (Ray Satiro) Date: Thu, 28 May 2015 23:40:16 -0400 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> <55654AE8.8050808@yahoo.com> Message-ID: <5567DFA0.70500@yahoo.com> On 5/27/2015 4:21 AM, Matt Caswell via RT wrote: > On Wed May 27 06:41:51 2015, raysatiro at yahoo.com wrote: >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote: >>> Thank you very much for your work on this issue! >>> In my testing so far, it works as requested. >>> >>> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 >>> stable branch, and the test suite succeeeds. >>> >>> Will you consider to add this enhancement in a feature release on the >>> 1.0.2 branch? >> I second this. It looks like this is also discussed in bug #2634 where >> it was considered an enhancement and therefore will not be in 1.0.2. It >> seems more like a bug fix to me though. If OpenSSL can complete the >> chain it should. What would be the disadvantage of doing so? > This issue is now being treated as a bug fix and the fix was already applied to > the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2 > release). A backport for 1.0.1 also exists but has not yet hit the repo. > > Matt Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on curl-library and we are wondering what would be the disadvantages if we added it to our default flags? Also, the alt chain check in x509_vfy.c isn't done if TRUSTED_FIRST and I'm having trouble grasping why that is. Why not check for alternate chains regardless of whether or not you're checking trusted store first? From rt at openssl.org Fri May 29 03:40:57 2015 From: rt at openssl.org (Ray Satiro via RT) Date: Fri, 29 May 2015 05:40:57 +0200 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: <5567DFA0.70500@yahoo.com> References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> <55654AE8.8050808@yahoo.com> <5567DFA0.70500@yahoo.com> Message-ID: On 5/27/2015 4:21 AM, Matt Caswell via RT wrote: > On Wed May 27 06:41:51 2015, raysatiro at yahoo.com wrote: >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote: >>> Thank you very much for your work on this issue! >>> In my testing so far, it works as requested. >>> >>> I noticed the code changes in x509_vfy.c apply fine on top of the 1.0.2 >>> stable branch, and the test suite succeeeds. >>> >>> Will you consider to add this enhancement in a feature release on the >>> 1.0.2 branch? >> I second this. It looks like this is also discussed in bug #2634 where >> it was considered an enhancement and therefore will not be in 1.0.2. It >> seems more like a bug fix to me though. If OpenSSL can complete the >> chain it should. What would be the disadvantage of doing so? > This issue is now being treated as a bug fix and the fix was already applied to > the 1.0.2 tree a while ago (and therefore will appear in the next 1.0.2 > release). A backport for 1.0.1 also exists but has not yet hit the repo. > > Matt Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on curl-library and we are wondering what would be the disadvantages if we added it to our default flags? Also, the alt chain check in x509_vfy.c isn't done if TRUSTED_FIRST and I'm having trouble grasping why that is. Why not check for alternate chains regardless of whether or not you're checking trusted store first? From balajimarisetti at gmail.com Fri May 29 04:09:20 2015 From: balajimarisetti at gmail.com (balaji marisetti) Date: Fri, 29 May 2015 09:39:20 +0530 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: References: <1427720548359.36445@caviumnetworks.com> <5563456F.2000007@openssl.org> Message-ID: Hi Andy, Thanks for pointing us to a better alternative. We'll try and change the way of configuring OpenSSL for OCTEON. -Balaji M On 25 May 2015 at 21:23, Andy Polyakov via RT wrote: > Hi, > >> This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. > > Well, objective is not to collect as many exotic config lines as > possible, but rather more generic ones that we are ready to support and > make them flexible enough to be reusable in more specific contexts. For > example in this case what prevents you from using > > ./Configure linux-generic32 > --cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32 > > and > > ./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu- > > Or better yet > > ./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- > > and > > ./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- > > and take advantage of assembly support? > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- :-)balaji From rt at openssl.org Fri May 29 04:10:21 2015 From: rt at openssl.org (balaji marisetti via RT) Date: Fri, 29 May 2015 06:10:21 +0200 Subject: [openssl-dev] [openssl.org #3773] [PATCH] Configure support for OCTEON boards In-Reply-To: References: <1427720548359.36445@caviumnetworks.com> <5563456F.2000007@openssl.org> Message-ID: Hi Andy, Thanks for pointing us to a better alternative. We'll try and change the way of configuring OpenSSL for OCTEON. -Balaji M On 25 May 2015 at 21:23, Andy Polyakov via RT wrote: > Hi, > >> This patch adds Cavium Networks' OCTEON target to Configure file. The diff is taken against OpenSSL-1.0.2a release. > > Well, objective is not to collect as many exotic config lines as > possible, but rather more generic ones that we are ready to support and > make them flexible enough to be reusable in more specific contexts. For > example in this case what prevents you from using > > ./Configure linux-generic32 > --cross-compile-prefix=mips64-octeon-linux-gnu- -mabi=n32 > > and > > ./Configure linux-generic64 --cross-compile-prefix=mips64-octeon-linux-gnu- > > Or better yet > > ./Configure linux-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- > > and > > ./Configure linux64-mips64 --cross-compile-prefix=misp4-octeon-linux-gnu- > > and take advantage of assembly support? > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- :-)balaji From rt at openssl.org Fri May 29 05:06:05 2015 From: rt at openssl.org (Joy Tu via RT) Date: Fri, 29 May 2015 07:06:05 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: Message-ID: Hi, I am porting openssl_1.0.1g to our private OS. But we meet some problem, could you please give me a favor. The issue is described below. Inside the file obj_xref.c, there is a variable sigx_app that never be initialize, so this variable sigx_app will be changed anytime. The uninitialized variable sigx_app will cause the system crash at anytime. Could you please tell me the reason why the variable didn?t initialize? l The code we modified below will fix the issue at our OS, could you give us some suggession. Origin : STACK_OF(nid_triple) *sig_app, *sigx_app; Modified : STACK_OF(nid_triple) *sig_app = NULL, *sigx_app = NULL; Best regards. From beldmit at gmail.com Fri May 29 09:26:22 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 29 May 2015 12:26:22 +0300 Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do not complain if config file not found In-Reply-To: References: <65D2FD736B6B2B48B2EAD2BD189DC9CC271D1F48@LLE2K10-MBX01.mitll.ad.local> Message-ID: Hello all, Some engines configure themselves using config, so absence of config can mean non-functional engine. On Thu, May 28, 2015 at 3:36 PM, Short, Todd via RT wrote: > > The parameters in the configuration file, in general, apply only to > certificate operations. The openssl application does way more than > certificate operations, and seeing a warning for a configuration file that > has no impact on the operation being performed is annoying. Rather than > completely remove the warning, I would instead suggest that the warning > only be issued for certain commands that may use parameters from the > configuration file. > > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet." > > On May 28, 2015, at 8:19 AM, Blumenthal, Uri - 0553 - MITLL < > uri at ll.mit.edu> wrote: > > If I want and expect openssl to use a config file, and it did not find it > - it's darn useful for me to be informed of that fact by openssl. > > > ----- Original Message ----- > From: Rich Salz via RT [mailto:rt at openssl.org] > Sent: Wednesday, May 27, 2015 08:44 PM > To: tshort at akamai.com tshort at akamai.com>> > Cc: openssl-dev at openssl.org < > openssl-dev at openssl.org> > Subject: [openssl-dev] [openssl.org #3876] [PATCH] Do > not complain if config file not found > > Because it goes ahead and proceeds. Not it is explicit testing ENOTFOUND. > It should either error+exit or not complain. > > I can be convinced the current behavior is useful. > -- > Rich Salz, OpenSSL dev team; rsalz at openssl.org > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > > > _______________________________________________ > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri May 29 10:05:13 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 29 May 2015 12:05:13 +0200 Subject: [openssl-dev] [openssl.org #3621] Support legacy CA removal, ignore unnecessary intermediate CAs in SSL/TLS handshake by default In-Reply-To: References: <1417696415.31613.83.camel@kuix.de> <1426499080.2298.11.camel@kuix.de> <55654AE8.8050808@yahoo.com> <5567DFA0.70500@yahoo.com> Message-ID: On Fri May 29 05:40:51 2015, raysatiro at yahoo.com wrote: > On 5/27/2015 4:21 AM, Matt Caswell via RT wrote: > > On Wed May 27 06:41:51 2015, raysatiro at yahoo.com wrote: > >> On 3/16/2015 5:45 AM, Kai Engert via RT wrote: > >>> Thank you very much for your work on this issue! > >>> In my testing so far, it works as requested. > >>> > >>> I noticed the code changes in x509_vfy.c apply fine on top of the > 1.0.2 > >>> stable branch, and the test suite succeeeds. > >>> > >>> Will you consider to add this enhancement in a feature release on > the > >>> 1.0.2 branch? > >> I second this. It looks like this is also discussed in bug #2634 > where > >> it was considered an enhancement and therefore will not be in > 1.0.2. It > >> seems more like a bug fix to me though. If OpenSSL can complete the > >> chain it should. What would be the disadvantage of doing so? > > This issue is now being treated as a bug fix and the fix was already > applied to > > the 1.0.2 tree a while ago (and therefore will appear in the next > 1.0.2 > > release). A backport for 1.0.1 also exists but has not yet hit the > repo. > > > > Matt > > Thanks Matt. TRUSTED_FIRST flag has been brought up a few times on > curl-library and we are wondering what would be the disadvantages if > we > added it to our default flags? Also, the alt chain check in x509_vfy.c > isn't done if TRUSTED_FIRST and I'm having trouble grasping why that > is. > Why not check for alternate chains regardless of whether or not you're > checking trusted store first? > >From 1.0.2b onwards OpenSSL will support three different strategies for achieving the goal of building a valid certificate chain: 1) Old style 2) Trusted first 3) Alt chains With old style (all current versions of OpenSSL) we start with the peer provided certificate, then we add as many certificates to the chain as we can from the list provided by the peer. Finally we add as many as we can from the trusted certificate store. If we end up with a valid chain then we have been successful. >From 1.0.2 we additionally support the trusted first strategy (although this is not the default). In this strategy we start with the peer provided certificate and then see if we can add certificates from the trusted store to build a chain. If we can then great - we're done. Otherwise we add a certificate from the peer provided list and then check the trusted store again, and so on until we have either found a chain or run out of peer provided certificates to add. We considered making trusted first the default strategy however there is a problem with this. The trusted store logic will cache certificates that we look up. However we only cache *success* but not *failure*. Therefore there is a potential performance hit every time we go through the trusted store but fail to find any certificates. The trusted first strategy could end up doing this a lot. Its unclear exactly how big this performance hit is - but that is the reason why we were wary of making this the default. >From 1.0.2b we will also support the alt chains strategy (and this will be the default). This starts off in exactly the same way as the old style approach. However if after adding all the certificates from the peer provided list we are unable to build a trusted chain, then we pop the last certificate off the chain we've built so far and go back to the trusted store to have another go. We continue this until we've got no more certificates to pop. The primary advantage of the alt chains strategy is that there is no performance hit over any chain that would be successfully built using the old style strategy (because it starts off in the same way). There might be a performance hit on unsuccessful chain building over the old style - but we assume this is less of an issue. It makes no sense to combine the trusted first and alt chains strategies. With trusted first we have already checked all of the possible chains by the time we get to the end of the peer provided list - so there is no point in then popping certs off the top of our chain and checking the trusted store again. Hope that clarifies things, Matt From beldmit at gmail.com Fri May 29 10:23:03 2015 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 29 May 2015 13:23:03 +0300 Subject: [openssl-dev] GOST89 cipher control command In-Reply-To: References: Message-ID: Hello OpenSSL team, Any recommendations? Thank you! On Mon, May 25, 2015 at 10:40 PM, Dmitry Belyavsky wrote: > Hello Openssl team, > > GOST89 cipher algorithm seems to be the only cipher algorithm supporting > more than one sets of S-boxes. > > Current implementation of the GOST89 cipher provided by the ccgost engine > does not allow to specify usage of particular S-boxes for a particular > EVP_CIPHER_CTX instance. If I understand correctly, the only way to do it > is to specify a ctrl-command and implement it in the engine. > > Is it OK to reuse EVP_CTRL_INIT ctrl command for this purpose or it will > be better to add a special value for this? > > Thank you! > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri May 29 10:43:23 2015 From: rt at openssl.org (=?UTF-8?B?RW1pbGlhIEvDpHNwZXI=?= via RT) Date: Fri, 29 May 2015 12:43:23 +0200 Subject: [openssl-dev] [openssl.org #3871] Patch for latest git master to fix crypto/ec build errors (OSX) In-Reply-To: <55656DAE.2000407@bouncycastle.org> References: <55656DAE.2000407@bouncycastle.org> Message-ID: Fixed in 88f4c6f3d2f884715f8f5f8eb81f0a96cbec8cef, thanks for spotting! From rt at openssl.org Fri May 29 12:58:32 2015 From: rt at openssl.org (Matt Caswell via RT) Date: Fri, 29 May 2015 14:58:32 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: Message-ID: On Fri May 29 07:06:02 2015, Joy.Tu at moxa.com wrote: > Hi, > I am porting openssl_1.0.1g to our private OS. > But we meet some > problem, could you please give me a favor. > > The issue is described > below. > Inside the file obj_xref.c, there is a variable sigx_app that > never be initialize, > so this variable sigx_app will be changed > anytime. > The uninitialized variable sigx_app will cause the system > crash at anytime. > > Could you please tell me the reason why the > variable didn?t initialize? The variable sigx_app is a global variable. If your global variables are not being initialised then I would classify this as a compiler bug. OpenSSL assumes a compiler to be conformant with the C90 spec. All global variables have static storage duration. From section 6.5.7 of C90: "If an object that has static storage duration is not initialized explicitly, it is initialized implicitly as if every member that has arithmetic type were assigned 0 and every member that has pointer type were assigned a null pointer constant". Matt From kurt at roeckx.be Fri May 29 16:57:15 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Fri, 29 May 2015 18:57:15 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: Message-ID: <20150529165714.GA20429@roeckx.be> On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: > On Fri May 29 07:06:02 2015, Joy.Tu at moxa.com wrote: > > Hi, > > I am porting openssl_1.0.1g to our private OS. > > But we meet some > > problem, could you please give me a favor. > > > > The issue is described > > below. > > Inside the file obj_xref.c, there is a variable sigx_app that > > never be initialize, > > so this variable sigx_app will be changed > > anytime. > > The uninitialized variable sigx_app will cause the system > > crash at anytime. > > > > Could you please tell me the reason why the > > variable didn't initialize? > > The variable sigx_app is a global variable. If your global variables are not > being initialised then I would classify this as a compiler bug. > > OpenSSL assumes a compiler to be conformant with the C90 spec. All global > variables have static storage duration. From section 6.5.7 of C90: > > "If an object that has static storage duration is not initialized explicitly, > it is initialized implicitly as if every member that has arithmetic type were > assigned 0 and every member that has pointer type were assigned a null pointer > constant". This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. Kurt From rt at openssl.org Fri May 29 16:58:14 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Fri, 29 May 2015 18:58:14 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: <20150529165714.GA20429@roeckx.be> References: <20150529165714.GA20429@roeckx.be> Message-ID: On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: > On Fri May 29 07:06:02 2015, Joy.Tu at moxa.com wrote: > > Hi, > > I am porting openssl_1.0.1g to our private OS. > > But we meet some > > problem, could you please give me a favor. > > > > The issue is described > > below. > > Inside the file obj_xref.c, there is a variable sigx_app that > > never be initialize, > > so this variable sigx_app will be changed > > anytime. > > The uninitialized variable sigx_app will cause the system > > crash at anytime. > > > > Could you please tell me the reason why the > > variable didn't initialize? > > The variable sigx_app is a global variable. If your global variables are not > being initialised then I would classify this as a compiler bug. > > OpenSSL assumes a compiler to be conformant with the C90 spec. All global > variables have static storage duration. From section 6.5.7 of C90: > > "If an object that has static storage duration is not initialized explicitly, > it is initialized implicitly as if every member that has arithmetic type were > assigned 0 and every member that has pointer type were assigned a null pointer > constant". This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. Kurt From rt at openssl.org Sat May 30 01:41:47 2015 From: rt at openssl.org (Joy Tu via RT) Date: Sat, 30 May 2015 03:41:47 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: <20150529165714.GA20429@roeckx.be>, Message-ID: ________________________________________ From: Kurt Roeckx via RT [rt at openssl.org] Sent: Saturday, May 30, 2015 12:58 AM To: Joy Tu (???) Cc: openssl-dev at openssl.org Subject: Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: > On Fri May 29 07:06:02 2015, Joy.Tu at moxa.com wrote: > > >Hi, > > >I am porting openssl_1.0.1g to our private OS. > > >But we meet some > > >problem, could you please give me a favor. > > > > > >The issue is described > > >below. > > >Inside the file obj_xref.c, there is a variable sigx_app that > > >never be initialize, > > >so this variable sigx_app will be changed > > >anytime. > > >The uninitialized variable sigx_app will cause the system > > >crash at anytime. > > > > > >Could you please tell me the reason why the > > >variable didn't initialize? > > > >The variable sigx_app is a global variable. If your global variables are not > >being initialised then I would classify this as a compiler bug. > > >OpenSSL assumes a compiler to be conformant with the C90 spec. All global > >variables have static storage duration. From section 6.5.7 of C90: > > >"If an object that has static storage duration is not initialized explicitly, > >it is initialized implicitly as if every member that has arithmetic type were > >assigned 0 and every member that has pointer type were assigned a null pointer > >constant". >This is typically done by putting those variables in the bss >segment. Your private OS probably didn't set the bss segment to >all 0's. So the solution is to initialize the variable by myself or update the compiler to conformant with the C90 spec or force those global variable in the bss segment to be all 0's on my private OS? From rt at openssl.org Sat May 30 01:50:09 2015 From: rt at openssl.org (Joy Tu via RT) Date: Sat, 30 May 2015 03:50:09 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: , <20150529165714.GA20429@roeckx.be> Message-ID: So the solution is to initialize the variable by myself or update the compiler to conformant with the C90 spec or force those global variable in the bss segment to be all 0's on my private OS? ________________________________________ From: Kurt Roeckx [kurt at roeckx.be] Sent: Saturday, May 30, 2015 12:57 AM To: rt at openssl.org; openssl-dev at openssl.org Cc: Joy Tu (???) Subject: Re: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) On Fri, May 29, 2015 at 02:58:32PM +0200, Matt Caswell via RT wrote: > On Fri May 29 07:06:02 2015, Joy.Tu at moxa.com wrote: > > Hi, > > I am porting openssl_1.0.1g to our private OS. > > But we meet some > > problem, could you please give me a favor. > > > > The issue is described > > below. > > Inside the file obj_xref.c, there is a variable sigx_app that > > never be initialize, > > so this variable sigx_app will be changed > > anytime. > > The uninitialized variable sigx_app will cause the system > > crash at anytime. > > > > Could you please tell me the reason why the > > variable didn't initialize? > > The variable sigx_app is a global variable. If your global variables are not > being initialised then I would classify this as a compiler bug. > > OpenSSL assumes a compiler to be conformant with the C90 spec. All global > variables have static storage duration. From section 6.5.7 of C90: > > "If an object that has static storage duration is not initialized explicitly, > it is initialized implicitly as if every member that has arithmetic type were > assigned 0 and every member that has pointer type were assigned a null pointer > constant". This is typically done by putting those variables in the bss segment. Your private OS probably didn't set the bss segment to all 0's. Kurt From kurt at roeckx.be Sat May 30 06:30:41 2015 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 30 May 2015 08:30:41 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: References: <20150529165714.GA20429@roeckx.be> Message-ID: <20150530063040.GA20507@roeckx.be> On Sat, May 30, 2015 at 01:49:30AM +0000, Joy Tu (???) wrote: > So the solution is to initialize the variable by myself or > update the compiler to conformant with the C90 spec or > force those global variable in the bss segment to be all 0's on my private OS? Most likely your compiler will already put them in the bss. Various programs will rely on the bss to be set to 0, so I suggest you do that. Kurt From rt at openssl.org Sat May 30 06:31:33 2015 From: rt at openssl.org (Kurt Roeckx via RT) Date: Sat, 30 May 2015 08:31:33 +0200 Subject: [openssl-dev] [openssl.org #3879] [BUG] opennssl 1.0.1g cause the system crash (obj_xref.c) In-Reply-To: <20150530063040.GA20507@roeckx.be> References: <20150529165714.GA20429@roeckx.be> <20150530063040.GA20507@roeckx.be> Message-ID: On Sat, May 30, 2015 at 01:49:30AM +0000, Joy Tu (???) wrote: > So the solution is to initialize the variable by myself or > update the compiler to conformant with the C90 spec or > force those global variable in the bss segment to be all 0's on my private OS? Most likely your compiler will already put them in the bss. Various programs will rely on the bss to be set to 0, so I suggest you do that. Kurt From rt at openssl.org Sat May 30 07:48:01 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:01 +0200 Subject: [openssl-dev] [openssl.org #3881] [PATCH] Instrument OpenSSL buffer heap memory usage In-Reply-To: <85151430-D7D2-47B9-A88A-41A1AE2F7160@akamai.com> References: <85151430-D7D2-47B9-A88A-41A1AE2F7160@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Instrument OpenSSL buffer heap memory usage Added function to register callbacks to allocate and free data buffers. These callbacks can then allocate and free the memory as needed, while also recording buffer allocations. This permits a user-definable implementation of FREE_BUFLIST, which has been removed. (Yes, documentation is lacking at this point). Github link: https://github.com/akamai/openssl/commit/4a6d71bbd2f4fe38ebcbe2f9917a1c7fedd117f8 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0022-Instrument-OpenSSL-buffer-heap-memory-usage.patch Type: application/octet-stream Size: 3534 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:01 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:01 +0200 Subject: [openssl-dev] [openssl.org #3880] [PATCH] Windows: Add definitions for AI_ constants In-Reply-To: References: Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Windows: Add definitions for AI_ constants Add definitions for AI_ADDRCONFIG and AI_NUMERICSERV Github link: https://github.com/akamai/openssl/commit/4ca23c77fabd23cd610ada221fac494c0ae9b030 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0021-Windows-Add-defintions-for-AI_-constants.patch Type: application/octet-stream Size: 1056 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:07 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:07 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: lh_SSL_SESSION_delete() not checked Fix an OpenSSL issue where the return code of lh_SSL_SESSION_delete() is not checked, causing a stale reference in the lhash. Github link: https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-lh_SSL_SESSION_delete-not-checked.patch Type: application/octet-stream Size: 1453 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:33 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:33 +0200 Subject: [openssl-dev] [openssl.org #3884] [PATCH] Add support for Win64 in o_str.c In-Reply-To: <18C01F4B-FCD5-416F-BADE-1B0A43933684@akamai.com> References: <18C01F4B-FCD5-416F-BADE-1B0A43933684@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add support for Win64 in o_str.c OPENSSL_SYS_WIN64 is missing in a check for windows. Github link: https://github.com/akamai/openssl/commit/a4204b839be4b33cd0f4e7e2639aae6384e1c2d7 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0003-Add-support-for-Win64-in-o_str.c.patch Type: application/octet-stream Size: 737 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:33 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:33 +0200 Subject: [openssl-dev] [openssl.org #3885] [BUGFIX] OpenSSL fails to cross-compile on 32-bit->64-bit In-Reply-To: <0EBAC0E8-E1E9-4630-B627-9D7B90C25B03@akamai.com> References: <0EBAC0E8-E1E9-4630-B627-9D7B90C25B03@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: OpenSSL fails to cross-compile on 32-bit->64-bit Older/32-bit versions of perl cannot handle 64-bit numbers, so when the x86_64-xlate.pl script encounters a 64-bit number, the oct() function munges it into a double-precision rather than a 64-bit integer. In this case, we know it's either a hex number or an octal number. So, if hex, just pass through as hex string, otherwise allow oct() to handle it. This is a problem in ghash-x86_64.pl (ghash-x86_64.s), and the solution has an impact all 64-bit platforms. Ran the unit tests to make sure it's OK Github link: https://github.com/akamai/openssl/commit/89808ba6a3e3ab69b12518dc5ba651eb29c18ee7 And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0004-OpenSSL-fails-to-cross-compile-on-32-bit-64-bit.patch Type: application/octet-stream Size: 1689 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:43 2015 From: rt at openssl.org (John Lofgren via RT) Date: Sat, 30 May 2015 09:48:43 +0200 Subject: [openssl-dev] [openssl.org #3886] [BUG] [PATCH] verify fails for 3-level cert chain when using X509v3 Authority Key Identifier In-Reply-To: References: Message-ID: I believe I have pinpointed a typo-error that may be the cause of one or two other outstanding bugs related to certificate chain validation. This bug only occurs in a chain of certs at least 3 deep when the certs use the X509v3 Authority Key Identifier extension. I am attaching a chain of 3 certs that verifies using the Windows Certificate Manager, but fails to verify in versions 1.0.1, 1.0.1c and 1.0.1m. Example failure command: openssl verify -CAfile openssl-verify-chain-bug-CA.crt -untrusted openssl-verify-chain-bug-IM-CA.crt openssl-verify-chain-bug-CS.crt If have also provided a one line patch to crypto/x509v3/v3_purp.c. I believe the error is due to a simple typo. The function X509_check_akid() is meant to compare the keyID, serial number, and issuer name between a cert and its issuer cert. The keyID and serial number compares are working correctly. However, when comparing the issuer name, instead of comparing the cert's issuer name to the issuer cert's subject name, it is comparing to the issuer cert's *issuer* name. i.e. instead of comparing to the parent name, it is comparing to the grandparent name. John Lofgren -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl_bug.zip Type: application/zip Size: 4148 bytes Desc: not available URL: From rt at openssl.org Sat May 30 07:48:15 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sat, 30 May 2015 09:48:15 +0200 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> Message-ID: Hello OpenSSL Org: This is a change that Akamai has made to its implementation of OpenSSL. Version: master branch Description: Add IPv4/IPv6:port-based client cache Update client cache to use IPv4/v6 addresses via sockaddr_storage. Add unit tests for client cache (Documentation is in the source files, not a .pod) Github link: https://github.com/akamai/openssl/commit/6bac97c07d7f6eb3015a2b5fe2869b0560a9594a And attachment. Thank you. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, three if by the Internet.? -------------- next part -------------- A non-text attachment was scrubbed... Name: 0002-Add-IPv4-IPv6-port-based-client-cache.patch Type: application/octet-stream Size: 57049 bytes Desc: not available URL: From rt at openssl.org Sat May 30 15:00:47 2015 From: rt at openssl.org (Andy Polyakov via RT) Date: Sat, 30 May 2015 17:00:47 +0200 Subject: [openssl-dev] [openssl.org #3615] [PATCH] ChaCha20 with Poly1305 TLS Cipher Suites via the EVP interface In-Reply-To: <5569D08B.6000608@openssl.org> References: <555A08F0.8030508@openssl.org> <5561D3B3.1060506@openssl.org> <5569D08B.6000608@openssl.org> Message-ID: >> More coming in. > > Consider 32-bit results. First column is assembly results for base 2^32 > integer-only code in comparison to compiler-generate code. Second column > is my result for NEON, and last column are results for Andrew Moon's > NEON implementation, both are base 2^26. > > # IALU/gcc-4.4 NEON poly1305-opt > # > # Cortex-A5 6.30/+130% 2.96 4.90 > # Cortex-A8 6.25/+115% 2.40 2.36 > # Cortex-A9 5.10/+95% 2.56 2.25 > # Cortex-A15 3.79/+85% 1.30 1.53 > # Snapdragon S4 5.70/+100% 1.48 7.58(?) > > As mentioned earlier goal is "all-round" performance, i.e. near-optimal > performance across *range* of platforms. Judging from Cortex-A9 result I > have some room for improvement, hopefully it will benefit all > processors. After experimenting I'm leaning toward settling for above results. A little bit improved on couple of CPUs, but same approach. What are the approaches? When pulling input data and performing due conversion to base 2^26 it's possible to a) do it completely in NEON (above results); b) do it with integer-only instructions and move data to NEON with inter-register vmov; c) do it with integer-only instructions and transfer data to NEON through memory. It was found that b) gives me ~8% improvement on Cortex-A15 and Snapdragon S4, but hurts low-end Cortex-A5 as well as Cortex-A7 by 15/12%. Then c) performs as b) on Cortex-A15 and S4, improves Cortex-A9 by 10%, but losses on low-end go over 20%. Keep in mind that there is certain asymmetry in how losses vs. gains are presented. For example when we measure 25% regression it means that original is 33% faster. Anyway, all-NEON approach appears to provide best "all-round" performance. -------------- next part -------------- A non-text attachment was scrubbed... Name: poly1305-armv4.pl Type: application/x-perl Size: 25164 bytes Desc: not available URL: From openssl-users at dukhovni.org Sun May 31 06:06:03 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 31 May 2015 06:06:03 +0000 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> Message-ID: <20150531060603.GX2342@mournblade.imrryr.org> On Sat, May 30, 2015 at 09:48:15AM +0200, Short, Todd via RT wrote: > Hello OpenSSL Org: > > This is a change that Akamai has made to its implementation of OpenSSL. > > Version: master branch > Description: Add IPv4/IPv6:port-based client cache > > Update client cache to use IPv4/v6 addresses via sockaddr_storage. > Add unit tests for client cache > > (Documentation is in the source files, not a .pod) Do you have code to produce usable manpages from the embedded documentation? We can't ask users to read the source. Perhaps a ".pod" could be generated? > > Github link: > > https://github.com/akamai/openssl/commit/6bac97c07d7f6eb3015a2b5fe2869b0560a9594a Apart from documentation, I have two major issues: * The copyright notice does not refer to any license that would allow inclusion in OpenSSL. * The cache is indexed by "ip & port", but the same TCP endpoint can serve multiple domains via SNI. It is wrong to reuse a session obtained for one SNI name (server certificate) with a different SNI name (different server certificate). * The use of the session cache hash function appears to be wrong. The session hash is based on the session id, but the session used for lookup has just ex_data with the ip/port, which don't get used at all. * Perhaps other issues too, but this is far from ready it seems. -- Viktor. From openssl-users at dukhovni.org Sun May 31 06:39:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 31 May 2015 06:39:49 +0000 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: <20150531060603.GX2342@mournblade.imrryr.org> References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> <20150531060603.GX2342@mournblade.imrryr.org> Message-ID: <20150531063949.GZ2342@mournblade.imrryr.org> On Sun, May 31, 2015 at 06:06:03AM +0000, Viktor Dukhovni wrote: > * Perhaps other issues too, but this is far from ready it seems. Also why is line 399 of ssl_client_cache.c setting "s->hit = 1"? -- Viktor. From rt at openssl.org Sun May 31 07:46:41 2015 From: rt at openssl.org (noloader@gmail.com via RT) Date: Sun, 31 May 2015 09:46:41 +0200 Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails In-Reply-To: References: Message-ID: apps.c has a couple of parsing routines called load_pubkey and load_key. rsautl uses those routines. However, there's no option in rsautil to use anything other than a ASN.1/DER or PEM encoded traditional key (or subject public key info). The code paths are present, we just can't seem to get to them. Folks in the field have problem with it on occasion. See, for example, "Can't load programmatically generated public key," http://stackoverflow.com/q/30547646. This patch adds an intelligent fallback: /* rsautl does not offer a way to specify just a public key. It requires a */ /* subjectPublicKeyInfo, and there's no argument or option to switch to */ /* the other type with either ASN.1/DER or PEM. This attempts to make an */ /* intelligent retry. */ if(keyformat == FORMAT_PEM) { next_format = FORMAT_PEMRSA; } if(keyformat == FORMAT_ASN1) { next_format = FORMAT_ASN1RSA; } else { next_format = -1; } switch (key_type) { case KEY_PRIVKEY: pkey = load_key(keyfile, keyformat, 0, passin, e, "Private Key", 0 /*last_try*/); if(!pkey && next_format != -1) { pkey = load_key(keyfile, next_format, 0, passin, e, "Private Key", 1 /*last_try*/); } break; case KEY_PUBKEY: pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public Key", 0 /*last_try*/); if(!pkey && next_format != -1) { pkey = load_pubkey(keyfile, next_format, 0, NULL, e, "Public Key", 1 /*last_try*/); } break; Then, functions load_key and load_pubkey suppress the error messages if last_try is 0: if (pkey == NULL && last_try) { BIO_printf(bio_err, "unable to load %s\n", key_descrip); } All in all, existing behavior and error messages are maintained. The subcommand is just a little more robust. Related, we might be able to make similar changes to rsa.c. But there's some extra special sauce present, so it was not a clear cut-in. I think the special sauce kid of attempts to do the same thing as above. (Maybe this patch should act more like rsa.c?) -------------- next part -------------- diff --git a/apps/apps.c b/apps/apps.c index 60f71c3..f80767a 100644 --- a/apps/apps.c +++ b/apps/apps.c @@ -763,7 +763,7 @@ X509_CRL *load_crl(const char *infile, int format) } EVP_PKEY *load_key(const char *file, int format, int maybe_stdin, - const char *pass, ENGINE *e, const char *key_descrip) + const char *pass, ENGINE *e, const char *key_descrip, int last_try) { BIO *key = NULL; EVP_PKEY *pkey = NULL; @@ -773,7 +773,7 @@ EVP_PKEY *load_key(const char *file, int format, int maybe_stdin, cb_data.prompt_info = file; if (file == NULL && (!maybe_stdin || format == FORMAT_ENGINE)) { - BIO_printf(bio_err, "no keyfile specified\n"); + if(last_try) { BIO_printf(bio_err, "no keyfile specified\n"); } goto end; } #ifndef OPENSSL_NO_ENGINE @@ -827,7 +827,7 @@ EVP_PKEY *load_key(const char *file, int format, int maybe_stdin, } end: BIO_free(key); - if (pkey == NULL) { + if (pkey == NULL && last_try) { BIO_printf(bio_err, "unable to load %s\n", key_descrip); ERR_print_errors(bio_err); } @@ -842,7 +842,7 @@ static const char *key_file_format(int format) } EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin, - const char *pass, ENGINE *e, const char *key_descrip) + const char *pass, ENGINE *e, const char *key_descrip, int last_try) { BIO *key = NULL; EVP_PKEY *pkey = NULL; @@ -852,7 +852,7 @@ EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin, cb_data.prompt_info = file; if (file == NULL && (!maybe_stdin || format == FORMAT_ENGINE)) { - BIO_printf(bio_err, "no keyfile specified\n"); + if(last_try) { BIO_printf(bio_err, "no keyfile specified\n"); } goto end; } #ifndef OPENSSL_NO_ENGINE @@ -914,8 +914,9 @@ EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin, #endif end: BIO_free(key); - if (pkey == NULL) + if (pkey == NULL && last_try) { BIO_printf(bio_err, "unable to load %s\n", key_descrip); + } return (pkey); } diff --git a/apps/apps.h b/apps/apps.h index a8652a1..0cd563a 100644 --- a/apps/apps.h +++ b/apps/apps.h @@ -427,9 +427,9 @@ X509 *load_cert(const char *file, int format, X509_CRL *load_crl(const char *infile, int format); int load_cert_crl_http(const char *url, X509 **pcert, X509_CRL **pcrl); EVP_PKEY *load_key(const char *file, int format, int maybe_stdin, - const char *pass, ENGINE *e, const char *key_descrip); + const char *pass, ENGINE *e, const char *key_descrip, int last_try); EVP_PKEY *load_pubkey(const char *file, int format, int maybe_stdin, - const char *pass, ENGINE *e, const char *key_descrip); + const char *pass, ENGINE *e, const char *key_descrip, int last_try); STACK_OF(X509) *load_certs(const char *file, int format, const char *pass, ENGINE *e, const char *cert_descrip); diff --git a/apps/ca.c b/apps/ca.c index 4dc9176..8c03efd 100644 --- a/apps/ca.c +++ b/apps/ca.c @@ -587,7 +587,7 @@ end_of_options: goto end; } } - pkey = load_key(keyfile, keyformat, 0, key, e, "CA private key"); + pkey = load_key(keyfile, keyformat, 0, key, e, "CA private key", 1 /*last_try*/); if (key) OPENSSL_cleanse(key, strlen(key)); if (pkey == NULL) { diff --git a/apps/cms.c b/apps/cms.c index 7ccca5b..5966873 100644 --- a/apps/cms.c +++ b/apps/cms.c @@ -762,7 +762,7 @@ int cms_main(int argc, char **argv) keyfile = NULL; if (keyfile) { - key = load_key(keyfile, keyform, 0, passin, e, "signing key file"); + key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/); if (!key) goto end; } @@ -966,7 +966,7 @@ int cms_main(int argc, char **argv) e, "signer certificate"); if (!signer) goto end; - key = load_key(keyfile, keyform, 0, passin, e, "signing key file"); + key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/); if (!key) goto end; for (kparam = key_first; kparam; kparam = kparam->next) { diff --git a/apps/crl.c b/apps/crl.c index 17391e2..cc82ac2 100644 --- a/apps/crl.c +++ b/apps/crl.c @@ -266,7 +266,7 @@ int crl_main(int argc, char **argv) newcrl = load_crl(crldiff, informat); if (!newcrl) goto end; - pkey = load_key(keyfile, keyformat, 0, NULL, NULL, "CRL signing key"); + pkey = load_key(keyfile, keyformat, 0, NULL, NULL, "CRL signing key", 1 /*last_try*/); if (!pkey) { X509_CRL_free(newcrl); goto end; diff --git a/apps/dgst.c b/apps/dgst.c index 308555c..03f0f3f 100644 --- a/apps/dgst.c +++ b/apps/dgst.c @@ -286,9 +286,9 @@ int dgst_main(int argc, char **argv) if (keyfile) { if (want_pub) - sigkey = load_pubkey(keyfile, keyform, 0, NULL, e, "key file"); + sigkey = load_pubkey(keyfile, keyform, 0, NULL, e, "key file", 1 /*last_try*/); else - sigkey = load_key(keyfile, keyform, 0, passin, e, "key file"); + sigkey = load_key(keyfile, keyform, 0, passin, e, "key file", 1 /*last_try*/); if (!sigkey) { /* * load_[pub]key() has already printed an appropriate message diff --git a/apps/dsa.c b/apps/dsa.c index f02f293..34d8e0b 100644 --- a/apps/dsa.c +++ b/apps/dsa.c @@ -204,9 +204,9 @@ int dsa_main(int argc, char **argv) EVP_PKEY *pkey; if (pubin) - pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key"); + pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key", 1 /*last_try*/); else - pkey = load_key(infile, informat, 1, passin, e, "Private Key"); + pkey = load_key(infile, informat, 1, passin, e, "Private Key", 1 /*last_try*/); if (pkey) { dsa = EVP_PKEY_get1_DSA(pkey); diff --git a/apps/ocsp.c b/apps/ocsp.c index 4c3aa39..944b14c 100644 --- a/apps/ocsp.c +++ b/apps/ocsp.c @@ -528,7 +528,7 @@ int ocsp_main(int argc, char **argv) goto end; } rkey = load_key(rkeyfile, FORMAT_PEM, 0, NULL, NULL, - "responder private key"); + "responder private key", 1 /*last_try*/); if (!rkey) goto end; } @@ -573,7 +573,7 @@ int ocsp_main(int argc, char **argv) goto end; } key = load_key(keyfile, FORMAT_PEM, 0, NULL, NULL, - "signer private key"); + "signer private key", 1 /*last_try*/); if (!key) goto end; diff --git a/apps/pkcs12.c b/apps/pkcs12.c index 82131e8..b603794 100644 --- a/apps/pkcs12.c +++ b/apps/pkcs12.c @@ -386,7 +386,7 @@ int pkcs12_main(int argc, char **argv) if (!(options & NOKEYS)) { key = load_key(keyname ? keyname : infile, - FORMAT_PEM, 1, passin, e, "private key"); + FORMAT_PEM, 1, passin, e, "private key", 1 /*last_try*/); if (!key) goto export_end; } diff --git a/apps/pkcs8.c b/apps/pkcs8.c index f8a340e..ddc2062 100644 --- a/apps/pkcs8.c +++ b/apps/pkcs8.c @@ -236,7 +236,7 @@ int pkcs8_main(int argc, char **argv) if (out == NULL) goto end; if (topk8) { - pkey = load_key(infile, informat, 1, passin, e, "key"); + pkey = load_key(infile, informat, 1, passin, e, "key", 1 /*last_try*/); if (!pkey) goto end; if ((p8inf = EVP_PKEY2PKCS8_broken(pkey, p8_broken)) == NULL) { diff --git a/apps/pkey.c b/apps/pkey.c index 875087f..cde83ec 100644 --- a/apps/pkey.c +++ b/apps/pkey.c @@ -173,9 +173,9 @@ int pkey_main(int argc, char **argv) goto end; if (pubin) - pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key"); + pkey = load_pubkey(infile, informat, 1, passin, e, "Public Key", 1 /*last_try*/); else - pkey = load_key(infile, informat, 1, passin, e, "key"); + pkey = load_key(infile, informat, 1, passin, e, "key", 1 /*last_try*/); if (!pkey) goto end; diff --git a/apps/pkeyutl.c b/apps/pkeyutl.c index 4c267c1..d6c7e19 100644 --- a/apps/pkeyutl.c +++ b/apps/pkeyutl.c @@ -352,11 +352,11 @@ static EVP_PKEY_CTX *init_ctx(int *pkeysize, } switch (key_type) { case KEY_PRIVKEY: - pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key"); + pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key", 1 /*last_try*/); break; case KEY_PUBKEY: - pkey = load_pubkey(keyfile, keyform, 0, NULL, e, "Public Key"); + pkey = load_pubkey(keyfile, keyform, 0, NULL, e, "Public Key", 1 /*last_try*/); break; case KEY_CERT: @@ -427,7 +427,7 @@ static int setup_peer(EVP_PKEY_CTX *ctx, int peerform, const char *file) return 0; } - peer = load_pubkey(file, peerform, 0, NULL, NULL, "Peer Key"); + peer = load_pubkey(file, peerform, 0, NULL, NULL, "Peer Key", 1 /*last_try*/); if (!peer) { BIO_printf(bio_err, "Error reading peer key %s\n", file); diff --git a/apps/req.c b/apps/req.c index 3bae59e..dd3c629 100644 --- a/apps/req.c +++ b/apps/req.c @@ -481,7 +481,7 @@ int req_main(int argc, char **argv) } if (keyfile != NULL) { - pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key"); + pkey = load_key(keyfile, keyform, 0, passin, e, "Private Key", 1 /*last_try*/); if (!pkey) { /* load_key() has already printed an appropriate message */ goto end; diff --git a/apps/rsa.c b/apps/rsa.c index 87cb702..dae59f2 100644 --- a/apps/rsa.c +++ b/apps/rsa.c @@ -275,9 +275,9 @@ int rsa_main(int argc, char **argv) } else tmpformat = informat; - pkey = load_pubkey(infile, tmpformat, 1, passin, e, "Public Key"); + pkey = load_pubkey(infile, tmpformat, 1, passin, e, "Public Key", 1 /*last_try*/); } else - pkey = load_key(infile, informat, 1, passin, e, "Private Key"); + pkey = load_key(infile, informat, 1, passin, e, "Private Key", 1 /*last_try*/); if (pkey != NULL) rsa = EVP_PKEY_get1_RSA(pkey); diff --git a/apps/rsautl.c b/apps/rsautl.c index 8ba838b..9706923 100644 --- a/apps/rsautl.c +++ b/apps/rsautl.c @@ -120,7 +120,7 @@ int rsautl_main(int argc, char **argv) char *passinarg = NULL, *passin = NULL, *prog; char rsa_mode = RSA_VERIFY, key_type = KEY_PRIVKEY; unsigned char *rsa_in = NULL, *rsa_out = NULL, pad = RSA_PKCS1_PADDING; - int rsa_inlen, keyformat = FORMAT_PEM, keysize, ret = 1; + int rsa_inlen, keyformat = FORMAT_PEM, next_format, keysize, ret = 1; int rsa_outlen = 0, hexdump = 0, asn1parse = 0, need_priv = 0, rev = 0; OPTION_CHOICE o; @@ -217,16 +217,30 @@ int rsautl_main(int argc, char **argv) if (!app_load_modules(NULL)) goto end; -/* FIXME: seed PRNG only if needed */ + /* FIXME: seed PRNG only if needed */ app_RAND_load_file(NULL, 0); + + /* rsautl does not offer a way to specify just a public key. It requires a */ + /* subjectPublicKeyInfo, and there's no argument or option to switch to */ + /* the other type with either ASN.1/DER or PEM. This attempts to make an */ + /* intelligent retry. */ + if(keyformat == FORMAT_PEM) { + next_format = FORMAT_PEMRSA; + } if(keyformat == FORMAT_ASN1) { + next_format = FORMAT_ASN1RSA; + } else { + next_format = -1; + } switch (key_type) { case KEY_PRIVKEY: - pkey = load_key(keyfile, keyformat, 0, passin, e, "Private Key"); + pkey = load_key(keyfile, keyformat, 0, passin, e, "Private Key", 0 /*last_try*/); + if(!pkey && next_format != -1) { pkey = load_key(keyfile, next_format, 0, passin, e, "Private Key", 1 /*last_try*/); } break; case KEY_PUBKEY: - pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public Key"); + pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public Key", 0 /*last_try*/); + if(!pkey && next_format != -1) { pkey = load_pubkey(keyfile, next_format, 0, NULL, e, "Public Key", 1 /*last_try*/); } break; case KEY_CERT: diff --git a/apps/s_cb.c b/apps/s_cb.c index 35366c5..10e6c0a 100644 --- a/apps/s_cb.c +++ b/apps/s_cb.c @@ -1050,10 +1050,10 @@ int load_excert(SSL_EXCERT **pexc) return 0; if (exc->keyfile) { exc->key = load_key(exc->keyfile, exc->keyform, - 0, NULL, NULL, "Server Key"); + 0, NULL, NULL, "Server Key", 1 /*last_try*/); } else { exc->key = load_key(exc->certfile, exc->certform, - 0, NULL, NULL, "Server Key"); + 0, NULL, NULL, "Server Key", 1 /*last_try*/); } if (!exc->key) return 0; diff --git a/apps/s_client.c b/apps/s_client.c index 009e5fe..85a9e39 100644 --- a/apps/s_client.c +++ b/apps/s_client.c @@ -1112,7 +1112,7 @@ int s_client_main(int argc, char **argv) if (key_file) { key = load_key(key_file, key_format, 0, pass, e, - "client certificate private key file"); + "client certificate private key file", 1 /*last_try*/); if (key == NULL) { ERR_print_errors(bio_err); goto end; diff --git a/apps/s_server.c b/apps/s_server.c index 189019d..3469add 100644 --- a/apps/s_server.c +++ b/apps/s_server.c @@ -1452,7 +1452,7 @@ int s_server_main(int argc, char *argv[]) if (nocert == 0) { s_key = load_key(s_key_file, s_key_format, 0, pass, e, - "server certificate private key file"); + "server certificate private key file", 1 /*last_try*/); if (!s_key) { ERR_print_errors(bio_err); goto end; @@ -1474,7 +1474,7 @@ int s_server_main(int argc, char *argv[]) if (tlsextcbp.servername) { s_key2 = load_key(s_key_file2, s_key_format, 0, pass, e, - "second server certificate private key file"); + "second server certificate private key file", 1 /*last_try*/); if (!s_key2) { ERR_print_errors(bio_err); goto end; @@ -1532,7 +1532,7 @@ int s_server_main(int argc, char *argv[]) s_dkey_file = s_dcert_file; s_dkey = load_key(s_dkey_file, s_dkey_format, - 0, dpass, e, "second certificate private key file"); + 0, dpass, e, "second certificate private key file", 1 /*last_try*/); if (!s_dkey) { ERR_print_errors(bio_err); goto end; diff --git a/apps/smime.c b/apps/smime.c index 45898de..f74105f 100644 --- a/apps/smime.c +++ b/apps/smime.c @@ -491,7 +491,7 @@ int smime_main(int argc, char **argv) keyfile = NULL; if (keyfile) { - key = load_key(keyfile, keyform, 0, passin, e, "signing key file"); + key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/); if (!key) goto end; } @@ -574,7 +574,7 @@ int smime_main(int argc, char **argv) e, "signer certificate"); if (!signer) goto end; - key = load_key(keyfile, keyform, 0, passin, e, "signing key file"); + key = load_key(keyfile, keyform, 0, passin, e, "signing key file", 1 /*last_try*/); if (!key) goto end; if (!PKCS7_sign_add_signer(p7, signer, key, sign_md, flags)) diff --git a/apps/spkac.c b/apps/spkac.c index d41331c..72f8b3a 100644 --- a/apps/spkac.c +++ b/apps/spkac.c @@ -163,7 +163,7 @@ int spkac_main(int argc, char **argv) if (keyfile) { pkey = load_key(strcmp(keyfile, "-") ? keyfile : NULL, - FORMAT_PEM, 1, passin, e, "private key"); + FORMAT_PEM, 1, passin, e, "private key", 1 /*last_try*/); if (!pkey) { goto end; } diff --git a/apps/x509.c b/apps/x509.c index 77a2a6b..0c7a810 100644 --- a/apps/x509.c +++ b/apps/x509.c @@ -510,7 +510,7 @@ int x509_main(int argc, char **argv) } if (fkeyfile) { - fkey = load_pubkey(fkeyfile, keyformat, 0, NULL, e, "Forced key"); + fkey = load_pubkey(fkeyfile, keyformat, 0, NULL, e, "Forced key", 1 /*last_try*/); if (fkey == NULL) goto end; } @@ -823,7 +823,7 @@ int x509_main(int argc, char **argv) BIO_printf(bio_err, "Getting Private key\n"); if (Upkey == NULL) { Upkey = load_key(keyfile, keyformat, 0, - passin, e, "Private key"); + passin, e, "Private key", 1 /*last_try*/); if (Upkey == NULL) goto end; } @@ -835,7 +835,7 @@ int x509_main(int argc, char **argv) BIO_printf(bio_err, "Getting CA Private Key\n"); if (CAkeyfile != NULL) { CApkey = load_key(CAkeyfile, CAkeyformat, - 0, passin, e, "CA Private Key"); + 0, passin, e, "CA Private Key", 1 /*last_try*/); if (CApkey == NULL) goto end; } @@ -855,7 +855,7 @@ int x509_main(int argc, char **argv) goto end; } else { pk = load_key(keyfile, keyformat, 0, - passin, e, "request key"); + passin, e, "request key", 1 /*last_try*/); if (pk == NULL) goto end; } From rt at openssl.org Sun May 31 13:27:23 2015 From: rt at openssl.org (Salz, Rich via RT) Date: Sun, 31 May 2015 15:27:23 +0200 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com> References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> <20150531060603.GX2342@mournblade.imrryr.org> <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com> Message-ID: > > (Documentation is in the source files, not a .pod) > > Do you have code to produce usable manpages from the embedded > documentation? We can't ask users to read the source. I believe Todd meant for the test program. > * The copyright notice does not refer to any license that would allow > inclusion in OpenSSL. Sigh. We'll fix that to just submit with the akamai copyright and openssl license. From tshort at akamai.com Sun May 31 13:31:31 2015 From: tshort at akamai.com (Short, Todd) Date: Sun, 31 May 2015 13:31:31 +0000 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> <20150531060603.GX2342@mournblade.imrryr.org> <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>, Message-ID: <2962ADAC-4338-456B-AB99-434F74267B86@akamai.com> Many of the changes Akamai has did not include proper documentation. I have noted these and will send updated patches when done. I will also update the copyrights. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 9:27 AM, Salz, Rich via RT wrote: > > >>> (Documentation is in the source files, not a .pod) >> >> Do you have code to produce usable manpages from the embedded >> documentation? We can't ask users to read the source. > > I believe Todd meant for the test program. > > >> * The copyright notice does not refer to any license that would allow >> inclusion in OpenSSL. > > Sigh. We'll fix that to just submit with the akamai copyright and openssl license. > > > From rt at openssl.org Sun May 31 13:32:10 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sun, 31 May 2015 15:32:10 +0200 Subject: [openssl-dev] [openssl.org #3883] [PATCH] Add IPv4/IPv6:port-based client cache In-Reply-To: <2962ADAC-4338-456B-AB99-434F74267B86@akamai.com> References: <119586B5-9754-4E3A-9DDB-D299F5987DAA@akamai.com> <20150531060603.GX2342@mournblade.imrryr.org> <0864f22a33284fb0accd6b3b582aac32@ustx2ex-dag1mb2.msg.corp.akamai.com>, <2962ADAC-4338-456B-AB99-434F74267B86@akamai.com> Message-ID: Many of the changes Akamai has did not include proper documentation. I have noted these and will send updated patches when done. I will also update the copyrights. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 9:27 AM, Salz, Rich via RT wrote: > > >>> (Documentation is in the source files, not a .pod) >> >> Do you have code to produce usable manpages from the embedded >> documentation? We can't ask users to read the source. > > I believe Todd meant for the test program. > > >> * The copyright notice does not refer to any license that would allow >> inclusion in OpenSSL. > > Sigh. We'll fix that to just submit with the akamai copyright and openssl license. > > > From rt at openssl.org Sun May 31 16:27:46 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 31 May 2015 18:27:46 +0200 Subject: [openssl-dev] [openssl.org #3887] PATCH: rsautl and intelligent retry for Public Key parse after Traditional/Subject Public Key Info parse fails In-Reply-To: References: Message-ID: Nice idea, I'm however thinking that much of the trying different formats could be moved to load_key / load_pubkey, all that would be needed is a keyformat denoting "try anything". -1, perhaps? On Sun May 31 09:46:28 2015, noloader at gmail.com wrote: > apps.c has a couple of parsing routines called load_pubkey and > load_key. rsautl uses those routines. > > However, there's no option in rsautil to use anything other than a > ASN.1/DER or PEM encoded traditional key (or subject public key info). > The code paths are present, we just can't seem to get to them. > > Folks in the field have problem with it on occasion. See, for example, > "Can't load programmatically generated public key," > http://stackoverflow.com/q/30547646. > > This patch adds an intelligent fallback: > > /* rsautl does not offer a way to specify just a public key. It > requires a */ > /* subjectPublicKeyInfo, and there's no argument or option to > switch to */ > /* the other type with either ASN.1/DER or PEM. This attempts to > make an */ > /* intelligent retry. */ > if(keyformat == FORMAT_PEM) { > next_format = FORMAT_PEMRSA; > } if(keyformat == FORMAT_ASN1) { > next_format = FORMAT_ASN1RSA; > } else { > next_format = -1; > } > > switch (key_type) { > case KEY_PRIVKEY: > pkey = load_key(keyfile, keyformat, 0, passin, e, "Private > Key", 0 /*last_try*/); > if(!pkey && next_format != -1) { pkey = load_key(keyfile, > next_format, 0, passin, e, "Private Key", 1 /*last_try*/); } > break; > > case KEY_PUBKEY: > pkey = load_pubkey(keyfile, keyformat, 0, NULL, e, "Public > Key", 0 /*last_try*/); > if(!pkey && next_format != -1) { pkey = load_pubkey(keyfile, > next_format, 0, NULL, e, "Public Key", 1 /*last_try*/); } > break; > > Then, functions load_key and load_pubkey suppress the error messages > if last_try is 0: > > if (pkey == NULL && last_try) { > BIO_printf(bio_err, "unable to load %s\n", key_descrip); > } > > All in all, existing behavior and error messages are maintained. The > subcommand is just a little more robust. > > Related, we might be able to make similar changes to rsa.c. But > there's some extra special sauce present, so it was not a clear > cut-in. I think the special sauce kid of attempts to do the same thing > as above. (Maybe this patch should act more like rsa.c?) -- Richard Levitte levitte at openssl.org From rt at openssl.org Sun May 31 16:43:24 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 31 May 2015 18:43:24 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: Message-ID: You solution does the following: if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { (void)lh_SSL_SESSION_delete(p->cache, s); ... Would you agree that the following does the same? if (lh_SSL_SESSION_delete(p->cache, s) == s) { ... On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: > Hello OpenSSL Org: > > This is a change that Akamai has made to its > implementation of OpenSSL. > > Version: master branch > Description: > lh_SSL_SESSION_delete() not checked > > Fix an OpenSSL issue where the > return code of lh_SSL_SESSION_delete() > is not checked, causing a > stale reference in the lhash. > > Github link: > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc > And attachment. > > Thank you. > -- > -Todd Short > // tshort at akamai.com > // ?One if by land, two if by sea, three if by the Internet.? -- Richard Levitte levitte at openssl.org From rt at openssl.org Sun May 31 16:59:26 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 31 May 2015 18:59:26 +0200 Subject: [openssl-dev] [openssl.org #3864] OS390 Bug: Make fails In-Reply-To: References: Message-ID: It's unclear to me what needs to change. Would you mind helping us figure it out? On Tue May 26 20:06:21 2015, rhidalgo at indra.es wrote: > Make Output (tail ): > > >>> Makefile: line 206: Defined macro CLEARENV=TOP= && unset TOP > $${LIB+LIB} $${LIBS+LIBS} $${INCLUDE+INCLUDE} > $${INCLUDES+INCLUDES} $${DIR+DIR} $${DIRS+DIRS} $${SRC+SRC} > $${LIBSRC+LIBSRC} $${LIBOBJ+LIBOBJ} $${ALL+ALL} > $${EXHEADER+EXHEADER} $${HEADER+HEADER} > $${GENERAL+GENERAL} $${CFLAGS+CFLAGS} $${ASFLAGS+ASFLAGS} > $${AFLAGS+AFLAGS} $${LDCMD+LDCMD} $${LDFLAGS+LDFLAGS} > $${SCRIPTS+SCRIPTS} $${SHAREDCMD+SHAREDCMD} > $${SHAREDFLAGS+SHAREDFLAGS} $${SHARED_LIB+SHARED_LIB} > $${LIBEXTRAS+LIBEXTRAS} > >>> Makefile: line 242: Defined macro BUILDENV=PLATFORM='$(PLATFORM)' > PROCESSOR='$(PROCESSOR)' CC='$(CC)' CFLAG='$(CFLAG)' > AS='$(CC)' ASFLAG='$(CFLAG) -c' AR='$(AR)' > NM='$(NM)' RANLIB='$(RANLIB)' > CROSS_COMPILE='$(CROSS_COMPILE)' PERL='$(PERL)' > ENGDIRS='$(ENGDIRS)' SDIRS='$(SDIRS)' > LIBRPATH='$(INSTALLTOP)/$(LIBDIR)' > INSTALL_PREFIX='$(INSTALL_PREFIX)' > INSTALLTOP='$(INSTALLTOP)' OPENSSLDIR='$(OPENSSLDIR)' > LIBDIR='$(LIBDIR)' > MAKEDEPEND='$$$${TOP}/util/domd $$$${TOP} -MD $(MAKEDEPPROG)' > DEPFLAG='-DOPENSSL_NO_DEPRECATED $(DEPFLAG)' > MAKEDEPPROG='$(MAKEDEPPROG)' > SHARED_LDFLAGS='$(SHARED_LDFLAGS)' > KRB5_INCLUDES='$(KRB5_INCLUDES)' LIBKRB5='$(LIBKRB5)' > ZLIB_INCLUDE='$(ZLIB_INCLUDE)' LIBZLIB='$(LIBZLIB)' > EXE_EXT='$(EXE_EXT)' SHARED_LIBS='$(SHARED_LIBS)' > SHLIB_EXT='$(SHLIB_EXT)' SHLIB_TARGET='$(SHLIB_TARGET)' > PEX_LIBS='$(PEX_LIBS)' EX_LIBS='$(EX_LIBS)' > CPUID_OBJ='$(CPUID_OBJ)' BN_ASM='$(BN_ASM)' EC_ASM='$(EC_ASM)' > DES_ENC='$(DES_ENC)' AES_ENC='$(AES_ENC)' > CMLL_ENC='$(CMLL_ENC)' BF_ENC='$(BF_ENC)' CAST_ENC='$(CAST_ENC)' > RC4_ENC='$(RC4_ENC)' RC5_ENC='$(RC5_ENC)' > SHA1_ASM_OBJ='$(SHA1_ASM_OBJ)' > MD5_ASM_OBJ='$(MD5_ASM_OBJ)' > RMD160_ASM_OBJ='$(RMD160_ASM_OBJ)' > WP_ASM_OBJ='$(WP_ASM_OBJ)' > MODES_ASM_OBJ='$(MODES_ASM_OBJ)' > ENGINES_ASM_OBJ='$(ENGINES_ASM_OBJ)' > PERLASM_SCHEME='$(PERLASM_SCHEME)' > FIPSLIBDIR='${FIPSLIBDIR}' > FIPSDIR='${FIPSDIR}' FIPSCANLIB="$${FIPSCANLIB:-$(FIPSCANLIB)}" > THIS=$${THIS:-$@} MAKEFILE=Makefile MAKEOVERRIDES= > >>> Makefile: line 264: Defined macro BUILD_CMD=if [ -d "$$dir" ]; > then ( cd $$dir && echo "making $$target in $$dir..." && > $(CLEARENV) && $(MAKE) -e $(BUILDENV) TOP=.. DIR=$$dir $$target ) > || exit 1; fi > >>> Makefile: line 266: Defined macro RECURSIVE_BUILD_CMD=for dir in > $(DIRS); do $(BUILD_CMD); done > >>> Makefile: line 267: Defined macro BUILD_ONE_CMD=if expr " $(DIRS) > " : ".* $$dir " >/dev/null 2>&1; then $(BUILD_CMD); fi > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in > target list > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [&&] in > target list > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [-O] in > target list > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [- > DB_ENDIAN] in target list > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [- > DCHARSET_EBCDIC] in target list > make: Makefile: line 270: Warning -- FSUM9432 Duplicate entry [- > DNO_SYS_PARAM_H] in target list > >>> Defined macro INCDEPTH=0 > make: Error -- FSUM8229 Incomplete rule recipe group detected > > Operating System : OS3090-Unix == zOS 1.13 > > Open SSL 1.02a, from openssl-1.0.2a.tar untared with : pax -rf > openssl-1.0.2a.tar -ofrom=ISO8859-1,to=IBM-1047 > > > ________________________________ > Este correo electr?nico y, en su caso, cualquier fichero anexo al > mismo, contiene informaci?n de car?cter confidencial exclusivamente > dirigida a su destinatario o destinatarios. Si no es vd. el > destinatario indicado, queda notificado que la lectura, > utilizaci?n, divulgaci?n y/o copia sin autorizaci?n est? prohibida > en virtud de la legislaci?n vigente. En el caso de haber recibido > este correo electr?nico por error, se ruega notificar > inmediatamente esta circunstancia mediante reenv?o a la direcci?n > electr?nica del remitente. > Evite imprimir este mensaje si no es estrictamente necesario. > > This email and any file attached to it (when applicable) contain(s) > confidential information that is exclusively addressed to its > recipient(s). If you are not the indicated recipient, you are > informed that reading, using, disseminating and/or copying it > without authorisation is forbidden in accordance with the > legislation in effect. If you have received this email by mistake, > please immediately notify the sender of the situation by resending > it to their email address. > Avoid printing this message if it is not absolutely necessary. -- Richard Levitte levitte at openssl.org From tshort at akamai.com Sun May 31 19:23:18 2015 From: tshort at akamai.com (Short, Todd) Date: Sun, 31 May 2015 19:23:18 +0000 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: , Message-ID: <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> No, The second code sample removes a matching instance, but not necessarily the same instance. If they are not the same instance, then it would need to be re-inserted in and else clause. This is a fine distinction. This would leave to having the list and hash not contain the same contents: Either the number of items is different, or the two sets of items are different. There's a similar example in the code, I believe, but I'd have to search for it. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 12:43 PM, Richard Levitte via RT wrote: > > You solution does the following: > > if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { > (void)lh_SSL_SESSION_delete(p->cache, s); > ... > > Would you agree that the following does the same? > > if (lh_SSL_SESSION_delete(p->cache, s) == s) { > ... > > >> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: >> Hello OpenSSL Org: >> >> This is a change that Akamai has made to its >> implementation of OpenSSL. >> >> Version: master branch >> Description: >> lh_SSL_SESSION_delete() not checked >> >> Fix an OpenSSL issue where the >> return code of lh_SSL_SESSION_delete() >> is not checked, causing a >> stale reference in the lhash. >> >> Github link: > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc >> And attachment. >> >> Thank you. >> -- >> -Todd Short >> // tshort at akamai.com >> // ?One if by land, two if by sea, three if by the Internet.? > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Sun May 31 19:24:07 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sun, 31 May 2015 21:24:07 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> References: , <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> Message-ID: No, The second code sample removes a matching instance, but not necessarily the same instance. If they are not the same instance, then it would need to be re-inserted in and else clause. This is a fine distinction. This would leave to having the list and hash not contain the same contents: Either the number of items is different, or the two sets of items are different. There's a similar example in the code, I believe, but I'd have to search for it. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 12:43 PM, Richard Levitte via RT wrote: > > You solution does the following: > > if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { > (void)lh_SSL_SESSION_delete(p->cache, s); > ... > > Would you agree that the following does the same? > > if (lh_SSL_SESSION_delete(p->cache, s) == s) { > ... > > >> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: >> Hello OpenSSL Org: >> >> This is a change that Akamai has made to its >> implementation of OpenSSL. >> >> Version: master branch >> Description: >> lh_SSL_SESSION_delete() not checked >> >> Fix an OpenSSL issue where the >> return code of lh_SSL_SESSION_delete() >> is not checked, causing a >> stale reference in the lhash. >> >> Github link: > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc >> And attachment. >> >> Thank you. >> -- >> -Todd Short >> // tshort at akamai.com >> // ?One if by land, two if by sea, three if by the Internet.? > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Sun May 31 20:22:42 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 31 May 2015 22:22:42 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: , <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> Message-ID: I'm not sure how that can happen, as each SSL_SESSION in that lhash will have unique content. This is assured by the way lh_insert functions and by ssl_session_cmp (which gets called by getrn in lhash.c, via the function pointer cf). So while your suggestion will most probably work as a band aid, I'm thinking you've really found a bug in ssl_session_cmp or in the lhash code itself. Could you verify? On Sun May 31 21:24:04 2015, tshort at akamai.com wrote: > No, > > The second code sample removes a matching instance, but not > necessarily the same instance. If they are not the same instance, then > it would need to be re-inserted in and else clause. > > This is a fine distinction. > > This would leave to having the list and hash not contain the same > contents: Either the number of items is different, or the two sets of > items are different. > > There's a similar example in the code, I believe, but I'd have to > search for it. > > -- > -Todd Short > // tshort at akamai.com > // Sent from my iPhone > // "One if by land, two if by sea, three if by the Internet." > > > > On May 31, 2015, at 12:43 PM, Richard Levitte via RT > wrote: > > > > You solution does the following: > > > > if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { > > (void)lh_SSL_SESSION_delete(p->cache, s); > > ... > > > > Would you agree that the following does the same? > > > > if (lh_SSL_SESSION_delete(p->cache, s) == s) { > > ... > > > > > >> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: > >> Hello OpenSSL Org: > >> > >> This is a change that Akamai has made to its > >> implementation of OpenSSL. > >> > >> Version: master branch > >> Description: > >> lh_SSL_SESSION_delete() not checked > >> > >> Fix an OpenSSL issue where the > >> return code of lh_SSL_SESSION_delete() > >> is not checked, causing a > >> stale reference in the lhash. > >> > >> Github link: > > > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc > >> And attachment. > >> > >> Thank you. > >> -- > >> -Todd Short > >> // tshort at akamai.com > >> // ?One if by land, two if by sea, three if by the Internet.? > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- Richard Levitte levitte at openssl.org From tshort at akamai.com Sun May 31 20:27:44 2015 From: tshort at akamai.com (Short, Todd) Date: Sun, 31 May 2015 20:27:44 +0000 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: , <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> , Message-ID: <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com> We (Akamai) had a bad session compare function at one point; the compare was fixed, but also added this change to protect the LHASH. So, yes, this can only really happen if one has a bad comparison function. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 4:22 PM, Richard Levitte via RT wrote: > > I'm not sure how that can happen, as each SSL_SESSION in that lhash will have > unique content. This is assured by the way lh_insert functions and by > ssl_session_cmp (which gets called by getrn in lhash.c, via the function > pointer cf). > > So while your suggestion will most probably work as a band aid, I'm thinking > you've really found a bug in ssl_session_cmp or in the lhash code itself. Could > you verify? > >> On Sun May 31 21:24:04 2015, tshort at akamai.com wrote: >> No, >> >> The second code sample removes a matching instance, but not >> necessarily the same instance. If they are not the same instance, then >> it would need to be re-inserted in and else clause. >> >> This is a fine distinction. >> >> This would leave to having the list and hash not contain the same >> contents: Either the number of items is different, or the two sets of >> items are different. >> >> There's a similar example in the code, I believe, but I'd have to >> search for it. >> >> -- >> -Todd Short >> // tshort at akamai.com >> // Sent from my iPhone >> // "One if by land, two if by sea, three if by the Internet." >> >> >>>> On May 31, 2015, at 12:43 PM, Richard Levitte via RT >>> wrote: >>> >>> You solution does the following: >>> >>> if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { >>> (void)lh_SSL_SESSION_delete(p->cache, s); >>> ... >>> >>> Would you agree that the following does the same? >>> >>> if (lh_SSL_SESSION_delete(p->cache, s) == s) { >>> ... >>> >>> >>>> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: >>>> Hello OpenSSL Org: >>>> >>>> This is a change that Akamai has made to its >>>> implementation of OpenSSL. >>>> >>>> Version: master branch >>>> Description: >>>> lh_SSL_SESSION_delete() not checked >>>> >>>> Fix an OpenSSL issue where the >>>> return code of lh_SSL_SESSION_delete() >>>> is not checked, causing a >>>> stale reference in the lhash. >>>> >>>> Github link: > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc >>>> And attachment. >>>> >>>> Thank you. >>>> -- >>>> -Todd Short >>>> // tshort at akamai.com >>>> // ?One if by land, two if by sea, three if by the Internet.? >>> >>> >>> -- >>> Richard Levitte >>> levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Sun May 31 20:28:20 2015 From: rt at openssl.org (Short, Todd via RT) Date: Sun, 31 May 2015 22:28:20 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com> References: , <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> , <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com> Message-ID: We (Akamai) had a bad session compare function at one point; the compare was fixed, but also added this change to protect the LHASH. So, yes, this can only really happen if one has a bad comparison function. -- -Todd Short // tshort at akamai.com // Sent from my iPhone // "One if by land, two if by sea, three if by the Internet." > On May 31, 2015, at 4:22 PM, Richard Levitte via RT wrote: > > I'm not sure how that can happen, as each SSL_SESSION in that lhash will have > unique content. This is assured by the way lh_insert functions and by > ssl_session_cmp (which gets called by getrn in lhash.c, via the function > pointer cf). > > So while your suggestion will most probably work as a band aid, I'm thinking > you've really found a bug in ssl_session_cmp or in the lhash code itself. Could > you verify? > >> On Sun May 31 21:24:04 2015, tshort at akamai.com wrote: >> No, >> >> The second code sample removes a matching instance, but not >> necessarily the same instance. If they are not the same instance, then >> it would need to be re-inserted in and else clause. >> >> This is a fine distinction. >> >> This would leave to having the list and hash not contain the same >> contents: Either the number of items is different, or the two sets of >> items are different. >> >> There's a similar example in the code, I believe, but I'd have to >> search for it. >> >> -- >> -Todd Short >> // tshort at akamai.com >> // Sent from my iPhone >> // "One if by land, two if by sea, three if by the Internet." >> >> >>>> On May 31, 2015, at 12:43 PM, Richard Levitte via RT >>> wrote: >>> >>> You solution does the following: >>> >>> if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { >>> (void)lh_SSL_SESSION_delete(p->cache, s); >>> ... >>> >>> Would you agree that the following does the same? >>> >>> if (lh_SSL_SESSION_delete(p->cache, s) == s) { >>> ... >>> >>> >>>> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: >>>> Hello OpenSSL Org: >>>> >>>> This is a change that Akamai has made to its >>>> implementation of OpenSSL. >>>> >>>> Version: master branch >>>> Description: >>>> lh_SSL_SESSION_delete() not checked >>>> >>>> Fix an OpenSSL issue where the >>>> return code of lh_SSL_SESSION_delete() >>>> is not checked, causing a >>>> stale reference in the lhash. >>>> >>>> Github link: > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc >>>> And attachment. >>>> >>>> Thank you. >>>> -- >>>> -Todd Short >>>> // tshort at akamai.com >>>> // ?One if by land, two if by sea, three if by the Internet.? >>> >>> >>> -- >>> Richard Levitte >>> levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org > From rt at openssl.org Sun May 31 20:46:18 2015 From: rt at openssl.org (Richard Levitte via RT) Date: Sun, 31 May 2015 22:46:18 +0200 Subject: [openssl-dev] [openssl.org #3882] [BUGFIX] lh_SSL_SESSION_delete() not checked In-Reply-To: References: , <2F6A132B-AA16-4F31-A1B7-C81315C02465@akamai.com> , <4D06E1D9-072B-4824-8753-D6A1E17D6C84@akamai.com> Message-ID: Hmm, but does it? If you look for the comment '/* We *are* in trouble ... */' in ssl_sess.c, you'll see that there is a similar kind of protection in place already at the time of insert. So quite frankly and with all respect, I'm not sure if this particular fix does anything of value any longer. On Sun May 31 22:28:18 2015, tshort at akamai.com wrote: > We (Akamai) had a bad session compare function at one point; the > compare was fixed, but also added this change to protect the LHASH. > > So, yes, this can only really happen if one has a bad comparison > function. > > -- > -Todd Short > // tshort at akamai.com > // Sent from my iPhone > // "One if by land, two if by sea, three if by the Internet." > > > > On May 31, 2015, at 4:22 PM, Richard Levitte via RT > wrote: > > > > I'm not sure how that can happen, as each SSL_SESSION in that lhash > will have > > unique content. This is assured by the way lh_insert functions and > by > > ssl_session_cmp (which gets called by getrn in lhash.c, via the > function > > pointer cf). > > > > So while your suggestion will most probably work as a band aid, I'm > thinking > > you've really found a bug in ssl_session_cmp or in the lhash code > itself. Could > > you verify? > > > >> On Sun May 31 21:24:04 2015, tshort at akamai.com wrote: > >> No, > >> > >> The second code sample removes a matching instance, but not > >> necessarily the same instance. If they are not the same instance, > then > >> it would need to be re-inserted in and else clause. > >> > >> This is a fine distinction. > >> > >> This would leave to having the list and hash not contain the same > >> contents: Either the number of items is different, or the two sets > of > >> items are different. > >> > >> There's a similar example in the code, I believe, but I'd have to > >> search for it. > >> > >> -- > >> -Todd Short > >> // tshort at akamai.com > >> // Sent from my iPhone > >> // "One if by land, two if by sea, three if by the Internet." > >> > >> > >>>> On May 31, 2015, at 12:43 PM, Richard Levitte via RT > >>> wrote: > >>> > >>> You solution does the following: > >>> > >>> if (lh_SSL_SESSION_retrieve(p->cache, s) == s) { > >>> (void)lh_SSL_SESSION_delete(p->cache, s); > >>> ... > >>> > >>> Would you agree that the following does the same? > >>> > >>> if (lh_SSL_SESSION_delete(p->cache, s) == s) { > >>> ... > >>> > >>> > >>>> On Sat May 30 09:48:06 2015, tshort at akamai.com wrote: > >>>> Hello OpenSSL Org: > >>>> > >>>> This is a change that Akamai has made to its > >>>> implementation of OpenSSL. > >>>> > >>>> Version: master branch > >>>> Description: > >>>> lh_SSL_SESSION_delete() not checked > >>>> > >>>> Fix an OpenSSL issue where the > >>>> return code of lh_SSL_SESSION_delete() > >>>> is not checked, causing a > >>>> stale reference in the lhash. > >>>> > >>>> Github link: > > > https://github.com/akamai/openssl/commit/3a114c2f0e3bf241732fef7a2d339a230ca68abc > >>>> And attachment. > >>>> > >>>> Thank you. > >>>> -- > >>>> -Todd Short > >>>> // tshort at akamai.com > >>>> // ?One if by land, two if by sea, three if by the Internet.? > >>> > >>> > >>> -- > >>> Richard Levitte > >>> levitte at openssl.org > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- Richard Levitte levitte at openssl.org