From rt at openssl.org Thu Sep 1 10:08:47 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Thu, 01 Sep 2016 10:08:47 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C7FDC9.8040800@atos.net> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> Message-ID: Hi Richard, Here are more information. I'm using two AIX 6.1 machines. I built openssl 1.0.1* and 1.0.2* on first machine, compiled with GCC & -O . I moved to second machine for 1.1.0 . I have rebuilt/tested 1.0.2h , still with GCC & -O (same .spec file), on the second machine and I got the same results than on machine 1 (which has different AIX 6.1 details and different XLC 12.1.0 sub-versions than the other machine. See below). On machine 2, once I had built valid RPMs of openssl 1.1.0, I have installed them on the machine so that I'm sure that tests are done with the current version (sometimes, some packages make use of installed stuff, like .h or .a files). However, I've made local experiments and I've checked that only/simply locally compiling ppccap.o with -O and then with -O0 (and rebuilding the libcrypto.so and libcrypto.a that are used when testing by end) DOES trigger the test error or not. First, I've noticed some changes between 1.0.2h and 1.1.0 . - One notable change deals with the AIX targets for Configure: - 1.0.2h : aix-gcc aix-xlc_r aix3-cc aix64-gcc aix64-xlc_r - 1.1.0 : aix-cc aix-gcc aix64-cc aix64-gcc So, for 1.0.2h and XLC, I used aix-xlc_r & aix64-xlc_r . And, for 1.1.0 and XLC, I'm using aix-cc & aix64-cc . I have no idea about the impact. - Another change deals with the tests, which have a different output. - Machine 1 (hardy1) # oslevel -s 6100-07-10-1415 # xlc -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0016 # gcc --version gcc (GCC) 4.8.4 - Machine 2 (castor1) # oslevel -s 6100-09-03-1415 # xlc -qversion IBM XL C/C++ for AIX, V12.1 (5765-J02, 5725-C72) Version: 12.01.0000.0014 # gcc --version gcc (GCC) 6.2.0 Results: In short: - no issue with v1.0.2h on both machines - issue appears with: - XLC -O but only for 64bits - GCC -O for both 64bits and 32bits - issue disappears when building ppccap.c with -O0 . So, I think that the probability that both XLC and GCC have an issue when optimizing ppccap.c is very low. So, I guess that ppccap.c has something special. Further experimentations could be: - still on machine2 : - use XLC v13 instead of v12 - use GCC v4.8.4 instead of v6.2.0 . - maybe redo all on machine1, if needed. Details: 1) openssl v1.0.2h with XLC and -O for all C source code. Machine 1 & Machine 2 - 64bit: /usr/vac/bin/xlc_r -I. -I.. -I../include -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_ALLOW_ADH -q64 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o ppccap.o ppccap.c # grep SUCCESSFUL $SPECS/openssl-1.0.2h-2.spec.res4.TESTS-64 ALL TESTS SUCCESSFUL. ALL OCSP TESTS SUCCESSFUL # cd 64bit/test # ../util/shlib_wrap.sh ./evp_test evptests.txt ... # echo $? 0 - 32bit: /usr/vac/bin/xlc_r -I. -I.. -I../include -DZLIB_SHARED -DZLIB -DOPENSSL_THREADS -qthreaded -D_THREAD_SAFE -DDSO_DLFCN -DHAVE_DLFCN_H -DSSL_ALLOW_ADH -q32 -O -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -c -o ppccap.o ppccap.c # grep SUCCESSFUL $SPECS/openssl-1.0.2h-2.spec.res4.TESTS-32 ALL TESTS SUCCESSFUL. ALL OCSP TESTS SUCCESSFUL # cd 32bit/test # ../util/shlib_wrap.sh ./evp_test evptests.txt ... # echo $? 0 2) openssl v1.1.0 with XLC and -O for all C source code. Machine 2 - 64bit: xlc_r -q64 -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -DPOLY1305_ASM -DSSL_ALLOW_ADH -DOPENSSLDIR="\"/var/ssl/64\"" -DENGINESDIR="\"/opt/freeware/lib/engines-1.1\"" -q64 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -O -qthreaded -D_THREAD_SAFE -c -o crypto/ppccap.o crypto/ppccap.c "crypto/ppccap.c", line 123.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const unsigned char*,unsigned long,unsigned int)" is not allowed. "crypto/ppccap.c", line 124.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,unsigned char*,const unsigned int*)" is not allowed. "crypto/ppccap.c", line 127.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const unsigned char*,unsigned long,unsigned int)" is not allowed. "crypto/ppccap.c", line 128.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,unsigned char*,const unsigned int*)" is not allowed. # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests - 32bit: xlc_r -q32 -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -DPOLY1305_ASM -DSSL_ALLOW_ADH -DOPENSSLDIR="\"/var/ssl\"" -DENGINESDIR="\"/opt/freeware/lib/engines-1.1\"" -q32 -DB_ENDIAN -qmaxmem=16384 -qro -qroconst -O -qthreaded -D_THREAD_SAFE -c -o crypto/ppccap.o crypto/ppccap.c "crypto/ppccap.c", line 123.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const unsigned char*,unsigned long,unsigned int)" is not allowed. "crypto/ppccap.c", line 124.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,unsigned char*,const unsigned int*)" is not allowed. "crypto/ppccap.c", line 127.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,const unsigned char*,unsigned long,unsigned int)" is not allowed. "crypto/ppccap.c", line 128.17: 1506-068 (W) Operation between types "void*" and "void(*)(void*,unsigned char*,const unsigned int*)" is not allowed. ../test/recipes/30-test_evp.t .............. ok 3) openssl v1.1.0 with GCC and -O for all C source code. Machine 2 - 64bit: gcc -maix64 -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -DPOLY1305_ASM -DSSL_ALLOW_ADH -DOPENSSLDIR="\"/var/ssl/64\"" -DENGINESDIR="\"/opt/freeware/lib/engines-1.1\"" -maix64 -DB_ENDIAN -O -pthread -MMD -MF crypto/ppccap.d.tmp -MT crypto/ppccap.o -c -o crypto/ppccap.o crypto/ppccap.c # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests - 32bit: gcc -maix32 -I. -Icrypto/include -Iinclude -DZLIB -DZLIB_SHARED -DDSO_DLFCN -DHAVE_DLFCN_H -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_DYNAMIC_ENGINE -DOPENSSL_PIC -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DVPAES_ASM -DPOLY1305_ASM -DSSL_ALLOW_ADH -DOPENSSLDIR="\"/var/ssl\"" -DENGINESDIR="\"/opt/freeware/lib/engines-1.1\"" -DB_ENDIAN -O -pthread -MMD -MF crypto/ppccap.d.tmp -MT crypto/ppccap.o -c -o crypto/ppccap.o crypto/ppccap.c # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Regards, Tony Le 31/08/2016 18:46, Richard Levitte via RT a ?crit : Curious. The diverse flags for the aix config targets' information in 1.1.0 are exact copies from the 1.0.x series... The best way you can help out here is to show us the build command lines you got for building crypto/ppccap.o in both 1.1.0 and 1.0.2, so we can see what actually differs. Cheers, Richard On Wed Aug 31 16:06:30 2016, tony.reix at atos.net wrote: Hi, I do ports of OpenSSL on AIX 6.1 for one year. I had no issue with 1.0.1* and 1.0.2* versions, compiled with XLC. With version 1.1.0, I am encountering an issue with -O, both with XLC and GCC . 30-test_evp.t fails because using -O when compiling crypto/ppccap.c generates something wrong. Compiling only crypto/ppccap.c with -O0 does fix the issue. It is the same with XLC. I have put in place a simple work-around: use -O0 for crypto/ppccap.c . However, do you have an idea about: why crypto/ppccap.c seems sensitive to optimization ? Thanks/Regards, Tony Reix http://www.bullfreeware.com -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 10:53:13 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 01 Sep 2016 10:53:13 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <4f70f811-3ffc-988f-9255-76bed1a07e1d@openssl.org> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <4f70f811-3ffc-988f-9255-76bed1a07e1d@openssl.org> Message-ID: > Results: > > > In short: > - no issue with v1.0.2h on both machines > - issue appears with: > - XLC -O but only for 64bits > - GCC -O for both 64bits and 32bits > - issue disappears when building ppccap.c with -O0 . > > So, I think that the probability that both XLC and GCC have an issue when optimizing ppccap.c is very low. What they have in common is that they both use same linker, so they both can trigger some linker quirk... > So, I guess that ppccap.c has something special. Could you tell which test does it fail? In order to do that run 'make test TESTS=test_evp VERBOSE=1' and note which line[s] it fails. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From beldmit at gmail.com Thu Sep 1 13:06:54 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 1 Sep 2016 16:06:54 +0300 Subject: [openssl-dev] Linking with extra library Message-ID: Hello Openssl Team, I'm currently working on a patch providing support of the https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-00 draft. I want to use functions from the libidn library to process the specified conversion. How do I add the linkage against libidn to the build system? Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Sep 1 13:09:27 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Thu, 01 Sep 2016 13:09:27 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C8281D.7000706@atos.net> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <4f70f811-3ffc-988f-9255-76bed1a07e1d@openssl.org> <57C8281D.7000706@atos.net> Message-ID: About the possible "linker quirk", the same linker is used also for version 1.0.2h which runs perferctly. Also, that does not explain why simply compiling ppccap.c only with -O0 makes the issue to dispappear. I also tried to repeat the failing test several times: failure is consistent. Here below are the details you asked. Please note that the (wrong) result of the 12th failing test is different when compiled with xlc vs gcc. I've done several experiments (see below for details). And it appears that, on machine2 where the issue appears with GCC 6.2.0 (both 32/64), the issue does not appear with GCC 4.8.4 (both 32/64). The issue with XLC (only 64) appears both on machine1 and machine2. So, my main hypothesis is now: I think that the root cause of the issue is that ppccap.c contains some code that was correctly -O optimized by GCC 4.84 (and maybe other versions) and that it is no more correctly optimized by GCC 6.2.0 and that it is badly optimized by XLC v12 and v13 only for 64bits. Some kind of more aggressive optimization. Since I had another -O2 issue with Python due to ANSI aliasing, I've tried: "-fPIC -fno-strict-aliasing -fwrapv " but it does not fix the issue. I have built/run openssl 1.1.0 on Ubuntu/x86_64 with GCC 4.8.4 and tests are perfect. Which version of GCC are you using for compiling openssl ? I would recommend you to try building/testing with GCC 6.2.0 , if you have not moved to this version of GCC yet, and see tests results. Regards, Tony 1) Results are the same (on machine2) when compiling with xlc v13 compared to xlc v12: evp test fails for 64bit, not 32bit. # cd openssl-1.1.0-XLCv13-O/64bit # make test TESTS=test_evp VERBOSE=1 2>&1 | grep error Test line 3089(aligned in-place): unexpected error VALUE_MISMATCH Test line 3095(aligned in-place): unexpected error VALUE_MISMATCH Test line 3101(aligned in-place): unexpected error VALUE_MISMATCH Test line 3107(aligned in-place): unexpected error VALUE_MISMATCH Test line 3113(aligned in-place): unexpected error VALUE_MISMATCH Test line 3119(aligned in-place): unexpected error VALUE_MISMATCH Test line 3125(aligned in-place): unexpected error VALUE_MISMATCH Test line 3131(aligned in-place): unexpected error VALUE_MISMATCH Test line 3137(aligned in-place): unexpected error VALUE_MISMATCH Test line 3143(aligned in-place): unexpected error VALUE_MISMATCH Test line 3149(aligned in-place): unexpected error VALUE_MISMATCH Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH 499 tests completed with 12 errors, 0 skipped Example of last error (I've cut the line in several lines) : Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH Expected: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 332F830E710B97CE98C8A84ABD0B948114AD176E008D33BD60F982B1FF37C8559797A06EF4F0EF61C186324E2B3506383606907B6A7C02B0F9F6157B53C867E4B9166C767B 804D46A59B5216CDE7A4E99040C5A40433225EE282A1B0A06C523EAF4534D7F83FA1155B0047718CBC546A0D072B04B3564EEA1B422273F548271A0BB2316053FA76991955 EBD63159434ECEBB4E466DAE5A1073A6727627097A1049E617D91D361094FA68F0FF77987130305BEABA2EDA04DF997B714D6C6F2C29A6AD5CB4022B02709B Got: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 5CC4390C72D4C96E3F8E5AD8889518DE44EA6CBC81D3529169E78F6A03A6BF57FF8AB174F4B07680658E50DE7A64545D3B181FA6BC19D9844F1CB6F86374A973DF67F27764 4FA0AA095EC097F78D9E9F1B9FAEE68A0FCF88B786861391AB0750A70EC7DD5F0617BD07FA6DCA4C8068F403D4E9DDDDFCFFD5F12814C3D0BCD88A11F3128EDCE8B52376AB 4B417FD34183FC2555B24DA1E2B0B44587127F0F61BFE107137F4290CFFE476C85DA50CEAE07B00C8A23EA96FB60DF6F504FED2DE79FA6AD5CB4022B02709B 499 tests completed with 12 errors, 0 skipped ../util/shlib_wrap.sh ./evp_test ../test/evptests.txt => 1 # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. Failed 1/1 test programs. 1/1 subtests failed. 2) Here are the results (on machine2) when compiling with GCC 6.2.0 : evp test fails for both 64bit and 32bit. # gmake test TESTS=test_evp VERBOSE=1 2>&1 | grep error Test line 3089(aligned in-place): unexpected error VALUE_MISMATCH Test line 3095(aligned in-place): unexpected error VALUE_MISMATCH Test line 3101(aligned in-place): unexpected error VALUE_MISMATCH Test line 3107(aligned in-place): unexpected error VALUE_MISMATCH Test line 3113(aligned in-place): unexpected error VALUE_MISMATCH Test line 3119(aligned in-place): unexpected error VALUE_MISMATCH Test line 3125(aligned in-place): unexpected error VALUE_MISMATCH Test line 3131(aligned in-place): unexpected error VALUE_MISMATCH Test line 3137(aligned in-place): unexpected error VALUE_MISMATCH Test line 3143(aligned in-place): unexpected error VALUE_MISMATCH Test line 3149(aligned in-place): unexpected error VALUE_MISMATCH Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH 499 tests completed with 12 errors, 0 skipped Example of last error (I've cut the line in several) : Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH Expected: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 332F830E710B97CE98C8A84ABD0B948114AD176E008D33BD60F982B1FF37C8559797A06EF4F0EF61C186324E2B3506383606907B6A7C02B0F9F6157B53C867E4B9166C767B 804D46A59B5216CDE7A4E99040C5A40433225EE282A1B0A06C523EAF4534D7F83FA1155B0047718CBC546A0D072B04B3564EEA1B422273F548271A0BB2316053FA76991955 EBD63159434ECEBB4E466DAE5A1073A6727627097A1049E617D91D361094FA68F0FF77987130305BEABA2EDA04DF997B714D6C6F2C29A6AD5CB4022B02709B Got: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 0F992F281153EA39F7C9ABFE79F6C798B92C144DCB2725EEB09726399BC279D604F98608C03BAC80E7BD967AB51DB2311360CB3EE2BC70BCC5E97CA6EC2E0A1C6B02435677 97A344344318B428CE15C6A44087082CCE4847AE57BDFA07F859208D4E72CA5DD2F560B1E003E6350C451FCB839B30E91318A01DDAA58E0FB4D97DB449A603DC61F257CD64 94A96EADB6A31F970A57D93D37E40F36A6803C78CDA313F84B7290174D9B112E7D74EC016EE8A2753BCB32BEF25603F092995EF97AA7A6AD5CB4022B02709B 3) Here are the results (on machine1) when compiling with GCC 4.8.4 : evp test succeeds for both 64bit and 32bit. 64bit: ../test/recipes/30-test_evp.t .............. ok 32bit: ../test/recipes/30-test_evp.t .............. ok 4) Here are the results (on machine1) when compiling with XLC v13.1.0.6 : evp test fails for both 64bit and not for 32bit. 64bits: # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests # gmake test TESTS=test_evp VERBOSE=1 2>&1 | grep error Test line 3089(aligned in-place): unexpected error VALUE_MISMATCH Test line 3095(aligned in-place): unexpected error VALUE_MISMATCH Test line 3101(aligned in-place): unexpected error VALUE_MISMATCH Test line 3107(aligned in-place): unexpected error VALUE_MISMATCH Test line 3113(aligned in-place): unexpected error VALUE_MISMATCH Test line 3119(aligned in-place): unexpected error VALUE_MISMATCH Test line 3125(aligned in-place): unexpected error VALUE_MISMATCH Test line 3131(aligned in-place): unexpected error VALUE_MISMATCH Test line 3137(aligned in-place): unexpected error VALUE_MISMATCH Test line 3143(aligned in-place): unexpected error VALUE_MISMATCH Test line 3149(aligned in-place): unexpected error VALUE_MISMATCH Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH 499 tests completed with 12 errors, 0 skipped Test line 3164(aligned in-place): unexpected error VALUE_MISMATCH Expected: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 332F830E710B97CE98C8A84ABD0B948114AD176E008D33BD60F982B1FF37C8559797A06EF4F0EF61C186324E2B3506383606907B6A7C02B0F9F6157B53C867E4B9166C767B 804D46A59B5216CDE7A4E99040C5A40433225EE282A1B0A06C523EAF4534D7F83FA1155B0047718CBC546A0D072B04B3564EEA1B422273F548271A0BB2316053FA76991955 EBD63159434ECEBB4E466DAE5A1073A6727627097A1049E617D91D361094FA68F0FF77987130305BEABA2EDA04DF997B714D6C6F2C29A6AD5CB4022B02709B Got: 64A0861575861AF460F062C79BE643BD5E805CFD345CF389F108670AC76C8CB24C6CFC18755D43EEA09EE94E382D26B0BDB7B73C321B0100D4F03B7F355894CF 5CC4390C72D4C96E3F8E5AD8889518DE44EA6CBC81D3529169E78F6A03A6BF57FF8AB174F4B07680658E50DE7A64545D3B181FA6BC19D9844F1CB6F86374A973DF67F27764 4FA0AA095EC097F78D9E9F1B9FAEE68A0FCF88B786861391AB0750A70EC7DD5F0617BD07FA6DCA4C8068F403D4E9DDDDFCFFD5F12814C3D0BCD88A11F3128EDCE8B52376AB 4B417FD34183FC2555B24DA1E2B0B44587127F0F61BFE107137F4290CFFE476C85DA50CEAE07B00C8A23EA96FB60DF6F504FED2DE79FA6AD5CB4022B02709B 32bit: ../test/recipes/30-test_evp.t .............. ok 5) Here are the results (on machine2) when compiling with GCC 4.8.4 : evp test fails for both 64bit and not for 32bit. 64bits: ../test/recipes/30-test_evp.t .............. ok 32bits: ../test/recipes/30-test_evp.t .............. ok Le 01/09/2016 12:53, Andy Polyakov via RT a ?crit : Results: In short: - no issue with v1.0.2h on both machines - issue appears with: - XLC -O but only for 64bits - GCC -O for both 64bits and 32bits - issue disappears when building ppccap.c with -O0 . So, I think that the probability that both XLC and GCC have an issue when optimizing ppccap.c is very low. What they have in common is that they both use same linker, so they both can trigger some linker quirk... So, I guess that ppccap.c has something special. Could you tell which test does it fail? In order to do that run 'make test TESTS=test_evp VERBOSE=1' and note which line[s] it fails. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 13:13:44 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 01 Sep 2016 13:13:44 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160901130650.mIGFiev67%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> Message-ID: Before sending the last message i looked around on the website (it has become particularly complicated to find the bug tracker), and looking at the "go-back" list i saw dozens of "OpenSSL" entries, rather than rt, "Getting started as a contributor", etc. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 13:18:44 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Thu, 01 Sep 2016 13:18:44 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> Message-ID: Hello. >From the documentation i cannot tell what is wrong with the following: echo abc > a; echo def > b; echo ghi > c openssl genpkey -algorithm RSA -out k.prv openssl pkey -in k.prv -pubout -out k.pub openssl dgst -sha512 -sign k.prv -out .sig a b c openssl dgst -sha512 -verify k.pub -signature .sig a b c rm k.prv k.pub a b c It gives me ?0[steffen at wales bin]$ sh /tmp/t.sh ..............++++++ ...++++++ Verified OK Verification Failure Verification Failure And being able to produce textual output would be great. Thanks. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 13:45:52 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 01 Sep 2016 13:45:52 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <4f70f811-3ffc-988f-9255-76bed1a07e1d@openssl.org> <57C8281D.7000706@atos.net> Message-ID: > About the possible "linker quirk", the same linker is used also for version 1.0.2h which runs perferctly. Yes, but 1.0.2 and 1.1 ppccap's are different. > Also, that does not explain why simply compiling ppccap.c only with -O0 makes the issue to dispappear. Bugs seldom make sense. If they did, we would spot them prior they manifest themselves, so there would be no bugs :-) > I also tried to repeat the failing test several times: failure is consistent. > > > Here below are the details you asked. Thanks! I've have closer look at it a bit later today. Just in case, 1.1. was tested on AIX 7.x... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 14:01:28 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Thu, 01 Sep 2016 14:01:28 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C83457.1000506@atos.net> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <57C8281D.7000706@atos.net> <57C83457.1000506@atos.net> Message-ID: Hi Andy, We need bugs ! Without bugs, no more job !! ;) About openssl built/tested on AIX 7.1 , I have an AIX 7.1 machine. Would you mind saying me which compiler was used ? GCC I guess. Which version ? Thanks, Tony Le 01/09/2016 15:45, Andy Polyakov via RT a ?crit : About the possible "linker quirk", the same linker is used also for version 1.0.2h which runs perferctly. Yes, but 1.0.2 and 1.1 ppccap's are different. Also, that does not explain why simply compiling ppccap.c only with -O0 makes the issue to dispappear. Bugs seldom make sense. If they did, we would spot them prior they manifest themselves, so there would be no bugs :-) I also tried to repeat the failing test several times: failure is consistent. Here below are the details you asked. Thanks! I've have closer look at it a bit later today. Just in case, 1.1. was tested on AIX 7.x... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 14:07:59 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 01 Sep 2016 14:07:59 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <81fe8c0c-3368-9146-ceb5-8c37b4575682@openssl.org> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <57C83457.1000506@atos.net> <81fe8c0c-3368-9146-ceb5-8c37b4575682@openssl.org> Message-ID: > About openssl built/tested on AIX 7.1 , I have an AIX 7.1 machine. > Would you mind saying me which compiler was used ? GCC I guess. Which version ? The reason for why I said "I'll look at it a bit later today" is that accessing that system is problematic for me for this very moment. And since I don't keep version in mind, I can't tell :-) Sorry... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From levitte at openssl.org Thu Sep 1 14:39:43 2016 From: levitte at openssl.org (Richard Levitte) Date: Thu, 01 Sep 2016 16:39:43 +0200 (CEST) Subject: [openssl-dev] Linking with extra library In-Reply-To: References: Message-ID: <20160901.163943.560356257837971846.levitte@openssl.org> In message on Thu, 1 Sep 2016 16:06:54 +0300, Dmitry Belyavsky said: beldmit> Hello Openssl Team, beldmit> beldmit> I'm currently working on a patch providing support of the beldmit> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-00 draft. beldmit> beldmit> I want to use functions from the libidn library to process the beldmit> specified conversion. beldmit> How do I add the linkage against libidn to the build system? ./config -lidn (you might want to toss in a -L argument there as well if your libidn isn't in a standard location) Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rt at openssl.org Thu Sep 1 14:48:30 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Thu, 01 Sep 2016 14:48:30 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57C83F59.30908@atos.net> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <57C8281D.7000706@atos.net> <57C83F59.30908@atos.net> Message-ID: On my AIX 7.1 machine, building/testing evp test of openssl 1.1.0 with: - GCC 4.8.5 is: OK, 64 & 32 bits: ../test/recipes/30-test_evp.t .............. ok - GCC 5.4.0 is: OK, 64 & 32 bits: ../test/recipes/30-test_evp.t .............. ok - GCC 6.1.0 is: KO, 64 & 32 bits: # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests - GCC 6.2.0 is: KO, 64 & 32 bits: # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests GCC team look to have changed something in their -O optimization. And, as I said already, XLC also has some aggressive optimization that does not work in 64bit with ppccap.c file. I think that there is some not-perfect code in ppccap.c of version 1.1.0 . Regards, Tony Le 01/09/2016 15:45, Andy Polyakov via RT a ?crit : About the possible "linker quirk", the same linker is used also for version 1.0.2h which runs perferctly. Yes, but 1.0.2 and 1.1 ppccap's are different. Also, that does not explain why simply compiling ppccap.c only with -O0 makes the issue to dispappear. Bugs seldom make sense. If they did, we would spot them prior they manifest themselves, so there would be no bugs :-) I also tried to repeat the failing test several times: failure is consistent. Here below are the details you asked. Thanks! I've have closer look at it a bit later today. Just in case, 1.1. was tested on AIX 7.x... -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 15:32:53 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 01 Sep 2016 15:32:53 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <6eb12036c63e4510aa0d370fc71d3407@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <6eb12036c63e4510aa0d370fc71d3407@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Can you please provide some concrete examples, so I know what to look for and fix? (I'm kinda slow sometimes) Thanks! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 16:58:33 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 01 Sep 2016 16:58:33 +0000 Subject: [openssl-dev] [openssl.org #4666] Fix for setenv-android.sh In-Reply-To: <20160831090750.GA3007@clausfischer.com> References: <20160831090750.GA3007@clausfischer.com> Message-ID: updated the wiki, thanks. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4666 Please log in as guest with password guest if prompted From beldmit at gmail.com Thu Sep 1 18:23:52 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Thu, 1 Sep 2016 21:23:52 +0300 Subject: [openssl-dev] Linking with extra library In-Reply-To: <20160901.163943.560356257837971846.levitte@openssl.org> References: <20160901.163943.560356257837971846.levitte@openssl.org> Message-ID: Dear Richard, On Thu, Sep 1, 2016 at 5:39 PM, Richard Levitte wrote: > In message gmail.com> on Thu, 1 Sep 2016 16:06:54 +0300, Dmitry Belyavsky < > beldmit at gmail.com> said: > > beldmit> Hello Openssl Team, > beldmit> > beldmit> I'm currently working on a patch providing support of the > beldmit> https://tools.ietf.org/html/draft-ietf-lamps-eai-addresses-00 > draft. > beldmit> > beldmit> I want to use functions from the libidn library to process the > beldmit> specified conversion. > beldmit> How do I add the linkage against libidn to the build system? > > ./config -lidn > > (you might want to toss in a -L argument there as well if your libidn > isn't in a standard location) > > Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Thu Sep 1 19:16:03 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Thu, 01 Sep 2016 19:16:03 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <757821.16247.qm@web101209.mail.kks.yahoo.co.jp> References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <757821.16247.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: I'm sorry to be late. I was too busy and had to prepare 64 bit gdb (& 64 bit perl). It seems to be 32 bit perl (perl-5.24.0) problem. (Generating 64 bit code with? 32 bit perl.) Tested with openssl-1.1.0 instead of pre-6, and on pure Solaris 10, without any VM. (1) with 32 bit perl Did test/hmactest under gdb, break, confirmed it was in OPENSSL_cleanse, "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi") and making a short loop. (2) with 64 bit perl make test passed both with gcc 5.4.0 & developerstudio12.5. Regrads, --- Kiyoshi > Hi, > >> make test stops on Solaris10 x64. >> >> >> % ./Configure solaris64-x86_64-gcc >> >> % make >> % make test >> ? ? : >> ../test/recipes/01-test_abort.t ............ ok? >> ../test/recipes/01-test_sanity.t ........... ok? >> ../test/recipes/01-test_symbol_presence.t .. ok? >> ../test/recipes/02-test_ordinals.t ......... ok? >> ../test/recipes/05-test_bf.t ............... ok? >> ../test/recipes/05-test_cast.t ............. ok? >> ../test/recipes/05-test_des.t .............. ok? >> ../test/recipes/05-test_fuzz.t ............. ok? ? >> ../test/recipes/05-test_hmac.t ............. > > There was private report about similar problem. I mean if you can > confirm that it's stuck in OPENSSL_cleanse, then it's same problem(*). > Trouble is that it doesn't seem to be OpenSSL problem, because generated > code appears to be mis-compiled. When single-stepping with 'stepi' you > are likely to observe "lea 0(%rdi),%rdi" instruction, and it should be > "lea 1(%rdi),%rdi". I mean it *is* "lea 1(%rdi),%rdi" in > source file, > crypto/x86_64cpuid.pl, and that's where our responsibility ends. In > sense that we are responsible for providing source, and you are > effectively responsible for providing working compiler environment. I > don't know which components were involved in first report, I mean things > like perl version, which assembler and its version, so I can't give any > advice about updates that might be required... > > (*) To confirm run test/hmactest under debugger, break, see if it's in > OPENSSL_cleanse, issue 'stepi' command few times to see if it's > going > "in circles". > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 20:23:15 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 01 Sep 2016 20:23:15 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <757821.16247.qm@web101209.mail.kks.yahoo.co.jp> Message-ID: > I'm sorry to be late. > I was too busy and had to prepare 64 bit gdb (& 64 bit perl). > > It seems to be 32 bit perl (perl-5.24.0) problem. > (Generating 64 bit code with 32 bit perl.) For reference, I'm using 32-bit perl version 5.10.1, minimally supported version, by default, i.e. *all* the time. Well, not on Solaris, on Linux, but I do use it with 64-bit builds. As well with cross-compile builds for a handful qemu-based environments, 32- and 64-bit ones, and with mingw/wine. As for Solaris, I can say that 32-bit perl version 5.12.5 works for me. Bottom line is that perl's 32-bitness doesn't seem to be the problem, on the contrary, it's actually *known* to be capable of generating 64-bit assembly code, and failure to do so will be caught swiftly. > Tested with openssl-1.1.0 instead of pre-6, > and on pure Solaris 10, without any VM. > > > (1) with 32 bit perl > Did test/hmactest under gdb, break, > confirmed it was in OPENSSL_cleanse, > "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi") > and making a short loop. > > (2) with 64 bit perl > make test passed both with gcc 5.4.0 & developerstudio12.5. In other words it's effectively confirmed that it's not really OpenSSL problem, but likely to be a problem with specific Solaris perl binary. I wonder if you could find opportunity to post broken crypto/x86_64cpuid.s generated by this broken perl, please? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From quanah at zimbra.com Thu Sep 1 20:58:00 2016 From: quanah at zimbra.com (Quanah Gibson-Mount) Date: Thu, 01 Sep 2016 13:58:00 -0700 Subject: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine In-Reply-To: <621497F2AD76E17D24EB9CFC@[192.168.1.19]> References: <89871704495BA8B3771170F2@[192.168.1.19]> <20160824233637.GN4670@mournblade.imrryr.org> <621497F2AD76E17D24EB9CFC@[192.168.1.19]> Message-ID: <5617BF4FF2C41C8F8724D19F@[192.168.1.19]> --On Wednesday, August 24, 2016 5:47 PM -0700 Quanah Gibson-Mount wrote: >> this is clearly a TLS client-side stack trace. Why is nginx acting >> as an SSL/TLS client? > > It's a proxy server... so it's proxying between the client connecting to > nginx on the IMAPS port and the jetty server on the other side. > > so: > > end user <-> nginx:143 <-> jetty:7143 > > The issue only happens when proxying IMAP on port 143 with startTLS or > 993 (IMAPS). It does not occur on POP w/ starttls or web traffic (443). > It also is only happening with this one particular client, as we have > numerous customers (and our own setup) not experiencing this issue. > > I'll have them supply what's in their keystore that Jetty's using as well. Note, when this happens, the nginx log shows: 2016/08/22 03:12:10 [info] 530#0: *3326370 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown:SSL alert number 46) w *** Error in `nginx: worker process': free(): invalid size: 0x00000000010cf560 *** The CA certs in play are the same for both the jetty process being proxied to, and what nginx is using. I see nothing unusual about the server cert on the jetty side. Is there any more info I can provide? --Quanah -- Quanah Gibson-Mount From rt at openssl.org Thu Sep 1 21:09:20 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Thu, 01 Sep 2016 21:09:20 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <179196.3165.qm@web101213.mail.kks.yahoo.co.jp> References: <593784.48311.qm@web101204.mail.kks.yahoo.co.jp> <757821.16247.qm@web101209.mail.kks.yahoo.co.jp> <179196.3165.qm@web101213.mail.kks.yahoo.co.jp> Message-ID: Hello, crypto/x86_64cpuid.s generated by perl 32 bit (has problem) & 64 bit (no problem) are attached. Regards, --- Kiyoshi > >> I'm sorry to be late. >> I was too busy and had to prepare 64 bit gdb (& 64 bit perl). >> >> It seems to be 32 bit perl (perl-5.24.0) problem. >> (Generating 64 bit code with? 32 bit perl.) > > For reference, I'm using 32-bit perl version 5.10.1, minimally supported > version, by default, i.e. *all* the time. Well, not on Solaris, on > Linux, but I do use it with 64-bit builds. As well with cross-compile > builds for a handful qemu-based environments, 32- and 64-bit ones, and > with mingw/wine. As for Solaris, I can say that 32-bit perl version > 5.12.5 works for me. Bottom line is that perl's 32-bitness doesn't seem > to be the problem, on the contrary, it's actually *known* to be capable > of generating 64-bit assembly code, and failure to do so will be caught > swiftly. > >> Tested with openssl-1.1.0 instead of pre-6, >> and on pure Solaris 10, without any VM. >> >> >> (1) with 32 bit perl >> Did test/hmactest under gdb, break, >> confirmed it was in OPENSSL_cleanse, >> "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi") >> and making a short loop. >> >> (2) with 64 bit perl >> make test passed both with gcc 5.4.0 & developerstudio12.5. > > In other words it's effectively confirmed that it's not really OpenSSL > problem, but likely to be a problem with specific Solaris perl binary. I > wonder if you could find opportunity to post broken crypto/x86_64cpuid.s > generated by this broken perl, please? > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: x86_64cpuid.s-with_32bit_perl.gz Type: application/x-tar Size: 1801 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: x86_64cpuid.s-with_64bit_perl.gz Type: application/x-tar Size: 1810 bytes Desc: not available URL: From erik at efca.com Thu Sep 1 21:39:46 2016 From: erik at efca.com (Erik Forsberg) Date: Thu, 1 Sep 2016 14:39:46 -0700 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: References: Message-ID: Note that a 32-bit Perl can be compiled with or without support for 64-bit integers. That fact hit me once doing OpenSSL builds, some 64-bit constants were not calculated correctly, however that showed up at build time so not likely to be the case here. However, it might be helpful checking if the 32-bit perl in question supports 64-bit or not. >-- Original Message -- > > >Hello, > >crypto/x86_64cpuid.s generated by perl > >32 bit (has problem) & 64 bit (no problem) are attached. > >Regards, > >--- Kiyoshi > > > >> >>> I'm sorry to be late. >>> I was too busy and had to prepare 64 bit gdb (& 64 bit perl). >>> >>> It seems to be 32 bit perl (perl-5.24.0) problem. >>> (Generating 64 bit code with? 32 bit perl.) >> >> For reference, I'm using 32-bit perl version 5.10.1, minimally supported >> version, by default, i.e. *all* the time. Well, not on Solaris, on >> Linux, but I do use it with 64-bit builds. As well with cross-compile >> builds for a handful qemu-based environments, 32- and 64-bit ones, and >> with mingw/wine. As for Solaris, I can say that 32-bit perl version >> 5.12.5 works for me. Bottom line is that perl's 32-bitness doesn't seem >> to be the problem, on the contrary, it's actually *known* to be capable >> of generating 64-bit assembly code, and failure to do so will be caught >> swiftly. >> >>> Tested with openssl-1.1.0 instead of pre-6, >>> and on pure Solaris 10, without any VM. >>> >>> >>> (1) with 32 bit perl >>> Did test/hmactest under gdb, break, >>> confirmed it was in OPENSSL_cleanse, >>> "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi") >>> and making a short loop. >>> >>> (2) with 64 bit perl >>> make test passed both with gcc 5.4.0 & developerstudio12.5. >> >> In other words it's effectively confirmed that it's not really OpenSSL >> problem, but likely to be a problem with specific Solaris perl binary. I >> wonder if you could find opportunity to post broken crypto/x86_64cpuid.s >> generated by this broken perl, please? >> >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 >> Please log in as guest with password guest if prompted >> >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 >Please log in as guest with password guest if prompted > > >Attachment: x86_64cpuid.s-with_32bit_perl.gz (1.8 KB) > >Attachment: x86_64cpuid.s-with_64bit_perl.gz (1.8 KB) > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rt at openssl.org Thu Sep 1 21:39:57 2016 From: rt at openssl.org (Erik Forsberg via RT) Date: Thu, 01 Sep 2016 21:39:57 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: References: Message-ID: Note that a 32-bit Perl can be compiled with or without support for 64-bit integers. That fact hit me once doing OpenSSL builds, some 64-bit constants were not calculated correctly, however that showed up at build time so not likely to be the case here. However, it might be helpful checking if the 32-bit perl in question supports 64-bit or not. >-- Original Message -- > > >Hello, > >crypto/x86_64cpuid.s generated by perl > >32 bit (has problem) & 64 bit (no problem) are attached. > >Regards, > >--- Kiyoshi > > > >> >>> I'm sorry to be late. >>> I was too busy and had to prepare 64 bit gdb (& 64 bit perl). >>> >>> It seems to be 32 bit perl (perl-5.24.0) problem. >>> (Generating 64 bit code with? 32 bit perl.) >> >> For reference, I'm using 32-bit perl version 5.10.1, minimally supported >> version, by default, i.e. *all* the time. Well, not on Solaris, on >> Linux, but I do use it with 64-bit builds. As well with cross-compile >> builds for a handful qemu-based environments, 32- and 64-bit ones, and >> with mingw/wine. As for Solaris, I can say that 32-bit perl version >> 5.12.5 works for me. Bottom line is that perl's 32-bitness doesn't seem >> to be the problem, on the contrary, it's actually *known* to be capable >> of generating 64-bit assembly code, and failure to do so will be caught >> swiftly. >> >>> Tested with openssl-1.1.0 instead of pre-6, >>> and on pure Solaris 10, without any VM. >>> >>> >>> (1) with 32 bit perl >>> Did test/hmactest under gdb, break, >>> confirmed it was in OPENSSL_cleanse, >>> "leaq -0(%rsi),%rsi" (not "lea 0(%rdi),%rdi") >>> and making a short loop. >>> >>> (2) with 64 bit perl >>> make test passed both with gcc 5.4.0 & developerstudio12.5. >> >> In other words it's effectively confirmed that it's not really OpenSSL >> problem, but likely to be a problem with specific Solaris perl binary. I >> wonder if you could find opportunity to post broken crypto/x86_64cpuid.s >> generated by this broken perl, please? >> >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 >> Please log in as guest with password guest if prompted >> >-- >Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 >Please log in as guest with password guest if prompted > > >Attachment: x86_64cpuid.s-with_32bit_perl.gz (1.8 KB) > >Attachment: x86_64cpuid.s-with_64bit_perl.gz (1.8 KB) > >-- >openssl-dev mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 1 22:10:50 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Thu, 01 Sep 2016 22:10:50 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <92fb2db3-15aa-b779-8421-2eeead3a5b3f@openssl.org> References: <92fb2db3-15aa-b779-8421-2eeead3a5b3f@openssl.org> Message-ID: > Note that a 32-bit Perl can be compiled with or without support for 64-bit integers. > That fact hit me once doing OpenSSL builds, some 64-bit constants were not > calculated correctly, however that showed up at build time so not likely > to be the case here. However, it might be helpful checking if the 32-bit perl > in question supports 64-bit or not. Those problems were addressed and both configurations are known to work. For example 32-bit perl I use by default on Linux is *not* compiled with 64-bit integers, while 32-bit perl I have on Solaris is. No problem with either. It appears to me that problem is likely to occur at sign extension when processing effective addresses. To demonstrate this with one-liner: perl -e 'use integer; printf "%d\n",0xffffffff<<32>>32' It should print -1 in either combination of bitnesses. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From openssl-users at dukhovni.org Thu Sep 1 22:42:15 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 1 Sep 2016 22:42:15 +0000 Subject: [openssl-dev] [openssl.org #4658] bug: Abort() in 1.0.2h parsing server cert in ASN.1 routine In-Reply-To: <5617BF4FF2C41C8F8724D19F@[192.168.1.19]> References: <89871704495BA8B3771170F2@[192.168.1.19]> <20160824233637.GN4670@mournblade.imrryr.org> <621497F2AD76E17D24EB9CFC@[192.168.1.19]> <5617BF4FF2C41C8F8724D19F@[192.168.1.19]> Message-ID: <20160901224214.GS4670@mournblade.imrryr.org> On Thu, Sep 01, 2016 at 01:58:00PM -0700, Quanah Gibson-Mount wrote: > >The issue only happens when proxying IMAP on port 143 with startTLS or > >993 (IMAPS). It does not occur on POP w/ starttls or web traffic (443). > >It also is only happening with this one particular client, as we have > >numerous customers (and our own setup) not experiencing this issue. > > > >I'll have them supply what's in their keystore that Jetty's using as well. > > Note, when this happens, the nginx log shows: > > 2016/08/22 03:12:10 [info] 530#0: *3326370 SSL_do_handshake() failed (SSL: > error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate > unknown:SSL alert number 46) w > *** Error in `nginx: worker process': free(): invalid size: > 0x00000000010cf560 *** If this is the outbound connection from nginx to the backend IMAP server, then the "alert" is received by nginx from the IMAP server, which means that it is the IMAP server that fails to authenticate the client cert used by nginx. In which you're looking at the wrong certs: > The CA certs in play are the same for both the jetty process being proxied > to, and what nginx is using. I see nothing unusual about the server cert on > the jetty side. Perhaps something goes wrong when the connection fails as a result of the IMAP server terminating it with an alert. -- Viktor. From rt at openssl.org Fri Sep 2 05:59:42 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Fri, 02 Sep 2016 05:59:42 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <465461.70179.qm@web101207.mail.kks.yahoo.co.jp> References: <92fb2db3-15aa-b779-8421-2eeead3a5b3f@openssl.org> <465461.70179.qm@web101207.mail.kks.yahoo.co.jp> Message-ID: With my old 32 bit perl,built by default except for prefix, ? perl -e 'use integer; printf "%d\n",0xffffffff<<32>>32' prints 0. 64 bit perl prints -1. After rebuilding 32 bit perl with Configuring "-Duse64bitint", output was changed to -1. With this rebuilt 32 bit perl, openssl-1.1.0 "make test" passes. (I checked perl-5.24.0, building both with gcc 5.4.0 & developerstudio12.5 cc, and had the same results.) Regards, --- Kiyoshi > >> Note that a 32-bit Perl can be compiled with or without support for 64-bit > integers. >> That fact hit me once doing OpenSSL builds, some 64-bit constants were not >> calculated correctly, however that showed up at build time so not likely >> to be the case here. However, it might be helpful checking if the 32-bit > perl >> in question supports 64-bit or not. > > Those problems were addressed and both configurations are known to work. > For example 32-bit perl I use by default on Linux is *not* compiled with > 64-bit integers, while 32-bit perl I have on Solaris is. No problem with > either. It appears to me that problem is likely to occur at sign > extension when processing effective addresses. To demonstrate this with > one-liner: > > perl -e 'use integer; printf > "%d\n",0xffffffff<<32>>32' > > It should print -1 in either combination of bitnesses. > > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 > Please log in as guest with password guest if prompted > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 10:31:36 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 02 Sep 2016 10:31:36 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160902103159.pOvl5T9GD%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <6eb12036c63e4510aa0d370fc71d3407@usma1ex-dag1mb1.msg.corp.akamai.com> <20160902103159.pOvl5T9GD%steffen@sdaoden.eu> Message-ID: "Salz, Rich" wrote: .. |for and fix? (I'm kinda slow sometimes) Do you know the story of the couple that had been married for decades when suddenly, at a Sunday morning breakfast, it has been revealed that she, who was given the upper half of the bread rolls for so long -- because he thought that was what she likes --, would much rather have eaten the lower half, but didn't say a word, because she thought it would have hurt him if she would have done so? This story is one of my childhood Traumatas, by the way. ^_^ --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 12:13:22 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 02 Sep 2016 12:13:22 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160901130650.mIGFiev67%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> Message-ID: On Thu Sep 01 13:13:44 2016, steffen at sdaoden.eu wrote: > Before sending the last message i looked around on the website (it > has become particularly complicated to find the bug tracker), and > looking at the "go-back" list i saw dozens of "OpenSSL" entries, > rather than rt, "Getting started as a contributor", etc. Not sure what you're on about... I just had a look through the whole set of files, and there's only one page that has that string. This one: https://www.openssl.org/community/getting-started.html As for page titles, all our pages have the title 'OpenSSL' To sum it up, I don't think we have a problem here. Closing this ticket. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 12:34:43 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 02 Sep 2016 12:34:43 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> Message-ID: On Thu Sep 01 13:18:44 2016, steffen at sdaoden.eu wrote: > Hello. > > From the documentation i cannot tell what is wrong with the > following: > > echo abc > a; echo def > b; echo ghi > c > openssl genpkey -algorithm RSA -out k.prv > openssl pkey -in k.prv -pubout -out k.pub > openssl dgst -sha512 -sign k.prv -out .sig a b c > openssl dgst -sha512 -verify k.pub -signature .sig a b c > rm k.prv k.pub a b c The manual for dgst has this little note The signing and verify options should only be used if a single file is being signed or verified. In other words, don't do that. While I can understand the desire to do multiple files in one swoop, the signature file (.sig in this case) isn't formatted in any special way, it's litterally just a stream of bytes. So it does contain all the signatures, but in an unstructured format. Verification will read that file and use the first n bytes from it when verifying each file you give it. That's why you get correct verification on the first file but not the others. The solution to this is to enhance dgst so it loudly refuses to sign or verify more than one file. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669 Please log in as guest with password guest if prompted From steffen at sdaoden.eu Fri Sep 2 13:00:14 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 02 Sep 2016 15:00:14 +0200 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> Message-ID: <20160902130014.LkNBzd204%steffen@sdaoden.eu> Richard Levitte via RT wrote: |On Thu Sep 01 13:13:44 2016, steffen at sdaoden.eu wrote: |> Before sending the last message i looked around on the website (it |> has become particularly complicated to find the bug tracker), and |> looking at the "go-back" list i saw dozens of "OpenSSL" entries, |> rather than rt, "Getting started as a contributor", etc. | |Not sure what you're on about... I just had a look through the whole set of |files, and there's only one page that has that string. This one: |https://www.openssl.org/community/getting-started.html | |As for page titles, all our pages have the title 'OpenSSL' My name is Hare and i know nothing. I don't have a Github account (they don't accept hard cash), but i have found a repository there which seems to be this web page. The makefile etc. seem to follow security-by-obscurity, but it seems that you use SSI to generate some load. If that is really true, the pages could very well be changed to have a that is repeated in the

further down via I must admit that i don't know whether that is working, the last time i have used SSI was, i think, and if i recall correctly, with the Xitami webserver, and before 1999? Can this be correct? I am not lying this, anyway. |To sum it up, I don't think we have a problem here. Closing this ticket. I could place this on my (pretty long) TODO and adjust the web pages as above at some later time. Because i think you are mistaken: to me it seems to be bad style and impolite; the latter not so much because of the filenames, but these you don't see in the browser navigation buttons of my graphical browser, only in the history. Just my one penny. Ciao. --steffen From rt at openssl.org Fri Sep 2 12:59:50 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 02 Sep 2016 12:59:50 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160902130014.LkNBzd204%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160902130014.LkNBzd204%steffen@sdaoden.eu> Message-ID: Richard Levitte via RT wrote: |On Thu Sep 01 13:13:44 2016, steffen at sdaoden.eu wrote: |> Before sending the last message i looked around on the website (it |> has become particularly complicated to find the bug tracker), and |> looking at the "go-back" list i saw dozens of "OpenSSL" entries, |> rather than rt, "Getting started as a contributor", etc. | |Not sure what you're on about... I just had a look through the whole set of |files, and there's only one page that has that string. This one: |https://www.openssl.org/community/getting-started.html | |As for page titles, all our pages have the title 'OpenSSL' My name is Hare and i know nothing. I don't have a Github account (they don't accept hard cash), but i have found a repository there which seems to be this web page. The makefile etc. seem to follow security-by-obscurity, but it seems that you use SSI to generate some load. If that is really true, the pages could very well be changed to have a that is repeated in the

further down via I must admit that i don't know whether that is working, the last time i have used SSI was, i think, and if i recall correctly, with the Xitami webserver, and before 1999? Can this be correct? I am not lying this, anyway. |To sum it up, I don't think we have a problem here. Closing this ticket. I could place this on my (pretty long) TODO and adjust the web pages as above at some later time. Because i think you are mistaken: to me it seems to be bad style and impolite; the latter not so much because of the filenames, but these you don't see in the browser navigation buttons of my graphical browser, only in the history. Just my one penny. Ciao. --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From steffen at sdaoden.eu Fri Sep 2 13:17:10 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Fri, 02 Sep 2016 15:17:10 +0200 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> Message-ID: <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> Richard Levitte via RT wrote: |On Thu Sep 01 13:18:44 2016, steffen at sdaoden.eu wrote: |> From the documentation i cannot tell what is wrong with the |> following: |> |> echo abc > a; echo def > b; echo ghi > c |> openssl genpkey -algorithm RSA -out k.prv |> openssl pkey -in k.prv -pubout -out k.pub |> openssl dgst -sha512 -sign k.prv -out .sig a b c |> openssl dgst -sha512 -verify k.pub -signature .sig a b c |> rm k.prv k.pub a b c | |The manual for dgst has this little note | |The signing and verify options should only be used if a single file \ |is being |signed or verified. |In other words, don't do that. I really haven't seen that. It is the second last sentence. Hm. |While I can understand the desire to do multiple files in one swoop, the |signature file (.sig in this case) isn't formatted in any special way, it's |litterally just a stream of bytes. So it does contain all the signatures, \ |but |in an unstructured format. Verification will read that file and use \ |the first n |bytes from it when verifying each file you give it. That's why you \ |get correct |verification on the first file but not the others. | |The solution to this is to enhance dgst so it loudly refuses to sign \ |or verify |more than one file. If that is your way. I haven't actually tried it, but the following should do what you want?! Ciao, --- dgst.c.orig 2016-09-02 15:06:08.952110179 +0200 +++ dgst.c 2016-09-02 15:13:57.592904667 +0200 @@ -369,6 +369,14 @@ int dgst_main(int argc, char **argv) if (md) md_name = EVP_MD_name(md); } + + if (argc > 1 && (sigbuf != NULL || sigkey != NULL)){ + BIO_printf(bio_err, "Signing and verifying cannot be used with " + "multiple files\n"); + ret = 1; + goto end; + } + ret = 0; for (i = 0; i < argc; i++) { int r; --steffen From rt at openssl.org Fri Sep 2 13:16:51 2016 From: rt at openssl.org (Steffen Nurpmeso via RT) Date: Fri, 02 Sep 2016 13:16:51 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> Message-ID: Richard Levitte via RT wrote: |On Thu Sep 01 13:18:44 2016, steffen at sdaoden.eu wrote: |> From the documentation i cannot tell what is wrong with the |> following: |> |> echo abc > a; echo def > b; echo ghi > c |> openssl genpkey -algorithm RSA -out k.prv |> openssl pkey -in k.prv -pubout -out k.pub |> openssl dgst -sha512 -sign k.prv -out .sig a b c |> openssl dgst -sha512 -verify k.pub -signature .sig a b c |> rm k.prv k.pub a b c | |The manual for dgst has this little note | |The signing and verify options should only be used if a single file \ |is being |signed or verified. |In other words, don't do that. I really haven't seen that. It is the second last sentence. Hm. |While I can understand the desire to do multiple files in one swoop, the |signature file (.sig in this case) isn't formatted in any special way, it's |litterally just a stream of bytes. So it does contain all the signatures, \ |but |in an unstructured format. Verification will read that file and use \ |the first n |bytes from it when verifying each file you give it. That's why you \ |get correct |verification on the first file but not the others. | |The solution to this is to enhance dgst so it loudly refuses to sign \ |or verify |more than one file. If that is your way. I haven't actually tried it, but the following should do what you want?! Ciao, --- dgst.c.orig 2016-09-02 15:06:08.952110179 +0200 +++ dgst.c 2016-09-02 15:13:57.592904667 +0200 @@ -369,6 +369,14 @@ int dgst_main(int argc, char **argv) if (md) md_name = EVP_MD_name(md); } + + if (argc > 1 && (sigbuf != NULL || sigkey != NULL)){ + BIO_printf(bio_err, "Signing and verifying cannot be used with " + "multiple files\n"); + ret = 1; + goto end; + } + ret = 0; for (i = 0; i < argc; i++) { int r; --steffen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 14:21:13 2016 From: rt at openssl.org (Kiyoshi KANAZAWA via RT) Date: Fri, 02 Sep 2016 14:21:13 +0000 Subject: [openssl-dev] [openssl.org #4641] [openssl-1.1.0-pre6] make test stops with solaris64-x86_64-gcc In-Reply-To: <968289.92151.qm@web101207.mail.kks.yahoo.co.jp> References: <92fb2db3-15aa-b779-8421-2eeead3a5b3f@openssl.org> <465461.70179.qm@web101207.mail.kks.yahoo.co.jp> <968289.92151.qm@web101207.mail.kks.yahoo.co.jp> Message-ID: I forgot writing. crypto/x86_64cpuid.s generated by 64 bit perl & generated by rebuilt 32 bit perl is the same. Regards, --- Kiyoshi > With my old 32 bit perl,built by default except for prefix, > ? perl -e 'use integer; printf > "%d\n",0xffffffff<<32>>32' > prints 0. > 64 bit perl prints -1. > > After rebuilding 32 bit perl with Configuring "-Duse64bitint", output > was changed to -1. > With this rebuilt 32 bit perl, openssl-1.1.0 "make test" passes. > > > (I checked perl-5.24.0, building both with gcc 5.4.0 & developerstudio12.5 > cc, > and had the same results.) > > Regards, > > --- Kiyoshi > > >> >>> ? Note that a 32-bit Perl can be compiled with or without support for > 64-bit >> integers. >>> ? That fact hit me once doing OpenSSL builds, some 64-bit constants were > not >>> ? calculated correctly, however that showed up at build time so not > likely >>> ? to be the case here. However, it might be helpful checking if the > 32-bit >> perl >>> ? in question supports 64-bit or not. >> >> Those problems were addressed and both configurations are known to work. >> For example 32-bit perl I use by default on Linux is *not* compiled with >> 64-bit integers, while 32-bit perl I have on Solaris is. No problem with >> either. It appears to me that problem is likely to occur at sign >> extension when processing effective addresses. To demonstrate this with >> one-liner: >> >> perl -e 'use integer; printf >> "%d\n",0xffffffff<<32>>32' >> >> It should print -1 in either combination of bitnesses. >> >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 >> Please log in as guest with password guest if prompted >> > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4641 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 14:37:30 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 02 Sep 2016 14:37:30 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160902130014.LkNBzd204%steffen@sdaoden.eu> Message-ID: There is a bug. Navigate around and then right-click on the back button. All the pages just say openssl. Re-opening. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 14:42:09 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Fri, 02 Sep 2016 14:42:09 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160902130014.LkNBzd204%steffen@sdaoden.eu> Message-ID: On Fri Sep 02 14:37:30 2016, rsalz at akamai.com wrote: > There is a bug. Navigate around and then right-click on the back > button. All the pages just say openssl. Errr, yes. That's because all pages include the same header, which has: OpenSSL I thought that was by design... Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rsalz at akamai.com Fri Sep 2 14:57:35 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Sep 2016 14:57:35 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> Message-ID: <1a38cc4ea1374df29a93c0506bae9fc1@usma1ex-dag1mb1.msg.corp.akamai.com> Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it. From rt at openssl.org Fri Sep 2 14:57:42 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 02 Sep 2016 14:57:42 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: <1a38cc4ea1374df29a93c0506bae9fc1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> <1a38cc4ea1374df29a93c0506bae9fc1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 15:00:32 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Fri, 02 Sep 2016 15:00:32 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <1f2e618ab7d54edf880a91a2e49e68c8@usma1ex-dag1mb1.msg.corp.akamai.com> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160902130014.LkNBzd204%steffen@sdaoden.eu> <1f2e618ab7d54edf880a91a2e49e68c8@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: > Errr, yes. That's because all pages include the same header, which has: > > OpenSSL > > I thought that was by design... No, it was because the person who rebuilt the web doesn't know much about the web. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 16:00:02 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 02 Sep 2016 16:00:02 +0000 Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object In-Reply-To: References: Message-ID: On Sat Aug 27 14:01:11 2016, 1047941314 at qq.com wrote: > hello: > i want to use libcurl with openssl, and i build openssl use this > cmd: > "perl configure VC-WIN32 no-asm -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi > -DOPENSSL_CAPIENG_DIALO" > > > when i use curl get url,eg "curl -k https://*.com",return the error: > error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object > Quick answer: use OpenSSL 1.1.0 . Alternatively disable TLS 1.2 (e.g. curl command line option) or indicate support only for SHA1+RSA for client signature algorithms (don't think there is a curl command line option for this). Long answer: the capi ENGINE in OpenSSL 1.0.2 and earlier uses the CSP attached to the key for cryptographic operations. Unfortunately this means that SHA2 algorithms are not supported for client authentication. OpenSSL 1.1.0 adds a workaround for this issue. If you disable TLS 1.2 in earlier versions of OpenSSL it will not use SHA2 for client auth so that will also work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4660 Please log in as guest with password guest if prompted From glenm at opentext.com Fri Sep 2 16:50:24 2016 From: glenm at opentext.com (Glen Matthews) Date: Fri, 2 Sep 2016 16:50:24 +0000 Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object In-Reply-To: References: Message-ID: <6D4F4080B6BD2B4F9F5955C645671A1FB2E64AB2@otwlxg22.opentext.net> Hi Are you saying that it was full? glen -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT Sent: Friday, September 02, 2016 12:00 PM To: 1047941314 at qq.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object On Sat Aug 27 14:01:11 2016, 1047941314 at qq.com wrote: > hello: > i want to use libcurl with openssl, and i build openssl use this > cmd: > "perl configure VC-WIN32 no-asm -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi > -DOPENSSL_CAPIENG_DIALO" > > > when i use curl get url,eg "curl -k https://urldefense.proofpoint.com/v2/url?u=https-3A__-2A.com&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=IuQq7WSAP9cJ_y-1fyCdn_8WwrZkjkgpnDza8tOuE7w&e= ",return the error: > error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object > Quick answer: use OpenSSL 1.1.0 . Alternatively disable TLS 1.2 (e.g. curl command line option) or indicate support only for SHA1+RSA for client signature algorithms (don't think there is a curl command line option for this). Long answer: the capi ENGINE in OpenSSL 1.0.2 and earlier uses the CSP attached to the key for cryptographic operations. Unfortunately this means that SHA2 algorithms are not supported for client authentication. OpenSSL 1.1.0 adds a workaround for this issue. If you disable TLS 1.2 in earlier versions of OpenSSL it will not use SHA2 for client auth so that will also work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=vd-4WnAUoA49neABl9NK-g38u00nQ2f7vJWLpope-KA&e= -- Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4660&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=d_EFK2MpG35FfJdpz5zxneka6JHkljpl79ksuSy143s&e= Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=_OR1SdBBZFy-d7W2zBYnsW_arfIKATUXmzPP9xSdAXA&e= From rt at openssl.org Fri Sep 2 17:59:02 2016 From: rt at openssl.org (Glen Matthews via RT) Date: Fri, 02 Sep 2016 17:59:02 +0000 Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object In-Reply-To: <6D4F4080B6BD2B4F9F5955C645671A1FB2E64AB2@otwlxg22.opentext.net> References: <6D4F4080B6BD2B4F9F5955C645671A1FB2E64AB2@otwlxg22.opentext.net> Message-ID: Hi Are you saying that it was full? glen -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Stephen Henson via RT Sent: Friday, September 02, 2016 12:00 PM To: 1047941314 at qq.com Cc: openssl-dev at openssl.org Subject: [openssl-dev] [openssl.org #4660] error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object On Sat Aug 27 14:01:11 2016, 1047941314 at qq.com wrote: > hello: > i want to use libcurl with openssl, and i build openssl use this > cmd: > "perl configure VC-WIN32 no-asm -DOPENSSL_SSL_CLIENT_ENGINE_AUTO=capi > -DOPENSSL_CAPIENG_DIALO" > > > when i use curl get url,eg "curl -k https://urldefense.proofpoint.com/v2/url?u=https-3A__-2A.com&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=IuQq7WSAP9cJ_y-1fyCdn_8WwrZkjkgpnDza8tOuE7w&e= ",return the error: > error:89070063:lib(137):CAPI_RSA_SIGN:cant create hash object > Quick answer: use OpenSSL 1.1.0 . Alternatively disable TLS 1.2 (e.g. curl command line option) or indicate support only for SHA1+RSA for client signature algorithms (don't think there is a curl command line option for this). Long answer: the capi ENGINE in OpenSSL 1.0.2 and earlier uses the CSP attached to the key for cryptographic operations. Unfortunately this means that SHA2 algorithms are not supported for client authentication. OpenSSL 1.1.0 adds a workaround for this issue. If you disable TLS 1.2 in earlier versions of OpenSSL it will not use SHA2 for client auth so that will also work. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: https://urldefense.proofpoint.com/v2/url?u=http-3A__www.openssl.org&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=vd-4WnAUoA49neABl9NK-g38u00nQ2f7vJWLpope-KA&e= -- Ticket here: https://urldefense.proofpoint.com/v2/url?u=http-3A__rt.openssl.org_Ticket_Display.html-3Fid-3D4660&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=d_EFK2MpG35FfJdpz5zxneka6JHkljpl79ksuSy143s&e= Please log in as guest with password guest if prompted -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=DQICAg&c=ZgVRmm3mf2P1-XDAyDsu4A&r=en90exXQg079MaPhrg6ehRKNiY_fq-tJFa8EsFg1CLY&m=GiaQ-aXTEAz2LIGw86R8W_YUndEECrAdv2HNMrMYIKs&s=_OR1SdBBZFy-d7W2zBYnsW_arfIKATUXmzPP9xSdAXA&e= -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4660 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 2 18:45:24 2016 From: rt at openssl.org (Rich Salz via RT) Date: Fri, 02 Sep 2016 18:45:24 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160901130650.mIGFiev67%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> Message-ID: The title now has the URL. Closing. Fixed as it's gonna get :) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4668 Please log in as guest with password guest if prompted From dwmw2 at infradead.org Fri Sep 2 19:36:52 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 02 Sep 2016 20:36:52 +0100 Subject: [openssl-dev] Certificate torture test Message-ID: <1472845012.3390.75.camel@infradead.org> I've started collecting a certificate torture test suite at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am It has RSA, DSA and EC keys in various forms (PKCS#1, PKCS#8, PKCS#12 with varying encryptions), and PKCS#11. I'm vaguely thinking about separating it from OpenConnect and making it available as a generic test suite ? and then perhaps trying to set expectations that any application that can use SSL client certs/keys should pass it. Currently, every application you encounter on a Linux system will support a *different* subset of the keys here. It would be nice to have a bit of consistency. Does that seem reasonable? Is there anything I'm missing from the tests above? I know I need to add some non-ASCII password tests, and I need a PKCS#11 test case where the certificate isn't visible until you log in to the token. What else? Should I add PKCS#12 in PEM form for completeness? FWIW I hate all crypto libraries... there isn't *one* which simply has a function that'll do the right thing and load a certificate given a string which identifies it (by filename or PKCS#11 URI). GnuTLS comes closest, I think, but we still have to jump through hoops in the *application* to work out what kind of file we're looking at and ask for it to be loaded. The library *really* ought to make that simple. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rsalz at akamai.com Fri Sep 2 20:20:12 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 2 Sep 2016 20:20:12 +0000 Subject: [openssl-dev] Certificate torture test In-Reply-To: <1472845012.3390.75.camel@infradead.org> References: <1472845012.3390.75.camel@infradead.org> Message-ID: > I've started collecting a certificate torture test suite at > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/ > Makefile.am I think this is cool, and splitting it off is a good idea. I think some IETF folks would be interested, too. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Fri Sep 2 22:42:17 2016 From: rt at openssl.org (Andy Polyakov via RT) Date: Fri, 02 Sep 2016 22:42:17 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <57C83F59.30908@atos.net> Message-ID: > - GCC 6.1.0 is: KO, 64 & 32 bits: > # Failed test 'running evp_test evptests.txt' > # at ../test/recipes/30-test_evp.t line 18. > # Looks like you failed 1 test of 1. > ../test/recipes/30-test_evp.t .............. > Dubious, test returned 1 (wstat 256, 0x100) > Failed 1/1 subtests Phew! Mystery solved! Verify attached patch. Trouble was that vector ChaCha subroutine relies on its alignment in memory. But on AIX it's impossible to *control* alignment with desired granularity without specifying higher alignment for .text segment itself. And .text directive was missing in chacha-ppc module :-( So it's not exactly optimizations of ppccap.o that mattered, but its changing size depending on optimization options that was affecting chacha subroutine's alignment. It actually *could* be vice versa, i.e. work with optimizations on and fail without, it's all about a coincidence. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted -------------- next part -------------- diff --git a/crypto/chacha/asm/chacha-ppc.pl b/crypto/chacha/asm/chacha-ppc.pl index b978f58..8a54cba 100755 --- a/crypto/chacha/asm/chacha-ppc.pl +++ b/crypto/chacha/asm/chacha-ppc.pl @@ -133,6 +133,7 @@ my ($a3,$b3,$c3,$d3)=map(($_&~3)+(($_+1)&3),($a2,$b2,$c2,$d2)); $code.=<<___; .machine "any" +.text .globl .ChaCha20_ctr32_int .align 5 From steffen at sdaoden.eu Sat Sep 3 02:07:54 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Sat, 03 Sep 2016 04:07:54 +0200 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> Message-ID: <20160903020754.B2bAIgSnW%steffen@sdaoden.eu> Rich Salz via RT wrote: |The title now has the URL. Closing. Fixed as it's gonna get :) Not on Github, but i have really cloned the repository from openssl.org (not promoted, but present) and had a short run on top what you have committed. Maybe you like it. I haven't tried it, but see no reason why it shouldn't work. It also adjusts headline tags in secpolicy.html, which don't comply to the rest of the site yet. Have a nice weekend, and ciao! --steffen -------------- next part -------------- A non-text attachment was scrubbed... Name: ossl-web.diff Type: text/x-diff Size: 42821 bytes Desc: not available URL: From rsalz at akamai.com Sat Sep 3 17:31:29 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 3 Sep 2016 17:31:29 +0000 Subject: [openssl-dev] [openssl.org #4668] Enhancement request: website: support proper titles In-Reply-To: <20160903020754.B2bAIgSnW%steffen@sdaoden.eu> References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160903020754.B2bAIgSnW%steffen@sdaoden.eu> Message-ID: > Maybe you like it. I haven't tried it, but see no reason why it > shouldn't work. It also adjusts headline tags in secpolicy.html, which don't > comply to the rest of the site yet. It's good enough. None of us our web developers. I just pushed the updated repo to https://github.com/openssl/web If you have improvements, plelase make a PR :) From rt at openssl.org Sun Sep 4 12:44:57 2016 From: rt at openssl.org (shuai.chang via RT) Date: Sun, 04 Sep 2016 12:44:57 +0000 Subject: [openssl-dev] =?utf-8?b?77+977+977+977+977+977+9UkU6ICBbb3BlbnNz?= =?utf-8?b?bC5vcmcgIzQ2NjBdIGVycm9yOjg5MDcwMDYzOmxpYigxMzcpOkNBUElf?= =?utf-8?q?RSA=5FSIGN=3Acant_create_hash_object?= In-Reply-To: References: <6D4F4080B6BD2B4F9F5955C645671A1FB2E64AB2@otwlxg22.opentext.net> Message-ID: This transaction appears to have no content -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4660 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 3258 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/octet-stream Size: 3936 bytes Desc: not available URL: From rt at openssl.org Sun Sep 4 17:08:23 2016 From: rt at openssl.org (aa via RT) Date: Sun, 04 Sep 2016 17:08:23 +0000 Subject: [openssl-dev] [openssl.org #4670] a bug in ssl_lib(ver 1.0.2) In-Reply-To: <68e18524.9bbf.156f5ba68c9.Coremail.alex.chen@vip.163.com> References: <68e18524.9bbf.156f5ba68c9.Coremail.alex.chen@vip.163.com> Message-ID: Hi OpenSSL, First, Thank you for your contribution in OpenSSL. I found the bug last week, that is: step-1, Create a socket of non-blocking mode, and then establish the connection-oriented; (all works successfully done) step-2, Call SSL_connect(or SSL_do_handshake) for establish a security session on that original-connection; (all works successfully done) step-3, After some works of data transfer, I want to shutdown the SSL-CONNECTION and close the original-socket, So I do the procedure as following, step-3.1, Call SSL_shutdown firstly, and it returns zero. According to comments of SSL_shutdown in manual as: (0: The shutdown is not yet finished. Call SSL_shutdown() for a second time, if a bidirectional shutdown shall be performed. The output of SSL_get_error may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.) So, I call SSL_shutdown again, and it returns -1, and SSL_get_error returns SSL_ERROR_SYSCALL. step-3.2, For a while, go back the step-1, at that time, I found SSL_connect / SSL_do_handshake will be always failed( the original-socket is still good ); But, if sleep/pause around 400ms between the operator 'connect'(original socket API) and the operator 'SSL_connect', then all works successfully finished. Hope you will check it. Maybe it occurred due to my incorrect processing. Best regards CXX SST. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4670 Please log in as guest with password guest if prompted From rt at openssl.org Sun Sep 4 18:39:09 2016 From: rt at openssl.org (Jarmo Jaakkola via RT) Date: Sun, 04 Sep 2016 18:39:09 +0000 Subject: [openssl-dev] [openssl.org #4671] Bug: pkcs8 application limits output passwords to 50 characters In-Reply-To: <20160904181002.GG15020@roskakori.fi> References: <20160904181002.GG15020@roskakori.fi> Message-ID: The pkcs8 application limits output keyfile passwords to at most 50 characters if -passout parameter is not used. This seems to be because the buffer used for password input in pkcs8.c has a fixed size of 50. This has a small security impact: the limitation leaks the maximum length of a password used on some PKCS#8 keys. How to reproduce: ---8<---8<--- $ openssl genrsa -out rsa.key $ openssl pkcs8 -topk8 -in rsa.key -out key.pkcs8 Enter Encryption Password:123456789012345678901234567890123456789012345678901 ---8<---8<--- Actual result: pkcs8 exits without output and returns value 1. ---8<---8<--- $ echo $? 1 ---8<---8<--- Expected result: pkcs8 prompts to verify the password and uses said password for encryption. It should be possible to use passwords of arbitrary length. Workaround: Use the -passout parameter, e.g. "-passout stdin". Versions tested: ---8<---8<--- $ uname -srm NetBSD 7.0.0 amd64 $ openssl version OpenSSL 1.0.2h 3 May 2016 $ /usr/bin/openssl version OpenSSL 1.0.1p 9 Jul 2015 $ uname -srm NetBSD 7.0.1 amd64 $ openssl version OpenSSL 1.0.1t 3 May 2016 ---8<---8<--- -- Jarmo Jaakkola -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4671 Please log in as guest with password guest if prompted From leonb at parsec.co.za Mon Sep 5 06:09:53 2016 From: leonb at parsec.co.za (Leon Brits) Date: Mon, 5 Sep 2016 06:09:53 +0000 Subject: [openssl-dev] FIPS validation Message-ID: <5a2f4d52f9e04fef839b4f36772777fc@EXCHANGESRV.PARSEC.local> The FIPS validation company says: "The tests I am most interested in are the failure cases, where you induce an error in each of the power-on self-tests and conditional tests (i.e, continuous RNG test, pairwise consistency test)." Can anybody tell me how I can induce these errors? I do run the FIPS_selftest() function on demand and the POST has never failed when I switch to FIPS mode with FIPS_mode_set(). Thanks LJB -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Mon Sep 5 10:22:45 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 05 Sep 2016 11:22:45 +0100 Subject: [openssl-dev] Certificate torture test In-Reply-To: References: <1472845012.3390.75.camel@infradead.org> Message-ID: <1473070965.61594.807.camel@infradead.org> On Fri, 2016-09-02 at 20:20 +0000, Salz, Rich wrote: > > I've started collecting a certificate torture test suite at > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am > > I think this is cool, and splitting it off is a good idea.? I think > some IETF folks would be interested, too. I'm tempted to split off the code with it. There's no way that applications should have to have *hundreds* of lines of their own code just to persuade the crypto library to use a cert/key pair specified by the user. Basically everything between http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l278 and http://git.infradead.org/users/dwmw2/openconnect.git/blob/e048030f8:/openssl.c#l1012 ... and the *whole* of openssl-pkcs11.c, is code I just don't want to have in the *application*. I could just BSD-license it and put it out there for people to use in the short term. In the (slightly) longer term, of course, OpenSSL should do it all. Including PKCS#11. FWIW, the torture test is now causing OpenSSL to crash because it assumes all EC *private* keys will also have the public key available, which isn't necessarily true when the key is in a hardware engine. ??https://github.com/openssl/openssl/issues/1532 -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From steffen at sdaoden.eu Mon Sep 5 11:00:40 2016 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Mon, 05 Sep 2016 13:00:40 +0200 Subject: [openssl-dev] [openssl.org beetle 4668] Enhancement request: website: support proper titles In-Reply-To: References: <20160901130650.mIGFiev67%steffen@sdaoden.eu> <20160903020754.B2bAIgSnW%steffen@sdaoden.eu> Message-ID: <20160905110040.4VJ49dAwi%steffen@sdaoden.eu> "Salz, Rich" wrote: |> Maybe you like it. I haven't tried it, but see no reason why it |> shouldn't work. It also adjusts headline tags in secpolicy.html, \ |> which don't |> comply to the rest of the site yet. | |It's good enough. None of us our web developers. I just pushed the \ |updated repo to https://github.com/openssl/web A 42 KB patch, and you and i both have seen it. |If you have improvements, plelase make a PR :o) I think less professionalism is better much often than not. (Just take these assembly lines of death for supermarket etc. meat.) As a natural born german i hate missing end tags etc. nonetheless. That must be said. Then again, browsers are used to swallow ... Ciao. --steffen From marquess at openssl.com Mon Sep 5 11:32:53 2016 From: marquess at openssl.com (Steve Marquess) Date: Mon, 5 Sep 2016 07:32:53 -0400 Subject: [openssl-dev] FIPS validation In-Reply-To: <5a2f4d52f9e04fef839b4f36772777fc@EXCHANGESRV.PARSEC.local> References: <5a2f4d52f9e04fef839b4f36772777fc@EXCHANGESRV.PARSEC.local> Message-ID: <0efe79c6-094b-9b28-b6e7-d04f2eb521fc@openssl.com> On 09/05/2016 02:09 AM, Leon Brits wrote: > The FIPS validation company says: > > > > ?The tests I am most interested in are the failure cases, where you > induce an error in each of the power-on self-tests and conditional tests > (i.e, continuous RNG test, pairwise consistency test).? > > > > Can anybody tell me how I can induce these errors? > > > > I do run the FIPS_selftest() function on demand and the POST has never > failed when I switch to FIPS mode with FIPS_mode_set(). > > > > Thanks > > LJB > > > So you're trying to obtain your own copycat validation based on the OpenSSL FIPS Object Module code (as many vendors have done). Since that has been done so many times your unnamed FIPS validation consultant or test lab should already be familiar enough with the OpenSSL FIPS module code to immediately know the answer to this question, rather than asking it of you (that's a hint). Most labs or consultants would direct you to the "fips_test_suite" test harness (also called from fips_algvs), which is included in the OpenSSL FIPS module tarballs and documented in the User Guide: https://www.openssl.org/docs/fips/UserGuide-2.0.pdf Test labs typically just run "fips_algv fips_test_suite" for the functional testing, as it was designed for exactly that purpose. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From waywardgeek at gmail.com Mon Sep 5 17:14:22 2016 From: waywardgeek at gmail.com (Bill Cox) Date: Mon, 5 Sep 2016 10:14:22 -0700 Subject: [openssl-dev] Enhancing ssltest_old.c? Message-ID: I wrote a simple change to custom extensions so that they can be negotiated on resume, which is needed by token binding. I put the test for this change in test/ssltest_old.c, which seems weird, but there are no custom extension tests in the new SSL tests AFAIK. Do we still extend the old tests when there are no equivalent new tests? Bill -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Sep 5 21:22:35 2016 From: levitte at openssl.org (Richard Levitte) Date: Mon, 05 Sep 2016 23:22:35 +0200 Subject: [openssl-dev] Enhancing ssltest_old.c? In-Reply-To: References: Message-ID: <31BDA31A-9ABE-4EBB-92EC-3AAED2AF1C96@openssl.org> I think it makes more sense to extend the new SSL test framework... Cheers Richard Bill Cox skrev: (5 september 2016 19:14:22 CEST) >I wrote a simple change to custom extensions so that they can be >negotiated >on resume, which is needed by token binding. I put the test for this >change in test/ssltest_old.c, which seems weird, but there are no >custom >extension tests in the new SSL tests AFAIK. Do we still extend the old >tests when there are no equivalent new tests? > >Bill > > >------------------------------------------------------------------------ -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From waywardgeek at gmail.com Tue Sep 6 02:12:50 2016 From: waywardgeek at gmail.com (Bill Cox) Date: Mon, 5 Sep 2016 19:12:50 -0700 Subject: [openssl-dev] Enhancing ssltest_old.c? In-Reply-To: <31BDA31A-9ABE-4EBB-92EC-3AAED2AF1C96@openssl.org> References: <31BDA31A-9ABE-4EBB-92EC-3AAED2AF1C96@openssl.org> Message-ID: I took a quick look through the new SSL test framework, which looks pretty good. I created this pull request to show what I currently propose: On Mon, Sep 5, 2016 at 2:22 PM, Richard Levitte wrote: > I think it makes more sense to extend the new SSL test framework... > > Cheers > Richard > > Bill Cox skrev: (5 september 2016 19:14:22 CEST) > >I wrote a simple change to custom extensions so that they can be > >negotiated > >on resume, which is needed by token binding. I put the test for this > >change in test/ssltest_old.c, which seems weird, but there are no > >custom > >extension tests in the new SSL tests AFAIK. Do we still extend the old > >tests when there are no equivalent new tests? > > > >Bill > > > > > >------------------------------------------------------------------------ > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From waywardgeek at gmail.com Tue Sep 6 02:33:52 2016 From: waywardgeek at gmail.com (Bill Cox) Date: Mon, 5 Sep 2016 19:33:52 -0700 Subject: [openssl-dev] Enhancing ssltest_old.c? In-Reply-To: References: <31BDA31A-9ABE-4EBB-92EC-3AAED2AF1C96@openssl.org> Message-ID: Sorry... stupid auto-send still happens on my Goobuntu latptop, even with tap-click disabled on the still poorly supported touchpad. Here's the current PR: https://github.com/openssl/openssl/pull/1538 My feeling is that if we put in the effort to upgrade the new SSL test harness to understand custom extensions, it might also be a good time to upgrade the custom extension API. There are a couple of enhancements that likely have been considered here before: - Add a way for custom extensions to save/restore state to the streamed session - Add a way for custom extensions to see what other extensions have been negotiated or not. Right now, custom extensions cannot save state between connections. This makes many simple extensions impossible to implement using the custom extension API. Often the server needs to remember the outcome of the original extension negotiation. Another issue is that custom extensions get zero knowledge of other extensions. This makes some things hard to implement. For example, we would like to stop including a version field in the token binding extension, and instead just issue a new extension if the binary format needs to be updated in an incompatible way. What happens if version 1.0 gets rewritten as a native extension, and we later write a new custom extension to override it? Right now, there is no way to do that, giving weight to the argument for keeping the version number in the extension. It is also not possible to ensure that extended-master-secret has been negotiated before the server add-callback has to commit to sending the token-binding extension in the server hello, meaning the client must check both extensions after the handshake completes, which is a bit goofy. So, what would you think about going forward with a simple upgrade similar to my PR, while working out what an improved custom extension API should look llike? Bill On Mon, Sep 5, 2016 at 7:12 PM, Bill Cox wrote: > I took a quick look through the new SSL test framework, which looks pretty > good. I created this pull request to show what I currently propose: > > > On Mon, Sep 5, 2016 at 2:22 PM, Richard Levitte > wrote: > >> I think it makes more sense to extend the new SSL test framework... >> >> Cheers >> Richard >> >> Bill Cox skrev: (5 september 2016 19:14:22 CEST) >> >I wrote a simple change to custom extensions so that they can be >> >negotiated >> >on resume, which is needed by token binding. I put the test for this >> >change in test/ssltest_old.c, which seems weird, but there are no >> >custom >> >extension tests in the new SSL tests AFAIK. Do we still extend the old >> >tests when there are no equivalent new tests? >> > >> >Bill >> > >> > >> >------------------------------------------------------------------------ >> >> -- >> Sent from my Android device with K-9 Mail. Please excuse my brevity. >> -- >> 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 Tue Sep 6 06:44:32 2016 From: rt at openssl.org (Tal Levi via RT) Date: Tue, 06 Sep 2016 06:44:32 +0000 Subject: [openssl-dev] [openssl.org #4672] BUG: NEWSLOG - an error occurred while processing this directive In-Reply-To: <1207216277.1861913.1473142753156@mail.yahoo.com> References: <1207216277.1861913.1473142753156.ref@mail.yahoo.com> <1207216277.1861913.1473142753156@mail.yahoo.com> Message-ID: Hi, I've encountered the following error: "an error occurred while processing this directive" when opening the news log.?https://www.openssl.org/news/newslog.html Thanks. Tal. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4672 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 6 06:47:23 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 06 Sep 2016 06:47:23 +0000 Subject: [openssl-dev] [openssl.org #4672] BUG: NEWSLOG - an error occurred while processing this directive In-Reply-To: <1207216277.1861913.1473142753156@mail.yahoo.com> References: <1207216277.1861913.1473142753156.ref@mail.yahoo.com> <1207216277.1861913.1473142753156@mail.yahoo.com> Message-ID: Thanks for the notification. Problem fixed, will be visible in a couple of minutes. Closing ticket Cheers, Richard On Tue Sep 06 06:44:32 2016, tallevi84 at yahoo.com wrote: > Hi, > I've encountered the following error: "an error occurred while > processing this directive" when > opening the news log. https://www.openssl.org/news/newslog.html > Thanks. > Tal. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4672 Please log in as guest with password guest if prompted From anirudhp at avaya.com Tue Sep 6 07:00:14 2016 From: anirudhp at avaya.com (Patel, Anirudh (Anirudh)) Date: Tue, 6 Sep 2016 07:00:14 +0000 Subject: [openssl-dev] APIs to convert a downloaded DER format CRL file to PEM format Message-ID: Hi Guys, I have a task to perform where I need to convert a downloaded CRL file which is in DER format to PEM format. As of now I came across one API which helps me to read the downloaded CRL file. BIO* crlBIO = NULL; X509_CRL* dlCRL = NULL; bool retCode = false; if ((crlBIO = (BIO_new(BIO_s_file()))) == NULL) { return retCode; } if (BIO_read_filename(crlBIO, hashFilePath) == 0) { return retCode; } if ((dlCRL = d2i_X509_CRL_bio(crlBIO, NULL)) == NULL) { } Now can I convert this dlCRL to PEM format? All this needs to be done programmatically and not by executing openssl crl commands. Thanks, Anirudh -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Sep 6 07:55:49 2016 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Sep 2016 08:55:49 +0100 Subject: [openssl-dev] APIs to convert a downloaded DER format CRL file to PEM format In-Reply-To: References: Message-ID: <6290730a-f1ba-3cba-21cb-210a2f804d98@openssl.org> On 06/09/16 08:00, Patel, Anirudh (Anirudh) wrote: > Now can I convert this dlCRL to PEM format? All this needs to be done > programmatically and not by executing openssl crl commands. Yes. Use PEM_write_bio_X509_CRL(), or PEM_write_X509_CRL(): https://www.openssl.org/docs/manmaster/crypto/PEM_read_X509.html Matt From anirudhp at avaya.com Tue Sep 6 11:33:21 2016 From: anirudhp at avaya.com (Patel, Anirudh (Anirudh)) Date: Tue, 6 Sep 2016 11:33:21 +0000 Subject: [openssl-dev] APIs to convert a downloaded DER format CRL file to PEM format In-Reply-To: <6290730a-f1ba-3cba-21cb-210a2f804d98@openssl.org> References: <6290730a-f1ba-3cba-21cb-210a2f804d98@openssl.org> Message-ID: Thanks a lot !!! -----Original Message----- From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Tuesday, September 06, 2016 1:26 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] APIs to convert a downloaded DER format CRL file to PEM format On 06/09/16 08:00, Patel, Anirudh (Anirudh) wrote: > Now can I convert this dlCRL to PEM format? All this needs to be done > programmatically and not by executing openssl crl commands. Yes. Use PEM_write_bio_X509_CRL(), or PEM_write_X509_CRL(): https://urldefense.proofpoint.com/v2/url?u=https-3A__www.openssl.org_docs_manmaster_crypto_PEM-5Fread-5FX509.html&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=tPCSvJtcu_uId0NG6Yo9I8n--A7FxNDZiXMcudwKPjM&s=KQy0slyF2P2Q05rM4o0Io8iGALOG351feKT5xPDs_Gs&e= Matt -- openssl-dev mailing list To unsubscribe: https://urldefense.proofpoint.com/v2/url?u=https-3A__mta.openssl.org_mailman_listinfo_openssl-2Ddev&d=CwICAg&c=BFpWQw8bsuKpl1SgiZH64Q&r=r_yFHjnA3pyorIMQVU-vjyndTmY6-rsuMCBf8EzS6oU&m=tPCSvJtcu_uId0NG6Yo9I8n--A7FxNDZiXMcudwKPjM&s=FiHjKbO9X_7TRgZtZPqpOQgi60KV-LApuor4fwi-zpY&e= From rt at openssl.org Tue Sep 6 14:58:38 2016 From: rt at openssl.org (REIX, Tony via RT) Date: Tue, 06 Sep 2016 14:58:38 +0000 Subject: [openssl-dev] [openssl.org #4667] Issue with OpenSSL v1.1.0 on AIX with XLC and GCC and -O In-Reply-To: <57CED92F.1060705@atos.net> References: <57C6FCB5.1010100@atos.net> <57C7FDC9.8040800@atos.net> <57C83F59.30908@atos.net> <57CED92F.1060705@atos.net> Message-ID: Hi Andy, Your patch DOES work fine with GCC 6.2.0 and -O, both for 32 & 64bits. It also works fine with XLC v12.1.0.14 and -O in 64bits (was OK in 32bits). Thanks for your help ! Regards, Tony Le 03/09/2016 00:42, Andy Polyakov via RT a ?crit : - GCC 6.1.0 is: KO, 64 & 32 bits: # Failed test 'running evp_test evptests.txt' # at ../test/recipes/30-test_evp.t line 18. # Looks like you failed 1 test of 1. ../test/recipes/30-test_evp.t .............. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/1 subtests Phew! Mystery solved! Verify attached patch. Trouble was that vector ChaCha subroutine relies on its alignment in memory. But on AIX it's impossible to *control* alignment with desired granularity without specifying higher alignment for .text segment itself. And .text directive was missing in chacha-ppc module :-( So it's not exactly optimizations of ppccap.o that mattered, but its changing size depending on optimization options that was affecting chacha subroutine's alignment. It actually *could* be vice versa, i.e. work with optimizations on and fail without, it's all about a coincidence. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted ATOS WARNING ! This message contains attachments that could potentially harm your computer. Please make sure you open ONLY attachments from senders you know, trust and is in an e-mail that you are expecting. AVERTISSEMENT ATOS ! Ce message contient des pi?ces jointes qui peuvent potentiellement endommager votre ordinateur. Merci de vous assurer que vous ouvrez uniquement les pi?ces jointes provenant d?emails que vous attendez et dont vous connaissez les exp?diteurs et leur faites confiance. AVISO DE ATOS ! Este mensaje contiene datos adjuntos que pudiera ser que da?aran su ordenador. Aseg?rese de abrir SOLO datos adjuntos enviados desde remitentes de confianza y que procedan de un correo esperado. ATOS WARNUNG ! Diese E-Mail enth?lt Anlagen, welche m?glicherweise ihren Computer besch?digen k?nnten. Bitte beachten Sie, da? Sie NUR Anlagen ?ffnen, von einem Absender den Sie kennen, vertrauen und vom dem Sie vor allem auch E-Mails mit Anlagen erwarten. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4667 Please log in as guest with password guest if prompted From rsalz at akamai.com Tue Sep 6 17:11:01 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 17:11:01 +0000 Subject: [openssl-dev] dates, times, durations in next release (commands) Message-ID: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> I am thinking of standardizing the syntax for dates, times, and durations used by the applications in the next releases, based on http://www.w3schools.com/xml/schema_dtypes_date.asp (with the extension that lowercase letters can also be used). Objects that need dates (x509 etc) will have a standard -start flag. It takes an ISO date-time, the time defaulting to 00:00. A time and duration can be specified by putting /duration after the start date. Or the abosolute time can be specified with an -end flag. For example -start 2017-02-10/p30d -start 2017-02-10 -end 2017-03-12 Both mean the same thing, from Feb 10 for 30 days. Comments? -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Tue Sep 6 17:39:33 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Sep 2016 19:39:33 +0200 (CEST) Subject: [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160906.193933.2272151712340631325.levitte@openssl.org> In message <490f88be6dcf4d5c9baa3f3b5e4c4e83 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 6 Sep 2016 17:11:01 +0000, "Salz, Rich" said: rsalz> I am thinking of standardizing the syntax for dates, times, and rsalz> durations used by the applications in the next releases, based on rsalz> http://www.w3schools.com/xml/schema_dtypes_date.asp (with the rsalz> extension that lowercase letters can also be used). rsalz> rsalz> Objects that need dates (x509 etc) will have a standard ?start flag. rsalz> It takes an ISO date-time, the time defaulting to 00:00. A time and rsalz> duration can be specified by putting /duration after the start date. rsalz> Or the abosolute time can be specified with an ?end flag. For example rsalz> rsalz> -start 2017-02-10/p30d rsalz> rsalz> -start 2017-02-10 ?end 2017-03-12 rsalz> rsalz> Both mean the same thing, from Feb 10 for 30 days. rsalz> rsalz> Comments? It's not a huge step to support full blown ISO 8601 (which has a few more alternatives to specify time intervals *). I like the idea. Cheers, Richard (*) https://en.wikipedia.org/wiki/ISO_8601 -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Tue Sep 6 19:14:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 19:14:38 +0000 Subject: [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <20160906.193933.2272151712340631325.levitte@openssl.org> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> Message-ID: <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> > It's not a huge step to support full blown ISO 8601 (which has a few more > alternatives to specify time intervals *). I like the idea. No, it *is* a huge step. There's a reason why W3C XML schema language (XSD), not known for being lightweight, profiled the ISO standard. From levitte at openssl.org Tue Sep 6 19:34:17 2016 From: levitte at openssl.org (Richard Levitte) Date: Tue, 06 Sep 2016 21:34:17 +0200 (CEST) Subject: [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160906.213417.1719569548619936717.levitte@openssl.org> In message <3a1728b8c014426bb3e557832d275961 at usma1ex-dag1mb1.msg.corp.akamai.com> on Tue, 6 Sep 2016 19:14:38 +0000, "Salz, Rich" said: rsalz> rsalz> > It's not a huge step to support full blown ISO 8601 (which has a few more rsalz> > alternatives to specify time intervals *). I like the idea. rsalz> rsalz> No, it *is* a huge step. There's a reason why W3C XML schema language (XSD), not known for being lightweight, profiled the ISO standard. Sorry, I was unclear. What I meant was that it's not a huge step from the XSD to full blown ISO 8601. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From rsalz at akamai.com Tue Sep 6 20:25:00 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 6 Sep 2016 20:25:00 +0000 Subject: [openssl-dev] dates, times, durations in next release (commands) In-Reply-To: <20160906.213417.1719569548619936717.levitte@openssl.org> References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.213417.1719569548619936717.levitte@openssl.org> Message-ID: <0e12673775fc460f9927690c8a1ece22@usma1ex-dag1mb1.msg.corp.akamai.com> > Sorry, I was unclear. What I meant was that it's not a huge step from the XSD > to full blown ISO 8601. No, sorry, *I* was unclear. I think it is a huge step to go full-blown. E.g., all the missing fields and the 'w' duration. From leonb at parsec.co.za Wed Sep 7 04:49:52 2016 From: leonb at parsec.co.za (Leon Brits) Date: Wed, 7 Sep 2016 04:49:52 +0000 Subject: [openssl-dev] FIPS validation In-Reply-To: <0efe79c6-094b-9b28-b6e7-d04f2eb521fc@openssl.com> References: <5a2f4d52f9e04fef839b4f36772777fc@EXCHANGESRV.PARSEC.local> <0efe79c6-094b-9b28-b6e7-d04f2eb521fc@openssl.com> Message-ID: Hi SteveM, Yes we are copycats - thanks for making it possible. I was also amazed when I received the email very close to our final source code review and operational testing phase. I've used the fips_algv tests suite to have the algorithms validated (#3768) using this lab but I cannot see how to use it to "induce" and error in the FIPS module. I think they want to see that we go into an error state in such cases. Should I use gdb to step into the module and alter return values? Can I compile the FIPS module like that without breaking the compile rules? Thanks for your time LJB > -----Original Message----- > From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of > Steve Marquess > Sent: 05 September 2016 01:33 PM > To: openssl-dev at openssl.org > Subject: Re: [openssl-dev] FIPS validation > > On 09/05/2016 02:09 AM, Leon Brits wrote: > > The FIPS validation company says: > > > > > > > > "The tests I am most interested in are the failure cases, where you > > induce an error in each of the power-on self-tests and conditional > > tests (i.e, continuous RNG test, pairwise consistency test)." > > > > > > > > Can anybody tell me how I can induce these errors? > > > > > > > > I do run the FIPS_selftest() function on demand and the POST has never > > failed when I switch to FIPS mode with FIPS_mode_set(). > > > > > > > > Thanks > > > > LJB > > > > > > > > So you're trying to obtain your own copycat validation based on the > OpenSSL FIPS Object Module code (as many vendors have done). > > Since that has been done so many times your unnamed FIPS validation > consultant or test lab should already be familiar enough with the OpenSSL > FIPS module code to immediately know the answer to this question, rather > than asking it of you (that's a hint). > > Most labs or consultants would direct you to the "fips_test_suite" test > harness (also called from fips_algvs), which is included in the OpenSSL > FIPS module tarballs and documented in the User Guide: > > https://www.openssl.org/docs/fips/UserGuide-2.0.pdf > > Test labs typically just run "fips_algv fips_test_suite" for the > functional testing, as it was designed for exactly that purpose. > > -Steve M. > > -- > Steve Marquess > OpenSSL Validation Services, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From rsalz at akamai.com Wed Sep 7 11:11:38 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Sep 2016 11:11:38 +0000 Subject: [openssl-dev] [openssl-users] dates, times, durations in next release (commands) In-Reply-To: References: <490f88be6dcf4d5c9baa3f3b5e4c4e83@usma1ex-dag1mb1.msg.corp.akamai.com> <20160906.193933.2272151712340631325.levitte@openssl.org> <3a1728b8c014426bb3e557832d275961@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <8f654ee535f74dc1a297ddd4d9f24483@usma1ex-dag1mb1.msg.corp.akamai.com> > Support RFC3339[1] is relative?easy. But it's not enough, as folks are asking for the ability to specify durations. From yordanosb at gmail.com Thu Sep 8 06:11:34 2016 From: yordanosb at gmail.com (yordanos beyene) Date: Wed, 7 Sep 2016 23:11:34 -0700 Subject: [openssl-dev] temporary EC Diffie-Hellman parameters Message-ID: Hello, I appreciate if anyone can guide me how to set temporary EC Diffie-Hellman parameters to be able to accept SSL connections from a client using ephemeral ECDHE cipher. I have an ssl based application that can accept SSL connections. I can establish SSL connections from a client using RSA cipher ( eg AES128-SHA), but when I use ECDHE ciphers (eg ECDHE-RSA-AES128-SHA), the SSL handshake fails. I have been googling to understand the issue for several hours, and it looks like I need to set temporary DH parameters. I added the following code right after SSL initialization and creating context. ... EC_KEY *ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); ecdh = EC_KEY_new_by_curve_name (NID_X9_62_prime256v1); if (! ecdh) error (); if (1 != SSL_CTX_set_tmp_ecdh (session_cache_ctx, ecdh)) return -ENOMEM; EC_KEY_free (ecdh); ... But it is still not working. I am not familiar with this area, and I greatly appreciate any help. I am running OpenSSL 1.0.1.EC JA. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwmw2 at infradead.org Thu Sep 8 13:07:57 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Sep 2016 14:07:57 +0100 Subject: [openssl-dev] Certificate torture test In-Reply-To: References: <1472845012.3390.75.camel@infradead.org> Message-ID: <1473340077.86279.141.camel@infradead.org> On Fri, 2016-09-02 at 20:20 +0000, Salz, Rich wrote: > > > > I've started collecting a certificate torture test suite at > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/ > > Makefile.am > > I think this is cool, and splitting it off is a good idea. I think > some IETF folks would be interested, too. Any suggestions on where to discuss this would be most welcome. I'd quite like to solicit input *before* splitting it out into its own project and presenting it as a fait accompli. For me, this is part of a larger crusade around SSL client certificates. For users, *all* software really sucks for this. Applications need to do better, and crypto libraries need to stop making it *hard* for applications to do better. I've *tried* to do a good job in OpenConnect, and it still sucks. Users report "my cert didn't work" bugs, but for some reason they're reluctant to provide a copy of the file and its passphrase, for me to reproduce the issue. :) I was actually trying to fix curl when I came up with the idea of the torture test... and quickly came to the realisation that I had to get my own house in order first. Which first involved fixing GnuTLS and OpenSSL because for some cases they weren't just making it *hard* for the application to do the right thing; they were making it *impossible*. So now I have a collection of RSA/DSA/EC certificates and keys in various esoteric file formats, and PKCS#11 objects where the key doesn't expose its public component or the certificate is marked private, etc. But there's more to it than just splitting out my own test suite into a separate project in its own right ? I actually want to set an expectation everywhere that "well behaved" applications *will* pass it, so that users can actually come to depend on consistent behaviour, and file bugs that get taken seriously if there's a failure. As things stand, users experience a whole *bunch* of crap that they just shouldn't, including: ?"My distribution builds this application against GnuTLS but this PEM? ? file is in the non-standard OpenSSL encrypted form so it doesn't? ? work." ?"My token doesn't expose the EC public key so I can't authenticate to ? the VPN... unless I rebuild OpenConnect to use GnuTLS instead of? ? OpenSSL. But I'm on CentOS where GnuTLS is too old to support Cisco's ? broken pre-standard version of DTLS." ?"My distribution builds cURL against NSS so the standard form of the ? URI doesn't work and I have to use a NSS-specific way of specify the ? cert instead." ?"Hm, my token is installed correctly and works everywhere. I can see? ? my cert in 'seahorse' and 'p11tool' and use it from OpenConnect? but ? why doesn't it work in Firefox? Oh, because NSS doesn't actually? ? load the tokens listed in the system configuration." ?"OK, so I fixed that... but now why doesn't it show up in Chrome. That ? uses NSS too, right? Oh, I have to add it to a *different* ? configuration file, ffs." ?"Now openvpn doesn't support the standard URI form either, it uses ? libpkcs11-helper which has an entirely different format that I need ? to use to specify the certificate." ?"Ick, when wpa_supplicant is built against OpenSSL it needs all this? ? explicit "engine" configuration nonsense in *addition* to needing ? the cert to be specified in a non-standard form. Unlike when built ? with GnuTLS, when it does just accept a RFC7512 PKCS#11 URI in its ? 'certificate' option." ?"Argh, FFS. The OpenSSL engine doesn't load the tokens listed in the? ? system configuration *either*, and needs to be explicitly told which ? provider module to load. And my application doesn't even give me the? ? hook to do that." ?"Oh, 'openvpn --cert' takes PEM files according to its documentation? ? but wait, *this* is a PEM file and it doesn't seem to work. Why?" ?"Hm, all this *used* to work but when I just renewed my certificate, ? it magically stopped working... oh, because the new cert was issued ? with OpenSSL 1.1 and that uses a SHA256 HMAC by default which this ? version of GnuTLS doesn't cope with. ?"Oh, my cert is marked with CKA_PRIVATE but libp11 doesn't return it ? from PKCS11_enumerate_certs() even *after* I log in, so I can't use? ? it." ?"Hm, I need to configure my VPN to use the cert in my token but the ? GUI configuration dialog only lets me choose from a file." Now, I've actually *fixed* most of the above; they are historical examples ? even for the 'NSS doesn't take RFC7512 URIs' one I had a GSoC student this year work on it, and patches are filed in bugzilla. But there are *plenty* more where they came from. I have attempted to address expectations through the Fedora packaging guidelines ? which already state that applications which accept certificate filenames SHOULD also accept a PKCS#11 URI according to RFC7512, and Just Work. I'm sure I can make a case for expanding that to cover a more comprehensive set of file and PKCS#11 tests. And that *does* have a knock-on effect in the wider ecosystem, as we fix upstream projects to comply. But this kind of thing shouldn't be distribution-specific. That just *happens* to the policy handle that I can easily influence. I haven't *yet* had an upstream push back and say that they don't want to do this "just for Fedora", but it wouldn't surprise me to see it happen. I'd *really* like to achieve a wider consensus, and I'd very much welcome suggestions for where and how to do that. -- David Woodhouse Open Source Technology Centre David.Woodhouse at intel.com Intel Corporation -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rsalz at akamai.com Thu Sep 8 13:44:11 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Sep 2016 13:44:11 +0000 Subject: [openssl-dev] Certificate torture test In-Reply-To: <1473340077.86279.141.camel@infradead.org> References: <1472845012.3390.75.camel@infradead.org> <1473340077.86279.141.camel@infradead.org> Message-ID: <4821764b5e874064ba74f4970f1cf0f7@usma1ex-dag1mb1.msg.corp.akamai.com> I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/charter/), which is the closest thing to PKIX these days, and perhaps cross-post to the SAAG mailing list the general catch-all for security area https://trac.tools.ietf.org/area/sec/trac/wiki. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From dwmw2 at infradead.org Thu Sep 8 13:55:25 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Sep 2016 14:55:25 +0100 Subject: [openssl-dev] Certificate torture test In-Reply-To: <4821764b5e874064ba74f4970f1cf0f7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1472845012.3390.75.camel@infradead.org> <1473340077.86279.141.camel@infradead.org> <4821764b5e874064ba74f4970f1cf0f7@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1473342925.86279.142.camel@infradead.org> On Thu, 2016-09-08 at 13:44 +0000, Salz, Rich wrote: > I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/c > harter/), which is the closest thing to PKIX these days, and perhaps > cross-post to the SAAG mailing list the general catch-all for > security area https://trac.tools.ietf.org/area/sec/trac/wiki. Thanks. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From marquess at openssl.com Thu Sep 8 13:57:49 2016 From: marquess at openssl.com (Steve Marquess) Date: Thu, 8 Sep 2016 09:57:49 -0400 Subject: [openssl-dev] FIPS validation In-Reply-To: References: <5a2f4d52f9e04fef839b4f36772777fc@EXCHANGESRV.PARSEC.local> <0efe79c6-094b-9b28-b6e7-d04f2eb521fc@openssl.com> Message-ID: On 09/07/2016 12:49 AM, Leon Brits wrote: > Hi SteveM, > > Yes we are copycats - thanks for making it possible. > > I was also amazed when I received the email very close to our final > source code review and operational testing phase. > > I've used the fips_algv tests suite to have the algorithms validated > (#3768) using this lab but I cannot see how to use it to "induce" and > error in the FIPS module. > Look at what the "fips_test_suite" option of fips_algv does. That's also discussed in the OpenSSL FIPS module user guide. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From dwmw2 at infradead.org Thu Sep 8 16:56:52 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 08 Sep 2016 17:56:52 +0100 Subject: [openssl-dev] Certificate torture test In-Reply-To: <4821764b5e874064ba74f4970f1cf0f7@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1472845012.3390.75.camel@infradead.org> <1473340077.86279.141.camel@infradead.org> <4821764b5e874064ba74f4970f1cf0f7@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <1473353812.86279.184.camel@infradead.org> On Thu, 2016-09-08 at 13:44 +0000, Salz, Rich wrote: > I would suggest the LAMPS WG (https://datatracker.ietf.org/wg/lamps/c > harter/), which is the closest thing to PKIX these days, and perhaps > cross-post to the SAAG mailing list the general catch-all for > security area https://trac.tools.ietf.org/area/sec/trac/wiki. I sent this to both lists; thanks again. It doesn't seem to have made it to either list yet, but hopefully it will shortly. -- dwmw2 -------------- next part -------------- An embedded message was scrubbed... From: David Woodhouse Subject: Best practices for applications using X.509 client certificates Date: Thu, 08 Sep 2016 16:14:32 +0100 Size: 12784 URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From rt at openssl.org Mon Sep 12 15:48:31 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 12 Sep 2016 15:48:31 +0000 Subject: [openssl-dev] [openssl.org #4130] Provide enginesdir in pkgconfig file In-Reply-To: <1447055825.81031.20.camel@infradead.org> References: <1447055825.81031.20.camel@infradead.org> Message-ID: Fixed in the 1.1.0 and 1.0.2 branches, as well as master. Closing ticket. Thank you! Cheers, Richard On Mon Nov 09 08:15:26 2015, dwmw2 at infradead.org wrote: > External engines such as engine_pkcs11 want to install into > $ENGINESDIR. Would be nice if we could tell where it is by using > $(pkg-config --variable=enginesdir openssl) > > It's theoretically possible to find it by defining HEADER_CRYPTLIB_H > and then including opensslconf.h, although that's horrid enough even > before you consider cross-compilation (i.e. you can't just use printf). > > Can we put it in openssl.pc please? > > (Of course, something as fundamental as engine_pkcs11 shouldn't be > external anyway, but that's a different story...) > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4130 Please log in as guest with password guest if prompted From rt at openssl.org Mon Sep 12 20:08:10 2016 From: rt at openssl.org (zy_chongqing via RT) Date: Mon, 12 Sep 2016 20:08:10 +0000 Subject: [openssl-dev] [openssl.org #4673] a weird error, please help to check whether is it a but. thanks! In-Reply-To: <28a273a8-e4e6-43b0-b270-b3b721431ecb.zy_chongqing@aliyun.com> References: <28a273a8-e4e6-43b0-b270-b3b721431ecb.zy_chongqing@aliyun.com> Message-ID: Hello, I have a function to initial the CTX as below: #define?CA_CERT_PATH ? ? ? ? ?"./pem" #define?RSA_CLIENT_CERT?????"./pem/PushChatCert.pem" #define?RSA_CLIENT_KEY ? ? ? "./pem/PushChatKey.pem" bool?CAPNSClient::InitCTX() { ????SSL_library_init(); ????SSL_load_error_strings(); ????OpenSSL_add_all_algorithms(); ? ????m_pMeth?=?TLS_client_method(); ????m_pCtx?=?SSL_CTX_new(m_pMeth); ????if(NULL?==?m_pCtx) ????{ ????????ERRLOG("Could?not?get?SSL?Context"); ????????return?false; ????} ????if(0?==?SSL_CTX_load_verify_locations(m_pCtx,?NULL,?CA_CERT_PATH)) ????{ ????????ERRLOG("Failed?to?set?CA?location:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????if?(0?==?SSL_CTX_use_certificate_file(m_pCtx,?RSA_CLIENT_CERT,?SSL_FILETYPE_PEM)) ????{ ????????ERRLOG("Cannot?use?Certificate?File:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????SSL_CTX_set_default_passwd_cb_userdata(m_pCtx,?(void*)"Memo_Server"); ? ????if?(0?==?SSL_CTX_use_PrivateKey_file(m_pCtx,?RSA_CLIENT_KEY,?SSL_FILETYPE_PEM)) ????{ ????????ERRLOG("Cannot?use?Private?Key:%s",?ERR_error_string(?ERR_get_error(),?NULL?)); ????????return?false; ????} ????/*?Check?if?the?client?certificate?and?private-key?matches????????????*/ ????if?(0?==?SSL_CTX_check_private_key(m_pCtx)) ????{ ????????ERRLOG("Private?key?does?not?match?the?certificate?public?key"); ????????return?false; ????} ????return?true; } SSL_CTX_use_certificate_file return 0, and the log show:?error:140AB18F:SSL?routines:SSL_CTX_use_certificate:ee?key?too?small 1. this programe is running well in one server, but failed in another. actually these 2 servers is mirrow relationship.?2. I checked the pem file (as attached), also is same on two servers3. I checked the error reason, but cannot find any description about it in the website.I am almost crazy for this issue, would you help to check what's the reason of this error for me? thanks a lot! my OS:?Linux?version?3.7.10-1.1-desktop?(geeko at buildhost)?(gcc?version?4.7.2?20130108?[gcc-4_7-branch?revision?195012]?(SUSE?Linux)?)?#1?SMP?PREEMPT?Thu?Feb?28?15:06:29?UTC?2013?(82d3f21)OpenSSL version:?OpenSSL?1.1.0??25?Aug?2016 thanks & Regards! -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4673 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: PushChatCert.pem Type: application/octet-stream Size: 2139 bytes Desc: not available URL: From openssl-users at dukhovni.org Tue Sep 13 00:34:56 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 12 Sep 2016 20:34:56 -0400 Subject: [openssl-dev] [openssl.org #4673] a weird error, please help to check whether is it a but. thanks! In-Reply-To: References: <28a273a8-e4e6-43b0-b270-b3b721431ecb.zy_chongqing@aliyun.com> Message-ID: > On Sep 12, 2016, at 4:08 PM, zy_chongqing via RT wrote: > > SSL_CTX_use_certificate_file return 0, and the log show: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small > 1. this programe is running well in one server, but failed in another. actually these 2 servers is mirrow relationship. 2. I checked the pem file (as attached), also is same on two servers3. I checked the error reason, but cannot find any description about it in the website.I am almost crazy for this issue, would you help to check what's the reason of this error for me? thanks a lot! > my OS: Linux version 3.7.10-1.1-desktop (geeko at buildhost) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21)OpenSSL version: OpenSSL 1.1.0 25 Aug 2016 > thanks & Regards! Use stronger keys, see: https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html -- Viktor. From rt at openssl.org Tue Sep 13 00:35:05 2016 From: rt at openssl.org (openssl-users@openssl.org via RT) Date: Tue, 13 Sep 2016 00:35:05 +0000 Subject: [openssl-dev] [openssl.org #4673] a weird error, please help to check whether is it a but. thanks! In-Reply-To: References: <28a273a8-e4e6-43b0-b270-b3b721431ecb.zy_chongqing@aliyun.com> Message-ID: > On Sep 12, 2016, at 4:08 PM, zy_chongqing via RT wrote: > > SSL_CTX_use_certificate_file return 0, and the log show: error:140AB18F:SSL routines:SSL_CTX_use_certificate:ee key too small > 1. this programe is running well in one server, but failed in another. actually these 2 servers is mirrow relationship. 2. I checked the pem file (as attached), also is same on two servers3. I checked the error reason, but cannot find any description about it in the website.I am almost crazy for this issue, would you help to check what's the reason of this error for me? thanks a lot! > my OS: Linux version 3.7.10-1.1-desktop (geeko at buildhost) (gcc version 4.7.2 20130108 [gcc-4_7-branch revision 195012] (SUSE Linux) ) #1 SMP PREEMPT Thu Feb 28 15:06:29 UTC 2013 (82d3f21)OpenSSL version: OpenSSL 1.1.0 25 Aug 2016 > thanks & Regards! Use stronger keys, see: https://www.openssl.org/docs/manmaster/ssl/SSL_CTX_set_security_level.html -- Viktor. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4673 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 13 17:23:48 2016 From: rt at openssl.org (Brian Howson via RT) Date: Tue, 13 Sep 2016 17:23:48 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: This may be two requests, one a bug and one a feature request. Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords (-1 / -apr1), returns "". I haven't tested other platforms. See output below. Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing algorithms used by unix / linux platforms. This limitation may force people to use weaker password storage than possible, for example if generating crypts using openssl passwd to feed into usermod -p. Please add support for password types 5 (SHA-256) and 6 (SHA-512). http://man7.org/linux/man-pages/man3/crypt.3.html ID | Method ????????????????????????????????????????????????????????? 1 | MD5 2a | Blowfish (not in mainline glibc; added in some | Linux distributions) 5 | SHA-256 (since glibc 2.7) 6 | SHA-512 (since glibc 2.7) Issue 1: collateral: Working in OpenSSL 1.0.2.h: D:\>openssl version OpenSSL 1.0.2h 3 May 2016 D:\>openssl passwd -apr1 password $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. D:\>openssl passwd -1 password $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 Compiled Openssl 1.1.0: D:\OpenSSL\openssl-1.1.0\apps>.\openssl version OpenSSL 1.1.0 25 Aug 2016 D:\OpenSSL\openssl-1.1.0\apps>.\openssl version OpenSSL 1.1.0 25 Aug 2016 D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password UZ8kfkzdGoYTQ D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password (To show that MD5 wasn't compiled out): D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help Usage: passwd [options] Valid options are: -help Display this summary -in infile Pead passwords from file -noverify Never verify when reading password from terminal -quiet No warnings -table Format output as table -reverse Switch table columns -salt val Use provided salt -stdin Read passwords from stdin -apr1 MD5-based password algorithm, Apache variant -1 MD5-based password algorithm -crypt Standard Unix password algorithm (default) -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 13 20:32:18 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 13 Sep 2016 20:32:18 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: I can confirm issue one and raise you one: it's not just on Windows On it. Cheers, Richard On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > This may be two requests, one a bug and one a feature request. > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords > (-1 / -apr1), returns "". I haven't tested other platforms. See > output below. > > Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing > algorithms used by unix / linux platforms. This limitation may force > people to use weaker password storage than possible, for example if > generating crypts using openssl passwd to feed into usermod -p. Please add > support for password types 5 (SHA-256) and 6 (SHA-512). > > http://man7.org/linux/man-pages/man3/crypt.3.html > > ID | Method > ????????????????????????????????????????????????????????? > 1 | MD5 > 2a | Blowfish (not in mainline glibc; added in some > | Linux distributions) > 5 | SHA-256 (since glibc 2.7) > 6 | SHA-512 (since glibc 2.7) > > > Issue 1: collateral: > > Working in OpenSSL 1.0.2.h: > D:\>openssl version > OpenSSL 1.0.2h 3 May 2016 > > D:\>openssl passwd -apr1 password > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > D:\>openssl passwd -1 password > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > Compiled Openssl 1.1.0: > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > OpenSSL 1.1.0 25 Aug 2016 > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > OpenSSL 1.1.0 25 Aug 2016 > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > UZ8kfkzdGoYTQ > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > (To show that MD5 wasn't compiled out): > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > Usage: passwd [options] > Valid options are: > -help Display this summary > -in infile Pead passwords from file > -noverify Never verify when reading password from terminal > -quiet No warnings > -table Format output as table > -reverse Switch table columns > -salt val Use provided salt > -stdin Read passwords from stdin > -apr1 MD5-based password algorithm, Apache variant > -1 MD5-based password algorithm > -crypt Standard Unix password algorithm (default) -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 13 21:37:41 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 13 Sep 2016 21:37:41 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: A note for the future: since this is really two issues, they should be one ticket each. I'll let this one slip by, 'cause it's relatively simple to fix both. However, please understand that while issue 1 will be fixed in OpenSSL 1.1.0a, issue 2 will not appear before OpenSSL 1.1.1. Cheers, Richard On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > This may be two requests, one a bug and one a feature request. > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords > (-1 / -apr1), returns "". I haven't tested other platforms. See > output below. > > Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing > algorithms used by unix / linux platforms. This limitation may force > people to use weaker password storage than possible, for example if > generating crypts using openssl passwd to feed into usermod -p. Please add > support for password types 5 (SHA-256) and 6 (SHA-512). > > http://man7.org/linux/man-pages/man3/crypt.3.html > > ID | Method > ????????????????????????????????????????????????????????? > 1 | MD5 > 2a | Blowfish (not in mainline glibc; added in some > | Linux distributions) > 5 | SHA-256 (since glibc 2.7) > 6 | SHA-512 (since glibc 2.7) > > > Issue 1: collateral: > > Working in OpenSSL 1.0.2.h: > D:\>openssl version > OpenSSL 1.0.2h 3 May 2016 > > D:\>openssl passwd -apr1 password > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > D:\>openssl passwd -1 password > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > Compiled Openssl 1.1.0: > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > OpenSSL 1.1.0 25 Aug 2016 > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > OpenSSL 1.1.0 25 Aug 2016 > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > UZ8kfkzdGoYTQ > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > (To show that MD5 wasn't compiled out): > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > Usage: passwd [options] > Valid options are: > -help Display this summary > -in infile Pead passwords from file > -noverify Never verify when reading password from terminal > -quiet No warnings > -table Format output as table > -reverse Switch table columns > -salt val Use provided salt > -stdin Read passwords from stdin > -apr1 MD5-based password algorithm, Apache variant > -1 MD5-based password algorithm > -crypt Standard Unix password algorithm (default) -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 13 22:32:37 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 13 Sep 2016 22:32:37 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Issue 1 now resolved, fix pushed to master branch as well as OpenSSL_1_1_0-stable. Issue 2 remaining. Cheers, Richard On Tue Sep 13 20:32:18 2016, levitte wrote: > I can confirm issue one and raise you one: it's not just on Windows > > On it. > > Cheers, > Richard > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > > This may be two requests, one a bug and one a feature request. > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 passwords > > (-1 / -apr1), returns "". I haven't tested other platforms. See > > output below. > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password hashing > > algorithms used by unix / linux platforms. This limitation may force > > people to use weaker password storage than possible, for example if > > generating crypts using openssl passwd to feed into usermod -p. Please add > > support for password types 5 (SHA-256) and 6 (SHA-512). > > > > http://man7.org/linux/man-pages/man3/crypt.3.html > > > > ID | Method > > ????????????????????????????????????????????????????????? > > 1 | MD5 > > 2a | Blowfish (not in mainline glibc; added in some > > | Linux distributions) > > 5 | SHA-256 (since glibc 2.7) > > 6 | SHA-512 (since glibc 2.7) > > > > > > Issue 1: collateral: > > > > Working in OpenSSL 1.0.2.h: > > D:\>openssl version > > OpenSSL 1.0.2h 3 May 2016 > > > > D:\>openssl passwd -apr1 password > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > > > D:\>openssl passwd -1 password > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > > > Compiled Openssl 1.1.0: > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > OpenSSL 1.1.0 25 Aug 2016 > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > OpenSSL 1.1.0 25 Aug 2016 > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > > UZ8kfkzdGoYTQ > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > > > > (To show that MD5 wasn't compiled out): > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > > Usage: passwd [options] > > Valid options are: > > -help Display this summary > > -in infile Pead passwords from file > > -noverify Never verify when reading password from terminal > > -quiet No warnings > > -table Format output as table > > -reverse Switch table columns > > -salt val Use provided salt > > -stdin Read passwords from stdin > > -apr1 MD5-based password algorithm, Apache variant > > -1 MD5-based password algorithm > > -crypt Standard Unix password algorithm (default) > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 02:09:15 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 14 Sep 2016 02:09:15 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572 Please try it out. Cheers, Richard On Tue Sep 13 22:32:37 2016, levitte wrote: > Issue 1 now resolved, fix pushed to master branch as well as > OpenSSL_1_1_0-stable. > > Issue 2 remaining. > > Cheers, > Richard > > On Tue Sep 13 20:32:18 2016, levitte wrote: > > I can confirm issue one and raise you one: it's not just on Windows > > > > On it. > > > > Cheers, > > Richard > > > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > > > This may be two requests, one a bug and one a feature request. > > > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 > > > passwords > > > (-1 / -apr1), returns "". I haven't tested other platforms. > > > See > > > output below. > > > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password > > > hashing > > > algorithms used by unix / linux platforms. This limitation may > > > force > > > people to use weaker password storage than possible, for example if > > > generating crypts using openssl passwd to feed into usermod -p. > > > Please add > > > support for password types 5 (SHA-256) and 6 (SHA-512). > > > > > > http://man7.org/linux/man-pages/man3/crypt.3.html > > > > > > ID | Method > > > ????????????????????????????????????????????????????????? > > > 1 | MD5 > > > 2a | Blowfish (not in mainline glibc; added in some > > > | Linux distributions) > > > 5 | SHA-256 (since glibc 2.7) > > > 6 | SHA-512 (since glibc 2.7) > > > > > > > > > Issue 1: collateral: > > > > > > Working in OpenSSL 1.0.2.h: > > > D:\>openssl version > > > OpenSSL 1.0.2h 3 May 2016 > > > > > > D:\>openssl passwd -apr1 password > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > > > > > D:\>openssl passwd -1 password > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > > > > > Compiled Openssl 1.1.0: > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > > > UZ8kfkzdGoYTQ > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > > > > > > > (To show that MD5 wasn't compiled out): > > > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > > > Usage: passwd [options] > > > Valid options are: > > > -help Display this summary > > > -in infile Pead passwords from file > > > -noverify Never verify when reading password from terminal > > > -quiet No warnings > > > -table Format output as table > > > -reverse Switch table columns > > > -salt val Use provided salt > > > -stdin Read passwords from stdin > > > -apr1 MD5-based password algorithm, Apache variant > > > -1 MD5-based password algorithm > > > -crypt Standard Unix password algorithm (default) > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 02:58:10 2016 From: rt at openssl.org (Brian Howson via RT) Date: Wed, 14 Sep 2016 02:58:10 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Thanks Richard, Quick work on issue 1, I git cloned & tested it, works as expected. I downloaded the pull above, built it and it appears to work. I found test vectors in the specification document here: https://www.akkadia.org/drepper/sha-crypt.html openssl passwd -5 -salt saltstring "Hello world!" | find "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5" openssl passwd -6 -salt saltstring "Hello world!" | find "$6$saltstring$svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBFdcbYEdFCoEOfaS35inz1" So looks good. One suggestion is to re-order the help output so it's in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's minor. Cheers, Brian On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT wrote: > Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572 > > Please try it out. > > Cheers, > Richard > > On Tue Sep 13 22:32:37 2016, levitte wrote: > > Issue 1 now resolved, fix pushed to master branch as well as > > OpenSSL_1_1_0-stable. > > > > Issue 2 remaining. > > > > Cheers, > > Richard > > > > On Tue Sep 13 20:32:18 2016, levitte wrote: > > > I can confirm issue one and raise you one: it's not just on Windows > > > > > > On it. > > > > > > Cheers, > > > Richard > > > > > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > > > > This may be two requests, one a bug and one a feature request. > > > > > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 > > > > passwords > > > > (-1 / -apr1), returns "". I haven't tested other platforms. > > > > See > > > > output below. > > > > > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password > > > > hashing > > > > algorithms used by unix / linux platforms. This limitation may > > > > force > > > > people to use weaker password storage than possible, for example if > > > > generating crypts using openssl passwd to feed into usermod -p. > > > > Please add > > > > support for password types 5 (SHA-256) and 6 (SHA-512). > > > > > > > > http://man7.org/linux/man-pages/man3/crypt.3.html > > > > > > > > ID | Method > > > > ????????????????????????????????????????????????????????? > > > > 1 | MD5 > > > > 2a | Blowfish (not in mainline glibc; added in some > > > > | Linux distributions) > > > > 5 | SHA-256 (since glibc 2.7) > > > > 6 | SHA-512 (since glibc 2.7) > > > > > > > > > > > > Issue 1: collateral: > > > > > > > > Working in OpenSSL 1.0.2.h: > > > > D:\>openssl version > > > > OpenSSL 1.0.2h 3 May 2016 > > > > > > > > D:\>openssl passwd -apr1 password > > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > > > > > > > D:\>openssl passwd -1 password > > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > > > > > > > Compiled Openssl 1.1.0: > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > > > > UZ8kfkzdGoYTQ > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > > > > > > > > > > (To show that MD5 wasn't compiled out): > > > > > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > > > > Usage: passwd [options] > > > > Valid options are: > > > > -help Display this summary > > > > -in infile Pead passwords from file > > > > -noverify Never verify when reading password from terminal > > > > -quiet No warnings > > > > -table Format output as table > > > > -reverse Switch table columns > > > > -salt val Use provided salt > > > > -stdin Read passwords from stdin > > > > -apr1 MD5-based password algorithm, Apache variant > > > > -1 MD5-based password algorithm > > > > -crypt Standard Unix password algorithm (default) > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org > > -- > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 > Please log in as guest with password guest if prompted > > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 03:16:11 2016 From: rt at openssl.org (Brian Howson via RT) Date: Wed, 14 Sep 2016 03:16:11 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Richard, I had taken a crack at this and got to the point of actually needing sha2crypt(). I compared your changes to mine, which is all pretty predictable so matched line by line. The only exception is 203, which is because it's entirely redundant as the max_pwlen defaults to 256. So maybe: - else if (use1 || useapr1) + else if (use1 || useapr1 || use5 || use6) or - else if (use1 || useapr1) - pw_maxlen = 256; /* arbitrary limit, should be enough for most - * passwords */ Cheers, Brian On Tue, Sep 13, 2016 at 10:57 PM, Brian Howson wrote: > Thanks Richard, > Quick work on issue 1, I git cloned & tested it, works as expected. > I downloaded the pull above, built it and it appears to work. > > I found test vectors in the specification document here: > https://www.akkadia.org/drepper/sha-crypt.html > > > openssl passwd -5 -salt saltstring "Hello world!" | find > "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5" > > openssl passwd -6 -salt saltstring "Hello world!" | find "$6$saltstring$ > svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBF > dcbYEdFCoEOfaS35inz1" > > > So looks good. One suggestion is to re-order the help output so it's > in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's minor. > > > Cheers, > Brian > > On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT > wrote: > >> Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572 >> >> Please try it out. >> >> Cheers, >> Richard >> >> On Tue Sep 13 22:32:37 2016, levitte wrote: >> > Issue 1 now resolved, fix pushed to master branch as well as >> > OpenSSL_1_1_0-stable. >> > >> > Issue 2 remaining. >> > >> > Cheers, >> > Richard >> > >> > On Tue Sep 13 20:32:18 2016, levitte wrote: >> > > I can confirm issue one and raise you one: it's not just on Windows >> > > >> > > On it. >> > > >> > > Cheers, >> > > Richard >> > > >> > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: >> > > > This may be two requests, one a bug and one a feature request. >> > > > >> > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 >> > > > passwords >> > > > (-1 / -apr1), returns "". I haven't tested other platforms. >> > > > See >> > > > output below. >> > > > >> > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password >> > > > hashing >> > > > algorithms used by unix / linux platforms. This limitation may >> > > > force >> > > > people to use weaker password storage than possible, for example if >> > > > generating crypts using openssl passwd to feed into usermod -p. >> > > > Please add >> > > > support for password types 5 (SHA-256) and 6 (SHA-512). >> > > > >> > > > http://man7.org/linux/man-pages/man3/crypt.3.html >> > > > >> > > > ID | Method >> > > > ????????????????????????????????????????????????????????? >> > > > 1 | MD5 >> > > > 2a | Blowfish (not in mainline glibc; added in some >> > > > | Linux distributions) >> > > > 5 | SHA-256 (since glibc 2.7) >> > > > 6 | SHA-512 (since glibc 2.7) >> > > > >> > > > >> > > > Issue 1: collateral: >> > > > >> > > > Working in OpenSSL 1.0.2.h: >> > > > D:\>openssl version >> > > > OpenSSL 1.0.2h 3 May 2016 >> > > > >> > > > D:\>openssl passwd -apr1 password >> > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. >> > > > >> > > > D:\>openssl passwd -1 password >> > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 >> > > > >> > > > Compiled Openssl 1.1.0: >> > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version >> > > > OpenSSL 1.1.0 25 Aug 2016 >> > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version >> > > > OpenSSL 1.1.0 25 Aug 2016 >> > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password >> > > > UZ8kfkzdGoYTQ >> > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password >> > > > >> > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password >> > > > >> > > > >> > > > (To show that MD5 wasn't compiled out): >> > > > >> > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help >> > > > Usage: passwd [options] >> > > > Valid options are: >> > > > -help Display this summary >> > > > -in infile Pead passwords from file >> > > > -noverify Never verify when reading password from terminal >> > > > -quiet No warnings >> > > > -table Format output as table >> > > > -reverse Switch table columns >> > > > -salt val Use provided salt >> > > > -stdin Read passwords from stdin >> > > > -apr1 MD5-based password algorithm, Apache variant >> > > > -1 MD5-based password algorithm >> > > > -crypt Standard Unix password algorithm (default) >> > > >> > > >> > > -- >> > > Richard Levitte >> > > levitte at openssl.org >> > >> > >> > -- >> > Richard Levitte >> > levitte at openssl.org >> >> >> -- >> Richard Levitte >> levitte at openssl.org >> >> -- >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 >> Please log in as guest with password guest if prompted >> >> > -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 03:20:49 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 14 Sep 2016 03:20:49 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Those test vectors are already in test/recipes/20-test_passwd.t On Wed Sep 14 02:58:09 2016, bkhowson at gmail.com wrote: > Thanks Richard, > Quick work on issue 1, I git cloned & tested it, works as > expected. > I downloaded the pull above, built it and it appears to work. > > I found test vectors in the specification document here: > https://www.akkadia.org/drepper/sha-crypt.html > > > openssl passwd -5 -salt saltstring "Hello world!" | find > "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5" > > openssl passwd -6 -salt saltstring "Hello world!" | find > "$6$saltstring$svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBFdcbYEdFCoEOfaS35inz1" > > > So looks good. One suggestion is to re-order the help output so it's > in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's > minor. > > > Cheers, > Brian > > On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT > > wrote: > > > Issue 2 is implemented in > > https://github.com/openssl/openssl/pull/1572 > > > > Please try it out. > > > > Cheers, > > Richard > > > > On Tue Sep 13 22:32:37 2016, levitte wrote: > > > Issue 1 now resolved, fix pushed to master branch as well as > > > OpenSSL_1_1_0-stable. > > > > > > Issue 2 remaining. > > > > > > Cheers, > > > Richard > > > > > > On Tue Sep 13 20:32:18 2016, levitte wrote: > > > > I can confirm issue one and raise you one: it's not just on > > > > Windows > > > > > > > > On it. > > > > > > > > Cheers, > > > > Richard > > > > > > > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > > > > > This may be two requests, one a bug and one a feature request. > > > > > > > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate > > > > > MD5 > > > > > passwords > > > > > (-1 / -apr1), returns "". I haven't tested other > > > > > platforms. > > > > > See > > > > > output below. > > > > > > > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password > > > > > hashing > > > > > algorithms used by unix / linux platforms. This limitation may > > > > > force > > > > > people to use weaker password storage than possible, for > > > > > example if > > > > > generating crypts using openssl passwd to feed into usermod -p. > > > > > Please add > > > > > support for password types 5 (SHA-256) and 6 (SHA-512). > > > > > > > > > > http://man7.org/linux/man-pages/man3/crypt.3.html > > > > > > > > > > ID | Method > > > > > ????????????????????????????????????????????????????????? > > > > > 1 | MD5 > > > > > 2a | Blowfish (not in mainline glibc; added in some > > > > > | Linux distributions) > > > > > 5 | SHA-256 (since glibc 2.7) > > > > > 6 | SHA-512 (since glibc 2.7) > > > > > > > > > > > > > > > Issue 1: collateral: > > > > > > > > > > Working in OpenSSL 1.0.2.h: > > > > > D:\>openssl version > > > > > OpenSSL 1.0.2h 3 May 2016 > > > > > > > > > > D:\>openssl passwd -apr1 password > > > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > > > > > > > > > D:\>openssl passwd -1 password > > > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > > > > > > > > > Compiled Openssl 1.1.0: > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > > > > > UZ8kfkzdGoYTQ > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > > > > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > > > > > > > > > > > > > (To show that MD5 wasn't compiled out): > > > > > > > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > > > > > Usage: passwd [options] > > > > > Valid options are: > > > > > -help Display this summary > > > > > -in infile Pead passwords from file > > > > > -noverify Never verify when reading password from terminal > > > > > -quiet No warnings > > > > > -table Format output as table > > > > > -reverse Switch table columns > > > > > -salt val Use provided salt > > > > > -stdin Read passwords from stdin > > > > > -apr1 MD5-based password algorithm, Apache variant > > > > > -1 MD5-based password algorithm > > > > > -crypt Standard Unix password algorithm (default) > > > > > > > > > > > > -- > > > > Richard Levitte > > > > levitte at openssl.org > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > > -- > > Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 > > Please log in as guest with password guest if prompted > > > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 03:21:14 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 14 Sep 2016 03:21:14 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: Done! On Wed Sep 14 03:16:11 2016, bkhowson at gmail.com wrote: > Richard, > I had taken a crack at this and got to the point of actually > needing > sha2crypt(). I compared your changes to mine, which is all pretty > predictable so matched line by line. The only exception is 203, which > is > because it's entirely redundant as the max_pwlen defaults to 256. > > So maybe: > > - else if (use1 || useapr1) > + else if (use1 || useapr1 || use5 || use6) > > or > > - else if (use1 || useapr1) > - pw_maxlen = 256; /* arbitrary limit, should be enough > for > most > - * passwords */ > > Cheers, > Brian > > > On Tue, Sep 13, 2016 at 10:57 PM, Brian Howson > wrote: > > > Thanks Richard, > > Quick work on issue 1, I git cloned & tested it, works as > > expected. > > I downloaded the pull above, built it and it appears to work. > > > > I found test vectors in the specification document here: > > https://www.akkadia.org/drepper/sha-crypt.html > > > > > > openssl passwd -5 -salt saltstring "Hello world!" | find > > "$5$saltstring$5B8vYYiY.CVt1RlTTf8KbXBH3hsxY/GNooZaBBGWEc5" > > > > openssl passwd -6 -salt saltstring "Hello world!" | find > > "$6$saltstring$ > > svn8UoSVapNtMuq1ukKS4tPQd8iKwSMHWjl/O817G3uBnIFNjnQJuesI68u4OTLiBF > > dcbYEdFCoEOfaS35inz1" > > > > > > So looks good. One suggestion is to re-order the help output so it's > > in declining "best to worst" 6 -> 5 -> 1 -> apr1 -> des), but that's > > minor. > > > > > > Cheers, > > Brian > > > > On Tue, Sep 13, 2016 at 10:09 PM, Richard Levitte via RT > > > > wrote: > > > >> Issue 2 is implemented in > >> https://github.com/openssl/openssl/pull/1572 > >> > >> Please try it out. > >> > >> Cheers, > >> Richard > >> > >> On Tue Sep 13 22:32:37 2016, levitte wrote: > >> > Issue 1 now resolved, fix pushed to master branch as well as > >> > OpenSSL_1_1_0-stable. > >> > > >> > Issue 2 remaining. > >> > > >> > Cheers, > >> > Richard > >> > > >> > On Tue Sep 13 20:32:18 2016, levitte wrote: > >> > > I can confirm issue one and raise you one: it's not just on > >> > > Windows > >> > > > >> > > On it. > >> > > > >> > > Cheers, > >> > > Richard > >> > > > >> > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > >> > > > This may be two requests, one a bug and one a feature request. > >> > > > > >> > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate > >> > > > MD5 > >> > > > passwords > >> > > > (-1 / -apr1), returns "". I haven't tested other > >> > > > platforms. > >> > > > See > >> > > > output below. > >> > > > > >> > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password > >> > > > hashing > >> > > > algorithms used by unix / linux platforms. This limitation may > >> > > > force > >> > > > people to use weaker password storage than possible, for > >> > > > example if > >> > > > generating crypts using openssl passwd to feed into usermod > >> > > > -p. > >> > > > Please add > >> > > > support for password types 5 (SHA-256) and 6 (SHA-512). > >> > > > > >> > > > http://man7.org/linux/man-pages/man3/crypt.3.html > >> > > > > >> > > > ID | Method > >> > > > ????????????????????????????????????????????????????????? > >> > > > 1 | MD5 > >> > > > 2a | Blowfish (not in mainline glibc; added in some > >> > > > | Linux distributions) > >> > > > 5 | SHA-256 (since glibc 2.7) > >> > > > 6 | SHA-512 (since glibc 2.7) > >> > > > > >> > > > > >> > > > Issue 1: collateral: > >> > > > > >> > > > Working in OpenSSL 1.0.2.h: > >> > > > D:\>openssl version > >> > > > OpenSSL 1.0.2h 3 May 2016 > >> > > > > >> > > > D:\>openssl passwd -apr1 password > >> > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > >> > > > > >> > > > D:\>openssl passwd -1 password > >> > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > >> > > > > >> > > > Compiled Openssl 1.1.0: > >> > > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > >> > > > OpenSSL 1.1.0 25 Aug 2016 > >> > > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > >> > > > OpenSSL 1.1.0 25 Aug 2016 > >> > > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > >> > > > UZ8kfkzdGoYTQ > >> > > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > >> > > > > >> > > > > >> > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > >> > > > > >> > > > > >> > > > (To show that MD5 wasn't compiled out): > >> > > > > >> > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > >> > > > Usage: passwd [options] > >> > > > Valid options are: > >> > > > -help Display this summary > >> > > > -in infile Pead passwords from file > >> > > > -noverify Never verify when reading password from terminal > >> > > > -quiet No warnings > >> > > > -table Format output as table > >> > > > -reverse Switch table columns > >> > > > -salt val Use provided salt > >> > > > -stdin Read passwords from stdin > >> > > > -apr1 MD5-based password algorithm, Apache variant > >> > > > -1 MD5-based password algorithm > >> > > > -crypt Standard Unix password algorithm (default) > >> > > > >> > > > >> > > -- > >> > > Richard Levitte > >> > > levitte at openssl.org > >> > > >> > > >> > -- > >> > Richard Levitte > >> > levitte at openssl.org > >> > >> > >> -- > >> Richard Levitte > >> levitte at openssl.org > >> > >> -- > >> Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 > >> Please log in as guest with password guest if prompted > >> > >> > > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 14 16:04:05 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Wed, 14 Sep 2016 16:04:05 +0000 Subject: [openssl-dev] [openssl.org #4674] Openssl 1.1.0 passwd bug & feature request In-Reply-To: References: Message-ID: And finally got committed to master, with all suggested fixups. Closing this ticket. Cheers, Richard On Wed Sep 14 02:09:15 2016, levitte wrote: > Issue 2 is implemented in https://github.com/openssl/openssl/pull/1572 > > Please try it out. > > Cheers, > Richard > > On Tue Sep 13 22:32:37 2016, levitte wrote: > > Issue 1 now resolved, fix pushed to master branch as well as > > OpenSSL_1_1_0-stable. > > > > Issue 2 remaining. > > > > Cheers, > > Richard > > > > On Tue Sep 13 20:32:18 2016, levitte wrote: > > > I can confirm issue one and raise you one: it's not just on Windows > > > > > > On it. > > > > > > Cheers, > > > Richard > > > > > > On Tue Sep 13 17:23:48 2016, bkhowson at gmail.com wrote: > > > > This may be two requests, one a bug and one a feature request. > > > > > > > > Issue 1: openssl 1.1.0 passwd on Windows 64 doesn't generate MD5 > > > > passwords > > > > (-1 / -apr1), returns "". I haven't tested other platforms. > > > > See > > > > output below. > > > > > > > > Issue 2: openssl 1.1.0 passwd doesn't support newer password > > > > hashing > > > > algorithms used by unix / linux platforms. This limitation may > > > > force > > > > people to use weaker password storage than possible, for example if > > > > generating crypts using openssl passwd to feed into usermod -p. > > > > Please add > > > > support for password types 5 (SHA-256) and 6 (SHA-512). > > > > > > > > http://man7.org/linux/man-pages/man3/crypt.3.html > > > > > > > > ID | Method > > > > ????????????????????????????????????????????????????????? > > > > 1 | MD5 > > > > 2a | Blowfish (not in mainline glibc; added in some > > > > | Linux distributions) > > > > 5 | SHA-256 (since glibc 2.7) > > > > 6 | SHA-512 (since glibc 2.7) > > > > > > > > > > > > Issue 1: collateral: > > > > > > > > Working in OpenSSL 1.0.2.h: > > > > D:\>openssl version > > > > OpenSSL 1.0.2h 3 May 2016 > > > > > > > > D:\>openssl passwd -apr1 password > > > > $apr1$hU.5TC8J$BaYCimZriQeWKBSupbQuO. > > > > > > > > D:\>openssl passwd -1 password > > > > $1$LxNTmc7h$FHDYsVvavnYy0KqB.2ZIx0 > > > > > > > > Compiled Openssl 1.1.0: > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl version > > > > OpenSSL 1.1.0 25 Aug 2016 > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd password > > > > UZ8kfkzdGoYTQ > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -1 password > > > > > > > > > > > > D:\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -apr1 password > > > > > > > > > > > > (To show that MD5 wasn't compiled out): > > > > > > > > D:\Download\OpenSSL\openssl-1.1.0\apps>.\openssl passwd -help > > > > Usage: passwd [options] > > > > Valid options are: > > > > -help Display this summary > > > > -in infile Pead passwords from file > > > > -noverify Never verify when reading password from terminal > > > > -quiet No warnings > > > > -table Format output as table > > > > -reverse Switch table columns > > > > -salt val Use provided salt > > > > -stdin Read passwords from stdin > > > > -apr1 MD5-based password algorithm, Apache variant > > > > -1 MD5-based password algorithm > > > > -crypt Standard Unix password algorithm (default) > > > > > > > > > -- > > > Richard Levitte > > > levitte at openssl.org > > > > > > -- > > Richard Levitte > > levitte at openssl.org > > > -- > Richard Levitte > levitte at openssl.org -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4674 Please log in as guest with password guest if prompted From openssl-dev at ml.breakpoint.cc Thu Sep 15 18:41:30 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Thu, 15 Sep 2016 20:41:30 +0200 Subject: [openssl-dev] custom X509_LOOKUP_METHOD in openssl 1.1.0 / load cert from memory Message-ID: <20160915184129.7hrrf7lzuy7wzg5p@breakpoint.cc> Hi, I've been looking at spice-gtk to get it compiled against openssl 1.1.0. One problem I have is that they are using a custom X509_LOOKUP_METHOD struct which is now not possible. It seems that this requirement was introduced [1] to able to load certs from within memory instead from file. Is there another way to get this done in 1.1.0 or would you consider providing X509_LOOKUP_mem() which is a struct similar to what they have now in tree? [0] https://cgit.freedesktop.org/spice/spice-gtk/tree/src/spice-channel.c#n2355 [1] https://cgit.freedesktop.org/spice/spice-gtk/commit/?id=1625aef30129d1961bead56bfcc1727ed46d1df3 Sebastian From steve at openssl.org Thu Sep 15 23:17:02 2016 From: steve at openssl.org (Dr. Stephen Henson) Date: Thu, 15 Sep 2016 23:17:02 +0000 Subject: [openssl-dev] custom X509_LOOKUP_METHOD in openssl 1.1.0 / load cert from memory In-Reply-To: <20160915184129.7hrrf7lzuy7wzg5p@breakpoint.cc> References: <20160915184129.7hrrf7lzuy7wzg5p@breakpoint.cc> Message-ID: <20160915231702.GA1935@openssl.org> On Thu, Sep 15, 2016, Sebastian Andrzej Siewior wrote: > Hi, > > I've been looking at spice-gtk to get it compiled against openssl 1.1.0. > One problem I have is that they are using a custom X509_LOOKUP_METHOD > struct which is now not possible. > It seems that this requirement was introduced [1] to able to load certs > from within memory instead from file. > While this isn't exactly the same, individual certificates (available in memory as X509 structures) can be added using X509_STORE_add_cert(). Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From benjamint at bsquare.com Fri Sep 16 12:01:38 2016 From: benjamint at bsquare.com (Ben Tucker) Date: Fri, 16 Sep 2016 13:01:38 +0100 Subject: [openssl-dev] Funded WEC7 Port Message-ID: Hello. I have an upcoming contract to port the tool kit to Windows Embedded Compact 7. The customer is asking for the port to be fully pushed to the mainline where it can be maintained. So I am reaching out to the development team early before the project starts to discuss. I have many years of software development experience working with open source. I must admit that I have made very few contributions in my time, however I am aware that it is important to reach out to developers and make early small patches towards the end goal, if I have any chance of succeeding in getting my contribution excepted. I hope that I am well received, and that you are interested in accepting support for WEC7 into the code base. Best regards, Ben Tucker -- *Ben Tucker* Principal Software Engineer *O * +44 1225 710660 *M * +44 7813 065663 P *Please consider the environment before printing this email* Join the campaign at thinkBeforePrinting.org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: bsquare.png Type: image/png Size: 7705 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: twitter.jpg Type: image/jpeg Size: 608 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: linkedin.jpg Type: image/jpeg Size: 590 bytes Desc: not available URL: From rt at openssl.org Fri Sep 16 13:54:00 2016 From: rt at openssl.org (=?UTF-8?B?R2VvcmcgSMO2bGxyaWds?= via RT) Date: Fri, 16 Sep 2016 13:54:00 +0000 Subject: [openssl-dev] [openssl.org #4675] Bug: Parsing Configuration that contains System Variables In-Reply-To: <001f01d20f87$44baa550$ce2feff0$@gmx.at> References: <001f01d20f87$44baa550$ce2feff0$@gmx.at> Message-ID: Hello, I think there is a bug in the config file parsing code. Configuration: ------------------------------- openssl version -a OpenSSL 1.0.1k 8 Jan 2015 (Library: OpenSSL 1.0.1g 7 Apr 2014) built on: Tue Apr 8 11:04:36 CEST 2014 platform: Cygwin options: bn(64,32) md2(int) rc4(8x,mmx) des(ptr,risc1,16,long) blowfish(idx) compiler: gcc -D_WINDLL -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DTERMIOS -DL_ENDIAN -fomit-frame-pointer -O3 -march=i486 -Wall -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 OPENSSLDIR: "/usr/ssl" ------------------------------- Changed Config File to ------------------------------- cat /usr/ssl/openssl.cnf [req] promt=no distinguished_name=dn default_md=sha256 default_bits=2048 req_extensions=alt_names [dn] C=AT ST=SomeState L=MyLocation O="Test" OU="Test" E="test at example.com" [alt_names] subjectAltName=${ENV::SAN} ------------------------------- As long as $SAN is unset I get openssl version 6870300:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:618:line 17 Setting an empty variable, fixes the problem: export SAN="" && openssl version OpenSSL 1.0.1k 8 Jan 2015 (Library: OpenSSL 1.0.1g 7 Apr 2014) Expected beahviour: Such a configuration file should also work when it contains an empty variable. I've tested this behaivor on different systems and with different verison. Kind Regards, Georg -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4675 Please log in as guest with password guest if prompted From rt at openssl.org Fri Sep 16 14:18:14 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Fri, 16 Sep 2016 14:18:14 +0000 Subject: [openssl-dev] [openssl.org #4675] Bug: Parsing Configuration that contains System Variables In-Reply-To: <001f01d20f87$44baa550$ce2feff0$@gmx.at> References: <001f01d20f87$44baa550$ce2feff0$@gmx.at> Message-ID: On Fri Sep 16 13:54:00 2016, georg.hoellrigl at gmx.at wrote: > > As long as $SAN is unset I get > openssl version > 6870300:error:0E065068:configuration file routines:STR_COPY:variable has no > value:conf_def.c:618:line 17 > This is expected and documented behaviour: see config manual page for details. If you want a non existent environment variable to have a default value you can use the default section to define it. Again see config manual page and examples for details. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4675 Please log in as guest with password guest if prompted From rsalz at akamai.com Fri Sep 16 15:12:37 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Sep 2016 15:12:37 +0000 Subject: [openssl-dev] Funded WEC7 Port In-Reply-To: References: Message-ID: <44638c9559664476bf056869b08ed79c@usma1ex-dag1mb1.msg.corp.akamai.com> This is advice from one team member, hope it helps. My personal opinion, don?t take it as gospel. I don?t know if we have any interest in supporting WEC7, it would depend on how big the changes are ? the fewer the better -- and if anyone on the team has a particular interest (and can run the OS). We now try to avoid platforms that we can?t actually test ourselves. Do things as pull request(s) on github. You might find https://www.openssl.org/community/getting-started.html useful and/or interesting. And thanks for the interest! -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Fri Sep 16 15:26:03 2016 From: hkario at redhat.com (Hubert Kario) Date: Fri, 16 Sep 2016 17:26:03 +0200 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 Message-ID: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> I've been running tests on the openssl 1.1.0 release recently and I've noticed that if the client doesn't include the supported_groups extension, OpenSSL will pick curve with id 0x001d, that is ecdh_x25519, as the curve to do ECDHE over. While this is not incorrect behaviour according to the standard (it is quite explicit that if client doesn't provide this extension, server can pick any curve it wants), I'm afraid that this will cause interoperability problems. The majority of servers (71%) support *only* prime256v1 curve and of the ones that default to ECDHE key exchange nearly 83% will also default to this curve. OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised by client. So it is very likely that any client that doesn't advertise curves will expect the server to select prime256v1. At the same time it is very unlikely that it will support x25519 (given how new it is). -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Fri Sep 16 15:52:30 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Sep 2016 15:52:30 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> Message-ID: <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> > The majority of servers (71%) support *only* prime256v1 curve and of the > ones that default to ECDHE key exchange nearly 83% will also default to this > curve. That's because most people have not moved to OpenSSL 1.1.0 yet. I'm not joking, I think that's a major reason. > OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised > by client. When I made X25519 the default, I didn't think about it. That was probably a mistake. Good catch! > So it is very likely that any client that doesn't advertise curves will expect the > server to select prime256v1. At the same time it is very unlikely that it will > support x25519 (given how new it is). Well the major browsers support it now, so once servers start upgrading to 1.1.0 it will be less of an issue. But maybe the community thinks the current behavior is a bug? From uri at ll.mit.edu Fri Sep 16 15:57:21 2016 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 16 Sep 2016 15:57:21 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On 9/16/16, 11:52, "openssl-dev on behalf of Salz, Rich" wrote: >>OpenSSL 1.0.2h also defaults to this curve if there are no curves advertised >> by client. > >When I made X25519 the default, I didn't think about it. That was probably a mistake. Good catch! I think so. > >> So it is very likely that any client that doesn't advertise curves will expect the >> server to select prime256v1. At the same time it is very unlikely that it will >> support x25519 (given how new it is). > >Well the major browsers support it now, so once servers start upgrading to 1.1.0 it will be less of an issue. But maybe the community thinks the current behavior is a bug? Yes I think it is a bug, and would like to see this behavior reverted. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From kudzu at tenebras.com Fri Sep 16 15:57:59 2016 From: kudzu at tenebras.com (Michael Sierchio) Date: Fri, 16 Sep 2016 08:57:59 -0700 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich wrote: ... That's because most people have not moved to OpenSSL 1.1.0 yet. I'm not > joking, I think that's a major reason. Well, you've provided them with a reason. ;-) Srsly, thanks for not making the NIST curves the default. - M -- "Well," Brahma said, "even after ten thousand explanations, a fool is no wiser, but an intelligent man requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Fri Sep 16 18:09:55 2016 From: rt at openssl.org (=?UTF-8?B?R2VvcmcgSMO2bGxyaWds?= via RT) Date: Fri, 16 Sep 2016 18:09:55 +0000 Subject: [openssl-dev] [openssl.org #4675] Bug: Parsing Configuration that contains System Variables In-Reply-To: <000a01d21045$81d937d0$858ba770$@gmx.at> References: <001f01d20f87$44baa550$ce2feff0$@gmx.at> <000a01d21045$81d937d0$858ba770$@gmx.at> Message-ID: Hello, I found a working configuration now. I could not find that when searching fort he problem. Nevertheless, it still feels somehow not working as expected. Thank you very much for pointing me in the right direction and sorry for bothering you. Georg -----Urspr?ngliche Nachricht----- Von: Stephen Henson via RT [mailto:rt at openssl.org] Gesendet: Freitag, 16. September 2016 16:18 An: georg.hoellrigl at gmx.at Cc: openssl-dev at openssl.org Betreff: [openssl.org #4675] Bug: Parsing Configuration that contains System Variables On Fri Sep 16 13:54:00 2016, georg.hoellrigl at gmx.at wrote: > > As long as $SAN is unset I get > openssl version > 6870300:error:0E065068:configuration file routines:STR_COPY:variable > has no value:conf_def.c:618:line 17 > This is expected and documented behaviour: see config manual page for details. If you want a non existent environment variable to have a default value you can use the default section to define it. Again see config manual page and examples for details. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4675 Please log in as guest with password guest if prompted -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4675 Please log in as guest with password guest if prompted From davidben at google.com Sat Sep 17 01:31:32 2016 From: davidben at google.com (David Benjamin) Date: Sat, 17 Sep 2016 01:31:32 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: When we added X25519 to BoringSSL, we at the same time started made the server require clients supply a curve list (and otherwise we'd just pick a non-ECDHE cipher), because of this issue. That went in back in December 2015 and it's been running just fine. I'd recommend OpenSSL do the same. Another option is to have separate notions of "most preferred" and "default" curve, but just requiring the curve list is cleaner. That turns out to be practical and aligns well with TLS 1.3. I think if we had to implement the "default" version, we'd probably have treated missing curve list as an advertisement of P-256, so if you prefer the other option, that seems a reasonable implementation strategy. (I don't have any data on how prevalent such clients are. The issue was noticed during implementation, so we never actually saw the breakage.) David On Fri, Sep 16, 2016 at 11:58 AM Michael Sierchio wrote: > > On Fri, Sep 16, 2016 at 8:52 AM, Salz, Rich wrote: > > ... > > That's because most people have not moved to OpenSSL 1.1.0 yet. I'm not > joking, I think that's a major reason. > > > Well, you've provided them with a reason. ;-) Srsly, thanks for not making > the NIST curves the default. > > - M > > -- > "Well," Brahma said, "even after ten thousand explanations, a fool is no > wiser, but an intelligent man requires only two thousand five hundred." > > - The Mah?bh?rata > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Sep 17 14:35:20 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 17 Sep 2016 14:35:20 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> > When we added X25519 to BoringSSL, we at the same time started made the server require clients supply a curve list (and otherwise we'd just pick a non-ECDHE cipher), because of this issue. That went in back in December 2015 and it's been running just fine. I'd recommend OpenSSL do the same. In other words: only use ECDHE if client specifies a curve list. WFM. From openssl-users at dukhovni.org Sat Sep 17 14:50:29 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 17 Sep 2016 14:50:29 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160917145028.GM4670@mournblade.imrryr.org> On Sat, Sep 17, 2016 at 02:35:20PM +0000, Salz, Rich wrote: > > When we added X25519 to BoringSSL, we at the same time started made the > > server require clients supply a curve list (and otherwise we'd just pick > > a non-ECDHE cipher), because of this issue. That went in back in December > > 2015 and it's been running just fine. I'd recommend OpenSSL do the same. > > In other words: only use ECDHE if client specifies a curve list. WFM. If a client offers ECDHE ciphers with no curve list, one might alternatively just use P-256. It is likely better than the other choices. Most clients will send a curve list. -- Viktor. From rsalz at akamai.com Sat Sep 17 15:46:53 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 17 Sep 2016 15:46:53 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <20160917145028.GM4670@mournblade.imrryr.org> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> <20160917145028.GM4670@mournblade.imrryr.org> Message-ID: <9a7e413e49fd4ac4930a2f6c0cff6122@usma1ex-dag1mb1.msg.corp.akamai.com> > > In other words: only use ECDHE if client specifies a curve list. WFM. > > If a client offers ECDHE ciphers with no curve list, one might alternatively just > use P-256. It is likely better than the other choices. Most clients will send a > curve list. Most will, and I'd rather get people off P256 and onto X25519, which is why I prefer no ECDHE unless the client sends a curve list. From openssl-users at dukhovni.org Sat Sep 17 16:06:22 2016 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 17 Sep 2016 16:06:22 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <9a7e413e49fd4ac4930a2f6c0cff6122@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> <20160917145028.GM4670@mournblade.imrryr.org> <9a7e413e49fd4ac4930a2f6c0cff6122@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <20160917160622.GN4670@mournblade.imrryr.org> On Sat, Sep 17, 2016 at 03:46:53PM +0000, Salz, Rich wrote: > > If a client offers ECDHE ciphers with no curve list, one might alternatively just > > use P-256. It is likely better than the other choices. Most clients will send a > > curve list. > > Most will, and I'd rather get people off P256 and onto X25519, which is > why I prefer no ECDHE unless the client sends a curve list. I think our responsibility to our users is primarily to provide the best security we're able, and only secondarily to prod and nudge them in the direction of progress. Offering X25519 and making it preferred over P-256 is compatible with those priorities. Avoiding ECDHE, and using FFDHE or RSA key exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in the interest of the users, and so is not I think in ours. -- Viktor. From davidben at google.com Sat Sep 17 16:14:02 2016 From: davidben at google.com (David Benjamin) Date: Sat, 17 Sep 2016 16:14:02 +0000 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <20160917160622.GN4670@mournblade.imrryr.org> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> <65238ba402a3427abd6dc0ffa63fab86@usma1ex-dag1mb1.msg.corp.akamai.com> <20160917145028.GM4670@mournblade.imrryr.org> <9a7e413e49fd4ac4930a2f6c0cff6122@usma1ex-dag1mb1.msg.corp.akamai.com> <20160917160622.GN4670@mournblade.imrryr.org> Message-ID: On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni wrote: > On Sat, Sep 17, 2016 at 03:46:53PM +0000, Salz, Rich wrote: > > > > If a client offers ECDHE ciphers with no curve list, one might > alternatively just > > > use P-256. It is likely better than the other choices. Most clients > will send a > > > curve list. > > > > Most will, and I'd rather get people off P256 and onto X25519, which is > > why I prefer no ECDHE unless the client sends a curve list. > > I think our responsibility to our users is primarily to provide > the best security we're able, and only secondarily to prod and > nudge them in the direction of progress. > > Offering X25519 and making it preferred over P-256 is compatible > with those priorities. Avoiding ECDHE, and using FFDHE or RSA key > exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in > the interest of the users, and so is not I think in ours. > Chrome always sends the curve list, so it not using DHE isn't really relevant here. Unless I missed one (there's a lot), client listed here either sends the curve list or doesn't support EC at all: https://www.ssllabs.com/ssltest/clients.html Any special-case here will also need to be dismantled or made more complex come TLS 1.3 where the curve/group list is required for (EC)DH-based key agreement. It was honestly a mistake for RFC 4492 to be omitted. In fact, a similar mistake in TLS 1.2 (omitted sigalgs implies SHA-1) actually cost OpenSSL a bug---PR 3560 would have been noticed since the handshake wouldn't have worked---which, in turn, cost the ecosystem. It will take much much longer to stop accepting SHA-1-signed ServerKeyExchange messages in TLS 1.2 because of this. TLS 1.3 fixes this too and forbids omitting sigalgs. David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Sat Sep 17 17:54:12 2016 From: rt at openssl.org (Peter Wu via RT) Date: Sat, 17 Sep 2016 17:54:12 +0000 Subject: [openssl-dev] [openssl.org #4677] Options after parameters are ignored in OpenSSL 1.1.0 In-Reply-To: <20160917162836.GB17138@al> References: <20160917162836.GB17138@al> Message-ID: Hi, Commands which execute normally with OpenSSL 1.0.2h fail in OpenSSL 1.1.0. Presumably after the "Big apps cleanup (option-parsing, etc)", Options after parameters are no longer interpreted. For example, 'openssl dhparam 128 -out /dev/null' used to discard the DH params output, but since 1.0.2 it no longer happens. I also noticed that 'openssl genrsa -help' no longer displays the 'numbits' option. -- Kind regards, Peter Wu https://lekensteyn.nl -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4677 Please log in as guest with password guest if prompted From rt at openssl.org Sat Sep 17 20:18:31 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Sat, 17 Sep 2016 20:18:31 +0000 Subject: [openssl-dev] [openssl.org #4677] Options after parameters are ignored in OpenSSL 1.1.0 In-Reply-To: <20160917162836.GB17138@al> References: <20160917162836.GB17138@al> Message-ID: On Sat Sep 17 17:54:11 2016, peter at lekensteyn.nl wrote: > Hi, > > Commands which execute normally with OpenSSL 1.0.2h fail in OpenSSL > 1.1.0. Presumably after the "Big apps cleanup (option-parsing, etc)", > > Options after parameters are no longer interpreted. For example, > 'openssl dhparam 128 -out /dev/null' used to discard the DH params > output, but since 1.0.2 it no longer happens. You're right. There should at least be a warning > I also noticed that 'openssl genrsa -help' no longer displays the > 'numbits' option. Good point. I'll have a closer look at this and the other commands in the next few days. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4677 Please log in as guest with password guest if prompted From rt at openssl.org Sun Sep 18 12:39:03 2016 From: rt at openssl.org (Ziyan Zhou via RT) Date: Sun, 18 Sep 2016 12:39:03 +0000 Subject: [openssl-dev] [openssl.org #4678] Bug: the 'dhtest_rfc5114_2048_224_bad_y' in dhtest.c didn't fail in FIPS mode In-Reply-To: <0bcf29ee-6bd7-539f-7ac9-2613322183ec@oracle.com> References: <0bcf29ee-6bd7-539f-7ac9-2613322183ec@oracle.com> Message-ID: Hi, The test case openssl-1.0.2h/test/dhtest.c failed when running in FIPS mode, because the BAD test vector 'dhtest_rfc5114_2048_224_bad_y' didn't fail. I found this issue when I was trying to run regular OpenSSL test code in FIPS mode. OpenSSL version: 1.0.2 OpenSSL fips version: 2.0.12 OS: CentOS release 6.7 (Final) Before building the dhtest.c, I did some code changes. [STEP 1] Calling FIPS_mode_set(1); in dhtest.c [STEP 2] Modifying the 'prime_len' of DH_generate_parameters_ex (line 128) to 1024 bits since the minimal bit for FIPS mode is 1024-bit. [STEP 3] # gcc -I /usr/local/ssl/include/ -L /usr/local/ssl/lib/ -lcrypto -Wl,-rpath=/usr/local/ssl/lib/ dhtest.c [STEP 4] # ./a.out ..+............... ... RFC5114 parameter test 1 OK RFC5114 parameter test 2 OK RFC5114 parameter test 3 OK Test failed RFC5114 set 4 The expected return value of DH_compute_key(Z1, bady, dhA); is -1, but I got 256. Thanks, Ziyan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4678 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3707 bytes Desc: not available URL: From dwmw2 at infradead.org Mon Sep 19 11:23:36 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 19 Sep 2016 12:23:36 +0100 Subject: [openssl-dev] SSL_CTX_add_cient_custom_ext() and known extensions Message-ID: <1474284216.144982.281.camel@infradead.org> The documentation for SSL_CTX_add_client_custom_ext() states that "the extension type must not be handled by OpenSSL internally or an error occurs". This isn't entirely true. In custom_ext_meth_add() we have this comment: ? ? /* ?????* Don't add if extension supported internally, but make exception ?????* for extension types that previously were not supported, but now are. ?????*/ The code that follows this comment just has an explicit exception for TLSEXT_TYPE_signed_certificate_timestamp, so an application is allowed to register its own handler for that even when OpenSSL does support it. (With another hard-coded check in SSL_CTX_add_client_custom_ext() so that you can only do so if you either don't *enable* OpenSSL's own SCT support.... or do so *after* registering your custom handler. The latter probably isn't intentional.) I'm interested in what interpretation exists of "extension types that previously were not supported, but now are" that isn't a tautology. But mostly I'd like to know how it would relate to the PSK identity support in?draft-jay-tls-psk-identity-extension?. I'd like to use that extension for OpenConnect VPN, but I'm concerned that when the RFC is published and OpenSSL starts to support it, my call to SSL_CTX_add_client_custom_ext() would suddenly start failing. Would it? -- dwmw2 ? https://tools.ietf.org/html/draft-jay-tls-psk-identity-extension-01 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From hkario at redhat.com Mon Sep 19 13:10:16 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 19 Sep 2016 15:10:16 +0200 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <95dcf6fd36754a8792ba7aadded833a1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <4431628.q54ALB4nmq@pintsize.usersys.redhat.com> On Friday, 16 September 2016 15:52:30 CEST Salz, Rich wrote: > > The majority of servers (71%) support *only* prime256v1 curve and of the > > ones that default to ECDHE key exchange nearly 83% will also default to > > this curve. > > That's because most people have not moved to OpenSSL 1.1.0 yet. I'm not > joking, I think that's a major reason. > > OpenSSL 1.0.2h also defaults to this curve if there are no curves > > advertised by client. > > When I made X25519 the default, I didn't think about it. That was probably > a mistake. Good catch! > > So it is very likely that any client that doesn't advertise curves will > > expect the server to select prime256v1. At the same time it is very > > unlikely that it will support x25519 (given how new it is). > > Well the major browsers support it now, so once servers start upgrading to > 1.1.0 it will be less of an issue. But maybe the community thinks the > current behavior is a bug? if client advertised curves, and the curves include stuff besides prime256v1 I *expect* the other stuff to be negotiated, unless it's smaller than 256 bits, but it's not what I was talking about I'm talking only about the case of "no curves advertised at all" i.e. supported_groups extension missing completely from client hello -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From hkario at redhat.com Mon Sep 19 13:14:46 2016 From: hkario at redhat.com (Hubert Kario) Date: Mon, 19 Sep 2016 15:14:46 +0200 Subject: [openssl-dev] X25519 is the default curve for ECDHE in OpenSSL 1.1.0 In-Reply-To: References: <1653994.qcj3bjmN45@pintsize.usersys.redhat.com> <20160917160622.GN4670@mournblade.imrryr.org> Message-ID: <10460292.eyFDlVAK9b@pintsize.usersys.redhat.com> On Saturday, 17 September 2016 16:14:02 CEST David Benjamin wrote: > On Sat, Sep 17, 2016 at 12:06 PM Viktor Dukhovni > > wrote: > > On Sat, Sep 17, 2016 at 03:46:53PM +0000, Salz, Rich wrote: > > > > If a client offers ECDHE ciphers with no curve list, one might > > > > alternatively just > > > > > > use P-256. It is likely better than the other choices. Most clients > > > > will send a > > > > > > curve list. > > > > > > Most will, and I'd rather get people off P256 and onto X25519, which is > > > why I prefer no ECDHE unless the client sends a curve list. > > > > I think our responsibility to our users is primarily to provide > > the best security we're able, and only secondarily to prod and > > nudge them in the direction of progress. > > > > Offering X25519 and making it preferred over P-256 is compatible > > with those priorities. Avoiding ECDHE, and using FFDHE or RSA key > > exchange (recall that Chrome, e.g., avoids FFDHE) is not IMHO in > > the interest of the users, and so is not I think in ours. > > Chrome always sends the curve list, so it not using DHE isn't really > relevant here. Unless I missed one (there's a lot), client listed here > either sends the curve list or doesn't support EC at all: > https://www.ssllabs.com/ssltest/clients.html but there may be clients that used similar logic to not advertise DHE ciphers... > Any special-case here will also need to be dismantled or made more complex > come TLS 1.3 where the curve/group list is required for (EC)DH-based key > agreement. It was honestly a mistake for RFC 4492 to be omitted. > > In fact, a similar mistake in TLS 1.2 (omitted sigalgs implies SHA-1) > actually cost OpenSSL a bug---PR 3560 would have been noticed since the > handshake wouldn't have worked---which, in turn, cost the ecosystem. It > will take much much longer to stop accepting SHA-1-signed ServerKeyExchange > messages in TLS 1.2 because of this. TLS 1.3 fixes this too and forbids > omitting sigalgs. yes, those were mistakes on part of specifications (probably to allow people not to implement extensions properly for at least "just a wee bit longer"), but it is in specifications, and it is essentially set in stone by already deployed implementations any kind of departure from this behaviour is likely to cause interoperability failures (and they will be blamed on OpenSSL as it was the last thing that changed...) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 99/71, 612 45, Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part. URL: From rt at openssl.org Tue Sep 20 10:38:22 2016 From: rt at openssl.org (ELHARRAR via RT) Date: Tue, 20 Sep 2016 10:38:22 +0000 Subject: [openssl-dev] [openssl.org #4680] new_session_callback issue. In-Reply-To: References: Message-ID: Hi OpenSSL team, A simple question: I wrote a proof of concept in order to use external cache for session id. In my POC I used openssl version 1.1.0 and all seemed OK. I mean, as server, the new_session callback was called as expected (at the first connection) and then the get_session callback, when the client send me an non empty session id in client hello. When I want to introduce this code in our real project, which uses openssl 1.0.2e, I see that at the first connection (when the session id in client hello is empty), the server does not call the new_session callback. Then it send a session id in server hello, and at the reuse (when session id is not empty in client hello) it call get_session and because the session was not cached, it call new_session callback because it generate a new session. Do you know something about this issue ? Thanks Mikael -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4680 Please log in as guest with password guest if prompted From rt at openssl.org Tue Sep 20 10:38:22 2016 From: rt at openssl.org (Ziyan Zhou via RT) Date: Tue, 20 Sep 2016 10:38:22 +0000 Subject: [openssl-dev] [openssl.org #4679] Bug: The 'test4' in openssl-1.0.2h/test/hmactest.c dumped core in FIPS mode In-Reply-To: <9bfef65a-d42c-1864-1856-dd3b0d860ce8@oracle.com> References: <9bfef65a-d42c-1864-1856-dd3b0d860ce8@oracle.com> Message-ID: Hi, When I was trying run the test code openssl-1.0.2h/test/hmactest.c in FIPS mode, I got SIGSEGV. I did following changes to run it in FIPS mode. a) Added FIPS_mode_set(1); b) Commented out the test 1 ~ test 3 since MD5 is not supported in FIPS mode. c) I renamed hmactest.c to hmactest_changed_for_test4_in_fips.c OpenSSL version: 1.0.2h OpenSSL FIPS version: 2.0.12 OS: CentOS 6.7 I compiled it like this: # gcc -I /usr/local/ssl/include/ -L /usr/local/ssl/lib/ -lcrypto -Wl,-rpath=/usr/local/ssl/lib/ hmactest_changed_for_test4_in_fips.c (The e_os.h is at same directory with hmactest.c) Output from gdb: (gdb) 192 if (HMAC_Init_ex(&ctx, NULL, 0, NULL, NULL)) { (gdb) 197 if (HMAC_Update(&ctx, test[4].data, test[4].data_len)) { (gdb) Program received signal SIGSEGV, Segmentation fault. This issue could be reproduced with the attached hmactest_changed_for_test4_in_fips.c Thanks, Ziyan -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4679 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: hmactest_changed_for_test4_in_fips.c Type: text/x-csrc Size: 11728 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3707 bytes Desc: not available URL: From rt at openssl.org Tue Sep 20 15:43:44 2016 From: rt at openssl.org (ELHARRAR via RT) Date: Tue, 20 Sep 2016 15:43:44 +0000 Subject: [openssl-dev] [openssl.org #4680] new_session_callback issue. In-Reply-To: References: , Message-ID: Sorry it is not a bug. It was a mistake in my code. I just want to know when exactly the callbacks new and get are called when I work with external caching. Thanks Mikael Sent from my iPhone > On 20 Sep 2016, at 1:38 PM, The default queue via RT wrote: > > [openssl.org #4680] -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4680 Please log in as guest with password guest if prompted From openssl-dev at ml.breakpoint.cc Tue Sep 20 19:31:42 2016 From: openssl-dev at ml.breakpoint.cc (Sebastian Andrzej Siewior) Date: Tue, 20 Sep 2016 21:31:42 +0200 Subject: [openssl-dev] [PATCH] rand/randfile: return the home directory if possible Message-ID: <20160920193142.5e2hpgsmml4cxs2d@breakpoint.cc> From: Sebastian Andrzej Siewior The command |$ openssl rand -base64 3 |gIX3 |unable to write 'random state' the last line is an error because `s' is never initialized if RANDFILE is not set. It never tries to look for $HOME for the normal user. The manpage says: |On all systems, if the environment variable RANDFILE is set, its value |will be used as the seed file name. not possible, go on |Otherwise, the file is called ".rnd", found in platform dependent locations: | On all other systems | $HOME Won't work for "normal" user. This was change in commit fc6076ca272f ("rand/randfile.c: make it non-ASCII-savvy."). Was this change on purpose? Signed-off-by: Sebastian Andrzej Siewior --- crypto/rand/randfile.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/crypto/rand/randfile.c b/crypto/rand/randfile.c index 7aeb87174370..0574cfcc3860 100644 --- a/crypto/rand/randfile.c +++ b/crypto/rand/randfile.c @@ -318,7 +318,8 @@ const char *RAND_file_name(char *buf, size_t size) #else if (OPENSSL_issetugid() == 0) { s = getenv("RANDFILE"); - } else { + } + if (!s) { use_randfile = 0; if (OPENSSL_issetugid() == 0) s = getenv("HOME"); -- 2.9.3 From rsalz at akamai.com Tue Sep 20 19:33:14 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 20 Sep 2016 19:33:14 +0000 Subject: [openssl-dev] [PATCH] rand/randfile: return the home directory if possible In-Reply-To: <20160920193142.5e2hpgsmml4cxs2d@breakpoint.cc> References: <20160920193142.5e2hpgsmml4cxs2d@breakpoint.cc> Message-ID: > Won't work for "normal" user. This was change in commit fc6076ca272f > ("rand/randfile.c: make it non-ASCII-savvy."). Was this change on purpose? The change was on purpose and a slightly different fix is in progress and will show up soon. From rt at openssl.org Tue Sep 20 19:58:37 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Tue, 20 Sep 2016 19:58:37 +0000 Subject: [openssl-dev] [openssl.org #4669] Enhancement request: let dgst support multiple files In-Reply-To: References: <20160901130354.9sJb2yJa7%steffen@sdaoden.eu> <20160902131710.l_9a4xKFW%steffen@sdaoden.eu> <1a38cc4ea1374df29a93c0506bae9fc1@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Fix in place in master, OpenSSL_1_1_0-stable and OpenSSL_1_0_2-stable Closing ticket. Cheers, Richard On Fri Sep 02 14:57:41 2016, rsalz at akamai.com wrote: > Yeah, something like that for 1.0.2; simpler for 1.1.0. I'll do it. > -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4669 Please log in as guest with password guest if prompted From openssl at openssl.org Thu Sep 22 10:56:19 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:56:19 +0000 Subject: [openssl-dev] OpenSSL version 1.0.1u published Message-ID: <20160922105619.GA14190@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.1u released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.1u of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.1-notes.html OpenSSL 1.0.1u is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.1u.tar.gz Size: 4567068 SHA1 checksum: 93e542696598517862115fbe76a93ab66369661d SHA256 checksum: 4312b4ca1215b6f2c97007503d80db80d5157f76f8f7d3febbe6b4c56ff26739 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.1u.tar.gz openssl sha256 openssl-1.0.1u.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX47LHAAoJENnE0m0OYESRBtwH/3+HUEkaq0AjniBI23BI3e42 AiU2dCKv4DvHo4x1lNHw79GCywY06saybIcdsIri8exR7JJqi2IJ5n7inL5GA0ss 3ts98r7mDmu3qd0Qo559avsb5ChVN4PIgAXbI76uoohmbpFYowHO7pVX75kXu6Eh STzjVxjlzkM7ka2CmE/D19x1sRWvlpwaWoBQ/DwUOC+1qpyMbTzqM/RODBucwT3T pqjivwSM6mgMYoWuAUMq/r4pvFCvS08GBOSf8XLNqLVNEgmO5b3FkuxxXnoR1m2R IjDqtn3d0aRTSruKsUXfVSwWgk+la3m8Hr8sCNACRZu03GSa0NwLXrc8vYH2iMM= =Ozj3 -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:56:45 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:56:45 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2i published Message-ID: <20160922105645.GA14378@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2i released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2i of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2i is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2i.tar.gz Size: 5308232 SHA1 checksum: 25a92574ebad029dcf2fa26c02e10400a0882111 SHA256 checksum: 9287487d11c9545b6efb287cdb70535d4e9b284dd10d51441d9b9963d000de6f The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2i.tar.gz openssl sha256 openssl-1.0.2i.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX47F5AAoJENnE0m0OYESRetYH/18tGdVDBTKEEhDxYQZ+UYCk CQpQK9Bjamv8/zD8uhj+jN92gSccTR3cPZGA88lMu5SbM48G+eU5znA8xopeHtcQ nLhiQ4XTq/Y31nGXpyAwXQElRAiEXix5QP7CA3kSAJDLF18TTzbzJWXv4wFfUPKS /5smGDQyv+40P82uo0KcS0ZRGJTH933LQCK8qqrtduxxtQRdBMU+BYuLPJZrMyFt iN05WawKk1527tqN4pmqzEVBghzd1lGe/D5VKnm77UH8zYXYPWeVXNoUoKGldMFv QCnuZ1thYCLnaolLvfzM9L4bRtIT0cOsermmes6myjRJBXUQhipjcRm4z8UGQlY= =6DTt -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:57:15 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:57:15 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0a published Message-ID: <20160922105715.GA14577@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0a released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0a of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0a is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0a.tar.gz Size: 5161414 SHA1 checksum: 335d7168b612efd3cf16f621b09d4cd5af4232a6 SHA256 checksum: c2e696e34296cde2c9ec5dcdad9e4f042cd703932591d395c389de488302442b The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0a.tar.gz openssl sha256 openssl-1.1.0a.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX468gAAoJENnE0m0OYESRMCUIAK+hb9xpoYbWNbGBm1rwp75G 9O0uBRCNtHEgyNcnrSW9bV0HT4v/EG64IFR9KmcTYn8Jc9GIh9176I/kb233V/sI 1MJ7sUmPXODKLp1Pjz8p8dcUrS1I+rO9QfLkgZD8LEEv3yaAzku4XVNPvyJ3v2Dg MYdz5qMvzEJBYtY2BlXbsTAlWj2h5kRvQpOTxS3jsNBEyU9o7HtQClFfHffcf80j tjiBw/oKmawQQSyz9ZcamUEd7YS3BAzCbdRXJd7halXfcJcEwu6ZcI7pNm+g6lHI WI0bxgX8K8olXzboWeF4AybfRgH5Y1hiMwpCrCjFWqWHbNA6A8lhJOb7NsOpOH4= =OiyL -----END PGP SIGNATURE----- From openssl at openssl.org Thu Sep 22 10:58:09 2016 From: openssl at openssl.org (OpenSSL) Date: Thu, 22 Sep 2016 10:58:09 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20160922105809.GA15135@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [22 Sep 2016] ======================================== OCSP Status Request extension unbounded memory growth (CVE-2016-6304) ===================================================================== Severity: High A malicious client can send an excessively large OCSP Status Request extension. If that client continually requests renegotiation, sending a large OCSP Status Request extension each time, then there will be unbounded memory growth on the server. This will eventually lead to a Denial Of Service attack through memory exhaustion. Servers with a default configuration are vulnerable even if they do not support OCSP. Builds using the "no-ocsp" build time option are not affected. Servers using OpenSSL versions prior to 1.0.1g are not vulnerable in a default configuration, instead only if an application explicitly enables OCSP stapling support. OpenSSL 1.1.0 users should upgrade to 1.1.0a OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 29th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. SSL_peek() hang on empty record (CVE-2016-6305) =============================================== Severity: Moderate OpenSSL 1.1.0 SSL/TLS will hang during a call to SSL_peek() if the peer sends an empty record. This could be exploited by a malicious peer in a Denial Of Service attack. OpenSSL 1.1.0 users should upgrade to 1.1.0a This issue was reported to OpenSSL on 10th September 2016 by Alex Gaynor. The fix was developed by Matt Caswell of the OpenSSL development team. SWEET32 Mitigation (CVE-2016-2183) ================================== Severity: Low SWEET32 (https://sweet32.info) is an attack on older block cipher algorithms that use a block size of 64 bits. In mitigation for the SWEET32 attack DES based ciphersuites have been moved from the HIGH cipherstring group to MEDIUM in OpenSSL 1.0.1 and OpenSSL 1.0.2. OpenSSL 1.1.0 since release has had these ciphersuites disabled by default. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 16th August 2016 by Karthikeyan Bhargavan and Gaetan Leurent (INRIA). The fix was developed by Rich Salz of the OpenSSL development team. OOB write in MDC2_Update() (CVE-2016-6303) ========================================== Severity: Low An overflow can occur in MDC2_Update() either if called directly or through the EVP_DigestUpdate() function using MDC2. If an attacker is able to supply very large amounts of input data after a previous call to EVP_EncryptUpdate() with a partial block then a length check can overflow resulting in a heap corruption. The amount of data needed is comparable to SIZE_MAX which is impractical on most platforms. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 11th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Malformed SHA512 ticket DoS (CVE-2016-6302) =========================================== Severity: Low If a server uses SHA512 for TLS session ticket HMAC it is vulnerable to a DoS attack where a malformed ticket will result in an OOB read which will ultimately crash. The use of SHA512 in TLS session tickets is comparatively rare as it requires a custom server callback and ticket lookup mechanism. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 19th August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB write in BN_bn2dec() (CVE-2016-2182) ======================================== Severity: Low The function BN_bn2dec() does not check the return value of BN_div_word(). This can cause an OOB write if an application uses this function with an overly large BIGNUM. This could be a problem if an overly large certificate or CRL is printed out from an untrusted source. TLS is not affected because record limits will reject an oversized certificate before it is parsed. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 2nd August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. OOB read in TS_OBJ_print_bio() (CVE-2016-2180) ============================================== Severity: Low The function TS_OBJ_print_bio() misuses OBJ_obj2txt(): the return value is the total length the OID text representation would use and not the amount of data written. This will result in OOB reads when large OIDs are presented. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 21st July 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Pointer arithmetic undefined behaviour (CVE-2016-2177) ====================================================== Severity: Low Avoid some undefined pointer arithmetic A common idiom in the codebase is to check limits in the following manner: "p + len > limit" Where "p" points to some malloc'd data of SIZE bytes and limit == p + SIZE "len" here could be from some externally supplied data (e.g. from a TLS message). The rules of C pointer arithmetic are such that "p + len" is only well defined where len <= SIZE. Therefore the above idiom is actually undefined behaviour. For example this could cause problems if some malloc implementation provides an address for "p" such that "p + len" actually overflows for values of len that are too big and therefore p + len < limit. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 4th May 2016 by Guido Vranken. The fix was developed by Matt Caswell of the OpenSSL development team. Constant time flag not preserved in DSA signing (CVE-2016-2178) =============================================================== Severity: Low Operations in the DSA signing algorithm should run in constant time in order to avoid side channel attacks. A flaw in the OpenSSL DSA implementation means that a non-constant time codepath is followed for certain operations. This has been demonstrated through a cache-timing attack to be sufficient for an attacker to recover the private DSA key. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 23rd May 2016 by C??sar Pereida (Aalto University), Billy Brumley (Tampere University of Technology), and Yuval Yarom (The University of Adelaide and NICTA). The fix was developed by C??sar Pereida. DTLS buffered message DoS (CVE-2016-2179) ========================================= Severity: Low In a DTLS connection where handshake messages are delivered out-of-order those messages that OpenSSL is not yet ready to process will be buffered for later use. Under certain circumstances, a flaw in the logic means that those messages do not get removed from the buffer even though the handshake has been completed. An attacker could force up to approx. 15 messages to remain in the buffer when they are no longer required. These messages will be cleared when the DTLS connection is closed. The default maximum size for a message is 100k. Therefore the attacker could force an additional 1500k to be consumed per connection. By opening many simulataneous connections an attacker could cause a DoS attack through memory exhaustion. OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u This issue was reported to OpenSSL on 22nd June 2016 by Quan Luo. The fix was developed by Matt Caswell of the OpenSSL development team. DTLS replay protection DoS (CVE-2016-2181) ========================================== Severity: Low A flaw in the DTLS replay attack protection mechanism means that records that arrive for future epochs update the replay protection "window" before the MAC for the record has been validated. This could be exploited by an attacker by sending a record for the next epoch (which does not have to decrypt or have a valid MAC), with a very large sequence number. This means that all subsequent legitimate packets are dropped causing a denial of service for a specific DTLS connection. OpenSSL 1.0.2 DTLS users should upgrade to 1.0.2i OpenSSL 1.0.1 DTLS users should upgrade to 1.0.1u This issue was reported to OpenSSL on 21st November 2015 by the OCAP audit team. The fix was developed by Matt Caswell of the OpenSSL development team. Certificate message OOB reads (CVE-2016-6306) ============================================= Severity: Low In OpenSSL 1.0.2 and earlier some missing message length checks can result in OOB reads of up to 2 bytes beyond an allocated buffer. There is a theoretical DoS risk but this has not been observed in practice on common platforms. The messages affected are client certificate, client certificate request and server certificate. As a result the attack can only be performed against a client or a server which enables client authentication. OpenSSL 1.1.0 is not affected. OpenSSL 1.0.2 users should upgrade to 1.0.2i OpenSSL 1.0.1 users should upgrade to 1.0.1u This issue was reported to OpenSSL on 22nd August 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Stephen Henson of the OpenSSL development team. Excessive allocation of memory in tls_get_message_header() (CVE-2016-6307) ========================================================================== Severity: Low A TLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect DTLS users. OpenSSL 1.1.0 TLS users should upgrade to 1.1.0a This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. Excessive allocation of memory in dtls1_preprocess_fragment() (CVE-2016-6308) ============================================================================= Severity: Low This issue is very similar to CVE-2016-6307. The underlying defect is different but the security analysis and impacts are the same except that it impacts DTLS. A DTLS message includes 3 bytes for its length in the header for the message. This would allow for messages up to 16Mb in length. Messages of this length are excessive and OpenSSL includes a check to ensure that a peer is sending reasonably sized messages in order to avoid too much memory being consumed to service a connection. A flaw in the logic of version 1.1.0 means that memory for the message is allocated too early, prior to the excessive message length check. Due to way memory is allocated in OpenSSL this could mean an attacker could force up to 21Mb to be allocated to service a connection. This could lead to a Denial of Service through memory exhaustion. However, the excessive message length check still takes place, and this would cause the connection to immediately fail. Assuming that the application calls SSL_free() on the failed conneciton in a timely manner then the 21Mb of allocated memory will then be immediately freed again. Therefore the excessive memory allocation will be transitory in nature. This then means that there is only a security impact if: 1) The application does not call SSL_free() in a timely manner in the event that the connection fails or 2) The application is working in a constrained environment where there is very little free memory or 3) The attacker initiates multiple connection attempts such that there are multiple connections in a state where memory has been allocated for the connection; SSL_free() has not yet been called; and there is insufficient memory to service the multiple requests. Except in the instance of (1) above any Denial Of Service is likely to be transitory because as soon as the connection fails the memory is subsequently freed again in the SSL_free() call. However there is an increased risk during this period of application crashes due to the lack of memory - which would then mean a more serious Denial of Service. This issue does not affect TLS users. OpenSSL 1.1.0 DTLS users should upgrade to 1.1.0a This issue was reported to OpenSSL on 18th September 2016 by Shi Lei (Gear Team, Qihoo 360 Inc.). The fix was developed by Matt Caswell of the OpenSSL development team. Note ==== As per our previous announcements and our Release Strategy (https://www.openssl.org/policies/releasestrat.html), support for OpenSSL version 1.0.1 will cease on 31st December 2016. No security updates for that version will be provided after that date. Users of 1.0.1 are advised to upgrade. Support for versions 0.9.8 and 1.0.0 ended on 31st December 2015. Those versions are no longer receiving security updates. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160922.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX465bAAoJENnE0m0OYESRfvoIAIWUhH3TgJvgh+0N4Z3FODmK CjytKRsk13F6tGPocXab5kesm602tQvjF4re9bcSHfzgDKqdrsBcGvX0ouyLzIeK Smsa/CLP2X6BH8oGa2UIbnyA4dRssnO0HPXDUC69SvplYZbhXFD3sBDK6mVudq3G N+WZ7Rba5FpcybR4ha6h13man/ArVY2p24qr0pxrlOivsTDPKHdDsY2JfezoNCKM H12Zsds5bmDxepNaRj8DNvjGJqsXENc8LLMQ1R/djp/R7yNi6OO3IDxA74JXBDsN OR+sPxlyaO7TZcktSk6YOZ5tVACxtbQmo9Tac61Pbx1QwgffK1scq/WNGsjQ1XY= =JPtf -----END PGP SIGNATURE----- From rt at openssl.org Thu Sep 22 12:22:59 2016 From: rt at openssl.org (Roumen Petrov via RT) Date: Thu, 22 Sep 2016 12:22:59 +0000 Subject: [openssl-dev] [openssl.org #4681] X.509 load method In-Reply-To: <57E3C925.9090208@roumenpetrov.info> References: <57E3C925.9090208@roumenpetrov.info> Message-ID: This is an enhancement request. OpenSSL 1.1 hides details of structures used to load X.509 certificates, in particular - x509_lookup_method_st , x509_lookup_st and x509_object_st. This impact non OpenSSL projects as external application has to duplicated those structures. Request is OpenSSL do not change those structures until new implementation in a binary incompatible release. It seems to me current look-up method is quite complex. For instance get_by_subject performs two main steps load and query - see "by_dir". In first step code using "query constraint" fetch data and adds each item found to store. Update of store requires thread lock. In second step code query entire store using "query constraint" and prepare result. Query of store requires thread lock. I guess that could be used more simple "callback" model - a method with callback context. Method fetch data, return only item (certificate, CRL, etc.) on each call and so until end of data. With this model library is responsible to update store and to prepare result. Lock of store could be managed internally. Regards, Roumen -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4681 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 22 15:38:35 2016 From: rt at openssl.org (Bruce Stephens via RT) Date: Thu, 22 Sep 2016 15:38:35 +0000 Subject: [openssl-dev] [openssl.org #4682] PKITS tests fails with 1.0.2i on GNU/Linux In-Reply-To: <80zin0rrcu.fsf@tinier.isode.net> References: <80zin0rrcu.fsf@tinier.isode.net> Message-ID: The problem appears to be 325da823, x509_vfy.c line 1132. best_score starts at 0 (from get_crl_delta's crl_score, initialised to 0), and (for whatever reason) crl_score also turns out to be 0. So if (ASN1_TIME_diff(&day, &sec, X509_CRL_get_lastUpdate(best_crl), X509_CRL_get_lastUpdate(crl)) == 0) segfaults (best_crl is NULL). The test (and the other tests) seem to pass if I change the initialisation in get_crl_delta: int crl_score = -1; I find this with test 4.4.19 specifically (with our own code which uses OpenSSL), but actually pkits-test.pl shows segfaulting for many tests, and this is resolved with the above change (the return codes seem to be different causing the script to report failure, but I suspect that's just the script needing updating). -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4682 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 22 15:39:13 2016 From: rt at openssl.org (Linsell, StevenX via RT) Date: Thu, 22 Sep 2016 15:39:13 +0000 Subject: [openssl-dev] [openssl.org #4683] [BUG] Failure running openssl speed ecdh in master branch In-Reply-To: References: Message-ID: Running against master branch (commit 39c136cc53d7b6fafdd1a0b52c035fd24358e01c - Updates CHANGES and NEWS for new release) we see a failure when running openssl speed with the ecdh parameter: ./openssl speed ecdh Doing 160 bit ecdh's for 10s: 35676 160-bit ECDH ops in 9.98s Doing 192 bit ecdh's for 10s: 29928 192-bit ECDH ops in 9.98s Doing 224 bit ecdh's for 10s: 21881 224-bit ECDH ops in 9.98s Doing 256 bit ecdh's for 10s: 91839 256-bit ECDH ops in 9.98s Doing 384 bit ecdh's for 10s: 9642 384-bit ECDH ops in 9.98s Doing 521 bit ecdh's for 10s: 4737 521-bit ECDH ops in 9.98s Doing 163 bit ecdh's for 10s: 32911 163-bit ECDH ops in 9.98s Doing 233 bit ecdh's for 10s: 25740 233-bit ECDH ops in 9.98s Doing 283 bit ecdh's for 10s: 14392 283-bit ECDH ops in 9.98s Doing 409 bit ecdh's for 10s: 9203 409-bit ECDH ops in 9.98s Doing 571 bit ecdh's for 10s: 3866 571-bit ECDH ops in 9.98s Doing 163 bit ecdh's for 10s: 31212 163-bit ECDH ops in 9.98s Doing 233 bit ecdh's for 10s: 24564 233-bit ECDH ops in 9.98s Doing 283 bit ecdh's for 10s: 13510 283-bit ECDH ops in 9.97s Doing 409 bit ecdh's for 10s: 8603 409-bit ECDH ops in 9.98s Doing 571 bit ecdh's for 10s: 3572 571-bit ECDH ops in 9.98s ECDH failure. 140194445354752:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100: 140194445354752:error:100AE081:elliptic curve routines:EC_GROUP_new_by_curve_name:unknown group:crypto/ec/ec_curve.c:3100: OpenSSL 1.1.1-dev xx XXX xxxx This bug appears to have been introduced by the recent refactoring of X25519. I'm not up to speed on the X25519 curve refactoring and how that curve should be used from the libCrypto interfaces now, so I'm not sure how this issue should be resolved. I could have made a pull request to just remove X25519 from the tested curves but that seemed to be a retrograde step. Let me know if that is the route you would like to take and I can submit a pull request for that if you like. Kind Regards, Steve Linsell Intel Shannon DCG/CID Software Development Team Stevenx.Linsell at intel.com -------------------------------------------------------------- Intel Research and Development Ireland Limited Registered in Ireland Registered Office: Collinstown Industrial Park, Leixlip, County Kildare Registered Number: 308263 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. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4683 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 22 15:55:07 2016 From: rt at openssl.org (Rich Salz via RT) Date: Thu, 22 Sep 2016 15:55:07 +0000 Subject: [openssl-dev] [openssl.org #4682] PKITS tests fails with 1.0.2i on GNU/Linux In-Reply-To: <80zin0rrcu.fsf@tinier.isode.net> References: <80zin0rrcu.fsf@tinier.isode.net> Message-ID: Duplicate of https://github.com/openssl/openssl/issues/1611 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4682 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 22 17:12:14 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 22 Sep 2016 17:12:14 +0000 Subject: [openssl-dev] [openssl.org #4256] CA.pl usage() does not mention -signcert In-Reply-To: <20160922171203.qbchzxjh2bznqjqo@roeckx.be> References: <569E8D8A.7030608@akamai.com> <20160922171203.qbchzxjh2bznqjqo@roeckx.be> Message-ID: On Tue, Jan 19, 2016 at 07:25:04PM +0000, Kaduk, Ben via RT wrote: > Part of the patch submitted to RT #844 includes a patch to the usage > message of CA.pl. Although the functionality itself of CA.pl was > rewritten for 1.1 (so that #844 was closed), the usage message remains > incomplete, and Debian continues to apply a local patch to add the usage. > > So, as mentioned in the closing message of #844, this is a new ticket > for this lingering issue. It seems this was partially fixed in the 1.0.2 version. But there are 2 places it shows the usage, and only 1 of the 2 was updated. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4256 Please log in as guest with password guest if prompted From rt at openssl.org Thu Sep 22 18:42:29 2016 From: rt at openssl.org (Kurt Roeckx via RT) Date: Thu, 22 Sep 2016 18:42:29 +0000 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: <20160922184221.cp6iyzq65kgixawo@roeckx.be> References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: Hi, Please read: http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html We use the same construct for our OPENSSL_cleanse, but I think we also have assmebler versions. Kurt -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684 Please log in as guest with password guest if prompted From rsalz at akamai.com Thu Sep 22 18:45:32 2016 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 22 Sep 2016 18:45:32 +0000 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: We do have assembler versions for most CPI's. Closing ticket. From rt at openssl.org Thu Sep 22 18:45:36 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Thu, 22 Sep 2016 18:45:36 +0000 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: We do have assembler versions for most CPI's. Closing ticket. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4684 Please log in as guest with password guest if prompted From appro at openssl.org Thu Sep 22 20:45:33 2016 From: appro at openssl.org (Andy Polyakov) Date: Thu, 22 Sep 2016 22:45:33 +0200 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: > We do have assembler versions for most CPI's. In the context one can also add that the kind of optimization that could omit memset invocation *has to* rely on deep inter-procedural *multi-file* analysis. If compiler is given mem_clr.c alone, and it doesn't look at it when compiling other modules, it won't be able to eliminate the call. I said it several times already that no security software should encourage deep inter-procedural optimizations such as -flto (or -ipo in Intel compiler context). For reference code generated by Intel compiler (when it's compiling mem_clr.c alone) is equivalent to f = memset_func; if (f==memset) _intel_fast_memset(args) else (*f)(args) From appro at openssl.org Thu Sep 22 22:37:02 2016 From: appro at openssl.org (Andy Polyakov) Date: Fri, 23 Sep 2016 00:37:02 +0200 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: >> We do have assembler versions for most CPI's. > > In the context one can also add that the kind of optimization that could > omit memset invocation *has to* rely on deep inter-procedural > *multi-file* analysis. If compiler is given mem_clr.c alone, and it > doesn't look at it when compiling other modules, it won't be able to > eliminate the call. I said it several times already that no security > software should encourage deep inter-procedural optimizations such as > -flto (or -ipo in Intel compiler context). > > For reference code generated by Intel compiler (when it's compiling > mem_clr.c alone) is equivalent to > > f = memset_func; > if (f==memset) _intel_fast_memset(args) > else (*f)(args) Actually it should also be noted that snippet presented in originally mentioned http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html is actually compiles as just _intel_fast_memset(args) by Intel compiler 17.0 (a.k.a. 2017). I.e. it actually does *not* reference *that* pointer to memset!!! Which in turn means that report is inaccurate claiming that compiler fulfills the contract by always referencing the pointer [just not calling the procedure]. It doesn't, and one can probably argue that compiler doesn't comply with the standard. Or can one? What's going on there? Trouble is that pointer is also declared as const in that example. But what does "const volatile" even mean? In physical world it's actually a meaningless combination, nothing can be both. And even logically it's meaningless. And if so, can one actually blame compiler for making an impossible choice? In addition one should not forget that the referred snippet declares "erase" static, which means that it ought to be a header that gets included, which in turn means that inter-procedural *multi-file* analysis is not required to eliminate it. To summarize. OpenSSL fall-back[!] OPENSSL_cleanse subroutine is different from snippet presented in report in question in two essential ways: - pointer to memset is *not* const (which by the way is not a coincidence, at least in sense that I would have argued against declaring it volatile const, and I likely did, just can't actually recall); - it's in separate file (and hence it takes deep IPA to even nominate it for optimization, which we shouldn't/don't recommend); And once again, not to forget that it's a fall-back[!] procedure for platforms that don't have assembly pack. [Well, with exception for arm64 in 1.0.2. I mean arm64cpuid.S in 1.0.2 doesn't have OPENSSL_cleanse. Should I back-port one from master? And MIPS. I mean MIPS assembly pack doesn't have "cpuid" module...] From dwmw2 at infradead.org Fri Sep 23 11:07:09 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 Sep 2016 12:07:09 +0100 Subject: [openssl-dev] Certificate torture test In-Reply-To: References: <1472845012.3390.75.camel@infradead.org> Message-ID: <1474628829.45169.143.camel@infradead.org> On Fri, 2016-09-02 at 20:20 +0000, Salz, Rich wrote: > > I've started collecting a certificate torture test suite at > > http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/ > > Makefile.am > > I think this is cool, and splitting it off is a good idea.? I think > some IETF?folks would be interested, too. We've turned this into a nascent Internet-Draft. It's not filed yet; preliminary feedback would be very welcome. http://david.woodhou.se/draft-woodhouse-cert-best-practice.html Pull requests accepted at https://github.com/dwmw2/ietf-cert-best-practice There's plenty of things I'm not quite sure about. In particular, is there any reason why we'd want to use the new PKCS#8 formats defined in RFC5958? OpenSSL doesn't support those at all, right? Does anyone? Also, should we make any attempt to handle keys managed by a TPM? Or can we rely on PKCS#11 for that? I note that historically, the OpenSSL TPM ENGINE supported a 'TSS KEY BLOB' PEM format which contained a TPM-wrapped key, and OpenConnect at least would Just Work? when handed such a PEM file. -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From shantibhushan.sale at gmail.com Fri Sep 23 11:21:52 2016 From: shantibhushan.sale at gmail.com (Shantibhushan Sale) Date: Fri, 23 Sep 2016 16:51:52 +0530 Subject: [openssl-dev] Openssl upgrade in debian Message-ID: I am a student developing some tool w.r.t openssl on DEBIAN.Currently my configuration of system is : Kernel:2.6.28.10. Openssl:1.0.1e system:ARMv5 Now i have to upgrade openssl version to Openssl 1.0.1t or higher.I do not have toolchain with me. I would need all binaries which used openssl1.0.1h for above installation.How can i proceed to this? Please help me on this.I need all the depending libraries/packages w.r.t 1.0.1t. Those are: 1.Libencryption. 2.openssh, 3.ntp, 4.ping6, 5.stunnel, 6.openldap Please help me here to solve this. -- *----------------------------RegardsShantibhushan Sale9545534899Pune* -------------- next part -------------- An HTML attachment was scrubbed... URL: From appro at openssl.org Fri Sep 23 11:42:05 2016 From: appro at openssl.org (Andy Polyakov) Date: Fri, 23 Sep 2016 13:42:05 +0200 Subject: [openssl-dev] [openssl.org #4684] Potential problem with OPENSSL_cleanse In-Reply-To: References: <20160922184221.cp6iyzq65kgixawo@roeckx.be> Message-ID: <200eec44-ed12-209f-8805-63c1d8005ebe@openssl.org> > Actually it should also be noted that snippet presented in originally > mentioned > http://www.metzdowd.com/pipermail/cryptography/2016-September/030151.html > is actually compiles as just > > _intel_fast_memset(args) > > by Intel compiler 17.0 (a.k.a. 2017). Second look at code generated by icc 17 revealed following. Consider #include static void *(*volatile const deleter)(void*,int,size_t)=memset; static void erase(void *buf,size_t len){deleter(buf, 0, len);} void foo() { char t[6]; erase(t,sizeof(t)); } void bar() { char t[6]; memset(t,0,sizeof(t)); } As it turns out icc 17 generates *identical* code for *both* foo() and bar(), i.e. foo doesn't reference deleter, but both[!] do wipe t[6]. Moreover, they do it in so called red zone, i.e. above stack pointer, without allocating frame. In other words icc 17 *apparently* considers _intel_fast_memset as memset_s. This by the way also differs from claim in original report. It might happen that reporter refers to different version... And just in case, for reference, gcc (as well as clang) reduces bar() to single return instruction, i.e. as if t is not there, while foo() does dereference deleter. From jingmliu at sina.com Fri Sep 23 13:17:48 2016 From: jingmliu at sina.com (Jing Liu) Date: Fri, 23 Sep 2016 21:17:48 +0800 Subject: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a Message-ID: <008e01d2159c$e9d00010$bd700030$@sina.com> Recently when I used a library 'libcrypto.lib' compiled from OpenSSL 1.1.0a in my project, some compiling errors led me to find that the header file 'evp.h' in OpenSSL 1.1.0a is incomplete. More specifically, definitions for many structures are strangely missing. For example, the definitions for structures EVP_ENCODE_CTX, EVP_CIPHER, EVP_CIPHER_CTX, EVP_MD, EVP_MD_CTX, and EVP_PKEY (maybe there are more) cannot be found in 'evp.h' or 'ossl_typ.h' or any other header files. While for OpenSSL 1.0.X, we can find definitions for these structures in 'evp.h' or other header files. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 23 13:54:41 2016 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 23 Sep 2016 13:54:41 +0000 Subject: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a In-Reply-To: <008e01d2159c$e9d00010$bd700030$@sina.com> References: <008e01d2159c$e9d00010$bd700030$@sina.com> Message-ID: Yes, in 1.1.0 we made many structures opaque. You will have to use accessors/settor functions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Fri Sep 23 14:00:11 2016 From: levitte at openssl.org (Richard Levitte) Date: Fri, 23 Sep 2016 16:00:11 +0200 (CEST) Subject: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a In-Reply-To: <008e01d2159c$e9d00010$bd700030$@sina.com> References: <008e01d2159c$e9d00010$bd700030$@sina.com> Message-ID: <20160923.160011.1889613979882384478.levitte@openssl.org> In message <008e01d2159c$e9d00010$bd700030$@sina.com> on Fri, 23 Sep 2016 21:17:48 +0800, "Jing Liu" said: jingmliu> Recently when I used a library ?libcrypto.lib? compiled from OpenSSL jingmliu> 1.1.0a in my project, some compiling errors led me to find that the jingmliu> header file 'evp.h' in OpenSSL 1.1.0a is incomplete. More jingmliu> specifically, definitions for many structures are strangely missing. jingmliu> For example, the definitions for structures EVP_ENCODE_CTX, jingmliu> EVP_CIPHER, EVP_CIPHER_CTX, EVP_MD, EVP_MD_CTX, and EVP_PKEY (maybe jingmliu> there are more) cannot be found in ?evp.h? or ?ossl_typ.h? or any jingmliu> other header files. While for OpenSSL 1.0.X, we can find definitions jingmliu> for these structures in ?evp.h? or other header files. Quite a lot has happened in 1.1.0. You might want to read NEWS. One of the items in there is this: o *Most* libcrypto and libssl public structures were made opaque, including: BIGNUM and associated types, EC_KEY and EC_KEY_METHOD, DH and DH_METHOD, DSA and DSA_METHOD, RSA and RSA_METHOD, BIO and BIO_METHOD, EVP_MD_CTX, EVP_MD, EVP_CIPHER_CTX, EVP_CIPHER, EVP_PKEY and associated types, HMAC_CTX, X509, X509_CRL, X509_OBJECT, X509_STORE_CTX, X509_STORE, X509_LOOKUP, X509_LOOKUP_METHOD Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From tshort at akamai.com Fri Sep 23 16:01:09 2016 From: tshort at akamai.com (Short, Todd) Date: Fri, 23 Sep 2016 16:01:09 +0000 Subject: [openssl-dev] Openssl upgrade in debian In-Reply-To: References: Message-ID: You need to do this on your own (get the toolchain), and/or get updates from Debian. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 23, 2016, at 7:21 AM, Shantibhushan Sale > wrote: I am a student developing some tool w.r.t openssl on DEBIAN.Currently my configuration of system is : Kernel:2.6.28.10. Openssl:1.0.1e system:ARMv5 Now i have to upgrade openssl version to Openssl 1.0.1t or higher.I do not have toolchain with me. I would need all binaries which used openssl1.0.1h for above installation.How can i proceed to this? Please help me on this.I need all the depending libraries/packages w.r.t 1.0.1t. Those are: 1.Libencryption. 2.openssh, 3.ntp, 4.ping6, 5.stunnel, 6.openldap Please help me here to solve this. -- ---------------------------- Regards Shantibhushan Sale 9545534899 Pune -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: From jingmliu at sina.com Sat Sep 24 00:37:04 2016 From: jingmliu at sina.com (J Liu) Date: Sat, 24 Sep 2016 08:37:04 +0800 Subject: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a In-Reply-To: References: <008e01d2159c$e9d00010$bd700030$@sina.com> Message-ID: <001f01d215fb$c6e92b30$54bb8190$@sina.com> Dear Salz, I don't know how to use accessors/settor functions. And I still don't know how to correct the compiling error in Visual Studio 2010. Specifically, for this line of code: EVP_ENCODE_CTX base64, I got the following error: error C2079: "base64"use undefined struct"evp_Encode_Ctx_st". My code is as follows: //base64 encoding void encode(unsigned char* outData, int * outlen, const unsigned char* data, int datalen) { int tmp=0; EVP_ENCODE_CTX base64; base64 = EVP_ENCODE_CTX_new(); EVP_EncodeInit(&base64); EVP_EncodeUpdate(&base64, outData, outlen, data, datalen ); tmp=*outlen; EVP_EncodeFinal(&base64,outData+*outlen,outlen); EVP_ENCODE_CTX_free(&base64); *outlen+=tmp; outData[*outlen]=0; print("base64 encoded:",outData,*outlen); } Cheers, Jing From: openssl-dev [mailto:openssl-dev-bounces at openssl.org] On Behalf Of Salz, Rich Sent: Friday, September 23, 2016 9:55 PM To: openssl-dev at openssl.org Subject: Re: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a Yes, in 1.1.0 we =ade many structures opaque. You will have to use accessors/settor =unctions. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Sep 24 03:04:20 2016 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 24 Sep 2016 03:04:20 +0000 Subject: [openssl-dev] Definitions for some structures are strangely missing from 'evp.h' or other header files in OpenSSL 1.1.0a In-Reply-To: <001f01d215fb$c6e92b30$54bb8190$@sina.com> References: <008e01d2159c$e9d00010$bd700030$@sina.com> <001f01d215fb$c6e92b30$54bb8190$@sina.com> Message-ID: <7ddcb9f2e6ef4809a6ee3fb128caf676@usma1ex-dag1mb1.msg.corp.akamai.com> >??? EVP_ENCODE_CTX base64; >??? base64 = EVP_ENCODE_CTX_new(); You can't do this kind of thing anymore. You can only have pointers, and the contents of those pointers are hidden from your program. This is what we mean by 'opaque' pointers. In this case, for example you do EVP_ENCODE_CTX *base64 = EVP_ENCODE_CTX_new(); ... and so on ... Perhaps post some code on openssl-users mailing list, and look at wiki.openssl.org for help. From openssl at openssl.org Mon Sep 26 10:32:20 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:32:20 +0000 Subject: [openssl-dev] OpenSSL version 1.0.2j published Message-ID: <20160926103220.GA15647@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.0.2j released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.0.2j of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.0.2-notes.html OpenSSL 1.0.2j is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.0.2j.tar.gz Size: 5307912 SHA1 checksum: bdfbdb416942f666865fa48fe13c2d0e588df54f SHA256 checksum: e7aff292be21c259c6af26469c7a9b3ba26e9abaaffd325e3dccc9785256c431 The checksums were calculated using the following commands: openssl sha1 openssl-1.0.2j.tar.gz openssl sha256 openssl-1.0.2j.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6O9BAAoJENnE0m0OYESRsT8H/R7NWjLkFqUOwOTjyiqOKDWa YUAUNtSM+NWgHBS8GZwNlYyvCv7oIPIuJ1cG4mwTnWc2qpUFbbOkc6bhn/VhPWi5 bW6xOlof5Xbn86G5KM5HPe9t5Gay4RiU9+ePVa8Vkn4c3UcPNYVrYdDXEjv3UvJq 3VSOJDlAndaqMyBTtX5uK82pfd63kZWi9p2a+NCEojGcBSD/cyUYQpMUdomGU5K+ ZaRh2bHLNUjGUDLDqlgTDMv8p+OYUtQ6bgGpwBYw5zQeTZy7c43yTqUjvmuEaxaj XEeJqkv59Jty5uKqYmasVHgFY+EGsE0vw3troBrNFq2ZbVCqBx41C/kOZ3828HQ= =fLO/ -----END PGP SIGNATURE----- From openssl at openssl.org Mon Sep 26 10:32:40 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:32:40 +0000 Subject: [openssl-dev] OpenSSL version 1.1.0b published Message-ID: <20160926103240.GA15835@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL version 1.1.0b released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.0b of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.0-notes.html OpenSSL 1.1.0b is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.0b.tar.gz Size: 5162355 SHA1 checksum: cbf391d0d68a9f144c24c5c3c5028c07fa00264c SHA256 checksum: a45de072bf9be4dea437230aaf036000f0e68c6a665931c57e76b5b036cef6f7 The checksums were calculated using the following commands: openssl sha1 openssl-1.1.0b.tar.gz openssl sha256 openssl-1.1.0b.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6O5iAAoJENnE0m0OYESRdEUIAKzNLCT+L0z6R6mUoHYMFT/4 jctbb93RX1nu3wx9ssRdlBikpVBa6vfsS2U4MWwyYSkRTbBHVlHuezq1/2FduXPF nsLT/tjPNmXqQPPTsceKx/p7nDAnSdapz6e36HJ/8erUR7nngHKUdalV0OqoQLeX Lz6ncYVH42qFPATMM4xJzcunmY3g+CXTORHAGBZLOM0HfSgAka/iQVC8aUlYWOMO E0pMalw9yRHzsFcR++9I/vpr9TcBj/falISsaGrgAxVNMkINYRITU8wWSO3+0y+N EkSi079/CNQx2LwoVW2qTPWdbbqMgYrUG3jsBlZUeVwvLfcXsVy2FHUep+FIb4k= =SQB4 -----END PGP SIGNATURE----- From openssl at openssl.org Mon Sep 26 10:35:38 2016 From: openssl at openssl.org (OpenSSL) Date: Mon, 26 Sep 2016 10:35:38 +0000 Subject: [openssl-dev] OpenSSL Security Advisory Message-ID: <20160926103538.GA17557@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 OpenSSL Security Advisory [26 Sep 2016] ======================================== This security update addresses issues that were caused by patches included in our previous security update, released on 22nd September 2016. Given the Critical severity of one of these flaws we have chosen to release this advisory immediately to prevent upgrades to the affected version, rather than delaying in order to provide our usual public pre-notification. Fix Use After Free for large message sizes (CVE-2016-6309) ========================================================== Severity: Critical This issue only affects OpenSSL 1.1.0a, released on 22nd September 2016. The patch applied to address CVE-2016-6307 resulted in an issue where if a message larger than approx 16k is received then the underlying buffer to store the incoming message is reallocated and moved. Unfortunately a dangling pointer to the old location is left which results in an attempt to write to the previously freed location. This is likely to result in a crash, however it could potentially lead to execution of arbitrary code. OpenSSL 1.1.0 users should upgrade to 1.1.0b This issue was reported to OpenSSL on 23rd September 2016 by Robert ??wi??cki (Google Security Team), and was found using honggfuzz. The fix was developed by Matt Caswell of the OpenSSL development team. Missing CRL sanity check (CVE-2016-7052) ======================================== Severity: Moderate This issue only affects OpenSSL 1.0.2i, released on 22nd September 2016. A bug fix which included a CRL sanity check was added to OpenSSL 1.1.0 but was omitted from OpenSSL 1.0.2i. As a result any attempt to use CRLs in OpenSSL 1.0.2i will crash with a null pointer exception. OpenSSL 1.0.2i users should upgrade to 1.0.2j The issue was reported to OpenSSL on 22nd September 2016 by Bruce Stephens and Thomas Jakobi. The fix was developed by Matt Caswell of the OpenSSL development team. References ========== URL for this Security Advisory: https://www.openssl.org/news/secadv/20160926.txt Note: the online version of the advisory may be updated with additional details over time. For details of OpenSSL severity classifications please see: https://www.openssl.org/policies/secpolicy.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJX6PBJAAoJENnE0m0OYESRGacIALa7/Vg0SQzqjhD/KphCdKos BjkDcEO00y3JDyYqqQxfcrM9jSwBbrNzmHdEzBcPlvvDq9qhGwsODKbGylI2St5r zVHw1qA60/+Hu9PjaGT24a8MX+fPjA4RObB/BGZ7ViucZzCxqqtJob73InKwM8+9 OyjTmrphbyFa/Hk/OUWVzjatzQjEN+a5QplRTR2Sd4fBZDWowrtOdPGmbBQfRRgm AbEO5ZPaVKBoRuMk6JsR3LFymZ2FpHjLs9HNBtSmLLdzfIXxVE+uOb9b5wdAMP/3 4cTMkhfeS3RF0GuMT3EyH/EuZS6KkjuE8y/aVTq5s3yhK3ah5kT85IO1ps0yDx0= =WJwY -----END PGP SIGNATURE----- From dwmw2 at infradead.org Mon Sep 26 13:16:33 2016 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 26 Sep 2016 14:16:33 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <20160926103538.GA17557@openssl.org> References: <20160926103538.GA17557@openssl.org> Message-ID: <1474895793.45169.254.camel@infradead.org> On Mon, 2016-09-26 at 10:35 +0000, OpenSSL wrote: > Content-Type: text/plain; charset="iso-8859-1" > This issue was reported to OpenSSL on 23rd September 2016 by Robert ??wi??cki Found by whom? Welcome to the 21st century... ?:) -- dwmw2 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 5760 bytes Desc: not available URL: From matt at openssl.org Mon Sep 26 13:19:34 2016 From: matt at openssl.org (Matt Caswell) Date: Mon, 26 Sep 2016 14:19:34 +0100 Subject: [openssl-dev] OpenSSL Security Advisory In-Reply-To: <1474895793.45169.254.camel@infradead.org> References: <20160926103538.GA17557@openssl.org> <1474895793.45169.254.camel@infradead.org> Message-ID: <52caa935-0502-1cd4-6ad7-55dc8d3ecbba@openssl.org> On 26/09/16 14:16, David Woodhouse wrote: > On Mon, 2016-09-26 at 10:35 +0000, OpenSSL wrote: > >> Content-Type: text/plain; charset="iso-8859-1" > >> This issue was reported to OpenSSL on 23rd September 2016 by Robert ??wi??cki > > Found by whom? Welcome to the 21st century... :) Yes. Sorry. A problem in our .muttrc file. Fixed now. Matt From rt at openssl.org Mon Sep 26 13:41:45 2016 From: rt at openssl.org (Dr. Matthias St. Pierre via RT) Date: Mon, 26 Sep 2016 13:41:45 +0000 Subject: [openssl-dev] [openssl.org #4685] [PATCH] Add missing prototype for FIPS callback In-Reply-To: <1474895852-14906-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1474895852-14906-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: The call to FIPS_crypto_set_id_callback() was added in revision a43cfd7bb1fc681d563e, but there is no prototype for it in . --- This leads to warnings on some platforms (e.g. x86_64-ncp-linux-gnu-gcc): o_init.c:77:5: warning: implicit declaration of function 'FIPS_crypto_set_id_callback' [-Wimplicit-function-declaration] and to an error on iOS (clang -arch arm64): o_init.c:77:5: error: implicit declaration of function 'FIPS_crypto_set_id_callback' is invalid in C99 [-Werror,-Wimplicit-function-declaration] crypto/o_init.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/crypto/o_init.c b/crypto/o_init.c index 185841e..a399318 100644 --- a/crypto/o_init.c +++ b/crypto/o_init.c @@ -74,6 +74,8 @@ void OPENSSL_init(void) #ifdef OPENSSL_FIPS FIPS_set_locking_callbacks(CRYPTO_lock, CRYPTO_add_lock); # ifndef OPENSSL_NO_DEPRECATED + /* the prototype is missing in */ + void FIPS_crypto_set_id_callback(unsigned long (*func)(void)); FIPS_crypto_set_id_callback(CRYPTO_thread_id); # endif FIPS_set_error_callbacks(ERR_put_error, ERR_add_error_vdata); -- 2.7.3 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4685 Please log in as guest with password guest if prompted From rt at openssl.org Mon Sep 26 14:32:31 2016 From: rt at openssl.org (Pumpanen Jan-Markus via RT) Date: Mon, 26 Sep 2016 14:32:31 +0000 Subject: [openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i In-Reply-To: <1474899727136.49492@bittium.com> References: <1474899727136.49492@bittium.com> Message-ID: Hi, When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build will fail in crypto/engine/eng_cryptodev.c. I am using 64-bit Ubuntu 14.04 in my build machine with gcc toolchain. For me it looks like there has been a typo in the OPENSSL_malloc return value check. Attached patch solves the issue. Below is the original error message: | gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -i/build/tmp/sysroots/x86_64-linux/usr/include -O2 -pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -ibuild/tmp/sysroots/x86_64-linux/usr/include -c -o eng_cryptodev.o eng_cryptodev.c | eng_cryptodev.c: In function 'cryptodev_digest_copy': | eng_cryptodev.c:942:23: error: 'struct dev_crypto_state' has no member named 'ac_data' | if (dstate->ac_data == NULL) { | ^ | make[2]: *** [eng_cryptodev.o] Error 1 Kind regards, Jan-Markus Pumpanen ---------------------------------------------------------------- Please note: This e-mail may contain confidential information intended solely for the addressee. If you have received this e-mail in error, please do not disclose it to anyone, notify the sender promptly, and delete the message from your system. Thank you. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: openssl-102i-eng_cryptodev.patch Type: text/x-patch Size: 533 bytes Desc: not available URL: From rt at openssl.org Mon Sep 26 14:34:17 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Mon, 26 Sep 2016 14:34:17 +0000 Subject: [openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i In-Reply-To: <4c266f0a8b3242b8a3284c64325b4553@usma1ex-dag1mb1.msg.corp.akamai.com> References: <1474899727136.49492@bittium.com> <4c266f0a8b3242b8a3284c64325b4553@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: We have a fix waiting for internal review; see GitHub issue 1546. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686 Please log in as guest with password guest if prompted From rt at openssl.org Mon Sep 26 14:46:38 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 26 Sep 2016 14:46:38 +0000 Subject: [openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i In-Reply-To: <1474899727136.49492@bittium.com> References: <1474899727136.49492@bittium.com> Message-ID: That has already been fixed in the 1.0.2 branch, and is part of 1.0.2j, which was released today. Cheers, Richard On Mon Sep 26 14:32:31 2016, Jan-Markus.Pumpanen at bittium.com wrote: > > > Hi, > > When building the OpenSSL 1.0.2i with -DHAVE_CRYPTODEV flag the build > will fail in crypto/engine/eng_cryptodev.c. I am using 64-bit Ubuntu > 14.04 in my build machine with gcc toolchain. > > For me it looks like there has been a typo in the OPENSSL_malloc > return value check. Attached patch solves the issue. Below is the > original error message: > > | gcc -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include > -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN > -DHAVE_DLFCN_H -DL_ENDIAN -DTERMIO -i/build/tmp/sysroots/x86_64- > linux/usr/include -O2 -pipe -Wall -Wa,--noexecstack -DHAVE_CRYPTODEV > -DUSE_CRYPTODEV_DIGESTS -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT > -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DRC4_ASM -DSHA1_ASM > -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM > -DWHIRLPOOL_ASM -DGHASH_ASM -DECP_NISTZ256_ASM > -ibuild/tmp/sysroots/x86_64-linux/usr/include -c -o eng_cryptodev.o > eng_cryptodev.c > | eng_cryptodev.c: In function 'cryptodev_digest_copy': > | eng_cryptodev.c:942:23: error: 'struct dev_crypto_state' has no > member named 'ac_data' > | if (dstate->ac_data == NULL) { > | ^ > | make[2]: *** [eng_cryptodev.o] Error 1 > > > Kind regards, > Jan-Markus Pumpanen > > ---------------------------------------------------------------- > Please note: This e-mail may contain confidential information > intended solely for the addressee. If you have received this > e-mail in error, please do not disclose it to anyone, notify > the sender promptly, and delete the message from your system. > Thank you. -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686 Please log in as guest with password guest if prompted From rt at openssl.org Mon Sep 26 14:47:27 2016 From: rt at openssl.org (Richard Levitte via RT) Date: Mon, 26 Sep 2016 14:47:27 +0000 Subject: [openssl-dev] [openssl.org #4686] [BUG] Failure to compile if HAVE_CRYPTODEV is defined in OpenSSL 1.0.2i In-Reply-To: References: <1474899727136.49492@bittium.com> <4c266f0a8b3242b8a3284c64325b4553@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: On Mon Sep 26 14:34:17 2016, rsalz at akamai.com wrote: > We have a fix waiting for internal review; see GitHub issue 1546. That's not related to this issue. Cheers, Richard -- Richard Levitte levitte at openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4686 Please log in as guest with password guest if prompted From leif.thuresson at foxt.com Mon Sep 26 15:45:31 2016 From: leif.thuresson at foxt.com (Leif Thuresson) Date: Mon, 26 Sep 2016 17:45:31 +0200 Subject: [openssl-dev] CVE-2016-2178 - Constant time flag not preserved in DSA signing Message-ID: <477e2e12-c93e-a44d-9468-8c2046d09e99@foxt.com> I'm trying to understand the severity of this issue. The demo exploit described here http://eprint.iacr.org/2016/594 relies on the fact the target program and the attacker share the same memory image of the OpenSSL shared library. If my program is statically linked to OpenSSL will that make it more resistant to this type of attack? Or will page de-duplication techniques like Linux KSM make it just as vulnerable as a dynamically linked program? /leif From rt at openssl.org Mon Sep 26 16:23:45 2016 From: rt at openssl.org (Dr. Matthias St. Pierre via RT) Date: Mon, 26 Sep 2016 16:23:45 +0000 Subject: [openssl-dev] [openssl.org #4685] [PATCH v2] Add missing prototype for FIPS callback In-Reply-To: <1474906985-17268-1-git-send-email-Matthias.St.Pierre@ncp-e.com> References: <1474906985-17268-1-git-send-email-Matthias.St.Pierre@ncp-e.com> Message-ID: The call to FIPS_crypto_set_id_callback() was added in revision a43cfd7bb1fc681d563e, but there is no prototype for it in . --- Moved the function prototype upwards, because declarations can only be placed at the top of a function in C. crypto/o_init.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/crypto/o_init.c b/crypto/o_init.c index 185841e..18bb858 100644 --- a/crypto/o_init.c +++ b/crypto/o_init.c @@ -58,6 +58,11 @@ #ifdef OPENSSL_FIPS # include # include + +# ifndef OPENSSL_NO_DEPRECATED +/* the prototype is missing in */ +void FIPS_crypto_set_id_callback(unsigned long (*func)(void)); +# endif #endif /* -- 2.7.3 -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4685 Please log in as guest with password guest if prompted From domboups at yahoo.fr Tue Sep 27 09:18:10 2016 From: domboups at yahoo.fr (modou MBOUP) Date: Tue, 27 Sep 2016 09:18:10 +0000 (UTC) Subject: [openssl-dev] Integration an Public Key Cryptographic Algorithm References: <1699091743.10300643.1474967890348.ref@mail.yahoo.com> Message-ID: <1699091743.10300643.1474967890348@mail.yahoo.com> Hello, I developed an public key cryptographic algorithm in C and I want to integrate openssl. I would like to know how to integrate openssl. Thank you for helping me on this integration. Thank you to conduct.?El Hadji Mdou MBOUP Ing?nieur en S?curit? des Syst?mes d'Informations Doctorant ?? l'UCAD Portable: +221 77 425 87 82 HLM GRAN YOFF villa 22 Dakar, S?n?gal -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Sep 27 10:55:49 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Sep 2016 06:55:49 -0400 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> Message-ID: <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> On 09/27/2016 02:36 AM, robin wrote: > > Hi there, > Is there possible to support Chinese cryptographic algorithms in OpenSSL project main branch in the future ? > > China authorities have been published their own cryptographic algorithms standard years ago,like Ecc based SM2, hash SM3, symmetric algorithm SM4 etc. > > Many companies, both Chinese and foreign, could not get a well-designed crypto lib like OpenSSL did for aes and other FIPS 140-2 complied products. > > We still believe a unified cryptographic algorithms implemented by open source especially be in OpenSSL was the best choice for both community's and marketing's, and Chinese companies would be happy to participate in this. > > If there is still worth time to discuss this issue I would be ready to contribute source code and other advices. > > Sincerely. > > Arcueid > Are technical specifications for these algorithms available in English? That would be at least one essential prerequisite. In the past we have declined the opportunity to implement some nation-specific algorithms because of the lack of English documentation. Even though most of us are not native English speakers, English is our lingua franca. -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Tue Sep 27 15:50:27 2016 From: marquess at openssl.com (Steve Marquess) Date: Tue, 27 Sep 2016 11:50:27 -0400 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> Message-ID: On 09/27/2016 11:24 AM, robin wrote: > Thanks for your reply Marquess. I understand English documents are > essential factor to start, and I certainly sure it is not A problem > to translate these kinds of published standard to English version if > there's no other unclear reasons. > > In the past, we have several cryptographic algorithms implement in > different platforms and obviously can contribute to community as a > reference including test samples. > > If possible, an English copy of standard would be a good start for > this work? > > It will be great to hear your further information. > Is there currently any documentation at all on these Chinese algorithms? I'm certainly curious, and I'm sure others in the OpenSSL community will be. I've had some limited experiences with translations of technical standards, and from that I know those are the hardest translations of all. It may well take a lot more manpower to generate quality translations than to code implementations. Please keep in mind that the technical documentation is a necessary prerequisite but not necessarily sufficient. The nature of the algorithms may be uninteresting (we've declined to accept/implement some algorithms we judged to be of insufficient virtue or utility, even for pay). We can be very picky about code contributions too, as any code added to OpenSSL has to work across a huge spectrum of platforms and be maintainable for the long haul. We may also not have the resources to tackle something that would otherwise be of interest (we have a back catalog of nice-to-have cryptography waiting for a rainy day). -Steve M. -- Steve Marquess OpenSSL Validation Services, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Tue Sep 27 16:25:39 2016 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 27 Sep 2016 16:25:39 +0000 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> Message-ID: <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> > Is there currently any documentation at all on these Chinese algorithms? > I'm certainly curious, and I'm sure others in the OpenSSL community will be. Also, please know that we are already looking at several large projects (TLS 1.3, FIPS, etc). In my personal opinion, I would be surprised if anyone on the team had a lot of time to spend on this. We have already turned down Camellia-GCM, for example. An English specification, test vectors, and a complete implementation as a Pull Request are the most likely ways for it to happen. Even better would be to implement it as a separate ENGINE, like Gost is. Then we only need to reserve a few #define's for you. From paul.dale at oracle.com Tue Sep 27 22:31:56 2016 From: paul.dale at oracle.com (Paul Dale) Date: Tue, 27 Sep 2016 15:31:56 -0700 (PDT) Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <7eb32dd1-4903-4e8f-b1c9-a0e8e89503fb@default> There are a couple of draft standards available: SM2 DSA: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 SM3 Hash: https://tools.ietf.org/html/draft-shen-sm3-hash-01 Neither of these two looks like it would be difficult to implement. I've not located English versions of the other algorithms but I haven't looked too deeply. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Salz, Rich [mailto:rsalz at akamai.com] Sent: Wednesday, 28 September 2016 2:26 AM To: openssl-dev at openssl.org; robin Subject: Re: [openssl-dev] About Chinese crypto-algorithms > Is there currently any documentation at all on these Chinese algorithms? > I'm certainly curious, and I'm sure others in the OpenSSL community will be. Also, please know that we are already looking at several large projects (TLS 1.3, FIPS, etc). In my personal opinion, I would be surprised if anyone on the team had a lot of time to spend on this. We have already turned down Camellia-GCM, for example. An English specification, test vectors, and a complete implementation as a Pull Request are the most likely ways for it to happen. Even better would be to implement it as a separate ENGINE, like Gost is. Then we only need to reserve a few #define's for you. -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From xoloki at gmail.com Tue Sep 27 22:53:55 2016 From: xoloki at gmail.com (Joey Yandle) Date: Tue, 27 Sep 2016 15:53:55 -0700 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <7eb32dd1-4903-4e8f-b1c9-a0e8e89503fb@default> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> <7eb32dd1-4903-4e8f-b1c9-a0e8e89503fb@default> Message-ID: This looks like an interesting project. I'd be willing to take a stab at it. I did notice the following while reading the doc: The sm2 digital signature algorithm requires random number generators approved by by Chinese Commercial Cryptography Administration Office. Preliminary googling was not helpful, I may have to email the author for clarification. Cheers, Joey On Sep 27, 2016 3:32 PM, "Paul Dale" wrote: > There are a couple of draft standards available: > > SM2 DSA: https://tools.ietf.org/html/draft-shen-sm2-ecdsa-02 > SM3 Hash: https://tools.ietf.org/html/draft-shen-sm3-hash-01 > > Neither of these two looks like it would be difficult to implement. > > I've not located English versions of the other algorithms but I haven't > looked too deeply. > > > Pauli > > -- > Oracle > Dr Paul Dale | Cryptographer | Network Security & Encryption > Phone +61 7 3031 7217 > Oracle Australia > > > -----Original Message----- > From: Salz, Rich [mailto:rsalz at akamai.com] > Sent: Wednesday, 28 September 2016 2:26 AM > To: openssl-dev at openssl.org; robin > Subject: Re: [openssl-dev] About Chinese crypto-algorithms > > > Is there currently any documentation at all on these Chinese algorithms? > > I'm certainly curious, and I'm sure others in the OpenSSL community will > be. > > Also, please know that we are already looking at several large projects > (TLS 1.3, FIPS, etc). In my personal opinion, I would be surprised if > anyone on the team had a lot of time to spend on this. We have already > turned down Camellia-GCM, for example. > > An English specification, test vectors, and a complete implementation as a > Pull Request are the most likely ways for it to happen. Even better would > be to implement it as a separate ENGINE, like Gost is. Then we only need > to reserve a few #define's for you. > -- > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 28 00:45:43 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Sep 2016 00:45:43 +0000 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <7eb32dd1-4903-4e8f-b1c9-a0e8e89503fb@default> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> <7eb32dd1-4903-4e8f-b1c9-a0e8e89503fb@default> Message-ID: > Neither of these two looks like it would be difficult to implement. Again, I strongly recommend that if anyone works on this, they do it as an externally-provided ENGINE, like GOST. From matt at openssl.org Wed Sep 28 08:27:46 2016 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Sep 2016 09:27:46 +0100 Subject: [openssl-dev] Input on renegotiation behaviour Message-ID: <33fbf11e-a3be-1b66-7699-48d4be8a3847@openssl.org> I recently implemented some tests for renegotiation that turned up a discrepancy between the way TLS and DTLS work. If a server sends a HelloRequest to the client, then the client responds by initiating a renegotiation handshake. We support two forms of renegotiation handshake: normal and abbreviated. The abbreviated form was added in OpenSSL 1.0.1. Basically the difference is whether we can do session resumption in a reneg handshake or not. With the normal form, we never do: with the abbreviated form we will do if possible. In TLS from 1.0.1, when a HelloRequest is received from the server, the client will always attempt an abbreviated reneg handshake, i.e. it will send through a session id in the ClientHello. In DTLS (and TLS before 1.0.1) it never attempts an abbreviated reneg handshake, i.e. it will always send through an empty session id in the ClientHello. This behaviour goes all the way back to when abbreviated reneg handshake support was first added in this commit: commit 48ae85b6ffe85e327f63c59d8de6a94a8b8f2d3b Author: Dr. Stephen Henson AuthorDate: Thu Aug 26 14:22:40 2010 +0000 Commit: Dr. Stephen Henson CommitDate: Thu Aug 26 14:22:40 2010 +0000 PR: 1833 Submitted By: Robin Seggelmann Support for abbreviated handshakes when renegotiating. Looking at that commit, it appears to me that the intention was that the "default" behaviour would remain unchanged. This was just a new feature that you could use if you want. That would suggest that the DTLS behaviour was what was intended to happen in this scenario, and the change of default TLS behaviour was a bug. Reading through the original RT ticket for this patch there is no suggestion that default behaviour was going to change...it reads like this is optional new functionality. The question is: what to do now? The current behaviour is not *wrong* either for TLS or DTLS, but the discrepancy is quite weird and confusing. Should we: 1) Change TLS to behave like it used to, and like DTLS still does 2) Change DTLS to be consistent with the TLS behaviour 3) Keep it as it is and retain the current inconsistency And if we change things, should we just change it in the current dev branch - or backport it as a bug fix? Thoughts? Matt From cory at lukasa.co.uk Wed Sep 28 10:11:18 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 28 Sep 2016 11:11:18 +0100 Subject: [openssl-dev] SSLKEYLOGFILE Support Message-ID: All, Some time ago I posted noting that it would be useful to have the SSLKEYLOGFILE environment variable supported by OpenSSL. I lost track of that request, and have since noticed that a patch that would have added support for that environment variable[0] was closed, with Rich asking for an alternative implementation based on an option flag. I?d like to volunteer to resurrect this patch, but to do so I need to better understand the objections to the proposed interface. Quoting from the issue, Rich has said that having the SSLKEYLOGFILE environment variable set to dump session keys is ?not safe?, and in particular that 'The risk that someone using this in production will get "tricked" into exposing session keys is too great.? Rich?s alternative proposal is that we should add a compile-time flag (?OPENSSL_NO_KEYLOG?) that is set by default and would need to be unset to allow dumping of session keys, and then a context option (?SSL_OP_LOG_KEYS?) that must be enabled, before this environment variable would function as expected. While I understand Rich?s concern, I?m not sure that this functionality requires such substantial handcuffing. The attack vector that I can see these requirements defending against is that an attacker may be able to inject the SSLKEYLOGFILE environment variable into the environment of a process running OpenSSL pointing at a file that is both writable by the OpenSSL process and readable by the attacker. It?s certainly not immediately apparent to me that this is an easily exploitable attack vector, though I?m definitely not an expert and I?m willing to be told that I?m wrong. It is the case, however, that if OPENSSL_NO_KEYLOG is the default value of that compile-time flag, the utility of the SSLKEYLOGFILE environment variable drops almost entirely to zero. My rationale for wanting this is to make it easier to debug the application-layer protocol running inside a TLS tunnel, and if my users have to recompile and re-link their applications against a new OpenSSL *and* also pass additional context options in order to enable the logging I think that the amount of work required to support this environment variable is basically zero: it would be easier to simply intercept the BIO reads and writes to simply dump the application data than to ask my users to do all of that. So what do the OpenSSL developers think? Do we need the compile flag, or is some lower bar sufficient? Cory [0]: https://github.com/openssl/openssl/pull/570 From rt at openssl.org Wed Sep 28 11:30:33 2016 From: rt at openssl.org (Nitschke, Mario via RT) Date: Wed, 28 Sep 2016 11:30:33 +0000 Subject: [openssl-dev] [openssl.org #4688] bug since openssl1.0.1i In-Reply-To: <84A6F1E379FC0046B012D308AD41D82D430F19B9@DTR-XCH-NODEB.d-trust.de> References: <84A6F1E379FC0046B012D308AD41D82D430F19B9@DTR-XCH-NODEB.d-trust.de> Message-ID: Hello, there is a bug in openssl since openssl1.0.1i I am compiling under Solaris 10 with CC from SolarisStudio 12.3. The problem is not the compiler, it is the implementation of the new test dtlstest. I always did "make dclean" and up to openssl1.0.1h there was no problem, since openssl1.0.1i linking fails if doing "make dclean" before building. This is what I have found out: "make dclean" deletes the new test file "test/ssltestlib.c" "./config" creates "ssltest.c => dummytest.c" in test And linking dtlstest fails with Linking Error because of there is a "main" function in dummitest.c also. Errormessage: ld: fatal: symbol 'main' is multiply-defined: (file dtlstest.o type=FUNC; file ssltestlib.o type=FUNC); ld: fatal: symbol '__fsr_init_value' is multiply-defined: (file dtlstest.o type=NOTY; file ssltestlib.o type=NOTY); ld: fatal: file processing errors. No output written to dtlstest *** Error code 2 Kind regards Mit freundlichen Gr??en Mario Nitschke IT-Systemadministrator ----------------------------------------------------------------------- D-TRUST GmbH Kommandantenstr. 15 10969 Berlin GERMANY Phone: + 49 (0) 30 - 2593 91-730 Fax: + 49 (0) 30 - 2593 91-778 M.Nitschke at d-trust.net www.D-TRUST.net Sitz der Gesellschaft: Berlin Handelsregister: AG Berlin-Charlottenburg HRB 74346. Ust.-IdNr.: DE202620438 Gesch?ftsf?hrer: Heinz-Otto Meyn, Dr. Kim Nguyen This message is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, we hereby give notice that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this message in error, please delete the message and notify us immediately. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4688 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 28 11:30:33 2016 From: rt at openssl.org (scott.openssl@scottrix.co.uk via RT) Date: Wed, 28 Sep 2016 11:30:33 +0000 Subject: [openssl-dev] [openssl.org #4687] Bug in apps/req.c introduced in openssl 1.0.2i In-Reply-To: <20160928070759.GA2669@scottrix.co.uk> References: <20160928070759.GA2669@scottrix.co.uk> Message-ID: Hi, When trying to generate a self signed certificate from a previously generate csr with the command line: openssl req -x509 -key privkey.pem -in csr.pem -out selfsigned.pem it now prompts for country code etc. which is stored in the CSR. This change in behavior was introduced by: commit fd7ca7465b67336b8950a505b6d2adee867a78f7 Author: Richard Levitte Date: Mon Aug 22 15:22:17 2016 +0200 Make 'openssl req -x509' more equivalent to 'openssl req -new' The following would fail, or rather, freeze: openssl genrsa -out rsa2048.pem 2048 openssl req -x509 -key rsa2048.pem -keyform PEM -out cert.pem In that case, the second command wants to read a certificate request from stdin, because -x509 wasn't fully flagged as being for creating something new. This changes makes it fully flagged. RT#4655 Reviewed-by: Andy Polyakov My propsed patch is: diff -Nru openssl-1.0.2i/apps/req.c openssl-1.0.2i-1/apps/req.c --- openssl-1.0.2i/apps/req.c 2016-09-22 19:59:10.000000000 +0100 +++ openssl-1.0.2i-1/apps/req.c 2016-09-27 17:37:07.917660064 +0100 @@ -787,7 +787,7 @@ BIO_printf(bio_err, "-----\n"); } - if (!newreq) { + if (!newreq || (x509 && infile)) { /* * Since we are using a pre-existing certificate request, the * kludge * 'format' info should not be changed. Scott Harrison -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4687 Please log in as guest with password guest if prompted From cory at lukasa.co.uk Wed Sep 28 11:51:59 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Wed, 28 Sep 2016 12:51:59 +0100 Subject: [openssl-dev] SSLKEYLOGFILE Support In-Reply-To: References: Message-ID: <86BA005D-7756-4D98-9F0C-B3C7C4F07CFA@lukasa.co.uk> > On 28 Sep 2016, at 11:11, Cory Benfield wrote: > > So what do the OpenSSL developers think? Do we need the compile flag, or is some lower bar sufficient? It was brought to my attention that BoringSSL takes an alternative approach to this problem: they allow users to register a callback for key logging purposes[0]. Essentially, this allows application developers to opt-in to generating a key log file in whatever manner they see fit, whether that be by setting SSLKEYLOGFILE in the environment or some other configuration option. This approach seems like it is likely to be the most generally appealing approach: for anyone who desperately wants SSLKEYLOGFILE behaviour they can code it in at their own application level with very little difficulty, while anyone who is more concerned about environment variables can choose other methods of configuration. Applications can opt out entirely by simply never calling the set callback function, or by calling it for all new contexts with an explicit NULL pointer, and it allows a single libssl shared object to have multiple key logging behaviours for different aspects of the same application. This approach would definitely work for my use-cases: if everyone in the OpenSSL team is happy with it, I?d be happy to write up and submit a patch for it. Cory [0]: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_CTX_set_keylog_callback -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 28 12:30:40 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Sep 2016 12:30:40 +0000 Subject: [openssl-dev] SSLKEYLOGFILE Support In-Reply-To: <86BA005D-7756-4D98-9F0C-B3C7C4F07CFA@lukasa.co.uk> References: <86BA005D-7756-4D98-9F0C-B3C7C4F07CFA@lukasa.co.uk> Message-ID: <9d0d0b8b82f34a8bac22c818ad492ff6@usma1ex-dag1mb1.msg.corp.akamai.com> > [0]: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_CTX_set_keylog_callback That seems like a reasonable thing to put into the next release. -- Senior Architect, Akamai Technologies Member, OpenSSL Dev Team IM: richsalz at jabber.at Twitter: RichSalz From rt at openssl.org Fri Sep 16 13:54:00 2016 From: rt at openssl.org (Eneges via RT) Date: Fri, 16 Sep 2016 13:54:00 +0000 Subject: [openssl-dev] [openssl.org #4676] Error converting to p12 crt In-Reply-To: References: Message-ID: Hi. I use openssl to convert a certificate with * . * . crt to p12 . I do this through a .bat withthe following command line : openssl pkcs12 -export -in -inkey SierrasClave.key Cert1_7a79ea64423417fd.crt -out Cert1_7a79ea64423417fd.p12 -name " Cert1_7a79ea64423417fd " pause The error message is attached . OpenSSL use for 64 -bit Win7. I hope your answer. Thank you very much -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4676 Please log in as guest with password guest if prompted -------------- next part -------------- A non-text attachment was scrubbed... Name: Sin t?tulo.png Type: image/png Size: 170739 bytes Desc: not available URL: From rt at openssl.org Wed Sep 28 12:34:51 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 28 Sep 2016 12:34:51 +0000 Subject: [openssl-dev] [openssl.org #4676] Error converting to p12 crt In-Reply-To: <79c24276f39e442895151a5ebf134b79@usma1ex-dag1mb1.msg.corp.akamai.com> References: <79c24276f39e442895151a5ebf134b79@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: You did not cut/paste the command line properly because you wrote "-in -inkey" which is wrong. Or maybe that is your error? -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4676 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 28 12:41:02 2016 From: rt at openssl.org (Salz, Rich via RT) Date: Wed, 28 Sep 2016 12:41:02 +0000 Subject: [openssl-dev] [openssl.org #4676] Error converting to p12 crt In-Reply-To: References: <79c24276f39e442895151a5ebf134b79@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Try putting a "dir" command before the openssl command, to make sure that the file exists. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4676 Please log in as guest with password guest if prompted From rsalz at akamai.com Wed Sep 28 12:44:16 2016 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 28 Sep 2016 12:44:16 +0000 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <1614132802.633305.1475033394684@mail.yahoo.com> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> <1614132802.633305.1475033394684@mail.yahoo.com> Message-ID: <8e68e19f9734425b99aaaee423cee32c@usma1ex-dag1mb1.msg.corp.akamai.com> (I subscribed you to openssl-dev; I hope it works.) ISO standards are ?pay to play.? That is, any member organization can get something as an ISO standard with not much effort. :) >> "I strongly recommend that if anyone works on this, they do it as an externally-provided ENGINE, like GOST. " >??? Again, I'm sorry I have not a clear notion about the difference between build-in approach, and certainly we will take this if necessary. >> "We may also not have the resources to tackle something that would otherwise be of interest (we have a back catalog of nice-to-have cryptography waiting for a rainy day)" >??? We certainly respect policy within community and be willing to participate in this if possible in all aspects. You will have to learn how to write an ENGINE. It is possible; Dmitry did it for GOST (look in the mailing list archives, https://mta.openssl.org, for some details; also maybe the Git log. Also maybe he'll reply to this post :) Richard Levitte has started a blog series on writing an ENGINE, see https://www.openssl.org/blog/blog/categories/engine-corner/ We want to make it easier to add new crypto via ENGINES. Each time someone does it, we learn more about what's needed, the documentation gets (a little) better, and so on. From beldmit at gmail.com Wed Sep 28 12:49:46 2016 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 28 Sep 2016 15:49:46 +0300 Subject: [openssl-dev] About Chinese crypto-algorithms In-Reply-To: <8e68e19f9734425b99aaaee423cee32c@usma1ex-dag1mb1.msg.corp.akamai.com> References: <01EF10EE-4801-4CAB-92AC-56917ED4BEF4@yahoo.com> <29784d4e-9e36-008d-9428-a8b6e1b736a1@openssl.com> <513773FD-B43C-4E8A-8ABC-BCF0099DFF6B@yahoo.com> <6bafec4b6d214f07bc1f6a9fc5e859c6@usma1ex-dag1mb1.msg.corp.akamai.com> <1614132802.633305.1475033394684@mail.yahoo.com> <8e68e19f9734425b99aaaee423cee32c@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: Hello Robin, On Wed, Sep 28, 2016 at 3:44 PM, Salz, Rich wrote: > (I subscribed you to openssl-dev; I hope it works.) > > ISO standards are ?pay to play.? That is, any member organization can get > something as an ISO standard with not much effort. :) > > >> "I strongly recommend that if anyone works on this, they do it as an > externally-provided ENGINE, like GOST. " > > Again, I'm sorry I have not a clear notion about the difference > between build-in approach, and certainly we will take this if necessary. > > >> "We may also not have the resources to tackle something that would > otherwise be of interest (we have a back catalog of nice-to-have > cryptography waiting for a rainy day)" > > We certainly respect policy within community and be willing to > participate in this if possible in all aspects. > > You will have to learn how to write an ENGINE. It is possible; Dmitry did > it for GOST (look in the mailing list archives, https://mta.openssl.org, > for some details; also maybe the Git log. Also maybe he'll reply to this > post :) Richard Levitte has started a blog series on writing an ENGINE, > see https://www.openssl.org/blog/blog/categories/engine-corner/ Sure. I'll be glad to assist. > > We want to make it easier to add new crypto via ENGINES. Each time > someone does it, we learn more about what's needed, the documentation gets > (a little) better, and so on. > > The best solution will be providing a skeleton engine (with a skeleton Makefile example). -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Sep 28 19:44:49 2016 From: rt at openssl.org (Michael Koch via RT) Date: Wed, 28 Sep 2016 19:44:49 +0000 Subject: [openssl-dev] [openssl.org #4689] Fwd: Bug in OpenSSL 1.0.2j ssl_accept In-Reply-To: References: <0f15a45b-3a74-6e65-b82b-5147ff30b849@michsoft.de> Message-ID: In addition to my message I send you my gdb backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffff1413700 (LWP 13663)] 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 (gdb) backtrace #0 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 #1 0x00007ffff6ef0ca0 in ssl3_get_client_hello () from /usr/lib64/libssl.so.1.0.0 #2 0x00007ffff6ef506f in ssl3_accept () from /usr/lib64/libssl.so.1.0.0 #3 0x00007ffff6f04acf in ssl23_accept () from /usr/lib64/libssl.so.1.0.0 #4 0x00007ffff79cafca in Thread_MCS_Networking_Listen (arg=0x6a2270) at ./mcs_networking_threads.cpp:222 #5 0x00007ffff714c444 in start_thread () from /lib64/libpthread.so.0 #6 0x00007ffff58fc4cd in clone () from /lib64/libc.so.6 (gdb) It seems as if the crash happens in "sk_value()". -------- Weitergeleitete Nachricht -------- Betreff: Bug in OpenSSL 1.0.2j ssl_accept Datum: Wed, 28 Sep 2016 21:07:48 +0200 Von: Michael Koch Organisation: MichSoft Consulting An: rt at openssl.org Hello, on our Webserver Management Software, based von Gentoo Linux, den XML REST Service which uses the OpenSSL Client library periodically crashed with Signal 11 on ssl_accept since we have updated to Openssl 1.0.2j two days ago. Best regards from Germany. -- Mit freundlichem Gru? Michael Koch MichSoft Consulting Pappelweg 7 D - 29664 Walsrode eMail michael.koch at michsoft.de Internet http://www.michsoft.de Phone +49 (0) 5161 / 94 94 83 - 0 Fax +49 (0) 5161 / 94 94 83 - 5 Umsatzsteuer Identifikationsnummer nach ? 27 Umsatzsteuergesetz: DE 41 123 05752 Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann vertraulich oder gesetzlich geschuetzte Informationen enthalten. Wenn Sie nicht der bestimmungsgemaesse Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemaessen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir verwenden aktuelle Virenschutzprogramme. Fuer Schaeden, die dem Empfaenger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schliessen wir jede Haftung aus. The information contained in this email is intended only for its addressee and may contain confidential and/or privileged information. If the reader of this email is not the intended recipient, you are hereby notified that reading, saving, distribution or use of the content of this email in any way is prohibited. If you have received this email in error, please notify the sender and delete the email. We use updated antivirus protection software. We do not accept any responsibility for damages caused anyhow by viruses transmitted via email. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4689 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 28 19:44:56 2016 From: rt at openssl.org (Michael Koch via RT) Date: Wed, 28 Sep 2016 19:44:56 +0000 Subject: [openssl-dev] [openssl.org #4690] Bug in OpenSSL 1.0.2j ssl_accept In-Reply-To: <0f15a45b-3a74-6e65-b82b-5147ff30b849@michsoft.de> References: <0f15a45b-3a74-6e65-b82b-5147ff30b849@michsoft.de> Message-ID: Hello, on our Webserver Management Software, based von Gentoo Linux, den XML REST Service which uses the OpenSSL Client library periodically crashed with Signal 11 on ssl_accept since we have updated to Openssl 1.0.2j two days ago. Best regards from Germany. -- Mit freundlichem Gru? Michael Koch MichSoft Consulting Pappelweg 7 D - 29664 Walsrode eMail michael.koch at michsoft.de Internet http://www.michsoft.de Phone +49 (0) 5161 / 94 94 83 - 0 Fax +49 (0) 5161 / 94 94 83 - 5 Umsatzsteuer Identifikationsnummer nach ? 27 Umsatzsteuergesetz: DE 41 123 05752 Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann vertraulich oder gesetzlich geschuetzte Informationen enthalten. Wenn Sie nicht der bestimmungsgemaesse Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemaessen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir verwenden aktuelle Virenschutzprogramme. Fuer Schaeden, die dem Empfaenger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schliessen wir jede Haftung aus. The information contained in this email is intended only for its addressee and may contain confidential and/or privileged information. If the reader of this email is not the intended recipient, you are hereby notified that reading, saving, distribution or use of the content of this email in any way is prohibited. If you have received this email in error, please notify the sender and delete the email. We use updated antivirus protection software. We do not accept any responsibility for damages caused anyhow by viruses transmitted via email. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4690 Please log in as guest with password guest if prompted From bkaduk at akamai.com Wed Sep 28 20:40:10 2016 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 28 Sep 2016 15:40:10 -0500 Subject: [openssl-dev] Input on renegotiation behaviour In-Reply-To: <33fbf11e-a3be-1b66-7699-48d4be8a3847@openssl.org> References: <33fbf11e-a3be-1b66-7699-48d4be8a3847@openssl.org> Message-ID: On 09/28/2016 03:27 AM, Matt Caswell wrote: > The current behaviour is not *wrong* either for TLS or DTLS, but the > discrepancy is quite weird and confusing. Should we: > > 1) Change TLS to behave like it used to, and like DTLS still does > > 2) Change DTLS to be consistent with the TLS behaviour > > 3) Keep it as it is and retain the current inconsistency > > And if we change things, should we just change it in the current dev > branch - or backport it as a bug fix? > > Thoughts? > I don't think any change should be backported --it's potentially disruptive, and if the behavior (change) has gone unnoticed for so long, it hardly seems urgent to normalize between DTLS and TLS. It seems like the abbreviated handshake would save some computational resources; on the flip side, it would not have the opportunity for a fresh DH exchange to stir the key material. If anything, that would almost suggest a (4) change DTLS to default to abbreviated handshakes and change TLS to default to normal handshakes since the DTLS server could be sending a HelloRequest because it had to dump state, but the TLS/TCP connection is persistent and the potential need for key update greater there. That said, I do prefer consistency between DTLS and TLS, so would lean towards option (2), myself, for the resource savings. -Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From rt at openssl.org Wed Sep 28 21:15:57 2016 From: rt at openssl.org (Stephen Henson via RT) Date: Wed, 28 Sep 2016 21:15:57 +0000 Subject: [openssl-dev] [openssl.org #4690] Bug in OpenSSL 1.0.2j ssl_accept In-Reply-To: References: <0f15a45b-3a74-6e65-b82b-5147ff30b849@michsoft.de> Message-ID: On Wed Sep 28 19:44:49 2016, michael at michsoft.de wrote: > In addition to my message I send you my gdb backtrace: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffff1413700 (LWP 13663)] > 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > (gdb) backtrace > #0 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 > #1 0x00007ffff6ef0ca0 in ssl3_get_client_hello () from > /usr/lib64/libssl.so.1.0.0 > #2 0x00007ffff6ef506f in ssl3_accept () from /usr/lib64/libssl.so.1.0.0 > #3 0x00007ffff6f04acf in ssl23_accept () from /usr/lib64/libssl.so.1.0.0 > #4 0x00007ffff79cafca in Thread_MCS_Networking_Listen (arg=0x6a2270) at > ./mcs_networking_threads.cpp:222 > #5 0x00007ffff714c444 in start_thread () from /lib64/libpthread.so.0 > #6 0x00007ffff58fc4cd in clone () from /lib64/libc.so.6 > (gdb) > > > It seems as if the crash happens in "sk_value()". > Which version of OpenSSL were you using before which didn't crash? Can you provide a backtrace with debugging symbols enabled? Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4690 Please log in as guest with password guest if prompted From rt at openssl.org Wed Sep 28 21:26:27 2016 From: rt at openssl.org (Michael Koch via RT) Date: Wed, 28 Sep 2016 21:26:27 +0000 Subject: [openssl-dev] [openssl.org #4690] Bug in OpenSSL 1.0.2j ssl_accept In-Reply-To: References: <0f15a45b-3a74-6e65-b82b-5147ff30b849@michsoft.de> Message-ID: Hallo Steve, since the output comes from an in production system, we doesn't have debugging symbols there. I'll try to setup a second machine with the same configuration and use debugging symbols there. Before upgrading to 1.0.2j we use 1.02h-r2 (each marked as "stable" in Gentoo portage tree). The problem only comes sometimes (not reconstruteable). Michael Am 28.09.2016 um 23:15 schrieb Stephen Henson via RT: > On Wed Sep 28 19:44:49 2016, michael at michsoft.de wrote: >> In addition to my message I send you my gdb backtrace: >> >> Program received signal SIGSEGV, Segmentation fault. >> [Switching to Thread 0x7ffff1413700 (LWP 13663)] >> 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 >> (gdb) backtrace >> #0 0x00007ffff6ba4e87 in sk_value () from /usr/lib64/libcrypto.so.1.0.0 >> #1 0x00007ffff6ef0ca0 in ssl3_get_client_hello () from >> /usr/lib64/libssl.so.1.0.0 >> #2 0x00007ffff6ef506f in ssl3_accept () from /usr/lib64/libssl.so.1.0.0 >> #3 0x00007ffff6f04acf in ssl23_accept () from /usr/lib64/libssl.so.1.0.0 >> #4 0x00007ffff79cafca in Thread_MCS_Networking_Listen (arg=0x6a2270) at >> ./mcs_networking_threads.cpp:222 >> #5 0x00007ffff714c444 in start_thread () from /lib64/libpthread.so.0 >> #6 0x00007ffff58fc4cd in clone () from /lib64/libc.so.6 >> (gdb) >> >> >> It seems as if the crash happens in "sk_value()". >> > Which version of OpenSSL were you using before which didn't crash? > > Can you provide a backtrace with debugging symbols enabled? > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > -- Mit freundlichem Gru? Michael Koch MichSoft Consulting Pappelweg 7 D - 29664 Walsrode eMail michael.koch at michsoft.de Internet http://www.michsoft.de Phone +49 (0) 5161 / 94 94 83 - 0 Fax +49 (0) 5161 / 94 94 83 - 5 Umsatzsteuer Identifikationsnummer nach ? 27 Umsatzsteuergesetz: DE 41 123 05752 Diese Information ist ausschliesslich fuer den Adressaten bestimmt und kann vertraulich oder gesetzlich geschuetzte Informationen enthalten. Wenn Sie nicht der bestimmungsgemaesse Adressat sind, unterrichten Sie bitte den Absender und vernichten Sie diese Mail. Anderen als dem bestimmungsgemaessen Adressaten ist es untersagt, diese E-Mail zu lesen, zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. Wir verwenden aktuelle Virenschutzprogramme. Fuer Schaeden, die dem Empfaenger gleichwohl durch von uns zugesandte mit Viren befallene E-Mails entstehen, schliessen wir jede Haftung aus. The information contained in this email is intended only for its addressee and may contain confidential and/or privileged information. If the reader of this email is not the intended recipient, you are hereby notified that reading, saving, distribution or use of the content of this email in any way is prohibited. If you have received this email in error, please notify the sender and delete the email. We use updated antivirus protection software. We do not accept any responsibility for damages caused anyhow by viruses transmitted via email. -- Ticket here: http://rt.openssl.org/Ticket/Display.html?id=4690 Please log in as guest with password guest if prompted From cory at lukasa.co.uk Thu Sep 29 08:26:25 2016 From: cory at lukasa.co.uk (Cory Benfield) Date: Thu, 29 Sep 2016 09:26:25 +0100 Subject: [openssl-dev] SSLKEYLOGFILE Support In-Reply-To: <9d0d0b8b82f34a8bac22c818ad492ff6@usma1ex-dag1mb1.msg.corp.akamai.com> References: <86BA005D-7756-4D98-9F0C-B3C7C4F07CFA@lukasa.co.uk> <9d0d0b8b82f34a8bac22c818ad492ff6@usma1ex-dag1mb1.msg.corp.akamai.com> Message-ID: <939F1CB9-DFD2-4BD0-9480-0488D429B8B8@lukasa.co.uk> Ok, I?ve proposed an initial patch at https://github.com/openssl/openssl/pull/1646 I?d like some feedback about how best to test this functionality, but initially this does appear to work. Cory > On 28 Sep 2016, at 13:30, Salz, Rich wrote: > >> [0]: https://commondatastorage.googleapis.com/chromium-boringssl-docs/ssl.h.html#SSL_CTX_set_keylog_callback > > That seems like a reasonable thing to put into the next release. > > -- > Senior Architect, Akamai Technologies > Member, OpenSSL Dev Team > IM: richsalz at jabber.at Twitter: RichSalz > > -- > openssl-dev mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev From matt at openssl.org Thu Sep 29 08:40:37 2016 From: matt at openssl.org (Matt Caswell) Date: Thu, 29 Sep 2016 09:40:37 +0100 Subject: [openssl-dev] Input on renegotiation behaviour In-Reply-To: References: <33fbf11e-a3be-1b66-7699-48d4be8a3847@openssl.org> Message-ID: <3b02eca0-2604-65f1-961a-e889b79e258d@openssl.org> On 28/09/16 21:40, Benjamin Kaduk wrote: > On 09/28/2016 03:27 AM, Matt Caswell wrote: >> The current behaviour is not *wrong* either for TLS or DTLS, but the >> discrepancy is quite weird and confusing. Should we: >> >> 1) Change TLS to behave like it used to, and like DTLS still does >> >> 2) Change DTLS to be consistent with the TLS behaviour >> >> 3) Keep it as it is and retain the current inconsistency >> >> And if we change things, should we just change it in the current dev >> branch - or backport it as a bug fix? >> >> Thoughts? >> > > I don't think any change should be backported --it's potentially > disruptive, and if the behavior (change) has gone unnoticed for so long, > it hardly seems urgent to normalize between DTLS and TLS. > > It seems like the abbreviated handshake would save some computational > resources; on the flip side, it would not have the opportunity for a > fresh DH exchange to stir the key material. If anything, that would > almost suggest a > > (4) change DTLS to default to abbreviated handshakes and change TLS to > default to normal handshakes > > since the DTLS server could be sending a HelloRequest because it had to > dump state, but the TLS/TCP connection is persistent and the potential > need for key update greater there. > > That said, I do prefer consistency between DTLS and TLS, so would lean > towards option (2), myself, for the resource savings. Thanks Ben. Option 2 still gives the server the opportunity to not resume the session if it so wishes (and in the scenario we are talking about the server has initiated this), so perhaps that is the more flexible route anyway. Any one else have any thoughts on this? Matt From rschm2 at unh.newhaven.edu Thu Sep 29 18:13:31 2016 From: rschm2 at unh.newhaven.edu (Schmicker, Robert) Date: Thu, 29 Sep 2016 18:13:31 +0000 Subject: [openssl-dev] RAND_bytes() Properly Reseeding Message-ID: <56662209-C1B1-4437-ABBC-4382E6C00A92@unh.newhaven.edu> Hello, I?m a little unsure on the recommended way to properly reseed the RAND_bytes() function. My output provides random numbers, but only the first 16 bytes. The output of byte 16 and on is just some period of the first 16 bytes and therefore has several duplicated numbers. My inputs are four seeds, each 128 bits in size. A SEED_SIZE with a value of 16 (where I believe the periodicity to be coming from). Then an output buffer of 256 bits containing the random bytes as well as the RAND_SIZE with a value of 64. 1: RAND_seed(s->seed1, SEED_SIZE); 2: RAND_bytes(buffer1, RAND_SIZE); 3: RAND_seed(s->seed2, SEED_SIZE); 4: RAND_bytes(buffer2, RAND_SIZE); 5: RAND_seed(s->seed3, SEED_SIZE); 6: RAND_bytes(buffer3, RAND_SIZE); 7: RAND_seed(s->seed4, SEED_SIZE); 8: RAND_bytes(buffer4, RAND_SIZE); Any reason why four very different seeds are providing the same random numbers, but just in different orders? Thank you for the read and any help, Rob Schmicker From tshort at akamai.com Fri Sep 30 17:31:55 2016 From: tshort at akamai.com (Short, Todd) Date: Fri, 30 Sep 2016 17:31:55 +0000 Subject: [openssl-dev] Input on renegotiation behaviour In-Reply-To: <3b02eca0-2604-65f1-961a-e889b79e258d@openssl.org> References: <33fbf11e-a3be-1b66-7699-48d4be8a3847@openssl.org> <3b02eca0-2604-65f1-961a-e889b79e258d@openssl.org> Message-ID: +1 for making DTLS behavior like TLS in terms of attempting an abbreviated handshake. (2) -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 29, 2016, at 4:40 AM, Matt Caswell > wrote: On 28/09/16 21:40, Benjamin Kaduk wrote: On 09/28/2016 03:27 AM, Matt Caswell wrote: The current behaviour is not *wrong* either for TLS or DTLS, but the discrepancy is quite weird and confusing. Should we: 1) Change TLS to behave like it used to, and like DTLS still does 2) Change DTLS to be consistent with the TLS behaviour 3) Keep it as it is and retain the current inconsistency And if we change things, should we just change it in the current dev branch - or backport it as a bug fix? Thoughts? I don't think any change should be backported --it's potentially disruptive, and if the behavior (change) has gone unnoticed for so long, it hardly seems urgent to normalize between DTLS and TLS. It seems like the abbreviated handshake would save some computational resources; on the flip side, it would not have the opportunity for a fresh DH exchange to stir the key material. If anything, that would almost suggest a (4) change DTLS to default to abbreviated handshakes and change TLS to default to normal handshakes since the DTLS server could be sending a HelloRequest because it had to dump state, but the TLS/TCP connection is persistent and the potential need for key update greater there. That said, I do prefer consistency between DTLS and TLS, so would lean towards option (2), myself, for the resource savings. Thanks Ben. Option 2 still gives the server the opportunity to not resume the session if it so wishes (and in the scenario we are talking about the server has initiated this), so perhaps that is the more flexible route anyway. Any one else have any thoughts on this? Matt -- openssl-dev mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: