From aroman at alienvault.com Tue Sep 1 17:28:35 2015 From: aroman at alienvault.com (Alberto Roman Linacero) Date: Tue, 1 Sep 2015 19:28:35 +0200 Subject: [openssl-users] Forcing the FIPS module to fail (no way) Message-ID: Hi there, I'd like to know how to make fail some application compiled with the FIPS module, I need to make that test for a certification process but my tests doesn't get the application fail. When some application is compiled with fipscanister.o it stores inside the application a FIPS_signature. Then, when the application calls to FIPS_mode_set(1) that HMAC-SHA1 signature is checked and if the application binary has been modified it will lead to an error. But I'm not able to generate that error. To test it, I compiled openssl with fips support , then I started FIPS mode, brutally changed some random bits in the apps/openssl binary, and then I tried a simple hash1: server:~/openssl-1.0.1p# export OPENSSL_FIPS=1 server:~/openssl-1.0.1p# vi apps/openssl server:~/openssl-1.0.1p# apps/openssl sha1 NEWS SHA1(NEWS)= 163e5a1ff9b2b06dafdc8783ce91c4d0a49f55db Why it is not failing? The fips self-tests should show some kind of error, AFAIK. (obviously I can easily get a segfault, but that's not what I want). Also, editing the openssl binary I can see the etaonrishdlcupfm signature. Then, I tried a similar thing with stunnel4, that links to a libcrypto.so.1.0.0 compiled with fips support (that file also has the etaonrishdlcupfm signature). I modified some bits in the libcrypto.so.1.0.0 file and stunnel is not giving any error, its log says that it enters into FIPS mode correctly. So, why is not the FIPS module failing to start? Why it doesn't alerts me about the application manipulation? Thanks in advance and best regards, Alberto. -- Alberto. From steve at openssl.org Tue Sep 1 17:53:01 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Tue, 1 Sep 2015 17:53:01 +0000 Subject: [openssl-users] Forcing the FIPS module to fail (no way) In-Reply-To: References: Message-ID: <20150901175301.GA7764@openssl.org> On Tue, Sep 01, 2015, Alberto Roman Linacero wrote: > Hi there, I'd like to know how to make fail some application compiled > with the FIPS module, I need to make that test for a certification > process but my tests doesn't get the application fail. > > When some application is compiled with fipscanister.o it stores > inside the application a FIPS_signature. Then, when the application > calls to FIPS_mode_set(1) that HMAC-SHA1 signature is checked and if > the application binary has been modified it will lead to an error. > > But I'm not able to generate that error. To test it, I compiled > openssl with fips support , then I started FIPS mode, brutally changed > some random bits in the apps/openssl binary, and then I tried a simple > hash1: > > server:~/openssl-1.0.1p# export OPENSSL_FIPS=1 > server:~/openssl-1.0.1p# vi apps/openssl > server:~/openssl-1.0.1p# apps/openssl sha1 NEWS > SHA1(NEWS)= 163e5a1ff9b2b06dafdc8783ce91c4d0a49f55db > > Why it is not failing? The fips self-tests should show some kind of > error, AFAIK. (obviously I can easily get a segfault, but that's not > what I want). > The FIPS signature checks for changes in the FIPS module code itself not the whole binary. So if you change some code that isn't part of the FIPS module the integrity test will not fail. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From aroman at alienvault.com Tue Sep 1 19:50:56 2015 From: aroman at alienvault.com (Alberto Roman Linacero) Date: Tue, 1 Sep 2015 21:50:56 +0200 Subject: [openssl-users] Forcing the FIPS module to fail (no way) In-Reply-To: <20150901175301.GA7764@openssl.org> References: <20150901175301.GA7764@openssl.org> Message-ID: So, it is possible in runtime to know if the FIPS module code has been changed after compiling? I mean, after the openssl has been compiled with the FIPS Object Module (./config fips & make & make install), the 4 files in the FIPS Object Module (fipscanister* and so on) doesn't need to be in the final system to let work the application (openssl for instance). Is there any way to know, at runtime, that the FIPS Object Module code has not been changed? Or, another way to ask, can I run a FIPS capable openssl and modify something somewhere that warns me that the crypto module has been changed? Also, just for the openssl-users records: to make fail the FIPS module it is needed to change the fipscanister.o file or the fips_premain.c file. Then an error will appear when try to link some other application (openssl in my example): server:~/openssl-1.0.1p# make install [...] ( :; LIBDEPS="${LIBDEPS:--L.. -lssl -L.. -lcrypto -ldl}"; LDCMD="${LDCMD:-/usr/local/ssl/fips-2.0/bin/fipsld}"; LDFLAGS="${LDFLAGS:--DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -Wa,--noexecstack -m64 -DL_ENDIAN -O3 -Wall -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DWHIRLPOOL_ASM -DGHASH_ASM}"; LIBPATH=`for x in $LIBDEPS; do echo $x; done | sed -e 's/^ *-L//;t' -e d | uniq`; LIBPATH=`echo $LIBPATH | sed -e 's/ /:/g'`; LD_LIBRARY_PATH=$LIBPATH:$LD_LIBRARY_PATH ${LDCMD} ${LDFLAGS} -o ${APPNAME:=openssl} openssl.o verify.o asn1pars.o req.o dgst.o dh.o dhparam.o enc.o passwd.o gendh.o errstr.o ca.o pkcs7.o crl2p7.o crl.o rsa.o rsautl.o dsa.o dsaparam.o ec.o ecparam.o x509.o genrsa.o gendsa.o genpkey.o s_server.o s_client.o speed.o s_time.o apps.o s_cb.o s_socket.o app_rand.o version.o sess_id.o ciphers.o nseq.o pkcs12.o pkcs8.o pkey.o pkeyparam.o pkeyutl.o spkac.o smime.o cms.o rand.o engine.o ocsp.o prime.o ts.o srp.o ${LIBDEPS} ) 1c1 < HMAC-SHA1(fipscanister.o)= 434ccf6304c5eb4724240ae1a6fd4345d4922db5 --- > HMAC-SHA1(fipscanister.o)= a1b9666ebbcb8fee0cbd15aa9d55862bf0d7062e /usr/local/ssl/fips-2.0/lib//fipscanister.o fingerprint mismatch make[2]: *** [link_app.] Error 1 Thanks again, Alberto. 2015-09-01 19:53 GMT+02:00 Dr. Stephen Henson : > On Tue, Sep 01, 2015, Alberto Roman Linacero wrote: > >> Hi there, I'd like to know how to make fail some application compiled >> with the FIPS module, I need to make that test for a certification >> process but my tests doesn't get the application fail. >> >> When some application is compiled with fipscanister.o it stores >> inside the application a FIPS_signature. Then, when the application >> calls to FIPS_mode_set(1) that HMAC-SHA1 signature is checked and if >> the application binary has been modified it will lead to an error. >> >> But I'm not able to generate that error. To test it, I compiled >> openssl with fips support , then I started FIPS mode, brutally changed >> some random bits in the apps/openssl binary, and then I tried a simple >> hash1: >> >> server:~/openssl-1.0.1p# export OPENSSL_FIPS=1 >> server:~/openssl-1.0.1p# vi apps/openssl >> server:~/openssl-1.0.1p# apps/openssl sha1 NEWS >> SHA1(NEWS)= 163e5a1ff9b2b06dafdc8783ce91c4d0a49f55db >> >> Why it is not failing? The fips self-tests should show some kind of >> error, AFAIK. (obviously I can easily get a segfault, but that's not >> what I want). >> > > The FIPS signature checks for changes in the FIPS module code itself not > the whole binary. So if you change some code that isn't part of the FIPS > module the integrity test will not fail. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Alberto Rom?n Engineering team http://www.alienvault.com Mobile: +34 605804179 Phone: + 91 5151344 Email: aroman at alienvault.com From secaficionado at gmail.com Tue Sep 1 19:48:44 2015 From: secaficionado at gmail.com (Sec_Aficiondado) Date: Tue, 1 Sep 2015 15:48:44 -0400 Subject: [openssl-users] ASN.1: Parsing a 'private' class In-Reply-To: <55E4DEF1.7080302@openca.org> References: <55E238A1.1010001@openca.org> <55E4DEF1.7080302@openca.org> Message-ID: <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> Hi Massimiliano, Please do share it here on the list. There might not be an immediate need for it, but you'll save a couple of days to the next poor soul that ventures down the same path :) Your solution will be indexed and pop right up on search engines in the future. Thanks! Sent from my mobile > On Aug 31, 2015, at 7:10 PM, Massimiliano Pala wrote: > > Hi all, > > I actually figured it out, if anybody is curious about the solution for parsing this CRYPTLIB signature envelope (in this case DSA) - write to me directly, I will be happy to share the solution. > > Cheers, > Max > >> On 8/29/15 6:56 PM, Massimiliano Pala wrote: >> Hi all, >> >> I am trying to parse a sequence that has, after an integer, a 'private' (xclass) item. I was wondering what is the right templates / macros to be able to generate the ASN1 functions with the usual macro. An example of the structure I have to parse (B64 - DER), is the following: >> >> MGICAQOAFGZKq8/wIYS7Iueq6NuaC3ESPqUKMAkGBSsOAwIaBQAwCwYHKoZIzjgEAQUABC8wLQIVAJTJ6W2QjBIbVQdAtLbPO3y1wazHAhRsXivNO/Eg4GMEgcmEx8OgsIxGzQ== >> >> [ you can paste it into http://www.lapo.it/asn1js/ to get useful info. ] >> >> The field that is giving me issues is the 2nd field in the sequence - offest 5, length 20 (i.e., after SEQUENCE (2 bytes) + INTEGER (3 bytes) and then the 20bytes field that I want to parse). The type is 0x80 - context specific. By using the ASN1_get_object() function, I get the correct size (20), the tag (0), and the xclass (128). Now, how do I go in order to generate the useful ASN1 function with teh usual macros ? Here's an example (besides the second field) for what I am trying to do: >> >> ASN1_SEQUENCE(TYPE) = { >> >> ASN1_SIMPLE(TYPE, field1, ASN1_INTEGER), >> >> XXXXXXX(TYPE, field2, YYYYY), <<-- What shall be used here ? What Macro ? >> >> ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), >> >> ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), >> >> ASN1_SIMPLE(TYPE, field3, ASN1_OCTET_STRING) <<-- This might be wrong as well - just noticed it is a very >> >> } ASN1_SEQUENCE_END(TYPE) weird encoding (octet-string that encapsulates a sequence of integers) >> >> >> Is there a way to have the macros do the work (e.g., shall I use other macros - template? - to define the field somehow) ? Or shall I just write my own d2i_ and i2d_ functions ? >> >> Please let me know, >> >> Cheers, >> Max >> >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From Matthias.St.Pierre at ncp-e.com Wed Sep 2 06:33:21 2015 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 2 Sep 2015 08:33:21 +0200 Subject: [openssl-users] FIPS_drbg_*() are not exported from FIPS capable libeay32.dll on Windows (OpenSSL 1.0.2x and 1.0.1x) In-Reply-To: <55DDD7CE.5080007@ncp-e.com> References: <55DDD7CE.5080007@ncp-e.com> Message-ID: <55E69831.7000909@ncp-e.com> Dear Mr. Henson, sorry for bothering you again with my question: is there a reason why the FIPS_drbg_*() functions are not exported from libeay32.dll on Windows, although they are officially documented in the OpenSSL FIPS 2.0 User Guide? Aren't they intended to be used by application developers? Thank you in advance, Regards, Matthias St. Pierre On 08/26/2015 05:14 PM, Dr. Matthias St. Pierre wrote: > > Dear Mr. Henson, > > I noticed that for OpenSSL 1.0.2x and 1.0.1x on Windows the FIPS capable libeay32.dll > does not export any of the FIPS_drbg_*() functions, although they are officially > documented by the OpenSSL FIPS 2.0 User Guide. > > Is this an oversight or was this done on purpose? (IOW, is it a bug or a feature? ;-) > > I checked the git repository and found out that the symbols are listed in util/libeay.num > on the master branch but are missing on the OpenSSL_1_0_2-stable and OpenSSL_1_0_1-stable > branch (see [1]). > > In fact, the entire log of the OpenSSL_1_0_{1,2}-stable branch shows no indication that these > symbols were ever added to or removed from libeay.num (see [2]). > > This is strange, because the symbols were initially added by you in the following commit, > where you state that symbol ordinals are in sync with the 1.0.1 stable branch. > > commit 7bd4095b127f7376bafd9010c45673c7d354fe81 > Author: Dr. Stephen Henson > Date: Sun Oct 9 15:29:43 2011 +0000 > > Sync ordinals with 1.0.1-stable. > > > It would be nice if you could be so kind to shed some light on this to clear up my confusion. > > Best regards, > MSP > > > > [1] ~/src/openssl$ git checkout master > Switched to branch 'master' > Your branch is up-to-date with 'origin/master'. > > ~/src/openssl$ grep FIPS_drbg_ util/libeay.num > FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: > FIPS_drbg_set_callbacks 4811 NOEXIST::FUNCTION: > FIPS_drbg_free 4812 NOEXIST::FUNCTION: > FIPS_drbg_get_strength 4813 NOEXIST::FUNCTION: > FIPS_drbg_set_reseed_interval 4814 NOEXIST::FUNCTION: > (...) > > ~/src/openssl$ git checkout OpenSSL_1_0_2-stable > Switched to branch 'OpenSSL_1_0_2-stable' > Your branch is up-to-date with 'origin/OpenSSL_1_0_2-stable'. > > ~/src/openssl$ grep FIPS_drbg_ util/libeay.num > > > > [2] ~/src/openssl$ git log -p OpenSSL_1_0_2-stable -- util/libeay.num | grep FIPS_drbg_ > > > ~/src/openssl$ git log -p OpenSSL_1_0_1-stable -- util/libeay.num | grep FIPS_drbg_ > > > msp at msppc:~/src/openssl$ git log -p master -- util/libeay.num | grep FIPS_drbg_ > FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: > FIPS_drbg_get_app_data 4870 NOEXIST::FUNCTION: > FIPS_drbg_get_app_data 4870 NOEXIST::FUNCTION: > FIPS_drbg_set_check_interval 4808 NOEXIST::FUNCTION: > -FIPS_drbg_set_check_interval 4685 EXIST:OPENSSL_FIPS:FUNCTION: > -FIPS_drbg_set_rand_callbacks 4687 EXIST:OPENSSL_FIPS:FUNCTION: > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From director at openca.org Wed Sep 2 14:11:54 2015 From: director at openca.org (Massimiliano Pala) Date: Wed, 2 Sep 2015 10:11:54 -0400 Subject: [openssl-users] SOLVED --- ASN.1: Parsing a 'context-specific' class (or app/private class) In-Reply-To: <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> References: <55E238A1.1010001@openca.org> <55E4DEF1.7080302@openca.org> <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> Message-ID: <55E703AA.2010805@openca.org> Hi all, since someone asked, here's my solution (if someone knows of a better one, please let me know). The problem that I tried to solve is how to parse the CRYTPLIB-specific envelope for signatures. In particular, the example reported in my original e-mail was a DSA signature. The main issue here was how to parse a context-specific 0-tagged value inside the structure. Here's the parsing: 0:d=0 hl=2 l= 98 cons: SEQUENCE 2:d=1 hl=2 l= 1 prim: INTEGER :03 5:d=1 hl=2 l= 20 prim: cont [ 0 ] 27:d=1 hl=2 l= 9 cons: SEQUENCE 29:d=2 hl=2 l= 5 prim: OBJECT :sha1 36:d=2 hl=2 l= 0 prim: NULL 38:d=1 hl=2 l= 11 cons: SEQUENCE 40:d=2 hl=2 l= 7 prim: OBJECT :dsaEncryption 49:d=2 hl=2 l= 0 prim: NULL 51:d=1 hl=2 l= 47 prim: OCTET STRING Since I could not find any ASN1 macro that would allow me to specify the field after the INTEGER (offset 5, class context-specific (0x80), no tag (0x0), and length 20), so I defined a new ASN1_ITEM type that uses the d2i_ASN1_bytes()/i2d_ASN1_bytes() for parsing or generating the value: *typedef ASN1_OCTET_STRING CRYPTLIB_KEYID;* // Defines the CRYPTLIB_KEYID as a string (keyID) ASN1_VALUE *cryptlib_keyid_d2i_func(ASN1_VALUE **a, const unsigned char **in, long length) { ASN1_VALUE * ret = NULL; // Return Value // Parse the key identifier ret = (ASN1_VALUE *)d2i_ASN1_bytes(NULL, in, length, 0, V_ASN1_CONTEXT_SPECIFIC); // Assigns the value (if the pointer to the structure was passed) if (a != NULL) *a = ret; // Returns the parsed value return ret; } int cryptlib_keyid_i2d_func(ASN1_VALUE *a, unsigned char **in) { // Generates the DER from the passed value return i2d_ASN1_bytes((ASN1_STRING *)a, in, 0, 0x80); } // Definition of the callbacks for the compat type static ASN1_COMPAT_FUNCS cryptlib_keyid_pf = { (ASN1_new_func *)ASN1_OCTET_STRING_new, (ASN1_free_func *)ASN1_OCTET_STRING_free, *cryptlib_keyid_d2i_func*, *cryptlib_keyid_i2d_func* }; ASN1_ITEM_start(*CRYPTLIB_KEYID*) ASN1_ITYPE_COMPAT, V_ASN1_OCTET_STRING, NULL, 0, &cryptlib_keyid_pf, sizeof(*CRYPTLIB_KEYID*), "*CRYPTLIB_KEYID*" ASN1_ITEM_end(*CRYPTLIB_KEYID*) DECLARE_ASN1_FUNCTIONS(*CRYPTLIB_KEYID*); IMPLEMENT_ASN1_FUNCTIONS(*CRYPTLIB_KEYID*); This allowed me to define the CRYPTLIB_SIG by using the usual macros: typedef struct sig_t { ASN1_INTEGER *version; *CRYPTLIB_KEYID* *keyId; X509_ALGOR *hashAlgorithm; X509_ALGOR *sigAlgorithm; ASN1_OCTET_STRING *value; } CRYPTLIB_SIG; ASN1_SEQUENCE(CRYPTLIB_SIG) = { ASN1_SIMPLE(CRYPTLIB_SIG, version, ASN1_INTEGER), ASN1_SIMPLE(CRYPTLIB_SIG, keyId, *CRYPTLIB_KEYID*), ASN1_SIMPLE(CRYPTLIB_SIG, hashAlgorithm, X509_ALGOR), ASN1_SIMPLE(CRYPTLIB_SIG, sigAlgorithm, X509_ALGOR), ASN1_SIMPLE(CRYPTLIB_SIG, value, ASN1_OCTET_STRING) } ASN1_SEQUENCE_END(CRYPTLIB_SIG) DECLARE_ASN1_FUNCTIONS(CRYPTLIB_SIG) IMPLEMENT_ASN1_FUNCTIONS(CRYPTLIB_SIG) Maybe a little hackerish solution... but this is the easiest I could think of. Does anybody have a better solution ? Also, is there anybody who knows how to use the new ADB macros? Or is there any documentation on how to use them? That would be really useful to have... Cheers, Max P.S.: The contents of the 'value' field in CRYPTLIB_SIG can be simply parsed by using the appropriate key-parsing function. In the example, you can use the d2i_DSA_SIG()/i2d_DSA_SIG() for parsing the actual DSA signatures. P.P.S: Parsing application or private classes should require minimum changes (e.g., changing the class value from 0x80 to 0xC0 should allow to parse/generate private fields). On 9/1/15 3:48 PM, Sec_Aficiondado wrote: > Hi Massimiliano, > > Please do share it here on the list. There might not be an immediate need for it, but you'll save a couple of days to the next poor soul that ventures down the same path :) > > Your solution will be indexed and pop right up on search engines in the future. > > Thanks! > Sent from my mobile > >> On Aug 31, 2015, at 7:10 PM, Massimiliano Pala wrote: >> >> Hi all, >> >> I actually figured it out, if anybody is curious about the solution for parsing this CRYPTLIB signature envelope (in this case DSA) - write to me directly, I will be happy to share the solution. >> >> Cheers, >> Max >> >>> On 8/29/15 6:56 PM, Massimiliano Pala wrote: >>> Hi all, >>> >>> I am trying to parse a sequence that has, after an integer, a 'private' (xclass) item. I was wondering what is the right templates / macros to be able to generate the ASN1 functions with the usual macro. An example of the structure I have to parse (B64 - DER), is the following: >>> >>> MGICAQOAFGZKq8/wIYS7Iueq6NuaC3ESPqUKMAkGBSsOAwIaBQAwCwYHKoZIzjgEAQUABC8wLQIVAJTJ6W2QjBIbVQdAtLbPO3y1wazHAhRsXivNO/Eg4GMEgcmEx8OgsIxGzQ== >>> >>> [ you can paste it into http://www.lapo.it/asn1js/ to get useful info. ] >>> >>> The field that is giving me issues is the 2nd field in the sequence - offest 5, length 20 (i.e., after SEQUENCE (2 bytes) + INTEGER (3 bytes) and then the 20bytes field that I want to parse). The type is 0x80 - context specific. By using the ASN1_get_object() function, I get the correct size (20), the tag (0), and the xclass (128). Now, how do I go in order to generate the useful ASN1 function with teh usual macros ? Here's an example (besides the second field) for what I am trying to do: >>> >>> ASN1_SEQUENCE(TYPE) = { >>> >>> ASN1_SIMPLE(TYPE, field1, ASN1_INTEGER), >>> >>> XXXXXXX(TYPE, field2, YYYYY), <<-- What shall be used here ? What Macro ? >>> >>> ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), >>> >>> ASN1_SEQUENCE_OF(TYPE, field3, ASN1_OBJECT), >>> >>> ASN1_SIMPLE(TYPE, field3, ASN1_OCTET_STRING) <<-- This might be wrong as well - just noticed it is a very >>> >>> } ASN1_SEQUENCE_END(TYPE) weird encoding (octet-string that encapsulates a sequence of integers) >>> >>> >>> Is there a way to have the macros do the work (e.g., shall I use other macros - template? - to define the field somehow) ? Or shall I just write my own d2i_ and i2d_ functions ? >>> >>> Please let me know, >>> >>> Cheers, >>> Max >>> >>> _______________________________________________ >>> openssl-users mailing list >>> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> _______________________________________________ >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at openssl.org Wed Sep 2 16:19:25 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 2 Sep 2015 16:19:25 +0000 Subject: [openssl-users] SOLVED --- ASN.1: Parsing a 'context-specific' class (or app/private class) In-Reply-To: <55E703AA.2010805@openca.org> References: <55E238A1.1010001@openca.org> <55E4DEF1.7080302@openca.org> <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> <55E703AA.2010805@openca.org> Message-ID: <20150902161925.GA28341@openssl.org> On Wed, Sep 02, 2015, Massimiliano Pala wrote: > Hi all, > > since someone asked, here's my solution (if someone knows of a > better one, please let me know). > > The problem that I tried to solve is how to parse the > CRYTPLIB-specific envelope for signatures. In particular, the > example reported in my original e-mail was a DSA signature. The main > issue here was how to parse a context-specific 0-tagged value inside > the structure. Here's the parsing: > > 0:d=0 hl=2 l= 98 cons: SEQUENCE > 2:d=1 hl=2 l= 1 prim: INTEGER :03 > 5:d=1 hl=2 l= 20 prim: cont [ 0 ] > 27:d=1 hl=2 l= 9 cons: SEQUENCE > 29:d=2 hl=2 l= 5 prim: OBJECT :sha1 > 36:d=2 hl=2 l= 0 prim: NULL > 38:d=1 hl=2 l= 11 cons: SEQUENCE > 40:d=2 hl=2 l= 7 prim: OBJECT :dsaEncryption > 49:d=2 hl=2 l= 0 prim: NULL > 51:d=1 hl=2 l= 47 prim: OCTET STRING > > Since I could not find any ASN1 macro that would allow me to specify > the field after the INTEGER (offset 5, class context-specific > (0x80), no tag (0x0), and length 20), so I defined a new ASN1_ITEM > type that uses the d2i_ASN1_bytes()/i2d_ASN1_bytes() for parsing or > generating the value: > [snip] > > Maybe a little hackerish solution... but this is the easiest I could > think of. Does anybody have a better solution ? > Well at first sight that looks like an IMPLICIT tag which replaces the normal tag with the context specific value. It is not possible to determine the underlying type from the encoding itself as it has been replaced. So you need the ASN.1 spec to see the appropriate type to use. In that particular example it looks like an SHA1 hash (20 bytes long) so we could use an implicitly tagged OCTET STRING like this: ASN1_IMP(struct_name, field_name, ASN1_OCTET_STRING, 0), Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From dnsands at sandia.gov Wed Sep 2 16:36:40 2015 From: dnsands at sandia.gov (Sands, Daniel) Date: Wed, 2 Sep 2015 16:36:40 +0000 Subject: [openssl-users] [EXTERNAL] Re: SOLVED --- ASN.1: Parsing a 'context-specific' class (or app/private class) In-Reply-To: <20150902161925.GA28341@openssl.org> References: <55E238A1.1010001@openca.org> <55E4DEF1.7080302@openca.org> <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> <55E703AA.2010805@openca.org> <20150902161925.GA28341@openssl.org> Message-ID: <1441211800.13655.3.camel@sandia.gov> > Well at first sight that looks like an IMPLICIT tag which replaces > the normal > tag with the context specific value. It is not possible to determine > the > underlying type from the encoding itself as it has been replaced. So > you need > the ASN.1 spec to see the appropriate type to use. > > In that particular example it looks like an SHA1 hash (20 bytes long) > so we > could use an implicitly tagged OCTET STRING like this: > > ASN1_IMP(struct_name, field_name, ASN1_OCTET_STRING, 0), And often, implicit tags are intended for ASN.1 Choice constructs so that you will know which option of the choice to parse into. If the OP knew exactly what was being parsed, most likely there's an RFC that defines the structure exactly, which relieves one of needing to reverse-engineer it. From steve at openssl.org Wed Sep 2 17:26:15 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 2 Sep 2015 17:26:15 +0000 Subject: [openssl-users] [EXTERNAL] Re: SOLVED --- ASN.1: Parsing a 'context-specific' class (or app/private class) In-Reply-To: <1441211800.13655.3.camel@sandia.gov> References: <55E238A1.1010001@openca.org> <55E4DEF1.7080302@openca.org> <1FF194FD-BFA5-47BA-8942-86A04F85F08E@gmail.com> <55E703AA.2010805@openca.org> <20150902161925.GA28341@openssl.org> <1441211800.13655.3.camel@sandia.gov> Message-ID: <20150902172615.GA29571@openssl.org> On Wed, Sep 02, 2015, Sands, Daniel wrote: > > Well at first sight that looks like an IMPLICIT tag which replaces > > the normal > > tag with the context specific value. It is not possible to determine > > the > > underlying type from the encoding itself as it has been replaced. So > > you need > > the ASN.1 spec to see the appropriate type to use. > > > > In that particular example it looks like an SHA1 hash (20 bytes long) > > so we > > could use an implicitly tagged OCTET STRING like this: > > > > ASN1_IMP(struct_name, field_name, ASN1_OCTET_STRING, 0), > > And often, implicit tags are intended for ASN.1 Choice constructs so > that you will know which option of the choice to parse into. > Or OPTIONAL and occasionally one does see tagged types for no apparent reason. Also just because you see a universal tag doesn't mean that it isn't part of a CHOICE: which would mean the parser would choke when it encountered an unexpected tag. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From steve at openssl.org Wed Sep 2 18:16:29 2015 From: steve at openssl.org (Dr. Stephen Henson) Date: Wed, 2 Sep 2015 18:16:29 +0000 Subject: [openssl-users] Forcing the FIPS module to fail (no way) In-Reply-To: References: <20150901175301.GA7764@openssl.org> Message-ID: <20150902181629.GA30262@openssl.org> On Tue, Sep 01, 2015, Alberto Roman Linacero wrote: > So, it is possible in runtime to know if the FIPS module code has been > changed after compiling? I mean, after the openssl has been compiled > with the FIPS Object Module (./config fips & make & make install), the > 4 files in the FIPS Object Module (fipscanister* and so on) doesn't > need to be in the final system to let work the application (openssl > for instance). > > Is there any way to know, at runtime, that the FIPS Object Module code > has not been changed? > Yes the integrity test will fail. Just to clarify. When you link the FIPS module part of the code will correspond to the application (which may be OpenSSL itself or the OpenSSL shared library) and part of it will be the FIPS module code from fipscanister.o. If you change the part of the binary corresponding to fipscanister.o the integrity test will fail, if you change the part of the binary outside fipscanister.o it wont. For example there is a version string which says something like "FIPS 2.0.10 validated module 14 May 2015", try changing that. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org From aroman at alienvault.com Wed Sep 2 18:35:34 2015 From: aroman at alienvault.com (Alberto Roman Linacero) Date: Wed, 2 Sep 2015 20:35:34 +0200 Subject: [openssl-users] Forcing the FIPS module to fail (no way) In-Reply-To: <20150902181629.GA30262@openssl.org> References: <20150901175301.GA7764@openssl.org> <20150902181629.GA30262@openssl.org> Message-ID: Yep, I understand now. I thought that the whole binary file application was signed, and not only the FIPS module part. I already did some tests (with that string and also in different parts of the code that belongs to the fipscanister.o), and it -correctly- fails. server:~# export OPENSSL_FIPS=1 server:~# openssl sha1 testfile 139697803871912:error:2D06B06F:FIPS routines:FIPS_check_incore_fingerprint:fingerprint does not match:fips.c:232: Thanks a lot!! 2015-09-02 20:16 GMT+02:00 Dr. Stephen Henson : > On Tue, Sep 01, 2015, Alberto Roman Linacero wrote: > >> So, it is possible in runtime to know if the FIPS module code has been >> changed after compiling? I mean, after the openssl has been compiled >> with the FIPS Object Module (./config fips & make & make install), the >> 4 files in the FIPS Object Module (fipscanister* and so on) doesn't >> need to be in the final system to let work the application (openssl >> for instance). >> >> Is there any way to know, at runtime, that the FIPS Object Module code >> has not been changed? >> > > Yes the integrity test will fail. > > Just to clarify. When you link the FIPS module part of the code will > correspond to the application (which may be OpenSSL itself or the > OpenSSL shared library) and part of it will be the FIPS module code from > fipscanister.o. If you change the part of the binary corresponding to > fipscanister.o the integrity test will fail, if you change the part of the > binary outside fipscanister.o it wont. > > For example there is a version string which says something like "FIPS 2.0.10 > validated module 14 May 2015", try changing that. > > Steve. > -- > Dr Stephen N. Henson. OpenSSL project core developer. > Commercial tech support now available see: http://www.openssl.org > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- Alberto Rom?n Engineering team http://www.alienvault.com Mobile: +34 605804179 Phone: + 91 5151344 Email: aroman at alienvault.com From marquess at opensslfoundation.com Wed Sep 2 18:51:54 2015 From: marquess at opensslfoundation.com (Steve Marquess) Date: Wed, 2 Sep 2015 14:51:54 -0400 Subject: [openssl-users] Forcing the FIPS module to fail (no way) In-Reply-To: References: <20150901175301.GA7764@openssl.org> <20150902181629.GA30262@openssl.org> Message-ID: <55E7454A.5000903@opensslfoundation.com> On 09/02/2015 02:35 PM, Alberto Roman Linacero wrote: > Yep, I understand now. I thought that the whole binary file > application was signed, and not only the FIPS module part. An understandable assumption, see below. > I already did some tests (with that string and also in different parts > of the code that belongs to the fipscanister.o), and it -correctly- > fails. Side note on ancient history: our initial implementation (circa 2003) calculated a digest over the entire binary file, application code plus FIPS module code. Our reasoning was that if the digest of the entire file did not change then no subset could have changed either. That was rejected by the CMVP on the grounds that there might be a SHA-1 digest collision; we are only allowed to calculate the digest over the FIPS module code proper. Needless to say that complicated the design of the "incore" calculation a bit. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at openssl.com marquess at opensslfoundation.net gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From rsalz at akamai.com Thu Sep 3 02:38:10 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 02:38:10 +0000 Subject: [openssl-users] Cleanup and changing the malloc routines Message-ID: We are considering a big cleanup to the memory-allocation API's in the next release. Please take a look at the attached documentation, which describes *ALL* of the public functions, and let us know if it will cause a problem. Thanks. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: OPENSSL_malloc.pod Type: application/octet-stream Size: 5598 bytes Desc: OPENSSL_malloc.pod URL: From kevinlong206 at gmail.com Thu Sep 3 04:53:05 2015 From: kevinlong206 at gmail.com (Kevin Long) Date: Wed, 2 Sep 2015 21:53:05 -0700 Subject: [openssl-users] using a random number file for generation of keys/certificates Message-ID: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> Hello, I?m using openssl to administer a root/intermediate CA and I use the certificates for a number of web servers and other applications. All of my users install my root CA certificate for trust. I?ve been asked to use a hardware random number generator to create the keys/certificates going forward. I have a hardware RNG, and have created several files of random numbers using it, and I would like to know: 1) Can I specify my random numbers file to create keys/certificates from my CA (openssl command line, mac or linux) 2) Will this actually do any good, security wise, given how openssl certs/keys ?work?. My users and superiors are concerned with backdoors in PRNGs and RNG predictabilities. 3) If I can indeed use my own random numbers, does this mean I have to start my CA from scratch to take advantage of any benefit using ?true? random numbers from my hardware RNG? or would simply using my RN?s for the generation of keys for new certificates going forward allow for the benefit the true randomness gives. Thank you. From bkahle at gmail.com Thu Sep 3 06:22:44 2015 From: bkahle at gmail.com (Bryce Kahle) Date: Wed, 2 Sep 2015 23:22:44 -0700 Subject: [openssl-users] DTLS cipher suite support Message-ID: I would like to use openssl as a basic DTLS server from the command line using: openssl s_server -dtls1_2 The catch is I want to require the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 cipher suite. It appears OpenSSL currently doesn?t support this cipher suite, even though it supports the both ECDHE_ECDSA and AES_128_CCM_8 individually as separate operations. Is there some small change I can make to enable support of this cipher suite? Perhaps this is already supported in an un-released version? Cheers, Bryce Kahle -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 3 08:31:22 2015 From: matt at openssl.org (Matt Caswell) Date: Thu, 3 Sep 2015 09:31:22 +0100 Subject: [openssl-users] DTLS cipher suite support In-Reply-To: References: Message-ID: <55E8055A.40001@openssl.org> On 03/09/15 07:22, Bryce Kahle wrote: > I would like to use openssl as a basic DTLS server from the command line > using: openssl s_server -dtls1_2 > > The catch is I want to require the TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 > cipher suite. It appears OpenSSL currently doesn?t support this cipher > suite, even though it supports the both ECDHE_ECDSA and AES_128_CCM_8 Released versions support ECDHE_ECDSA based ciphersuites, and libcrypto supports CCM. Released versions of libssl do not support any CCM based TLS ciphersuites. > individually as separate operations. > > Is there some small change I can make to enable support of this cipher > suite? Perhaps this is already supported in an un-released version? Support for this ciphersuite has recently been added to the master branch (unreleased version 1.1.0). The changes required are non-trivial so I would recommend against a backport. See: https://github.com/openssl/openssl/commit/e75c5a794e71baa3d76214be3ac8dc6e082e4a1a https://github.com/openssl/openssl/commit/3d3701ea20ca36215e3af5ac090797cfec5fca2a https://github.com/openssl/openssl/commit/176f85a28ec73b16f68a4f1737fb4645b9e9ae7b https://github.com/openssl/openssl/commit/f8f5f8369d1d76fd8ec28d3d2422a47f8440f452 https://github.com/openssl/openssl/commit/04dc8b36ef40d7ba8f33ff3d6c7c87a921e0715e Matt From akihana at gmail.com Thu Sep 3 09:23:29 2015 From: akihana at gmail.com (Mike Mohr) Date: Thu, 3 Sep 2015 02:23:29 -0700 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> Message-ID: Once you've written the random data to secondary storage you've permanently compromised the integrity of any cryptographic secrets generated from it. Depending on your threat model, underlying storage media, filesystem, and other factors the data files may be recoverable indefinitely (especially if you're using solid-state disks, due to their internal wear-leveling algorithms). Don't do that. The cryptographic secrets contained in your existing CA infrastructure were presumably generated using some sort of PRNG, so you'd have to regenerate them if you think the PRNG was somehow compromised. If not, you can use the TRNG for all newly issued certificates moving forward. However, I'd suggest not using one of the proprietary devices which are encased in epoxy ... you have no way to verify that they're doing what they say they are. The data quality coming out of those is fairly suspect in my mind (despite any positive results from e.g. dieharder, etc). On Wed, Sep 2, 2015 at 9:53 PM, Kevin Long wrote: > > > Hello, > > I?m using openssl to administer a root/intermediate CA and I use the > certificates for a number of web servers and other applications. All of my > users install my root CA certificate for trust. > > I?ve been asked to use a hardware random number generator to create the > keys/certificates going forward. I have a hardware RNG, and have created > several files of random numbers using it, and I would like to know: > > 1) Can I specify my random numbers file to create keys/certificates from > my CA (openssl command line, mac or linux) > > 2) Will this actually do any good, security wise, given how openssl > certs/keys ?work?. My users and superiors are concerned with backdoors in > PRNGs and RNG predictabilities. > > 3) If I can indeed use my own random numbers, does this mean I have to > start my CA from scratch to take advantage of any benefit using ?true? > random numbers from my hardware RNG? or would simply using my RN?s for the > generation of keys for new certificates going forward allow for the > benefit the true randomness gives. > > Thank you. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Sep 3 14:54:35 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 3 Sep 2015 16:54:35 +0200 Subject: [openssl-users] Cleanup and changing the malloc routines In-Reply-To: References: Message-ID: <55E85F2B.3080408@wisemo.com> On 03/09/2015 04:38, Salz, Rich wrote: > > We are considering a big cleanup to the memory-allocation API?s in the > next release. > > Please take a look at the attached documentation, which describes > **ALL** of the public functions, and let us know if it will cause a > problem. > A few practical notes: 1. I trust that functions to allocate specific data types (such as bignums) are not changed by this. 2. Macros that take zero arguments (such as "OPENSSL_malloc_init()") are not accepted by all compilers. In my own API designs this has forced me to give such macros a dummy argument (which is never used, it just pleases the preprocessor). 3. When compiling without compile-time debug flags, the various debug arguments should not be passed (or otherwise referenced) by the macros, avoiding a bunch of "foo.c" and line number values from filling up the compiled binary. Something like #ifdef SOME_DEBUG_DEFINE #define OPENSSL_malloc(num) (CRYPTO_malloc(num, __FILE__, __LINE__)) ... #else #define OPENSSL_malloc(num) (CRYPTO_malloc(num, NULL, 0)) // OR #define OPENSSL_malloc(num) (CRYPTO_malloc_nodbg(num)) ... #endif 4. For the basic functions (not the callbacks), there seems to be no reason not to change to size_t now. 5. Given the huge number of backward incompatibilities in OpenSSL 1.1.x, this seems a good time to change to size_t in the callbacks too. 6. Maybe there should be an alternate get/set_mem_functions with non-linenumber callbacks (behind the scenes, either would set the the other callbacks to stubs that add/remove the extra args, the initial defaults would be direct for speed and to support the "defer to default implementation" scenarios). 7. Maybe the get/set_mem_functions should (in their debug variant) should also be able to change the backend for debug_push/_pop. 8. For readability, defines with omitted (opaque) definitions should be documented with elided args such as #define OPENSSL_malloc(num) ... and #define CRYPTO_MEM_CHECK_ON 0x... to indicate that they do not (typically) expand to nothing/typically do expand to a numeric constant 9. Typo: "pointers for with the current functions" 10. It would be helpful to clarify which older functions are getting removed. It's a bit like reading a patch without the removed lines. Kind of impossible to tell what you propose to remove. Enjoy (NOT A CONTRIBUTION) Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From tmcclure at groupcaretech.com Thu Sep 3 15:21:25 2015 From: tmcclure at groupcaretech.com (tmcclure0501) Date: Thu, 3 Sep 2015 08:21:25 -0700 (MST) Subject: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format Message-ID: <1441293685420-59924.post@n7.nabble.com> We have an embedded MQTT framework that we want to configure for mutual authentication. The framework is complaining that it needs a key format of PKCS#1. We have p12 and pem formats of the key. Does openssl support converting keys to the PKCS#1, if so what is the command? Thanks, Tim -- View this message in context: http://openssl.6102.n7.nabble.com/Converting-a-p12-or-PEM-formatted-private-key-to-a-PKCS-1-format-tp59924.html Sent from the OpenSSL - User mailing list archive at Nabble.com. From openssl-users at dukhovni.org Thu Sep 3 16:06:06 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 16:06:06 +0000 Subject: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format In-Reply-To: <1441293685420-59924.post@n7.nabble.com> References: <1441293685420-59924.post@n7.nabble.com> Message-ID: <20150903160606.GG9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote: > We have an embedded MQTT framework that we want to configure for mutual > authentication. The framework is complaining that it needs a key format of > PKCS#1. We have p12 and pem formats of the key. Does openssl support > converting keys to the PKCS#1, if so what is the command? I've never heard of a PKCS#1 key format, I'm only aware of PKCS#8 - Private key PKCS#12 - Private key and related certificates Consult the documentation for the product, this is not an OpenSSL question until at least the desired key format is known. -- Viktor. From openssl-users at dukhovni.org Thu Sep 3 16:16:04 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 16:16:04 +0000 Subject: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format In-Reply-To: <20150903160606.GG9021@mournblade.imrryr.org> References: <1441293685420-59924.post@n7.nabble.com> <20150903160606.GG9021@mournblade.imrryr.org> Message-ID: <20150903161604.GH9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 04:06:06PM +0000, Viktor Dukhovni wrote: > On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote: > > > We have an embedded MQTT framework that we want to configure for mutual > > authentication. The framework is complaining that it needs a key format of > > PKCS#1. We have p12 and pem formats of the key. Does openssl support > > converting keys to the PKCS#1, if so what is the command? > > I've never heard of a PKCS#1 key format, I'm only aware of > > PKCS#8 - Private key > PKCS#12 - Private key and related certificates > > Consult the documentation for the product, this is not an OpenSSL > question until at least the desired key format is known. Perhaps what you're looking for is the legacy RSA key format (PEM or DER encoded). -----BEGIN RSA PRIVATE KEY----- -----END RSA PRIVATE KEY----- The "openssl rsa" command (unlike the "pkey" command) outputs RSA keys in either DER or PEM formats. -- Viktor. From rsalz at akamai.com Thu Sep 3 16:20:47 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 16:20:47 +0000 Subject: [openssl-users] Cleanup and changing the malloc routines In-Reply-To: <55E85F2B.3080408@wisemo.com> References: <55E85F2B.3080408@wisemo.com> Message-ID: <0fb646c798be4c218866f34577da5e68@ustx2ex-dag1mb3.msg.corp.akamai.com> 1. I trust that functions to allocate specific data ? types (such as bignums) are not changed by this. They are not. 2. Macros that take zero arguments (such as ? "OPENSSL_malloc_init()") are not accepted by all ? compilers.? In my own API designs this has forced ? me to give such macros a dummy argument (which is ? never used, it just pleases the preprocessor). Luckily, we are limiting to c89, so this isn't an issue. 3. When compiling without compile-time debug flags, ? the various debug arguments should not be passed ? (or otherwise referenced) by the macros, avoiding ? a bunch of "foo.c" and line number values from ? filling up the compiled binary.? Something like This is a good idea. In fact, I'll make all the memory-debug stuff disabled via the #ifdef. 4. For the basic functions (not the callbacks), there ? seems to be no reason not to change to size_t now. Agreed. It will happen in 1.1, just not the planned commit. 5. Given the huge number of backward incompatibilities ? in OpenSSL 1.1.x, this seems a good time to change to ? size_t in the callbacks too. Yup, same reason. 6. Maybe there should be an alternate get/set_mem_functions ? with non-linenumber callbacks (behind the scenes, either ? would set the the other callbacks to stubs that add/remove ? the extra args, the initial defaults would be direct for ? speed and to support the "defer to default implementation" ? scenarios). If you look, that's what the current (undocumented) code does. It was really hard to understand. I think being able to replace malloc/realloc/free at runtime, as opposed to editing the source and building your own version, is the wrong trade-off to make. But that's the goal of this thread: to find out if anyone is actually doing that. 7. Maybe the get/set_mem_functions should (in their debug ? variant) should also be able to change the backend for ? debug_push/_pop. Same as #6. 8. For readability, defines with omitted (opaque) ? definitions should be documented with elided args such ? as #define OPENSSL_malloc(num) ... and ? #define CRYPTO_MEM_CHECK_ON 0x... to indicate that they ? do not (typically) expand to nothing/typically do expand ? to a numeric constant That seems reasonable; anyone else agree? 9. Typo: "pointers for with the current functions" Thanks! 10. It would be helpful to clarify which older functions are ? getting removed.? It's a bit like reading a patch without ? the removed lines.? Kind of impossible to tell what you ? propose to remove. Here's the internal git commit message. Do you need/want more detail? Make the "change wrapper functions" be the only paradigm. Wrote documentation! Format the 'set func' functions so their paramlists are readible Format some multi-line comments. Remove LEVITTE_DEBUG_MEM Remove ability to get/set the "set options" functions at runtime. Remove ability to get/set the "memory debug" functions at runtme. Remove CRYPTO_pop_all Remove MemCheck_* and CRYPTO_malloc_debug_init macros Remove memleak_callback stuff. Remove {OPENSSL,CRYPTO}_remalloc. Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup. Add CRYPTO_mem_debug(int flag) function. Add test/memleaktest. Rename CRYPTO_dbg_xxx to CRYPTO_mem_debug_xxx Rename CRYPTO_{push,pop}_info to CRYPTO_mem_debug_{push,pop} Rename CRYPTO_malloc_init to OPENSSL_malloc_init; remove needless calls. Rename *_realloc_clear to *_clear_realloc, like *_clear_free Only two macros CRYPTO_MDEBUG,CRYPTO_MDEBUG_ABORT to control this. Enjoy (NOT A CONTRIBUTION) Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Thu Sep 3 16:23:59 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 3 Sep 2015 18:23:59 +0200 Subject: [openssl-users] Converting a p12 or PEM formatted private key to a PKCS#1 format In-Reply-To: <20150903161604.GH9021@mournblade.imrryr.org> References: <1441293685420-59924.post@n7.nabble.com> <20150903160606.GG9021@mournblade.imrryr.org> <20150903161604.GH9021@mournblade.imrryr.org> Message-ID: <55E8741F.1070501@wisemo.com> On 03/09/2015 18:16, Viktor Dukhovni wrote: > On Thu, Sep 03, 2015 at 04:06:06PM +0000, Viktor Dukhovni wrote: >> On Thu, Sep 03, 2015 at 08:21:25AM -0700, tmcclure0501 wrote: >> >>> We have an embedded MQTT framework that we want to configure for mutual >>> authentication. The framework is complaining that it needs a key format of >>> PKCS#1. We have p12 and pem formats of the key. Does openssl support >>> converting keys to the PKCS#1, if so what is the command? >> I've never heard of a PKCS#1 key format, I'm only aware of >> >> PKCS#8 - Private key >> PKCS#12 - Private key and related certificates >> >> Consult the documentation for the product, this is not an OpenSSL >> question until at least the desired key format is known. > Perhaps what you're looking for is the legacy RSA key format (PEM > or DER encoded). > > -----BEGIN RSA PRIVATE KEY----- > -----END RSA PRIVATE KEY----- > > The "openssl rsa" command (unlike the "pkey" command) outputs RSA > keys in either DER or PEM formats. > So to summarize: First use the command "openssl pkcs12" and a text editor to split the p12 file into individual certificate and encrypted private key files. Then use the "openssl rsa" command to convert the encrypted private key files from PKCS#8 format to "old-openssl/PKCS#1" format. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From kgoldman at us.ibm.com Thu Sep 3 16:28:48 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 3 Sep 2015 12:28:48 -0400 Subject: [openssl-users] PEM X509 certificate with no newline Message-ID: My application receives an X509 certificate string in PEM format (separators and base64 encoded certificate) with no newlines. PEM_read_bio_X509() fails because of the missing newlines. I can write some preprocessing code to add newlines every 72 characters when writing the BIO. I also thought about using a base64 filter in the BIO and stripping the separators first. Is there a strightforward approach, where I can send the entire PEM string and get back the X509 structure without preprocessing? From openssl-users at dukhovni.org Thu Sep 3 16:30:35 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 16:30:35 +0000 Subject: [openssl-users] Cleanup and changing the malloc routines In-Reply-To: <0fb646c798be4c218866f34577da5e68@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <55E85F2B.3080408@wisemo.com> <0fb646c798be4c218866f34577da5e68@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20150903163035.GI9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 04:20:47PM +0000, Salz, Rich wrote: > Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup. My DANESSL library (used by Exim) uses OPENSSL_strdup. Any reason to not leave a compatibility #define behind? There are likely other projects using that function. [ Yes we're aiming to have native DANE support in OpenSSL 1.1.0, and Exim can eventually switch to that, but it'll take time, and initially there'll be Exim versions using external DANE validation on top of OpenSSL 1.1.0. ] -- Viktor. From openssl-users at dukhovni.org Thu Sep 3 16:32:08 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 16:32:08 +0000 Subject: [openssl-users] PEM X509 certificate with no newline In-Reply-To: References: Message-ID: <20150903163208.GJ9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 12:28:48PM -0400, Ken Goldman wrote: > My application receives an X509 certificate string in PEM format (separators > and base64 encoded certificate) with no newlines. > > PEM_read_bio_X509() fails because of the missing newlines. > > I can write some preprocessing code to add newlines every 72 characters when > writing the BIO. Make that 64. > Is there a strightforward approach, where I can send the entire PEM string > and get back the X509 structure without preprocessing? Inserting the newlines is simple enough. -- Viktor. From rsalz at akamai.com Thu Sep 3 16:35:00 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 16:35:00 +0000 Subject: [openssl-users] PEM X509 certificate with no newline In-Reply-To: References: Message-ID: <5d80c4312f6040dcab6a22646a21781a@ustx2ex-dag1mb3.msg.corp.akamai.com> > PEM_read_bio_X509() fails because of the missing newlines. The underlying base64 decoder is horrible. It accepts invalid 8bit chars, and silently enforces a line-length limit. Wanna rewrite it? :) From rsalz at akamai.com Thu Sep 3 16:36:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 3 Sep 2015 16:36:01 +0000 Subject: [openssl-users] Cleanup and changing the malloc routines In-Reply-To: <20150903163035.GI9021@mournblade.imrryr.org> References: <55E85F2B.3080408@wisemo.com> <0fb646c798be4c218866f34577da5e68@ustx2ex-dag1mb3.msg.corp.akamai.com> <20150903163035.GI9021@mournblade.imrryr.org> Message-ID: <4d968f64a3f34d4b8b75a96652f26ecc@ustx2ex-dag1mb3.msg.corp.akamai.com> > > Remove {OPENSSL,CRYPTO}_strdup; use BUF_strdup. Reconsidering, I did this backward. The right thing is to use OPENSSL_strdup, not BUF_strdup. From openssl-users at dukhovni.org Thu Sep 3 17:31:55 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 17:31:55 +0000 Subject: [openssl-users] PEM X509 certificate with no newline In-Reply-To: <5d80c4312f6040dcab6a22646a21781a@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <5d80c4312f6040dcab6a22646a21781a@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <20150903173155.GK9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 04:35:00PM +0000, Salz, Rich wrote: > > PEM_read_bio_X509() fails because of the missing newlines. > > The underlying base64 decoder is horrible. It accepts invalid 8bit chars, and silently enforces a line-length limit. > > Wanna rewrite it? :) A large part of the complexity is that the base64 BIO is doing buffering wrong. Instead of buffering character data it buffers lines, and thus has to set a line length limit. Perhaps this BIO is intended to be used on multi-component PEM files, and to automatically stop when it reaches "-----END ...". I've not looked too closely and the use-cases. In any case, it is the messiest and least efficient (in terms of lines of code not run-time) code I've seen in OpenSSL. This code is very old, and has barely been touched for decades (except for a subtle bug fixed a few years back by EAY himself IIRC). The mess is just not very appealing to go near. The first step would be to figure out what the base64 BIO is currently doing and what we want it it to do going forward. Writing new code is likely easier than figuring out what it is doing now. -- Viktor. From kevinlong206 at gmail.com Thu Sep 3 18:06:57 2015 From: kevinlong206 at gmail.com (Kevin Long) Date: Thu, 3 Sep 2015 11:06:57 -0700 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> Message-ID: <789868A7-29FC-4E4C-9ABA-CC4B166BA6B9@gmail.com> Hi Mike (and all). Thanks for the info. I understand the implications of storing the randomized data to storage and precautions would be taken to air-gap this info from the outside world. > If not, you can use the TRNG for all newly issued certificates moving forward. Can you pease syntax? I have googled but I?m unclear if this would be with -rand flag, or setting the RANDFILE variable, or something else. Provided the randomized numbers are in a binary file, can you advise how to use this file for the generation of future keys/certs from the existing CA. Thank you > On Sep 3, 2015, at 2:23 AM, Mike Mohr wrote: > > Once you've written the random data to secondary storage you've permanently compromised the integrity of any cryptographic secrets generated from it. Depending on your threat model, underlying storage media, filesystem, and other factors the data files may be recoverable indefinitely (especially if you're using solid-state disks, due to their internal wear-leveling algorithms). Don't do that. > > The cryptographic secrets contained in your existing CA infrastructure were presumably generated using some sort of PRNG, so you'd have to regenerate them if you think the PRNG was somehow compromised. If not, you can use the TRNG for all newly issued certificates moving forward. However, I'd suggest not using one of the proprietary devices which are encased in epoxy ... you have no way to verify that they're doing what they say they are. The data quality coming out of those is fairly suspect in my mind (despite any positive results from e.g. dieharder, etc). > > On Wed, Sep 2, 2015 at 9:53 PM, Kevin Long > wrote: > > > Hello, > > I?m using openssl to administer a root/intermediate CA and I use the certificates for a number of web servers and other applications. All of my users install my root CA certificate for trust. > > I?ve been asked to use a hardware random number generator to create the keys/certificates going forward. I have a hardware RNG, and have created several files of random numbers using it, and I would like to know: > > 1) Can I specify my random numbers file to create keys/certificates from my CA (openssl command line, mac or linux) > > 2) Will this actually do any good, security wise, given how openssl certs/keys ?work?. My users and superiors are concerned with backdoors in PRNGs and RNG predictabilities. > > 3) If I can indeed use my own random numbers, does this mean I have to start my CA from scratch to take advantage of any benefit using ?true? random numbers from my hardware RNG? or would simply using my RN?s for the generation of keys for new certificates going forward allow for the benefit the true randomness gives. > > Thank you. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Sep 3 18:23:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 18:23:36 +0000 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> Message-ID: <20150903182336.GO9021@mournblade.imrryr.org> On Wed, Sep 02, 2015 at 09:53:05PM -0700, Kevin Long wrote: > I've been asked to use a hardware random number generator to create the > keys/certificates going forward. I have a hardware RNG, and have created > several files of random numbers using it, and I would like to know: Cat those files into /dev/urandom or /dev/random. That'll mix them into the system's entropy pool. Then generate keys as usual from /dev/urandom. -- Viktor. From kevinlong206 at gmail.com Thu Sep 3 18:29:01 2015 From: kevinlong206 at gmail.com (Kevin Long) Date: Thu, 3 Sep 2015 11:29:01 -0700 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <20150903182336.GO9021@mournblade.imrryr.org> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> <20150903182336.GO9021@mournblade.imrryr.org> Message-ID: <1213B5AD-191A-4A17-8572-9910828E68EA@gmail.com> Can I not use the file directly, as to not rely whatsoever on the OS?s PRNG ? > On Sep 3, 2015, at 11:23 AM, Viktor Dukhovni wrote: > > On Wed, Sep 02, 2015 at 09:53:05PM -0700, Kevin Long wrote: > >> I've been asked to use a hardware random number generator to create the >> keys/certificates going forward. I have a hardware RNG, and have created >> several files of random numbers using it, and I would like to know: > > Cat those files into /dev/urandom or /dev/random. That'll mix them > into the system's entropy pool. Then generate keys as usual from > /dev/urandom. > > -- > Viktor. > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Thu Sep 3 18:31:52 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 3 Sep 2015 18:31:52 +0000 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <1213B5AD-191A-4A17-8572-9910828E68EA@gmail.com> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> <20150903182336.GO9021@mournblade.imrryr.org> <1213B5AD-191A-4A17-8572-9910828E68EA@gmail.com> Message-ID: <20150903183152.GP9021@mournblade.imrryr.org> On Thu, Sep 03, 2015 at 11:29:01AM -0700, Kevin Long wrote: > Can I not use the file directly, as to not rely whatsoever on the OS?s PRNG ? That would be unwise. Much too easy to make a mistake and get that wrong. The best thing to do with additional entropy sources is to mix them with existing ones, rather than rely on them exlcusively, and especially if doing so means clever work-arounds that might go wrong. -- Viktor. From minfrin at sharp.fm Thu Sep 3 18:42:32 2015 From: minfrin at sharp.fm (Graham Leggett) Date: Thu, 3 Sep 2015 19:42:32 +0100 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <20150903182336.GO9021@mournblade.imrryr.org> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> <20150903182336.GO9021@mournblade.imrryr.org> Message-ID: <5C96BD87-4479-4E9D-A91B-7E9C009AD139@sharp.fm> On 3 Sep 2015, at 19:23, Viktor Dukhovni wrote: > Cat those files into /dev/urandom or /dev/random. That'll mix them > into the system's entropy pool. Then generate keys as usual from > /dev/urandom. I have used a deck of playing cards as a source of entropy, saved to a ram disk on a system with no swap, used then discarded. This has the advantage that you know where the randomness comes from. Regards, Graham -- From Michael.Wojcik at microfocus.com Thu Sep 3 21:14:16 2015 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 3 Sep 2015 21:14:16 +0000 Subject: [openssl-users] using a random number file for generation of keys/certificates In-Reply-To: <5C96BD87-4479-4E9D-A91B-7E9C009AD139@sharp.fm> References: <6A4AFD5C-C3B6-4912-ABCE-9272FC472DAC@gmail.com> <20150903182336.GO9021@mournblade.imrryr.org> <5C96BD87-4479-4E9D-A91B-7E9C009AD139@sharp.fm> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Graham Leggett > Sent: Thursday, September 03, 2015 14:43 > > I have used a deck of playing cards as a source of entropy, saved to a ram disk > on a system with no swap, used then discarded. This has the advantage that > you know where the randomness comes from. Yes, though even under ideal circumstances a standard deck of playing cards only has ~225 bits of entropy [log_2(52!)]. That's plenty for poker, but may not last long when used for cryptography by a busy system. It depends what you're using it for, of course, and how well it's mixed into the pool; and it's a decent-sized contribution. But considering the cost of reseeding (manually shuffling the cards and entering the data - which is time-expensive and opportunity-expensive, because it involves an expensive human component), it's not very efficient. You could build a card-shuffling-and-data-entering robot with some good physical randomness (tumbling the cards in a turbulent-air chamber, maybe), but there are physical-randomness alternatives with less complexity and better form factors. -- Michael Wojcik Technology Specialist, Micro Focus From gait.boxman at tie.nl Fri Sep 4 07:24:21 2015 From: gait.boxman at tie.nl (Gait Boxman) Date: Fri, 4 Sep 2015 09:24:21 +0200 Subject: [openssl-users] SSL_get_verify_result returning 5 on SSL setup? Message-ID: <55E94725.3070403@tie.nl> Hi all, I'm occasionally getting code 5 from SSL_get_verify_result when attempting to setup an SSL/TLS connection to an MS Exchange server using v1.02a. I checked the source code, which shows it's X509_V_ERR_UNABLE_TO_DECRYPT_CRL_SIGNATURE, but I can't find where that is coming from. The error is listed and documented, but not used in the library anywhere AFAICT. Can anyone tell me where this value might be set in the process, and where it is in the code? Could this be an error send back by the server? Thnx, Gait Boxman. From openssl-users at dukhovni.org Fri Sep 4 14:05:31 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 4 Sep 2015 14:05:31 +0000 Subject: [openssl-users] SSL_get_verify_result returning 5 on SSL setup? In-Reply-To: <55E94725.3070403@tie.nl> References: <55E94725.3070403@tie.nl> Message-ID: <20150904140530.GH9021@mournblade.imrryr.org> On Fri, Sep 04, 2015 at 09:24:21AM +0200, Gait Boxman wrote: > I'm occasionally getting code 5 from SSL_get_verify_result when attempting > to setup an SSL/TLS connection to an MS Exchange server using v1.02a. Show the relevant code that returns "5". Most frequently "5" is SSL_ERROR_SYSCALL, returned by SSL_get_error(). As you note, this value is never set as the verification result by OpenSSL itself, so unless you have verify callbacks that change the X509_STORE_CTX error value, perhaps you're reporting the return value of the wrong function. -- Viktor. From prabhat.puroshottam at outlook.com Fri Sep 4 14:43:00 2015 From: prabhat.puroshottam at outlook.com (Prabhat Puroshottam) Date: Fri, 4 Sep 2015 20:13:00 +0530 Subject: [openssl-users] SSL based Tunnel implementation Message-ID: Hi, We have software product which allows for Clients (C) to communicate with Agents (A) via a Proxy server (P). Client, Proxy and Agent all are part of our product suite. The data transferred can even be in Gigabytes (which actually are large files being transferred). Multiple client can communicate with multiple agents via the same Proxy. All data transfer happens via SSL. Right now, all data from coming from C is first decrypted at P and then encrypted again before being written to P, since separate connections exist between C & P and P & A, with separate SSL connections as well. This decryption/encryption at P is making overall communication slow, and is putting too much CPU load on P. To improve this situation, we plan to make P a sort of tunnel for data coming from C to A and that coming from A to C. Here is the proposed process (similar to a socks proxy): 1. TCP Connection and Handshake: C <==> P. Call this connection C1. 2. SSL Handshake: C <==> P. 3. Application level Handshake and authentication: C <==> P. 4. TCP Connection and Handshake: P <==> A. Call this connection C2. On completion of this step C has successfully authenticated itself to P, and all data coming from C is henceforth copied to A and vice-versa. 5. SSL Handshake: C <==> A. This handshake is between C and A. P just forwards all data coming from C1 to C2. So C and A who will negotiate the communication parameters between themselves including SSL cipher suite, etc. 6. Application Level Data Transfer: P just copies all data coming from C1 to C2 and vice-versa. a. C => P => A (No encryption/decryption/interpretation ? just plain copying of all data). b. A => P => C (No encryption/decryption/interpretation ? just plain copying of all data). 7. At some point, application Level Data Transfer Ends, and connections close. I have two questions: 1. Do you foresee any problem/difficulties implementing this approach? 2. Is their a concern of man in the middle attack between step 4 and 5? If yes, how can we overcome that - any pointers? -Prabhat PS: We are using openssl library, and this is security related question, that is why I have asked this here. Please forgive me if you feel this post doesn't belong here. From marquess at openssl.com Mon Sep 7 12:28:12 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 7 Sep 2015 08:28:12 -0400 Subject: [openssl-users] FIPS module 2.0.10 revision approved Message-ID: <55ED82DC.8080202@openssl.com> If you don't know or care what FIPS 140-2 is, then rejoice in your good fortune and run don't walk back to your brighter and happier world. The CMVP has approved the pending change letter update for the 2.0.10 revision to the #1747 validation, and at the same time they fixed the typos in their "Big Blob o' Text". I've summarized the results here (since the Big Blob is still essentially unreadable): http://openssl.com/fips/bigblob.html Note some of the "hostage" platforms are restored (partially) and the red scold text is gone. The same 2.0.10 change letter was submitted against the #2398 validation at the same time and that has not been approved yet. When it is those ten new platforms will appear on that validation as well. Those platforms were submitted against both validations since we were not sure what to expect. A 2.0.11 change letter update is also pending for the #2398 validation. We now know we can't add any more new platforms to the #1747 validation, because one of the CMVP responses to that change letter submission was a demand that we retroactively alter yet more previously approved platform descriptions (i.e., new "hostages"). We were able to deflect that by noting that the issue cited (optimized platforms with no non-optimized counterparts) is present in multiple very recently approved validations. But, the lesson is clear: any attempt to add new platforms means open season on older ones. So, we don't dare try to add any more platforms to #1747. We may eventually encounter the same issue with the clone validations too (e.g. #2398 and its still pending "RE" twin). The #1747 validation will remain at revision 2.0.10 forever. For now we're apparently still able to add platforms to the #2398 validation. We'll have to wait to see if any more surprises are in store. For now we are continuing to write change letter platform validation contracts, but with yet more caveats as the risk factors seem to keep rising. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Mon Sep 7 12:46:40 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 7 Sep 2015 08:46:40 -0400 Subject: [openssl-users] the fickleness of FIPS Message-ID: <55ED8730.4090004@openssl.com> This is just a random little factoid for observers of the bizarre little world of FIPS 140-2 validations. It's well known to that community that validation outcomes are highly unpredictable. We've tried the "do very similar submissions at the same time and marvel at the wild discrepancies in outcome" experiment many times[*], but this one is particularly illuminating. On April 17 we submitted two validations that as identical as any two such submissions could possibly be (exact same cryptographic module and only one trivial cosmetic difference between the two Security Policy documents[**]). Approval of the "SE" submission took 69 calendar days (48 workdays); after 143 calendar days (99 work days) its identical twin is still unapproved. That's quite a variance (over 100%), and we don't even know how that story ends yet. It could take days, weeks, months longer and we won't have a clue until it suddenly appears on the NIST CMVP web site. -Steve M. [*] See for instance http://veridicalsystems.com/blog/the-fickleness-of-fips/ [**] That difference consists of six occurrences of "RE" in one versus "SE" for the other; do a "s/SE/RE/g" substitution to http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140sp/140sp2398.pdf and you have the other validation. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From guninski at guninski.com Wed Sep 9 10:28:42 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 13:28:42 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? Message-ID: <20150909102842.GC2808@sivokote.iziade.m$> In short openssl 1.0.1p accepts composite $q$ in DSA verify/SSL. If $q$ is backdoored in the DSA/DH group parameters, this breaks all private keys using it (see links at bottom). On linux: $./apps/openssl s_server -accept 8080 -cert /tmp/cacert2.pem -key /tmp/key-comp2.key $./apps/openssl s_client -connect localhost:8080 Verify return code: 18 (self signed certificate) $./apps/openssl x509 -text -in /tmp/cacert2.pem (make Q hex). In sage: sage: q=0x008000000000000000001d8000000000000000012b sage: factor(q) 604462909807314587353111 * 1208925819614629174706189 The self signed cert and key are attached. The discussion started on cypherpunks: https://cpunks.org/pipermail/cypherpunks/2015-September/009007.html On my blog I summarized with title: RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken (and possibly backdoored) https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html -------------- next part -------------- -----BEGIN CERTIFICATE----- MIIDWTCCAxmgAwIBAgIJANFIfLCCwmohMAkGByqGSM44BAMwRTELMAkGA1UEBhMC QVUxEzARBgNVBAgMClNvbWUtU3RhdGUxITAfBgNVBAoMGEludGVybmV0IFdpZGdp dHMgUHR5IEx0ZDAeFw0xNTA5MDUwNDU5MDhaFw0xNTEwMDUwNDU5MDhaMEUxCzAJ BgNVBAYTAkFVMRMwEQYDVQQIDApTb21lLVN0YXRlMSEwHwYDVQQKDBhJbnRlcm5l dCBXaWRnaXRzIFB0eSBMdGQwggH6MIIBWAYHKoZIzjgEATCCAUsCgZcPiGcAAAAA AAADlG+9AAAAAAAAJEigmgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJwOatQAAAAAACP3Up7cAAAAAAFsia2LP AhUAgAAAAAAAAAAAHYAAAAAAAAAAASsCgZcJ0Mj2s9j1N/CsS+vIqYa5k3wugZhu yrgI1i+ZMmtqo7LrO49iH3YjnqRakj8ULK5mCzpSBR9KLBAlpO/1bmUHQc+231A1 71MfJ8M7rMQvn0mSKwIKSt9vdwRXv8cOIUiO3tP9ik1waHPM+EtoPAWhQwohG4wA vPvONp9j3mXkvICvx2qQwBa5PeEupzYR66yUJATABKClA4GbAAKBlwrWl9e0mw+D DEMMIjLRtfD4nJilQHF7cYHqhr6vJcFwYwkPuLyRZxokMHvOQmFH5XOdF9RG9Txt nfYw0gbmmnEQPWOqId2AGd5VJRHeeVvd5SPWKwQzETp0NkpaQjreMgwEb28elDUP xIvlT+/NOwjVVl/JiqrFDOIKEidQQxIVq227m60bvxbCymmUGOKMpNvy59dpUiyj UDBOMB0GA1UdDgQWBBR86RWS1KB00TAlUbBQ5fvT+m/dZDAfBgNVHSMEGDAWgBR8 6RWS1KB00TAlUbBQ5fvT+m/dZDAMBgNVHRMEBTADAQH/MAkGByqGSM44BAMDLwAw LAIUIgfVcrrQmbZ66mEuuovK1VMcw4gCFCIx+eoRWZKvFiuA6eBg++lN0uV9 -----END CERTIFICATE----- -------------- next part -------------- A non-text attachment was scrubbed... Name: key-comp2.key Type: application/pgp-keys Size: 938 bytes Desc: not available URL: From noloader at gmail.com Wed Sep 9 11:03:59 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 9 Sep 2015 07:03:59 -0400 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909102842.GC2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> Message-ID: On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski wrote: > In short openssl 1.0.1p accepts composite $q$ > in DSA verify/SSL. > > If $q$ is backdoored in the DSA/DH group parameters, > this breaks all private keys using it (see links at > bottom)... > Just bikeshedding, but before I went any further with it, I would verify DSA_check_key(...) does *not* reject the key. I can't find the name of the routine at the moment, though (I know its called RSA_check_key for RSA). Jeff From guninski at guninski.com Wed Sep 9 11:15:52 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 14:15:52 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: References: <20150909102842.GC2808@sivokote.iziade.m$> Message-ID: <20150909111552.GD2808@sivokote.iziade.m$> On Wed, Sep 09, 2015 at 07:03:59AM -0400, Jeffrey Walton wrote: > On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski wrote: > > In short openssl 1.0.1p accepts composite $q$ > > in DSA verify/SSL. > > > > If $q$ is backdoored in the DSA/DH group parameters, > > this breaks all private keys using it (see links at > > bottom)... > > > Just bikeshedding, but before I went any further with it, I would > verify DSA_check_key(...) does *not* reject the key. > Doesn't the sessions with s_client/s_server and dsa verify (in the links) show this works in practice, no matter of your question? From noloader at gmail.com Wed Sep 9 11:33:42 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 9 Sep 2015 07:33:42 -0400 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909111552.GD2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909111552.GD2808@sivokote.iziade.m$> Message-ID: On Wed, Sep 9, 2015 at 7:15 AM, Georgi Guninski wrote: > On Wed, Sep 09, 2015 at 07:03:59AM -0400, Jeffrey Walton wrote: >> On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski wrote: >> > In short openssl 1.0.1p accepts composite $q$ >> > in DSA verify/SSL. >> > >> > If $q$ is backdoored in the DSA/DH group parameters, >> > this breaks all private keys using it (see links at >> > bottom)... >> > >> Just bikeshedding, but before I went any further with it, I would >> verify DSA_check_key(...) does *not* reject the key. >> > > Doesn't the sessions with s_client/s_server and > dsa verify (in the links) show this works in practice, > no matter of your question? I don't believe so. Its been my experience that very few secure/high-integrity applications actually validate parameters out of the box :( In some cases, crypto parameters cannot be validated; for example, those damn Lim-Lee primes. To validate a Lim-Lee prime, you need the unique factorization of 'q' as a witness, which no one provides. (As opposed to a Sophie-Germain or safe primes). I also think the validation problems that plague high integrity software makes ed25519 and friends so appealing. I think all of the keys are valid, so you don't need to validate them. Jeff From noloader at gmail.com Wed Sep 9 11:45:16 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Wed, 9 Sep 2015 07:45:16 -0400 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909102842.GC2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> Message-ID: Hi Georgi, Sorry to go offlist... Also keep in mind that the IETF has effectively deprecated the DH parameters in PKIX certificates. In fact, they moved to fixed DH groups to avoid the option dance between client and server; and that has the benefit that the parameters can be validated offline. As for DSA, the IETF is killing it off, too. See, for example, https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 and https://www.ietf.org/mail-archive/web/tls/current/msg17489.html (archive of latter at https://www.ietf.org/mail-archive/web/tls/current/maillist.html). Jeff On Wed, Sep 9, 2015 at 6:28 AM, Georgi Guninski wrote: > In short openssl 1.0.1p accepts composite $q$ > in DSA verify/SSL. > > If $q$ is backdoored in the DSA/DH group parameters, > this breaks all private keys using it (see links at > bottom). > > On linux: > $./apps/openssl s_server -accept 8080 -cert /tmp/cacert2.pem -key > /tmp/key-comp2.key > > $./apps/openssl s_client -connect localhost:8080 > > Verify return code: 18 (self signed certificate) > > > $./apps/openssl x509 -text -in /tmp/cacert2.pem > (make Q hex). > > In sage: > sage: q=0x008000000000000000001d8000000000000000012b > sage: factor(q) > 604462909807314587353111 * 1208925819614629174706189 > > The self signed cert and key are attached. > > The discussion started on cypherpunks: > https://cpunks.org/pipermail/cypherpunks/2015-September/009007.html > > On my blog I summarized with title: > > RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken > (and possibly backdoored) > > https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html > From guninski at guninski.com Wed Sep 9 11:46:05 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 14:46:05 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909111552.GD2808@sivokote.iziade.m$> Message-ID: <20150909114605.GE2808@sivokote.iziade.m$> Ok, never mind. Is this ``issue'' real or imaginary according to developers, developers, developers(!) ? From guninski at guninski.com Wed Sep 9 11:55:10 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 14:55:10 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: References: <20150909102842.GC2808@sivokote.iziade.m$> Message-ID: <20150909115510.GF2808@sivokote.iziade.m$> On Wed, Sep 09, 2015 at 07:45:16AM -0400, Jeffrey Walton wrote: > Hi Georgi, > > Sorry to go offlist... > > Also keep in mind that the IETF has effectively deprecated the DH > parameters in PKIX certificates. In fact, they moved to fixed DH > groups to avoid the option dance between client and server; and that > has the benefit that the parameters can be validated offline. As for > DSA, the IETF is killing it off, too. > > See, for example, > https://tools.ietf.org/html/draft-gillmor-tls-negotiated-dl-dhe-00 and > https://www.ietf.org/mail-archive/web/tls/current/msg17489.html > (archive of latter at > https://www.ietf.org/mail-archive/web/tls/current/maillist.html). > > Jeff > 10x, might try to see these later. the issue appears still alive in openssl or am i missing something? From openssl-users at dukhovni.org Wed Sep 9 11:55:36 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Sep 2015 11:55:36 +0000 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> Message-ID: <20150909115536.GA21942@mournblade.imrryr.org> On Wed, Sep 09, 2015 at 02:46:05PM +0300, Georgi Guninski wrote: > Is this ``issue'' real or imaginary according to developers, developers, > developers(!) ? On Wed, Sep 09, 2015 at 01:28:42PM +0300, Georgi Guninski wrote: > In short openssl 1.0.1p accepts composite $q$ > in DSA verify/SSL. > > On my blog I summarized with title: > > RFC-2631, fips 186-3 and openssl's implementation of DSA appear broken > (and possibly backdoored) > > https://j.ludost.net/blog/archives/2015/09/05/rfc-2631_fips_186-3_and_openssls_implementation_of_dsa_appear_broken_and_possibly_backdoored/index.html The backdoor assertion looks wrong, the check on the bit-length of q is correct as required by the standards, and the subgroups in question are not "small", rather they are commensurate with the expected security level. As for running primality tests, presumably certificates signed by a trusted CA use a prime q. If the certificate is *not* signed by a trusted CA, of course the connection is not secure... You forgot to include the full context from the standard: ... Whether agents provide validation information in their certificates is a local matter between the agents and their CA. The expected time for this sort of check is when CAs sign certificates, not when TLS handshake participants validate the certificates of their peers (issued by trusted issuers, or else why bother). -- Viktor. From guninski at guninski.com Wed Sep 9 12:02:36 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 15:02:36 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909115536.GA21942@mournblade.imrryr.org> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> <20150909115536.GA21942@mournblade.imrryr.org> Message-ID: <20150909120236.GG2808@sivokote.iziade.m$> On Wed, Sep 09, 2015 at 11:55:36AM +0000, Viktor Dukhovni wrote: > > The expected time for this sort of check is when CAs sign certificates, > not when TLS handshake participants validate the certificates of > their peers (issued by trusted issuers, or else why bother). > Are you saying I can't sign the cert with another cert (the pubkey is easy to extract from the cert) with openssl? From openssl-users at dukhovni.org Wed Sep 9 12:07:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Sep 2015 12:07:43 +0000 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909120236.GG2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> <20150909115536.GA21942@mournblade.imrryr.org> <20150909120236.GG2808@sivokote.iziade.m$> Message-ID: <20150909120743.GB21942@mournblade.imrryr.org> On Wed, Sep 09, 2015 at 03:02:36PM +0300, Georgi Guninski wrote: > On Wed, Sep 09, 2015 at 11:55:36AM +0000, Viktor Dukhovni wrote: > > > > The expected time for this sort of check is when CAs sign certificates, > > not when TLS handshake participants validate the certificates of > > their peers (issued by trusted issuers, or else why bother). > > Are you saying I can't sign the cert with another cert > (the pubkey is easy to extract from the cert) with openssl? If you control a trusted root CA, or an intermediate CA issued (possibly indirectly) by a trusted root CA, you can sign anything you want and it will be trusted. The fact that malfeasant CAs can compromise security is not new. If you don't control a trusted CA, what significance would such a signature carry? Yes, most certificates (sometimes constrained by KeyUsage) can be used for signing, but unless "CA=true", they can't be used to sign other certificates that will be trusted by peers. -- Viktor. From guninski at guninski.com Wed Sep 9 12:17:01 2015 From: guninski at guninski.com (Georgi Guninski) Date: Wed, 9 Sep 2015 15:17:01 +0300 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909120743.GB21942@mournblade.imrryr.org> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> <20150909115536.GA21942@mournblade.imrryr.org> <20150909120236.GG2808@sivokote.iziade.m$> <20150909120743.GB21942@mournblade.imrryr.org> Message-ID: <20150909121701.GH2808@sivokote.iziade.m$> On Wed, Sep 09, 2015 at 12:07:43PM +0000, Viktor Dukhovni wrote: > > > > Are you saying I can't sign the cert with another cert > > (the pubkey is easy to extract from the cert) with openssl? > > If you control a trusted root CA, or an intermediate CA issued > (possibly indirectly) by a trusted root CA, you can sign anything > you want and it will be trusted. The fact that malfeasant CAs can > compromise security is not new. > > If you don't control a trusted CA, what significance would such a > signature carry? Yes, most certificates (sometimes constrained by > KeyUsage) can be used for signing, but unless "CA=true", they can't > be used to sign other certificates that will be trusted by peers. > I am gonna leave this list very soon. Feel free to CC me with answer: If I am CA and sign cert requests with vanilla openssl, will I sign a composite $q$? From openssl-users at dukhovni.org Wed Sep 9 12:32:37 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 9 Sep 2015 12:32:37 +0000 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909121701.GH2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> <20150909115536.GA21942@mournblade.imrryr.org> <20150909120236.GG2808@sivokote.iziade.m$> <20150909120743.GB21942@mournblade.imrryr.org> <20150909121701.GH2808@sivokote.iziade.m$> Message-ID: <20150909123237.GD21942@mournblade.imrryr.org> On Wed, Sep 09, 2015 at 03:17:01PM +0300, Georgi Guninski wrote: > If I am CA and sign cert requests with vanilla openssl, > will I sign a composite $q$? The "openssl ca" command won't stop you from signing a non-prime DSA $q$. Real CAs need to do a lot more than is done in "openssl ca". No real public CAs issue DSA certificates. Perhaps some internal USG CAs issue DSA certificates. What specific attack did you have in mind? The MiTM obtains a weak certificate from a trusted CA? And then uses static DH_DSS with a smooth $q$ allowing the attacker to recover the peer's ephemeral DH private exponent? What then? The peer is now performing a handshake with the authenticated MiTM, where's the attack against a third party? To make this interesting (not saying it is impossible, but no evidence has been provided yet that anything interesting is afoot), you need a more complete attack description than "OpenSSL accepts non-prime $q$". -- Viktor. From erwann.abalea at opentrust.com Wed Sep 9 12:35:18 2015 From: erwann.abalea at opentrust.com (Erwann Abalea) Date: Wed, 9 Sep 2015 14:35:18 +0200 Subject: [openssl-users] Why openssl 1.0.1p accepts composite $q$ in DSA? In-Reply-To: <20150909121701.GH2808@sivokote.iziade.m$> References: <20150909102842.GC2808@sivokote.iziade.m$> <20150909114605.GE2808@sivokote.iziade.m$> <20150909115536.GA21942@mournblade.imrryr.org> <20150909120236.GG2808@sivokote.iziade.m$> <20150909120743.GB21942@mournblade.imrryr.org> <20150909121701.GH2808@sivokote.iziade.m$> Message-ID: <4D67887B-C2BF-4733-B307-3148AF653F24@opentrust.com> Bonjour, > Le 9 sept. 2015 ? 14:17, Georgi Guninski a ?crit : > > On Wed, Sep 09, 2015 at 12:07:43PM +0000, Viktor Dukhovni wrote: >>> >>> Are you saying I can't sign the cert with another cert >>> (the pubkey is easy to extract from the cert) with openssl? >> >> If you control a trusted root CA, or an intermediate CA issued >> (possibly indirectly) by a trusted root CA, you can sign anything >> you want and it will be trusted. The fact that malfeasant CAs can >> compromise security is not new. >> >> If you don't control a trusted CA, what significance would such a >> signature carry? Yes, most certificates (sometimes constrained by >> KeyUsage) can be used for signing, but unless "CA=true", they can't >> be used to sign other certificates that will be trusted by peers. >> > > I am gonna leave this list very soon. > > Feel free to CC me with answer: > > If I am CA and sign cert requests with vanilla openssl, > will I sign a composite $q$? If you?re a CA and sign cert requests, you?re responsible to check the public key you?re signing. You could also sign an RSA key with e=1 or a dumb modulus, and it?s not a backdoor in RSA or OpenSSL. From bhat.jayalakshmi at gmail.com Thu Sep 10 12:44:00 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 10 Sep 2015 06:44:00 -0600 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158). Message-ID: Hello all, I have a question on FIPS. We have OpenSSL FIPS module integrated with our product. We have an option to enable/disable FIPS at run time. We are executing the following openSSL API's every time when FIPS status changes. { We have mapped OpenSSL crypto locks to mutex intenally. Hence we delete it and create it every time when FIPS status changes. ERR_free_strings() ERR_remove_state(0); EVP_cleanup(); SSL_library_init() SSLeay_add_all_algorithms() } Without executing this we are hitting the error, error:0409A09E:lib(4):func(154):reason(158). I wanted to know if our approach is correct? Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From noloader at gmail.com Thu Sep 10 13:55:57 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Thu, 10 Sep 2015 09:55:57 -0400 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158). In-Reply-To: References: Message-ID: > ... > Without executing this we are hitting the error, > error:0409A09E:lib(4):func(154):reason(158). I wanted to know if our > approach is correct? > $ openssl errstr 0x0409A09E error:0409A09E:rsa routines:PKEY_RSA_VERIFY:operation not allowed in fips mode From thomas.francis.jr at pobox.com Thu Sep 10 14:44:37 2015 From: thomas.francis.jr at pobox.com (Tom Francis) Date: Thu, 10 Sep 2015 10:44:37 -0400 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158). In-Reply-To: References: Message-ID: <72453EB8-7ACC-4216-8210-B2715BB56407@pobox.com> > On Sep 10, 2015, at 8:44 AM, Jayalakshmi bhat wrote: > > Hello all, > > I have a question on FIPS. We have OpenSSL FIPS module integrated with our product. We have an option to enable/disable FIPS at run time. We are executing the following openSSL API's every time when FIPS status changes. Typically, this is not allowed; you must restart your application in order to switch in or out of FIPS approved mode. Your customer?s auditor (or your auditor) may believe differently, but my former employer had auditors make it very clear that an application must never switch into or out of FIPS approved mode without restarting the application (and most of the auditors wanted us to require the user to reboot their entire system to make the switch; fortunately they were willing to allow the application with just an extra note recommending the user reboot after modifying the setting). > { > We have mapped OpenSSL crypto locks to mutex intenally. Hence we delete it and create it every time when FIPS status changes. > ERR_free_strings() > ERR_remove_state(0); > EVP_cleanup(); > SSL_library_init() > SSLeay_add_all_algorithms() > } > > Without executing this we are hitting the error, error:0409A09E:lib(4):func(154):reason(158). I wanted to know if our approach is correct? IIRC you should be able to switch in and out of FIPS appoved mode by simply calling FIPS_mode_set() with the appropriate argument. I know this worked with the FIPS 1.2 module, but I never bothered to try it with the 2.0 module (see above about allowed uses). I wouldn?t recommend trying to uninitialize and re-initialize OpenSSL, though ? while probably safe, it seems like a bad idea. If this is a long-running program that can do multiple things at a time, it?s definitely a bad idea to allow a toggle like that ? someone might?ve started a task, then turned on FIPS approved mode ? if the task hasn?t done anything with OpenSSL yet, it?ll probably be done with FIPS approved mode, but was that the user?s intent? I?d recommend that when a user changes the setting, you store the setting and inform the user that the new setting will take affect only after restarting the application. I really doubt you?ll be allowed to switch FIPS approved mode on and off with just a simple toggle (even if it works technically). > Regards > Jayalakshmi > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dlipubkey at gmail.com Fri Sep 11 00:13:07 2015 From: dlipubkey at gmail.com (David Li) Date: Thu, 10 Sep 2015 17:13:07 -0700 Subject: [openssl-users] Strange problem in using verify command Message-ID: Hi, I am using "openssl verify -CAfile " to verify the certificate. It's been running as expected. Recently I started to run this command on a different x86 platform. What I found is the the first few times I always got: error 9 at 1 depth lookup:certificate is not yet valid Then I waited 10 min and reran the same cmd and got "OK". I am puzzled by this. Is this a some timing issue? My openssl version is: OpenSSL 1.0.1e-fips 11 Feb 2013 David From jb-openssl at wisemo.com Fri Sep 11 02:20:04 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 11 Sep 2015 04:20:04 +0200 Subject: [openssl-users] Strange problem in using verify command In-Reply-To: References: Message-ID: <55F23A54.2010303@wisemo.com> On 11/09/2015 02:13, David Li wrote: > Hi, > > I am using "openssl verify -CAfile " to verify the > certificate. It's been running as expected. > > Recently I started to run this command on a different x86 platform. > What I found is the the first few times I always got: > > error 9 at 1 depth lookup:certificate is not yet valid > > Then I waited 10 min and reran the same cmd and got "OK". > > I am puzzled by this. Is this a some timing issue? Chances are that the clock on the computer was wrong until NTP corrected it from the network. > > My openssl version is: > > OpenSSL 1.0.1e-fips 11 Feb 2013 That's kind of old. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From dlipubkey at gmail.com Fri Sep 11 04:25:03 2015 From: dlipubkey at gmail.com (David Li) Date: Thu, 10 Sep 2015 21:25:03 -0700 Subject: [openssl-users] Strange problem in using verify command In-Reply-To: <55F23A54.2010303@wisemo.com> References: <55F23A54.2010303@wisemo.com> Message-ID: Hi Jakob, The computer has been up running for quite a while. I wonder if it really needs NTP to take that long to sync up. David On Thu, Sep 10, 2015 at 7:20 PM, Jakob Bohm wrote: > On 11/09/2015 02:13, David Li wrote: >> >> Hi, >> >> I am using "openssl verify -CAfile " to verify the >> certificate. It's been running as expected. >> >> Recently I started to run this command on a different x86 platform. >> What I found is the the first few times I always got: >> >> error 9 at 1 depth lookup:certificate is not yet valid >> >> Then I waited 10 min and reran the same cmd and got "OK". >> >> I am puzzled by this. Is this a some timing issue? > > Chances are that the clock on the computer was wrong until > NTP corrected it from the network. >> >> >> My openssl version is: >> >> OpenSSL 1.0.1e-fips 11 Feb 2013 > > That's kind of old. > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From bhat.jayalakshmi at gmail.com Fri Sep 11 05:54:06 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Thu, 10 Sep 2015 23:54:06 -0600 Subject: [openssl-users] Help needed on FIPS error 0409A09E:lib(4):func(154):reason(158). In-Reply-To: <72453EB8-7ACC-4216-8210-B2715BB56407@pobox.com> References: <72453EB8-7ACC-4216-8210-B2715BB56407@pobox.com> Message-ID: Hi Tom, Thanks a lot for clarifying the doubt. Regards Jayalakshmi On Thu, Sep 10, 2015 at 8:44 AM, Tom Francis wrote: > > > On Sep 10, 2015, at 8:44 AM, Jayalakshmi bhat < > bhat.jayalakshmi at gmail.com> wrote: > > > > Hello all, > > > > I have a question on FIPS. We have OpenSSL FIPS module integrated with > our product. We have an option to enable/disable FIPS at run time. We are > executing the following openSSL API's every time when FIPS status changes. > > Typically, this is not allowed; you must restart your application in order > to switch in or out of FIPS approved mode. Your customer?s auditor (or > your auditor) may believe differently, but my former employer had auditors > make it very clear that an application must never switch into or out of > FIPS approved mode without restarting the application (and most of the > auditors wanted us to require the user to reboot their entire system to > make the switch; fortunately they were willing to allow the application > with just an extra note recommending the user reboot after modifying the > setting). > > > { > > We have mapped OpenSSL crypto locks to mutex intenally. Hence we > delete it and create it every time when FIPS status changes. > > ERR_free_strings() > > ERR_remove_state(0); > > EVP_cleanup(); > > SSL_library_init() > > SSLeay_add_all_algorithms() > > } > > > > Without executing this we are hitting the error, > error:0409A09E:lib(4):func(154):reason(158). I wanted to know if our > approach is correct? > > IIRC you should be able to switch in and out of FIPS appoved mode by > simply calling FIPS_mode_set() with the appropriate argument. I know this > worked with the FIPS 1.2 module, but I never bothered to try it with the > 2.0 module (see above about allowed uses). I wouldn?t recommend trying to > uninitialize and re-initialize OpenSSL, though ? while probably safe, it > seems like a bad idea. If this is a long-running program that can do > multiple things at a time, it?s definitely a bad idea to allow a toggle > like that ? someone might?ve started a task, then turned on FIPS approved > mode ? if the task hasn?t done anything with OpenSSL yet, it?ll probably be > done with FIPS approved mode, but was that the user?s intent? I?d > recommend that when a user changes the setting, you store the setting and > inform the user that the new setting will take affect only after restarting > the application. > > I really doubt you?ll be allowed to switch FIPS approved mode on and off > with just a simple toggle (even if it works technically). > > > > Regards > > Jayalakshmi > > _______________________________________________ > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.heide at student.uni-siegen.de Fri Sep 11 10:30:04 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Fri, 11 Sep 2015 12:30:04 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG Message-ID: <20150911123004.6688b32f@tbb-phenom> Hi, I'm using OpenSSL to verify a (proprietary?) timestamp in Microsoft Authenticode via PKCS7_verify() (in pk7_smime.c). Those Timestamps are inside a PKCS7 SignerInfo Structure (OpenSSL type PKCS7_SIGNER_INFO). I put those inside a PKCS7 to be able to use PKCS7_verify(). Most of them are verified fine. In most cases the encryptedDigest structure inside (pkcs7_signer_info_st->enc_digest) corresponds to an OpenSSL type X509_SIG after decryption, which is an ASN.1 encoded Identifier+Hash (sha1,sha256,...). OpenSSL can parse them and use the hash aka message digest inside. But sometimes there is only the plain hash (sha1 usually) inside the decrypted "encryptedDigest". OpenSSL doesn't detect this. int_rsa_verify() simply tries to decode it via d2i_X509_SIG() which fails. The solution is simple. If there's only a hash inside, then after decryption and removing the rsa-padding the resulting structure has exactly the size of the expected hash (-> use the hash for comparison). In all other cases the decrypted ASN.1 structure must be bigger than the hash (including headers). This test is simple and fast, at least if it fails in the normal case. I've patched OpenSSL and it works. See Attachment. I don't think this is a bug inside OpenSSL. In fact, rfc2315 states the encrypted digest has to be a DigestInfo structure: DigestInfo ::= SEQUENCE { digestAlgorithm DigestAlgorithmIdentifier, digest Digest } This corresponds to OpenSSLs X509_SIG. So I do not report it as a bug. Probably those Authenticode Timestamps are not standards compliant. Or the PKCS7 structure I'm creating around those SignerInfos is wrong/broken/incomplete. Or maybe my approach to use PKCS7_verify() for this is wrong? Thus I would like to share my experiences here. Nevertheless, if there are no regular cases where i equals m_len in int_rsa_verify(), then it shouldn't do any harm to include those changes in OpenSSL. (with added handling of rm!=NULL which is ignored so far, doesn't get used by RSA_verify(), simple to implement if needed) Regards Michael -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssl-1.0.2d-non-enveloped-hash-patch.txt URL: From jb-openssl at wisemo.com Fri Sep 11 13:07:20 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 11 Sep 2015 15:07:20 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150911123004.6688b32f@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> Message-ID: <55F2D208.6010806@wisemo.com> On 11/09/2015 12:30, Michael Heide wrote: > Hi, > I'm using OpenSSL to verify a (proprietary?) timestamp in Microsoft Authenticode via PKCS7_verify() (in pk7_smime.c). According to my (initial) research, Microsoft Authenticode uses two forms of timestamp unauthenticated attributes Here is an excerpt from my draft specification so far: ... 7. Authenticode signatures SHOULD include a counterSignature attribute from a timestamping authority. 8. If there is a valid counterSignature from a timestamping authority and this counterSignature passes validation at the time when the countersigned signature is checked, and the countersigned signature itself was not made with a certificate with the KpLifetimeSigning extended key usage (OID 1.3.6.1.4.1.311.10.3.13), THEN the validity of the countersigned signature (and in particular the applicable certificates) SHOULD be checked as of the time specified by the Authenticated signingTime attribute found in the timestamping countersignature (not any other signingTime attributes found elsewhere in the overall signature structure). 9. If there is no valid counterSignature from a timestamping authority or that countersignature does not pass validation or KpLifetimeSigning was speficied, the signature SHOULD be checked as of the time when it is being checked. The failure or omission of the counterSignature does not invalidate the signature itself (but may still cause it to be invalid due to certificate expiration or revocation). 10. Authenticode signatures SHOULD include a signingTime authenticated attribute (which will usually differ from that attribute in a counterSignature). Recipients should treat this as for information only. ... 2.3 AuthentiCode Timestamp countersignature format ================================================== AuthentiCode signatures typically include a counter signature from a timestamping authority confirming that the signature was made on or prior to a specific time. This is done using a counterSignature unauthenticated attribute of one of the following forms. 2.3.1 RFC2985 form Timestamp countersignature Attribute ======================================================= This is a counter signature exactly as described in RFC2985 section 5.3.6 (OID 1.2.840.113549.1.9.6) with the following additional constraints: - The countersigning certificate MUST specify the timestamping extended key usage (OID 1.3.6.1.5.5.7.3.8) - The countersigning SignerInfo MUST include a signingTime attribute (as defined in RFC2985 section 5.3.3, OID 1.2.840.113549.1.9.5) 2.3.2 RFC3161 form Timestamp countersignature Attribute ======================================================= rFC3161CounterSign = 1.3.6.1.4.1.311.3.3.1 RFC3161CounterSign ::= TimeStampToken -- See RFC3161 The TimeStampToken must specify a messageImprint computed over the content octets of the encryptedDigest field in the SignerInfo having the attribute. This is identical to the SignatureTimeStampToken attribute specified in RFC3161 Appendix A, except that the OID differs. This form is understood only by those Microsoft validation programs that support SHA-2 or later hash algorithms. Therefore AuthentiCode signatures using the SHA-1 hash algorithm SHOULD use the RFC2985 timestamp countersignature format. AuthentiCode signatures not inside an SpcAdditionalSignatures attribute and made using the SHA-1 or MD5 hash algorithm SHOULD AVOID using the RFC3161 timestamp counter signature format. > Those Timestamps are inside a PKCS7 SignerInfo Structure (OpenSSL type PKCS7_SIGNER_INFO). I put those inside a PKCS7 to be able to use PKCS7_verify(). > Most of them are verified fine. In most cases the encryptedDigest structure inside (pkcs7_signer_info_st->enc_digest) corresponds to an OpenSSL type X509_SIG after decryption, which is an ASN.1 encoded Identifier+Hash (sha1,sha256,...). OpenSSL can parse them and use the hash aka message digest inside. > But sometimes there is only the plain hash (sha1 usually) inside the decrypted "encryptedDigest". OpenSSL doesn't detect this. int_rsa_verify() simply tries to decode it via d2i_X509_SIG() which fails. I have not encountered this before, which signing authority, AlgorithmIdentifier and year (first digits of timestamp) did you see this with? Have you considered the possibility that this may be an ISO/IEC 9796-1 or -2 signature (an old format broken in 1999 for 9796-1 and for 9796-2/MD5 and in 2009 for 9796-2/SHA-1)? Or if neither of those ancient specs match that format, it might besome other equally weak system, especially because Authenticode-compatible timestamp authorities are the perfect victims of chosen-message attacks such as those against ISO 9796-1/-2. > The solution is simple. If there's only a hash inside, then after decryption and removing the rsa-padding the resulting structure has exactly the size of the expected hash (-> use the hash for comparison). In all other cases the decrypted ASN.1 structure must be bigger than the hash (including headers). This test is simple and fast, at least if it fails in the normal case. > I've patched OpenSSL and it works. See Attachment. > I don't think this is a bug inside OpenSSL. In fact, rfc2315 states the encrypted digest has to be a DigestInfo structure: > DigestInfo ::= SEQUENCE { > digestAlgorithm DigestAlgorithmIdentifier, > digest Digest } > This corresponds to OpenSSLs X509_SIG. > So I do not report it as a bug. Probably those Authenticode Timestamps are not standards compliant. Or the PKCS7 structure I'm creating around those SignerInfos is wrong/broken/incomplete. Or maybe my approach to use PKCS7_verify() for this is wrong? Thus I would like to share my experiences here. > Nevertheless, if there are no regular cases where i equals m_len in int_rsa_verify(), then it shouldn't do any harm to include those changes in OpenSSL. (with added handling of rm!=NULL which is ignored so far, doesn't get used by RSA_verify(), simple to implement if needed) > Regards > Due to the likely weakness of this scheme, acceptance should be restricted to a very small number of specific signer certificates, and further restricted to specific (claimed) date ranges. Though restricting the claimed date rangewill have very little value, since if that authority signed just a few timestamps requested by an attacker knowing the method published in 1999, that attacker now has the ability to sign anything using any old date as if he was that authority. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From michael.heide at student.uni-siegen.de Fri Sep 11 21:26:04 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Fri, 11 Sep 2015 23:26:04 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <55F2D208.6010806@wisemo.com> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> Message-ID: <20150911232604.51bf0dd1@tbb-phenom> Am Fri, 11 Sep 2015 15:07:20 +0200 schrieb Jakob Bohm : > 2.3.1 RFC2985 form Timestamp countersignature Attribute This one. > I have not encountered this before, which signing authority, > AlgorithmIdentifier and year (first digits of timestamp) did > you see this with? Various intermediate certs. Verisign, Symantec, etc. But now I see, did't got it before: the root is always "Thawte Timestamping CA" -- using md5WithRSAEncryption. Example: https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/ > > Have you considered the possibility that this may be an > ISO/IEC 9796-1 or -2 signature (an old format broken in > 1999 for 9796-1 and for 9796-2/MD5 and in 2009 for > 9796-2/SHA-1)? ISO/IEC 9796-1 / -2 seems to be completely different signing schemes. That's not the case here. It's only the encryptedDigest which differs, everything else is quite like the other timestamps you describe in "2.3.1". Btw: Windows verifies those with success, valid signatures. But you are right, maybe those are "fakes" (the intermediate ones) or broken in another way. > Due to the likely weakness of this scheme, [...] I'm a layman here, but I don't think the differences in the scheme itself provides the weakness, not in this case. There's only one difference: The signature algorithm is not confirmed by the encryptedDigest. But it is via other places and it is sha1 for the timestamp itself (20 bytes in length). Maybe the root certificate using md5 is... I don't know... Regards Michael From david at coppit.org Fri Sep 11 21:49:26 2015 From: david at coppit.org (David Coppit) Date: Fri, 11 Sep 2015 17:49:26 -0400 Subject: [openssl-users] Best way to combine ControlPersist and ProxyCommand? Message-ID: Hi all, What's the best way to set up a persistent master connection, along with a proxy jump host? Ideally the persistent master would speed up connections to machines behind the proxy, not just the connection to the proxy. Is this okay? Host jumpbox User jumpboxuser IdentityFile jumpbox_key ControlMaster auto ControlPath ~/.ssh/controlmaster-%r@%h:%p ControlPersist 5m Host internal1 internal2 internal3 internal4 User internaluser IdentityFile internal_key ProxyCommand ssh -W %h:%p -F ssh.config jumpbox ControlMaster auto ControlPath ~/.ssh/controlmaster-%r@%h:%p ControlPersist 5m I was worried that the internal[1234] controlmaster connections would be multiplexed through the jumpbox one, but I stopped the jumpbox master with "-O stop", verified that the socket file was gone, and the internal[1234] controlmaster connections seemed to keep working. Thanks, David -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Sep 11 22:32:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 11 Sep 2015 22:32:06 +0000 Subject: [openssl-users] Best way to combine ControlPersist and ProxyCommand? In-Reply-To: References: Message-ID: > What's the best way to set up a persistent master connection, along with a proxy jump host? Ideally the persistent master would speed up connections to machines behind the proxy, not just the connection to the proxy. I think you?ve got the wrong mailing list. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From noloader at gmail.com Sun Sep 13 06:12:48 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Sun, 13 Sep 2015 02:12:48 -0400 Subject: [openssl-users] Strange problem in using verify command In-Reply-To: References: <55F23A54.2010303@wisemo.com> Message-ID: > The computer has been up running for quite a while. I wonder if it > really needs NTP to take that long to sync up. > Firewall blocking port 123/TCP or 123/UDP? From jb-openssl at wisemo.com Mon Sep 14 14:29:48 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 14 Sep 2015 16:29:48 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150911232604.51bf0dd1@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> Message-ID: <55F6D9DC.70907@wisemo.com> On 11/09/2015 23:26, Michael Heide wrote: > Am Fri, 11 Sep 2015 15:07:20 +0200 schrieb Jakob Bohm : > >> 2.3.1 RFC2985 form Timestamp countersignature Attribute > This one. I thought so, many people think this one is proprietary, not realizing it was in the original PKCS#9 document. >> I have not encountered this before, which signing authority, >> AlgorithmIdentifier and year (first digits of timestamp) did >> you see this with? > Various intermediate certs. Verisign, Symantec, etc. > But now I see, did't got it before: the root is always "Thawte Timestamping CA" -- using md5WithRSAEncryption. In other words, the Verisign/Symantec conglomerate, which for many years used that timestamping facility across all its brands, including German brands "geotrust"and "tc trustcenter". However, I don't think they stopped using MD5 for all but the old top level CA a long time ago by now. > > Example: > https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/ I'll have to have a look at that. > >> Have you considered the possibility that this may be an >> ISO/IEC 9796-1 or -2 signature (an old format broken in >> 1999 for 9796-1 and for 9796-2/MD5 and in 2009 for >> 9796-2/SHA-1)? > ISO/IEC 9796-1 / -2 seems to be completely different signing schemes. That's not the case here. It's only the encryptedDigest which differs, everything else is quite like the other timestamps you describe in "2.3.1". ISO/IEC 9796-1/-1 specifies a different way of doing the encryptedDigest calculation, not a different surrounding OSI/ITU structure around it. > > Btw: Windows verifies those with success, valid signatures. But you are right, maybe those are "fakes" (the intermediate ones) or broken in another way. Not so fast. From what you describe, these use an old/wrong way of doing the EncryptedDigest calculation, and it is highly likely that Microsoft have had to make a (hopefully limited) exception for those historic timestamps. >> Due to the likely weakness of this scheme, [...] > I'm a layman here, but I don't think the differences in the scheme itself provides the weakness, not in this case. There's only one difference: The signature algorithm is not confirmed by the encryptedDigest. But it is via other places and it is sha1 for the timestamp itself (20 bytes in length). I'm no expert either, but from what I read, the weakness was precisely in the way the 128/160 bit hash was turned into a 1024+ bit number to be "encrypted" with the RSA private key. The PKCS#1 v2.x format (still not supported by Microsoft) was designed to provide the best possible way of doing this safely, while the older PKCS#1 v1.x format was less carefully designed, though it still seems to be holding up. The ISO/IEC 9796-1 and -2 formats were badly designed, and simply using a zero-padded hash value would be even worse. The dangers in all cases are about what happens if someone bad carefully constructs signing request (which wouldn't match any actual outer signature and would thus not be in a valid signature timestamp signature), they could use the answers to calculate the keys of the timestamping authority, a bit similar (though not exactly) to how someone calculated the private key used by Sony to sign approved PS3 software disks. This is why I am asking which specific authorities and periods made the mistake of calculating the input to the "encryption" wrong, and when they stopped doing so. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Mon Sep 14 14:39:15 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 14 Sep 2015 16:39:15 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150911232604.51bf0dd1@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> Message-ID: <55F6DC13.9010907@wisemo.com> On 11/09/2015 23:26, Michael Heide wrote: > Various intermediate certs. Verisign, Symantec, etc. > But now I see, did't got it before: the root is always "Thawte Timestamping CA" -- using md5WithRSAEncryption. > > Example: > https://www.virustotal.com/en/file/1d1bb76575e780123814259eb2dbbf26f1c9035d8f0d4bab682703823b06323f/analysis/ Where can I see the actual file (Not the virustotal description of the signature), I would need to look at the actual details to make sense of this. By the way, whomever signed this seems to be mixing competing CAs (GlobalSign for the cert, Symantec for the timestamp). And this file is very new (July 2015), are you sure it uses the nonstandard EncryptedDigest calculation? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.heide at student.uni-siegen.de Mon Sep 14 15:40:02 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Mon, 14 Sep 2015 17:40:02 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <55F6DC13.9010907@wisemo.com> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> Message-ID: <20150914174002.4fe26888@tbb-phenom> Am Mon, 14 Sep 2015 16:39:15 +0200 schrieb Jakob Bohm : > Where can I see the actual file (Not the virustotal > description of the signature), I would need to look > at the actual details to make sense of this. I think you have to use some kind of a subscription and use their APIs to access their database. I've searched the web and found: http://admdownload.adobe.com/bin/live/flashplayer18ax_ha_install.exe (md5: 0c6b5474223a4b5bf90a46844ed865db) Seems to be a file with the same criteria here. > By the way, whomever signed this seems to be mixing > competing CAs (GlobalSign for the cert, Symantec for > the timestamp). Why not? ;-) > And this file is very new (July 2015), are you sure > it uses the nonstandard EncryptedDigest calculation? No, I'm not. Maybe I'm doing something wrong. I don't know. Regards Michael From jb-openssl at wisemo.com Mon Sep 14 16:00:38 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 14 Sep 2015 18:00:38 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150914174002.4fe26888@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> Message-ID: <55F6EF26.9000701@wisemo.com> On 14/09/2015 17:40, Michael Heide wrote: >> By the way, whomever signed this seems to be mixing >> competing CAs (GlobalSign for the cert, Symantec for >> the timestamp). > Why not? ;-) Because using the timestamp server is generally a paid service included in the certificate purchase. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Mon Sep 14 18:32:11 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 14 Sep 2015 14:32:11 -0400 Subject: [openssl-users] Behaviour facing a broken OCSP responder Message-ID: Hello, The documentation does not seem too clear about what the behaviour exactly is when OpenSSL deals with a broken OCSP responder. ?For instance, one that would send an OK without any contents. ?We call openssl from an application and would like to know what is returned in such a case, or in the case of any broken responder. Thanks. From jb-openssl at wisemo.com Mon Sep 14 19:01:49 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 14 Sep 2015 21:01:49 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150914174002.4fe26888@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> Message-ID: <55F7199D.1090906@wisemo.com> On 14/09/2015 17:40, Michael Heide wrote: > Am Mon, 14 Sep 2015 16:39:15 +0200 schrieb Jakob Bohm : > >> Where can I see the actual file (Not the virustotal >> description of the signature), I would need to look >> at the actual details to make sense of this. > I think you have to use some kind of a subscription and use their APIs to access their database. > > I've searched the web and found: > http://admdownload.adobe.com/bin/live/flashplayer18ax_ha_install.exe > (md5: 0c6b5474223a4b5bf90a46844ed865db) > > Seems to be a file with the same criteria here. That one is a big surprise to me. It seems that as late as in August 17 2015 (4 weeks ago), Symantec/Verisign issued a timestamp signature, whose "EncryptedDigest"was made on the following non-standard input: 00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D The first parts (00|01|FF...|00) form the PKCS#1 padding for a PCS#1 v1.x signature. But the last part is a 20 byte string that doesn't seem to match anything permitted by PKCS#1 v1.5 (or v2.1). I also note that the SignerInfo specifies "version 1" (aka PKCS#7 v1.5), so I don't think this could be the elusive PKCS#7 v1.4 signature format. It might hypothetically be an SHA1 SUM, but the initial 00 byte looks strange. I am struggling a bit with trying to figure out what bytes are covered by the hash value, so far I have failed to manually extract a relevant subset of of the message, but I may have made some basic mistake since I usually don't do this by hand. Well, the good news is that at least the PKCS#1 padding is still there, which makes it a lot less vulnerable than what your e-mails made me think. > ... >> And this file is very new (July 2015), are you sure >> it uses the nonstandard EncryptedDigest calculation? > No, I'm not. Maybe I'm doing something wrong. I don't know. It seems not, now I really wonder what is going on. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Mon Sep 14 19:51:57 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 14 Sep 2015 12:51:57 -0700 Subject: [openssl-users] Question about Openssl FIPS module and Python-openssl Message-ID: Hi, I've built an openssl library with the FIPS objects modules, and I was testing the new lib files by replacing the original library files such as libcrypto.so with the new ones. >From the FIPS user guide I understand that any applications which need to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set to enable the FIPS mode. My question is, for the applications/ libraries like Python-openssl which depends on the openssl libraries, how do I make the Python-openssl module to run the FIPS_mode_set API, in order to initialize/enable FIPS mode? Also, does the FIPS_mode_set API only need to be run once by one of the applications/ libraries which use OpenSSL? Thanks for your helps! -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 14 20:06:53 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 14 Sep 2015 20:06:53 +0000 Subject: [openssl-users] Behaviour facing a broken OCSP responder In-Reply-To: References: Message-ID: > The documentation does not seem too clear about what the behaviour > exactly is when OpenSSL deals with a broken OCSP responder. ?For instance, > one that would send an OK without any contents. ?We call openssl from an > application and would like to know what is returned in such a case, or in the > case of any broken responder. Broken can mean so many things. You included an example. Are you talking about the command-line? It would be great if someone sent in a patch that standardized and documented exit codes, like 0 for got a "good" response, "1" for got a "bad" response, and 10 for got an unparseable response" From foleyj at cisco.com Mon Sep 14 20:00:00 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 14 Sep 2015 16:00:00 -0400 Subject: [openssl-users] Question about Openssl FIPS module and Python-openssl In-Reply-To: References: Message-ID: <55F72740.6080907@cisco.com> Your first question should be presented to the Python developers that provide support for OpenSSL. They would be the user of the OpenSSL API. I'm not a Python expert, but somewhere they would have a native layer that leverages the OpenSSL API. This native layer code would need to invoke FIPS_mode_set(). The question is whether our not they expose a knob to the Python user layer to enable/disable FIPS. Maybe someone on this mailer happens to know the answer. If not, reach out to the Python developer community. Regarding your second question, FIPS_mode_set() needs to be invoked once within each process space. Therefore, if your Python code was all running in a single process space, then you'd only need to invoke it once. But if you're spawning multiple processes, then you'll need to invoke it whenever a new process was created. On 09/14/2015 03:51 PM, security veteran wrote: > Hi, > > I've built an openssl library with the FIPS objects modules, and I was > testing the new lib files by replacing the original library files such > as libcrypto.so with the new ones. > > From the FIPS user guide I understand that any applications which need > to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set > to enable the FIPS mode. > > My question is, for the applications/ libraries like Python-openssl > which depends on the openssl libraries, how do I make the > Python-openssl module to run the FIPS_mode_set API, in order to > initialize/enable FIPS mode? > > Also, does the FIPS_mode_set API only need to be run once by one of > the applications/ libraries which use OpenSSL? > > Thanks for your helps! > > > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jonetsu at teksavvy.com Mon Sep 14 20:17:32 2015 From: jonetsu at teksavvy.com (jonetsu) Date: Mon, 14 Sep 2015 16:17:32 -0400 Subject: [openssl-users] Behaviour facing a broken OCSP responder In-Reply-To: References: Message-ID: <6d191f8cad2f694f8439d4cc29c6e9a9@teksavvy.com> > From: "Salz, Rich" > Date: 09/14/15 16:07 > Are you talking about the command-line? Yes. > It would be great if someone sent in a patch that standardized > and documented exit codes, like 0 for got a "good" > response, "1" for got a "bad" response, and 10 for got an > unparseable response Are these the only three error codes ? From rsalz at akamai.com Mon Sep 14 20:26:01 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 14 Sep 2015 20:26:01 +0000 Subject: [openssl-users] Behaviour facing a broken OCSP responder In-Reply-To: <6d191f8cad2f694f8439d4cc29c6e9a9@teksavvy.com> References: <6d191f8cad2f694f8439d4cc29c6e9a9@teksavvy.com> Message-ID: <5b7a278185ec441ba0e422934390ed89@ustx2ex-dag1mb3.msg.corp.akamai.com> > Are these the only three error codes ? Nope. It's not standardized at all sadly From security.veteran at gmail.com Mon Sep 14 21:08:17 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 14 Sep 2015 14:08:17 -0700 Subject: [openssl-users] Question about Openssl FIPS module and Python-openssl Message-ID: Thanks John. In that case it may be more complicated to invoke the *FIPS_mode_set *API from the Python layer. Is there anyway to make the FIPS mode always enabled by default in the library layer, so that there's no need to invoke the FIPS_mode_set API? Thanks. ---------------- Your first question should be presented to the Python developers that provide support for OpenSSL. They would be the user of the OpenSSL API. I'm not a Python expert, but somewhere they would have a native layer that leverages the OpenSSL API. This native layer code would need to invoke FIPS_mode_set(). The question is whether our not they expose a knob to the Python user layer to enable/disable FIPS. Maybe someone on this mailer happens to know the answer. If not, reach out to the Python developer community. Regarding your second question, FIPS_mode_set() needs to be invoked once within each process space. Therefore, if your Python code was all running in a single process space, then you'd only need to invoke it once. But if you're spawning multiple processes, then you'll need to invoke it whenever a new process was created. On 09/14/2015 03:51 PM, security veteran wrote: >* Hi, *>>* I've built an openssl library with the FIPS objects modules, and I was *>* testing the new lib files by replacing the original library files such *>* as libcrypto.so with the new ones. *>>* From the FIPS user guide I understand that any applications which need *>* to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set *>* to enable the FIPS mode. *>>* My question is, for the applications/ libraries like Python-openssl *>* which depends on the openssl libraries, how do I make the *>* Python-openssl module to run the FIPS_mode_set API, in order to *>* initialize/enable FIPS mode? *>>* Also, does the FIPS_mode_set API only need to be run once by one of *>* the applications/ libraries which use OpenSSL? *>>* Thanks for your helps! *>>>* _______________________________________________ *>* openssl-users mailing list *>* To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users * -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 14 21:11:59 2015 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 14 Sep 2015 21:11:59 +0000 Subject: [openssl-users] Question about Openssl FIPS module and Python-openssl In-Reply-To: References: Message-ID: >Is there anyway to make the FIPS mode always enabled by default in the library layer, so that there's no need to invoke the FIPS_mode_set API? No. You'd have to end up calling some explicit routine of your own which called FIPS_mode_set. From security.veteran at gmail.com Mon Sep 14 21:21:36 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 14 Sep 2015 14:21:36 -0700 Subject: [openssl-users] How to enable FIPS mode by default of the OpenSSL FIPS modules Message-ID: I asked this question from a different thread, but thought it may be the best to start a new thread to discuss this question since it sounds like a big deal to me. I've built an openssl library with the FIPS objects modules, and I was testing the new lib files by replacing the original library files such as libcrypto.so with the new ones. >From the FIPS user guide I understand that any applications which need to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set to enable the FIPS mode. This sounds like a big issue to me: there are may other libraries/ services which depends on OpenSSL. For example, Python, Apache, PostgreSQL, etc. If the *FIPS_mode_set *API needs to be invoked in order to enable the FIPS mode, how can we make third party library/ services like Python and Apache to invoke this API? Is there any other way to make the FIPS mode always enabled? Thanks. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Sep 14 23:59:34 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 14 Sep 2015 19:59:34 -0400 Subject: [openssl-users] How to enable FIPS mode by default of the OpenSSL FIPS modules In-Reply-To: References: Message-ID: <55F75F66.2050309@openssl.com> On 09/14/2015 05:21 PM, security veteran wrote: > I asked this question from a different thread, but thought it may be the > best to start a new thread to discuss this question since it sounds like > a big deal to me. > > I've built an openssl library with the FIPS objects modules, and I was > testing the new lib files by replacing the original library files such > as libcrypto.so with the new ones. > > From the FIPS user guide I understand that any applications which need > to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set > to enable the FIPS mode. > > This sounds like a big issue to me: there are may other libraries/ services which depends on OpenSSL. For example, Python, Apache, PostgreSQL, etc. > > If the /FIPS_mode_set /API needs to be invoked in order to enable the > FIPS mode, how can we make third party library/ services like Python and > Apache to invoke this API? > > Is there any other way to make the FIPS mode always enabled? Well ... yes and no. It depends. The OpenSSL FIPS module User Guide (https://openssl.org/docs/fips/UserGuide-2.0.pdf) discusses use of the OPENSSL_Config() call and the global openssl.conf configuration file. In theory you could toggle FIPS mode for all the applications on a system with in one swell foop. In practice it's not that easy, because when you enable FIPS mode you also automatically disable use of all "non-allowed" cryptography. Many applications not specifically written to accommodate the restrictions of FIPS module may not behave gracefully. Some (OpenSSH for instance) require extensive hacks for FIPS mode. Apache httpd does have native FIPS support, but you'll need to invoke the right buildtime and runtime options; the typical httpd binary install won't have FIPS support. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From michael.heide at student.uni-siegen.de Tue Sep 15 06:06:44 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Tue, 15 Sep 2015 08:06:44 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <55F7199D.1090906@wisemo.com> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> Message-ID: <20150915080644.53ffa92b@tbb-phenom> Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm : > > Seems to be a file with the same criteria here. > That one is a big surprise to me. Thanks. (if it's a surprise to you, then it's ok to be a surprise for me too. ;-) ) > It seems that as late as in August 17 2015 (4 weeks ago), > Symantec/Verisign issued a timestamp signature, whose > "EncryptedDigest"was made on the following non-standard > input: > > 00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D > > The first parts (00|01|FF...|00) form the PKCS#1 padding > for a PCS#1 v1.x signature. > > But the last part is a 20 byte string that doesn't seem to > match anything permitted by PKCS#1 v1.5 (or v2.1). I also > note that the SignerInfo specifies "version 1" (aka PKCS#7 > v1.5), so I don't think this could be the elusive PKCS#7 > v1.4 signature format. > It might hypothetically be an SHA1 SUM, but the initial 00 > byte looks strange. That's life. sha1 sums can start by any value between 00 and FF. By change the sha1 sum can even be all 00. Would simply be a remarkable coincidence. I have several other files of this type here and this is the only one starting with 00. That means: the corresponding hash value calculated in EVP_VerifyFinal() also starts with 00. > I am struggling a bit with trying to figure out what bytes > are covered by the hash value, so far I have failed to > manually extract a relevant subset of of the message, but I > may have made some basic mistake since I usually don't do > this by hand. Me neither. I use gdb and/or add debug output to OpenSSL. the full hash: 00 87 34 69 20 D5 4C 68 F4 B1 30 6D EA 3E 40 CC B7 71 AC 1D calculated via EVP_DigestFinal_ex() by EVP_VerifyFinal() called from PKCS7_signatureVerify() where the authenticated attributes and their "content digest" is taken into account. (=> This is a calculated value and not extracted from EncryptedDigest.) > Well, the good news is that at least the PKCS#1 padding is > still there, which makes it a lot less vulnerable than what > your e-mails made me think. ok, sounds good. Maybe that's the reason for *1 (see below): It seems they think there are no known security drawbacks!? Like I said: OpenSSL can handle it like every other PKCS#7 until it tries to decode the decrypted "EncryptedDigest" via d2i_X509_SIG(), which fails on those non-ASN.1 plain hash string. [in int_rsa_verify() in crypto/rsa/rsa_sign.c using PKCS7_verify()] > > No, I'm not. Maybe I'm doing something wrong. I don't know. > It seems not, now I really wonder what is going on. me2 Maybe simply nobody thinks about it because it's accepted even by the brand-new Windows 10. Maybe because of *1 (see above). regards Michael From ml at bartschnet.de Tue Sep 15 06:28:25 2015 From: ml at bartschnet.de (Rene Bartsch) Date: Tue, 15 Sep 2015 08:28:25 +0200 Subject: [openssl-users] =?utf-8?q?How_does_OpenSSL_load/parse_the_certifi?= =?utf-8?q?cate_store=3F?= Message-ID: <3199f47cb4e77b2d972eab55a0f417fd@triangulum.uberspace.de> Hi, how does OpenSSL scan/parse the certificate store? Does it look for specific directory-/filenames (e.g. CA-identity = .crt) or does it just parse ALL files in the certificate store? -- Best regards, Renne From horatiu at ddhosted.com Tue Sep 15 07:55:41 2015 From: horatiu at ddhosted.com (Horatiu N) Date: Tue, 15 Sep 2015 10:55:41 +0300 Subject: [openssl-users] monitoring software depending on openssl not working on cloudflare ssl websites Message-ID: <55F7CEFD.3000400@ddhosted.com> Greetings, Using the nagios plugins (latest debian package for 8.1) to check availability of https websites using cloudflare gives errors > CRITICAL - Cannot make SSL connection. > 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770: same goes if i attempt to run > openssl s_client -connect :443 This basically makes monitoring impossible at this time, Any idea how to remedy this situation ? i attached a textfile with sample domains as extracted from the certificate's "Certificate Subject alt name" it's reproducible on any target as long as it's online openssl version > OpenSSL 1.0.1k 8 Jan 2015 dpkg -l openssl > ii openssl 1.0.1k-3+deb8u1 amd64 Secure Sockets Layer toolkit - cryptographic utility tried also to compile the newest one from openssl.org and use it, same problem. -------------- next part -------------- *.bluusun.com *.coridonculturevoyages.com *.filelist.ro *.flro.org *.footsy.ml *.futurete.pt *.howtowork.ru *.indiviser.ru *.jungs.ru *.linica.ru *.metafront.ru *.mightytravels.com *.segabite.ru *.shrine.moe *.soundgreat.ru *.supersadovod.ru *.tactum.ru *.theonlyjoy.ru *.wakarimasenlol.com bluusun.com coridonculturevoyages.com filelist.ro flro.org footsy.ml futurete.pt howtowork.ru indiviser.ru jungs.ru linica.ru metafront.ru mightytravels.com segabite.ru shrine.moe soundgreat.ru supersadovod.ru tactum.ru theonlyjoy.ru wakarimasenlol.com *.alvimu.ga *.bellowusersyp10.cf *.blankorientalvr40.ga *.carterjk.com *.dualmountingbg66.ml *.improverespectedml51.gq *.lovableshooterfm10.gq *.mutesnoutedof56.ml *.muztube.com *.oberonrarean96.gq *.paristravelbook.net *.prospectusnebulamj12.ml *.quarkrollesyp10.ga *.travelstokyo.net *.triple.ph *.triple.site *.vomeratomzj61.ga *.waxmanassociates.com *.werremeyer.com alvimu.ga bellowusersyp10.cf blankorientalvr40.ga carterjk.com dualmountingbg66.ml improverespectedml51.gq lovableshooterfm10.gq mutesnoutedof56.ml muztube.com oberonrarean96.gq paristravelbook.net prospectusnebulamj12.ml quarkrollesyp10.ga travelstokyo.net triple.ph triple.site vomeratomzj61.ga waxmanassociates.com werremeyer.com -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3709 bytes Desc: S/MIME Cryptographic Signature URL: From noloader at gmail.com Tue Sep 15 17:00:57 2015 From: noloader at gmail.com (Jeffrey Walton) Date: Tue, 15 Sep 2015 13:00:57 -0400 Subject: [openssl-users] monitoring software depending on openssl not working on cloudflare ssl websites In-Reply-To: <55F7CEFD.3000400@ddhosted.com> References: <55F7CEFD.3000400@ddhosted.com> Message-ID: On Tue, Sep 15, 2015 at 3:55 AM, Horatiu N wrote: > Greetings, > > Using the nagios plugins (latest debian package for 8.1) to check > availability of https websites using cloudflare gives errors >> CRITICAL - Cannot make SSL connection. >> 139729452828304:error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert internal error:s23_clnt.c:770: > > same goes if i attempt to run >> openssl s_client -connect :443 > You need to use TLS (not SSL), and you need to use SNI. Here's the first in the list using TLS and SNI: $ openssl s_client -connect www.bluusun.com:443 -tls1 -servername www.bluusun.com CONNECTED(00000003) depth=2 C = GB, ST = Greater Manchester, L = Salford, O = COMODO CA Limited, CN = COMODO ECC Certification Authority verify error:num=20:unable to get local issuer certificate --- Certificate chain 0 s:/OU=Domain Control Validated/OU=PositiveSSL Multi-Domain/CN=sni100936.cloudflaressl.com i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2 1 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Domain Validation Secure Server CA 2 i:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority 2 s:/C=GB/ST=Greater Manchester/L=Salford/O=COMODO CA Limited/CN=COMODO ECC Certification Authority i:/C=SE/O=AddTrust AB/OU=AddTrust External TTP Network/CN=AddTrust External CA Root --- ... From security.veteran at gmail.com Tue Sep 15 17:50:27 2015 From: security.veteran at gmail.com (security veteran) Date: Tue, 15 Sep 2015 10:50:27 -0700 Subject: [openssl-users] How to enable FIPS mode by default of the OpenSSL FIPS modules Message-ID: Thanks Steve. If we use Apache and Python as examples, does that mean both of them need to invoke OPENSSL_Config() in order to enable the FIPS mode? And if that's the case, how do we make them invoke OPENSSL_Config() API? Also regarding the openssl.cfg changes mentioned in the User Guide, what do I need to replace the XXXX string? Below are the config changes I made, does it look right to you? Thanks. HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) XXXX_conf = XXXX_options [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. # Add a simple OID like this: # testoid1=1.2.3.4 # Or use config file substitution like this: # testoid2=${testoid1}.5.6 # Policies used by the TSA examples. tsa_policy1 = 1.2.3.4.1 tsa_policy2 = 1.2.3.4.5.6 tsa_policy3 = 1.2.3.4.5.7 [ XXXX_options ] alg_section = algs [ algs ] fips_mode = yes #################################################################### [ ca ] default_ca = CA_default # The default ca section ------------------------------ On 09/14/2015 05:21 PM, security veteran wrote: >* I asked this question from a different thread, but thought it may be the *>* best to start a new thread to discuss this question since it sounds like *>* a big deal to me. *> >* I've built an openssl library with the FIPS objects modules, and I was *>* testing the new lib files by replacing the original library files such *>* as libcrypto.so with the new ones. *> >* From the FIPS user guide I understand that any applications which need *>* to use the OpenSSL FIPS modules will need to run the API FIPS_mode_set *>* to enable the FIPS mode. *> >* This sounds like a big issue to me: there are may other libraries/ services which depends on OpenSSL. For example, Python, Apache, PostgreSQL, etc. *> >* If the /FIPS_mode_set /API needs to be invoked in order to enable the *>* FIPS mode, how can we make third party library/ services like Python and *>* Apache to invoke this API? *> >* Is there any other way to make the FIPS mode always enabled? * Well ... yes and no. It depends. The OpenSSL FIPS module User Guide (https://openssl.org/docs/fips/UserGuide-2.0.pdf) discusses use of the OPENSSL_Config() call and the global openssl.conf configuration file. In theory you could toggle FIPS mode for all the applications on a system with in one swell foop. In practice it's not that easy, because when you enable FIPS mode you also automatically disable use of all "non-allowed" cryptography. Many applications not specifically written to accommodate the restrictions of FIPS module may not behave gracefully. Some (OpenSSH for instance) require extensive hacks for FIPS mode. Apache httpd does have native FIPS support, but you'll need to invoke the right buildtime and runtime options; the typical httpd binary install won't have FIPS support. -Steve M. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 15 18:27:37 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 15 Sep 2015 20:27:37 +0200 Subject: [openssl-users] How does OpenSSL load/parse the certificate store? In-Reply-To: <3199f47cb4e77b2d972eab55a0f417fd@triangulum.uberspace.de> References: <3199f47cb4e77b2d972eab55a0f417fd@triangulum.uberspace.de> Message-ID: <55F86319.1050603@wisemo.com> On 15/09/2015 08:28, Rene Bartsch wrote: > Hi, > > how does OpenSSL scan/parse the certificate store? > > Does it look for specific directory-/filenames (e.g. CA-identity = > .crt) or does it just parse ALL files in the certificate store? > See the documentation of the c_rehash program. Basically there are two alternative methods: A) (preferred): For each certificiate, there is a symlink from a (weak) checksum of the CA identity to .pem (Example: 17b51fe6.0 -> Certplus_Class_2_Primary_CA.pem). If more than one CA ends up with the same checksum, the additional links are given increasing numeric suffic, and OpenSSL will try them one by one. Because older OpenSSL versions used a different checksum formula, it is sometimes useful to set up both sets of symlinks. B) (preloaded): All the CA certificates (in PEM format) are concatenated into a giant certificates.pem file which is loaded into memory at OpenSSL start up, this is especially useful if the process will chroot() into a directory that doesn't contain the certificates. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 15 21:18:02 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 15 Sep 2015 23:18:02 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150915080644.53ffa92b@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> <20150915080644.53ffa92b@tbb-phenom> Message-ID: <55F88B0A.1050502@wisemo.com> On 15/09/2015 08:06, Michael Heide wrote: > Am Mon, 14 Sep 2015 21:01:49 +0200 schrieb Jakob Bohm : > >>> Seems to be a file with the same criteria here. >> That one is a big surprise to me. > Thanks. > > (if it's a surprise to you, then it's ok to be a surprise for me too. ;-) ) > >> It seems that as late as in August 17 2015 (4 weeks ago), >> Symantec/Verisign issued a timestamp signature, whose >> "EncryptedDigest"was made on the following non-standard >> input: >> >> 00|01|FF...|00|00 87 34 69 20 D5 4C 68 F4 B1 30 6DEA 3E 40 CC B7 71 AC 1D >> >> The first parts (00|01|FF...|00) form the PKCS#1 padding >> for a PCS#1 v1.x signature. >> >> But the last part is a 20 byte string that doesn't seem to >> match anything permitted by PKCS#1 v1.5 (or v2.1). I also >> note that the SignerInfo specifies "version 1" (aka PKCS#7 >> v1.5), so I don't think this could be the elusive PKCS#7 >> v1.4 signature format. >> It might hypothetically be an SHA1 SUM, but the initial 00 >> byte looks strange. > That's life. sha1 sums can start by any value between 00 and FF. > By change the sha1 sum can even be all 00. Would simply be a remarkable > coincidence. I have several other files of this type here and > this is the only one starting with 00. > > That means: the corresponding hash value calculated in > EVP_VerifyFinal() also starts with 00. Yes, it was just rare enough to make me suspicious. >> I am struggling a bit with trying to figure out what bytes >> are covered by the hash value, so far I have failed to >> manually extract a relevant subset of of the message, but I >> may have made some basic mistake since I usually don't do >> this by hand. > Me neither. I use gdb and/or add debug output to OpenSSL. > > the full hash: > 00 87 34 69 20 D5 4C 68 F4 B1 30 6D EA 3E 40 CC B7 71 AC 1D > calculated via EVP_DigestFinal_ex() by EVP_VerifyFinal() > called from PKCS7_signatureVerify() where the authenticated > attributes and their "content digest" is taken into account. > (=> This is a calculated value and not extracted from EncryptedDigest.) Of cause, my problem was what bytes to pass to the digestion process, I couldn't find the right subset, even after double checking the PKCS#7 spec and trying different interpretations of the standard text. >> Well, the good news is that at least the PKCS#1 padding is >> still there, which makes it a lot less vulnerable than what >> your e-mails made me think. > ok, sounds good. Maybe that's the reason for *1 (see below): > It seems they think there are no known security drawbacks!? Where is *1 ? > > Like I said: OpenSSL can handle it like every other PKCS#7 > until it tries to decode the decrypted "EncryptedDigest" > via d2i_X509_SIG(), which fails on those non-ASN.1 plain > hash string. > > [in int_rsa_verify() in crypto/rsa/rsa_sign.c using > PKCS7_verify()] Of cause, this error is really at the PKCS#1 level, even though the PKCS#7 standard formally repeats that particular part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs. OCTET STRING notation. >>> No, I'm not. Maybe I'm doing something wrong. I don't know. >> It seems not, now I really wonder what is going on. > me2 > > Maybe simply nobody thinks about it because it's accepted even by the > brand-new Windows 10. Maybe because of *1 (see above). Yep, it is probably also accepted by Microsoft's generic PKCS#7 code, since I have in the past checked timestamps from that server in that way and not noticed the deviation. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Tue Sep 15 22:11:47 2015 From: security.veteran at gmail.com (security veteran) Date: Tue, 15 Sep 2015 15:11:47 -0700 Subject: [openssl-users] How to enable the FIPS mode of the OpenSSL FIPS modules by calling OPENSSL_Config() API? Message-ID: >From the User Guide of OpenSSL FIPS Object Module v2.0, page 54, it mentioned the FIPS mode can be initialized indirectly by indirect call vial OPENSSL_config() API. My question is, from where should we call this API? If we use Apache and Python as examples, does that mean both of them need to invoke OPENSSL_Config() in order to enable the FIPS mode? And if that's the case, how do we make them invoke OPENSSL_Config() API? Also regarding the openssl.cfg changes mentioned in the User Guide, what do I need to replace the XXXX string? Below are the config changes I made, does it look right to you? Thanks for the helps and suggestions in advanced. ############# Below are my openssl.cfg ############## HOME = . RANDFILE = $ENV::HOME/.rnd # Extra OBJECT IDENTIFIER info: #oid_file = $ENV::HOME/.oid oid_section = new_oids # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: # extensions = # (Alternatively, use a configuration file that has only # X.509v3 extensions in its main [= default] section.) XXXX_conf = XXXX_options [ new_oids ] # We can add new OIDs in here for use by 'ca', 'req' and 'ts'. # Add a simple OID like this: # testoid1=1.2.3.4 # Or use config file substitution like this: # testoid2=${testoid1}.5.6 # Policies used by the TSA examples. tsa_policy1 = 1.2.3.4.1 tsa_policy2 = 1.2.3.4.5.6 tsa_policy3 = 1.2.3.4.5.7 [ XXXX_options ] alg_section = algs [ algs ] fips_mode = yes #################################################################### [ ca ] default_ca = CA_default # The default ca section -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.heide at student.uni-siegen.de Wed Sep 16 06:55:51 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Wed, 16 Sep 2015 08:55:51 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <55F88B0A.1050502@wisemo.com> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> <20150915080644.53ffa92b@tbb-phenom> <55F88B0A.1050502@wisemo.com> Message-ID: <20150916085551.552165ae@tbb-phenom> Am Tue, 15 Sep 2015 23:18:02 +0200 schrieb Jakob Bohm : > Where is *1 ? Sorry, never mind. I screwed it up... > Of cause, this error is really at the PKCS#1 level, even > though the PKCS#7 standard formally repeats that particular > part of PKCS#7 due to ISO/OSI/ITU fun with BIT STRING vs. > OCTET STRING notation. Do you think of Note #1 in chapter 9.4 of rfc 2315? Yes, using the Digest instead of a DigestInfo for the Digest-encryption process seems not covered by rfc 2315. Btw.: for me the problem described in Note #3 seems not as big a problem as it sounds to be. This does indeed work for md5->md2. One can try to match md2 hashes to any signed md5 hash. But not for sha1->md5 or sha256->sha1, because of the differences in length. Maybe that's the reason why it's still in use the way it is done by those timestamp-services and accepted by Windows. That's the thing I wanted to address with the "*1"-thing in my last mail. If there's a 160 bit hash expected, you have to find a 160 bit algorithm which gets accepted by those verifying the signature. If there's only sha1, then you got stuck to sha1, regardless if it's a DigestInfo or a plain Digest. > Yep, it is probably also accepted by Microsoft's generic PKCS#7 > code, since I have in the past checked timestamps from that > server in that way and not noticed the deviation. My question now is: how to (proper) handle it? - continue using a patched and self-compiled openssl? - copy all functionality down to the modified int_rsa_verify() into my own project to use the rest from system-included openssl? - rewrite my source to parse pkcs#7 myself? I'm using a verify_cb() for other things but I didn't find a usable callback for this. Regards Michael From matt at openssl.org Wed Sep 16 10:16:18 2015 From: matt at openssl.org (Matt Caswell) Date: Wed, 16 Sep 2015 11:16:18 +0100 Subject: [openssl-users] OpenSSL 1.1.0 Release Timetable Message-ID: <55F94172.4050706@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 The OpenSSL Project team would like to announce the publication of our current plans for the OpenSSL 1.1.0 release timetable. This has been included in our release strategy available here: https://www.openssl.org/policies/releasestrat.html Yours The OpenSSL Project Team -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV+UFyAAoJENnE0m0OYESRZiIH/0oT1j9Ipizi/IVjMSuE6BHY wDdvGuobNSwVUOb61TMxJejI6VX2mowZNjZrc8IdULYIVNnHNyF+iDNBrYQR+KcN bdVE8b1T6nzkKn8e7paI7cqdTYll59vE/p1fJ6uiZb0Y7oOLJ46jWuoRjtQB5xbw bJt8XweO7zR34ungk/kNLb76D8ZSKxGeaJsgD68ymJgOJdFpWHv4/phpg4eLClmk g+8g90COCfwQh9BskhVpUr5fT1+zxo91FA4HgQp3WdRhtcmYAbgoScc6/MWc73MH jIXEGBDURKaR0M2/WLf0Ezz/666ZxltjUhHNtOrhdv6waHmlpjsnYn1M7bxNh+Q= =R/23 -----END PGP SIGNATURE----- From security.veteran at gmail.com Wed Sep 16 23:09:46 2015 From: security.veteran at gmail.com (security veteran) Date: Wed, 16 Sep 2015 16:09:46 -0700 Subject: [openssl-users] Enable FIPS mode of OpenSSL by changing the configuration file, will it work for Python as well? Message-ID: Hi All: I tried to enable the FIPS mode by making the following changes in my openssl.cfg config file. After making the changes, I verified that I can no longer run the non FIPS approval algorithm such as MD5 by running openssl command, which is expected: openssl md5 123.txt However, I can still use Python hashlib.md5() function to generate MD5 hash. Does anyone know should the FIPS mode work for Python as well? My understanding is Python SSL module also use openssl underneath, so ideally the FIPS mode should have impacted my Python as well. Thanks and any suggestions are greatly appreciated. .......... # Default appname: should match "appname" parameter (if any) # supplied to CONF_modules_load_file et al. openssl_conf = openssl_conf_section [openssl_conf_section] # Configuration module list alg_section = evp_sect [evp_sect] # Set to "yes" to enter FIPS mode if supported fips_mode = yes [ new_oids ] ................. -------------- next part -------------- An HTML attachment was scrubbed... URL: From security.veteran at gmail.com Wed Sep 16 23:15:05 2015 From: security.veteran at gmail.com (security veteran) Date: Wed, 16 Sep 2015 16:15:05 -0700 Subject: [openssl-users] Is there any patch for OpenSSH for it to work with OpenSSL FIPS? Message-ID: It seems like there's no easy way to make OpenSSH to work with FIPS mode without making code changes to it. Is there any reliable patch for OpenSSH to support FIPS mode? Thanks and appreciate all the helps. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Sep 17 01:57:06 2015 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 17 Sep 2015 01:57:06 +0000 Subject: [openssl-users] Is there any patch for OpenSSH for it to work with OpenSSL FIPS? In-Reply-To: References: Message-ID: <3f475e2f9215402cb35e6dc1592c5575@ustx2ex-dag1mb3.msg.corp.akamai.com> > Is there any reliable patch for OpenSSH to support FIPS mode? Try the openssh mailing lists? From what I've seen the OpenBSD folks actively dislike FIPS, so good luck. From bhat.jayalakshmi at gmail.com Thu Sep 17 20:08:51 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Fri, 18 Sep 2015 01:38:51 +0530 Subject: [openssl-users] CBC mode does not work on OpenSSL 1.0.2d Message-ID: Hi All, I have ported OpenSSL 1.0.2d on out device. When I am using any cipher (AES,3DES) in CBC mode I am ending with the result SSL_R_DECRYPTION_FAILED_OR_BAD_RECORD_MAC in SSL_F_SSL3_GET_RECORD function. TLS 1.2 with working fine with AES_GCM ciphers. Has any one faced this issue?. Any help is appreciated. Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Fri Sep 18 11:49:31 2015 From: marquess at openssl.com (Steve Marquess) Date: Fri, 18 Sep 2015 07:49:31 -0400 Subject: [openssl-users] Is there any patch for OpenSSH for it to work with OpenSSL FIPS? In-Reply-To: <3f475e2f9215402cb35e6dc1592c5575@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <3f475e2f9215402cb35e6dc1592c5575@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <55FBFA4B.3030907@openssl.com> On 09/16/2015 09:57 PM, Salz, Rich wrote: >> Is there any reliable patch for OpenSSH to support FIPS mode? > > Try the openssh mailing lists? > >>From what I've seen the OpenBSD folks actively dislike FIPS, so good luck. You can find one out-of-date patch here: http://openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch Note that is a non-trivial patch, as all the inlined cryptographic operations must be replaced with references to the validated module. Also note that you'll only want FIPS mode if you're deploying in a USG/DoD environment, in which case you'll also need x.509 support. Roumen Petrov has for years maintained a very nice (and also non-trivial) set of patches (http://roumenpetrov.info/openssh/) that add x.509 functionality. So apply his patches first, then do the FIPS mode adaptation. It's my understanding that stock OpenSSH will not support either FIPS or x.509, ever, a deliberate choice that frankly makes perfect sense given their project objectives. They have chosen to implement a simpler, leaner, and tighter certificate scheme specific to OpenSSH, to avoid the huge attack surface of x.509. Likewise FIPS validated software is necessarily less secure than the unvalidated equivalent. You use it only because you must per policy mandates, not because it has any technical advantages. Ssh is the de facto 21st century telnet and is widely used in U.S. DoD either in violation of the policy requirements for FIPS 140-2 and x.509, or with various homegrown vendor hacks that probably introduce still more vulnerabilities. I've long felt there would be a market for a "U.S. government compliant" version of OpenSSH, but if that's ever done it won't be by the OpenSSH maintainers. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From zosrothko at orange.fr Fri Sep 18 16:05:42 2015 From: zosrothko at orange.fr (zosrothko) Date: Fri, 18 Sep 2015 18:05:42 +0200 Subject: [openssl-users] OPENSSL_VERSION_NUMBER and TLSv1_1 & TLSv1_2 supports Message-ID: <55FC3656.9080506@orange.fr> Hi is there a way to know the supported TLS protocols from the OPENSSL_VERSION_NUMBER (specifically, the TLSv1_1 and TLSv1_2? For exemple, I have a code that is using TLSv1_1_client_method & TLSv1_1_server_method for a OPENSSL_VERSION_NUMBER = 0x1000201fL, but I need to protect those TLSv1_1 and TLSv1_2 entry points references when my code is ported toward a previous version of OpenSSL that does not support those TLS versions as the 1.0.0k version . Since there is no OPEN_SSL_NO_TLSv1_1 constant nor OPEN_SSL_NO_TLSv1_2 constant in the ssl.h(1.0.0k), I would like to use the OPENSSL_VERSION_NUMBER to protect the references. Cheers zos This email has been protected by YAC (Yet Another Cleaner) http://www.yac.mx From jb-openssl at wisemo.com Fri Sep 18 17:34:43 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 18 Sep 2015 19:34:43 +0200 Subject: [openssl-users] OPENSSL_VERSION_NUMBER and TLSv1_1 & TLSv1_2 supports In-Reply-To: <55FC3656.9080506@orange.fr> References: <55FC3656.9080506@orange.fr> Message-ID: <55FC4B33.8030902@wisemo.com> On 18/09/2015 18:05, zosrothko wrote: > Hi > > is there a way to know the supported TLS protocols from the > OPENSSL_VERSION_NUMBER (specifically, the TLSv1_1 and TLSv1_2? > > For exemple, I have a code that is using TLSv1_1_client_method & > TLSv1_1_server_method for a OPENSSL_VERSION_NUMBER = 0x1000201fL, but > I need to protect those TLSv1_1 and TLSv1_2 entry points references > when my code is ported toward a previous version of OpenSSL that does > not support those TLS versions as the 1.0.0k version . > > Since there is no OPEN_SSL_NO_TLSv1_1 constant nor OPEN_SSL_NO_TLSv1_2 > constant in the ssl.h(1.0.0k), I would like to use the > OPENSSL_VERSION_NUMBER to protect the references. > The numeric value of OPENSSL_VERSION_NUMBER maps directly to the textual version number ("1.0.0k"), a look in the official changelogs for each branch (0.9.8, 1.0.0, 1.0.1, 1.0.2, 1.1.0 etc.) to see at which comparison limits any given feature was installed. Or, since you are using the version number of the header files, not the version of the runtime shared library, you can simply use ifdef tests for relevant defines existing, e.g. #if defined(SSL_OP_NO_TLSv1_1) && !defined(OPENSSL_NO_TLS1) /* SSL_OP_NO_TLSv1_1 is defined in ssl.h if the library version * supports TLSv1.1 . * * OPENSSL_NO_TLS1 is defined in opensslconf.h or on the * compiler command line if TLS1.x was removed at OpenSSL * library build time via Configure options. */ /* Code that requires headers from a TLSv1.1 capable OpenSSL * goes here. */ #endif Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.heide at student.uni-siegen.de Sat Sep 19 13:34:16 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Sat, 19 Sep 2015 15:34:16 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150916085551.552165ae@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> <20150915080644.53ffa92b@tbb-phenom> <55F88B0A.1050502@wisemo.com> <20150916085551.552165ae@tbb-phenom> Message-ID: <20150919153416.34bf155b@tbb-phenom> Am Wed, 16 Sep 2015 08:55:51 +0200 schrieb Michael Heide : > My question now is: how to (proper) handle it? Maybe a more sensible way to handle those signatures with OpenSSL is to still not allow such things but instead return an error indicating success if it /would/ be allowed to do it this way? The application then can check for this specific error and translate it into success. (meaning: this specific error is set if OpenSSL successfully compared both hashes and is - as such - not really a fatal error.) This way OpenSSLs default behaviour won't change, it's still an error to not encapsulate the encryptedDigest in an asn1 structure. But the application programmer is able to handle it. see attachment. (Maybe a callback-function at the place where the error gets generated would be a better option. But I think that would be a more extensive change in OpenSSL.) Regards Michael -------------- next part -------------- A non-text attachment was scrubbed... Name: non-enveloped-hash.patch Type: text/x-patch Size: 1714 bytes Desc: not available URL: From bhat.jayalakshmi at gmail.com Sat Sep 19 17:57:35 2015 From: bhat.jayalakshmi at gmail.com (Jayalakshmi bhat) Date: Sat, 19 Sep 2015 23:27:35 +0530 Subject: [openssl-users] CBC mode is not working in OpenSSL 1.0.2d Message-ID: Hi All, I have ported OpenSSL 1.0.2d on our product. After that CBC mode is not working. Handshakes are failing with bad mac alert failure. When I checked the code mac retrieved from ssl3_cbc_copy_mac does not match with the calculated mac. Any help on this is appreciated. Thanks and Regards Jayalakshmi -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Sat Sep 19 21:09:16 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 19 Sep 2015 23:09:16 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <20150919153416.34bf155b@tbb-phenom> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> <20150915080644.53ffa92b@tbb-phenom> <55F88B0A.1050502@wisemo.com> <20150916085551.552165ae@tbb-phenom> <20150919153416.34bf155b@tbb-phenom> Message-ID: <55FDCEFC.3040904@wisemo.com> On 19/09/2015 15:34, Michael Heide wrote: > Am Wed, 16 Sep 2015 08:55:51 +0200 schrieb Michael Heide : > >> My question now is: how to (proper) handle it? > Maybe a more sensible way to handle those signatures with OpenSSL is to still not allow such things but instead return an error indicating success if it /would/ be allowed to do it this way? The application then can check for this specific error and translate it into success. (meaning: this specific error is set if OpenSSL successfully compared both hashes and is - as such - not really a fatal error.) > > This way OpenSSLs default behaviour won't change, it's still an error to not encapsulate the encryptedDigest in an asn1 structure. But the application programmer is able to handle it. > > see attachment. > > (Maybe a callback-function at the place where the error gets generated would be a better option. But I think that would be a more extensive change in OpenSSL.) I am in no position to include this, but here are a few thoughts on improving your patch. 1. The error should not call this "plain", this would lead to the same misunderstanding I had earlier. Try something like "RSA_R_PKCS1_1_DIGEST_ONLY_VALID" to indicate that this is a variant of PKCS#1 v1.x signature formatting (the outer part with 00|01|FF....|00 is still there), but without the inner DER encoded ASN.1 structure. 2. Because the hash algorithm OID is not there, something needs to check that the hash algorithm is the right one for this RSA public key. This test is really in another layer (PKCS#7/CMS), but needs to be stronger in this case due to the lack of an embedded hash algorithm identifier inside the RSA calculation. 3. It would be really nice if someone in the know would explain under which conditions this alternative signature algorithm is used and/or necessary. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.heide at student.uni-siegen.de Sun Sep 20 08:51:26 2015 From: michael.heide at student.uni-siegen.de (Michael Heide) Date: Sun, 20 Sep 2015 10:51:26 +0200 Subject: [openssl-users] PKCS7->signerInfo->encryptedDigest not type X509_SIG In-Reply-To: <55FDCEFC.3040904@wisemo.com> References: <20150911123004.6688b32f@tbb-phenom> <55F2D208.6010806@wisemo.com> <20150911232604.51bf0dd1@tbb-phenom> <55F6DC13.9010907@wisemo.com> <20150914174002.4fe26888@tbb-phenom> <55F7199D.1090906@wisemo.com> <20150915080644.53ffa92b@tbb-phenom> <55F88B0A.1050502@wisemo.com> <20150916085551.552165ae@tbb-phenom> <20150919153416.34bf155b@tbb-phenom> <55FDCEFC.3040904@wisemo.com> Message-ID: <20150920105126.7f6e701f@tbb-phenom> Am Sat, 19 Sep 2015 23:09:16 +0200 schrieb Jakob Bohm : > 1. The error should not call this "plain", this would lead > to the same misunderstanding I had earlier. Right. I'm not an advanced english speaker, I shouldn't name it at all. ;-) Btw. In the meantime I think my last suggestion for a patch is poor. Still handling this kind of signatures as an error would fail/stop the whole verification process and if this happens with some intermediate certificate, then the application cannot turn this into a successful verification (AFAIK). I haven't found a way to make it configurable, yet. That is to not change OpenSSLs default behaviour but have an option to let it accept those kind of signatures. > 3. It would be really nice if someone in the know would > explain under which conditions this alternative signature > algorithm is used and/or necessary. Yes. I've found only a single time stamping service so far. Regards Michael From security.veteran at gmail.com Mon Sep 21 21:12:13 2015 From: security.veteran at gmail.com (security veteran) Date: Mon, 21 Sep 2015 14:12:13 -0700 Subject: [openssl-users] Is there any patch for OpenSSH for it to work with OpenSSL FIPS? In-Reply-To: <55FBFA4B.3030907@openssl.com> References: <3f475e2f9215402cb35e6dc1592c5575@ustx2ex-dag1mb3.msg.corp.akamai.com> <55FBFA4B.3030907@openssl.com> Message-ID: Thanks Steve. Just out of my curiosity that I can image there might already be a lot of companies use the OpenSSL FIPS modules for the FIPS validation. Since OpenSSH is almost everywhere in most of the server/ appliance products, people should have run into the "OpenSSH not working with OpenSSL FIPS mode" issue before. Do you know how do most people resolve problems like this? Do they mostly use the OpenSSH patch to build the FIPS compliant version of OpenSSH, or did people do something else to resolve the issue? Thanks and appreciate your helps. On Fri, Sep 18, 2015 at 4:49 AM, Steve Marquess wrote: > On 09/16/2015 09:57 PM, Salz, Rich wrote: > >> Is there any reliable patch for OpenSSH to support FIPS mode? > > > > Try the openssh mailing lists? > > > >>From what I've seen the OpenBSD folks actively dislike FIPS, so good > luck. > > You can find one out-of-date patch here: > > http://openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch > > Note that is a non-trivial patch, as all the inlined cryptographic > operations must be replaced with references to the validated module. > > Also note that you'll only want FIPS mode if you're deploying in a > USG/DoD environment, in which case you'll also need x.509 support. > > Roumen Petrov has for years maintained a very nice (and also > non-trivial) set of patches (http://roumenpetrov.info/openssh/) that add > x.509 functionality. So apply his patches first, then do the FIPS mode > adaptation. > > It's my understanding that stock OpenSSH will not support either FIPS or > x.509, ever, a deliberate choice that frankly makes perfect sense given > their project objectives. They have chosen to implement a simpler, > leaner, and tighter certificate scheme specific to OpenSSH, to avoid the > huge attack surface of x.509. Likewise FIPS validated software is > necessarily less secure than the unvalidated equivalent. You use it only > because you must per policy mandates, not because it has any technical > advantages. > > Ssh is the de facto 21st century telnet and is widely used in U.S. DoD > either in violation of the policy requirements for FIPS 140-2 and x.509, > or with various homegrown vendor hacks that probably introduce still > more vulnerabilities. I've long felt there would be a market for a "U.S. > government compliant" version of OpenSSH, but if that's ever done it > won't be by the OpenSSH maintainers. > > -Steve M. > > -- > Steve Marquess > OpenSSL Software Foundation, Inc. > 1829 Mount Ephraim Road > Adamstown, MD 21710 > USA > +1 877 673 6775 s/b > +1 301 874 2571 direct > marquess at opensslfoundation.com > marquess at openssl.com > gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc > _______________________________________________ > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Mon Sep 21 21:25:12 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 21 Sep 2015 17:25:12 -0400 Subject: [openssl-users] Is there any patch for OpenSSH for it to work with OpenSSL FIPS? In-Reply-To: References: <3f475e2f9215402cb35e6dc1592c5575@ustx2ex-dag1mb3.msg.corp.akamai.com> <55FBFA4B.3030907@openssl.com> Message-ID: <560075B8.6090301@openssl.com> On 09/21/2015 05:12 PM, security veteran wrote: > Thanks Steve. > > Just out of my curiosity that I can image there might already be a lot > of companies use the OpenSSL FIPS modules for the FIPS validation. > Since OpenSSH is almost everywhere in most of the server/ appliance > products, people should have run into the "OpenSSH not working with > OpenSSL FIPS mode" issue before. Yup, frequently. > Do you know how do most people resolve > problems like this? Do they mostly use the OpenSSH patch to build the > FIPS compliant version of OpenSSH, or did people do something else to > resolve the issue? I can't claim to know what "most" users do. I know that multiple software vendors have independently hacked OpenSSH for use in DoD (do a search on "site:csrc.nist.gov/groups/STM/cmvp/documents/ openssh" and you'll see a number of validated modules that specifically mention OpenSSH). I also know from consulting within DoD for many years that OpenSSH is often used unmodified, a policy violation that often went completely unnoticed. As a consultant I hacked OpenSSH multiple times for DoD clients and vendors to DoD clients, and I'm sure I wasn't the only one. There are also a handful of commercial knockoffs of OpenSSH supposedly adapted for DoD compliance, though I've been out of that arena long enough to no longer recall their names. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From kgoldman at us.ibm.com Mon Sep 21 22:29:02 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 21 Sep 2015 18:29:02 -0400 Subject: [openssl-users] X509 subject key identifier Message-ID: How can I programmatically get the Subject Key Identifier as a byte array from an X509 certificate. (Just to show that I tried before posting) I would like the output as a byte array, not text, so tracing the X509_print_fp() gave clues but not an answer. I have the general sense that it's within x509->cert_info_extensions, and that I use NID_subject_key_identifier to extract an extension from the stack. Then I perhaps get the ASN1 object from the extension and from there the value. Any leads? From openssl-users at dukhovni.org Tue Sep 22 05:25:43 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Sep 2015 05:25:43 +0000 Subject: [openssl-users] X509 subject key identifier In-Reply-To: References: Message-ID: <20150922052543.GT21942@mournblade.imrryr.org> On Mon, Sep 21, 2015 at 06:29:02PM -0400, Ken Goldman wrote: > How can I programmatically get the Subject Key Identifier as a byte array > from an X509 certificate. Unless I'm mistaken: size_t len; unsigned char *data; ASN1_OCTET_STRING *skid; skid = X509_get_ext_d2i(subject, NID_subject_key_identifier, NULL, NULL); len = ASN1_STRING_length(skid); data = ASN1_STRING_data(skid); ... Take unspeakable liberties with "data" and "len" ... ASN1_OCTET_STRING_free(skid); -- Viktor. From kgoldman at us.ibm.com Tue Sep 22 13:22:09 2015 From: kgoldman at us.ibm.com (Ken Goldman) Date: Tue, 22 Sep 2015 09:22:09 -0400 Subject: [openssl-users] X509 subject key identifier In-Reply-To: <20150922052543.GT21942@mournblade.imrryr.org> References: <20150922052543.GT21942@mournblade.imrryr.org> Message-ID: This (of course) worked. I have three further questions. 1 - Am I correct that "data" points to the internal structure, and so "skid" should not be freed until I'm done with "data"? 2 - For my education, I thought that d2i calls converted from DER to openssl internal format. Yet, the input "subject" is an X509*, the internal format. 3 - Are these calls documented? They're not in my usual starting point https://www.openssl.org/docs/man1.0.1/crypto/ nor are they on the X509 page. On 9/22/2015 1:25 AM, Viktor Dukhovni wrote: > On Mon, Sep 21, 2015 at 06:29:02PM -0400, Ken Goldman wrote: > >> How can I programmatically get the Subject Key Identifier as a byte array >> from an X509 certificate. > > Unless I'm mistaken: > > size_t len; > unsigned char *data; > ASN1_OCTET_STRING *skid; > > skid = X509_get_ext_d2i(subject, NID_subject_key_identifier, NULL, NULL); > len = ASN1_STRING_length(skid); > data = ASN1_STRING_data(skid); > > ... Take unspeakable liberties with "data" and "len" ... > > ASN1_OCTET_STRING_free(skid); > From openssl-users at dukhovni.org Tue Sep 22 14:31:14 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 22 Sep 2015 14:31:14 +0000 Subject: [openssl-users] X509 subject key identifier In-Reply-To: References: <20150922052543.GT21942@mournblade.imrryr.org> Message-ID: <20150922143114.GU21942@mournblade.imrryr.org> On Tue, Sep 22, 2015 at 09:22:09AM -0400, Ken Goldman wrote: > 1 - Am I correct that "data" points to the internal structure, and so "skid" > should not be freed until I'm done with "data"? Correct. The "data" element is part of the ASN1_STRING (of type ASN1_OCTET_STRING). > 2 - For my education, I thought that d2i calls converted from DER to openssl > internal format. Yet, the input "subject" is an X509*, the internal format. While the certificate object is already decoded, its extensions are not, they are stored in DER form, and you need to extract them via suitable decoding routines. > 3 - Are these calls documented? They're not in my usual starting point > > https://www.openssl.org/docs/man1.0.1/crypto/ > > nor are they on the X509 page. Sadly, they're not. Please open a ticket that requests these be documented. There's a tiny example in doc/HOWTO/proxy_certificates.txt but it does not amount to documentation of the interface. If you're really feeling generous, write the document. The underlying interface is in crypto/x509v3/v3_lib.c: /*- * Get critical flag and decoded version of extension from a NID. * The "idx" variable returns the last found extension and can * be used to retrieve multiple extensions of the same NID. * However multiple extensions with the same NID is usually * due to a badly encoded certificate so if idx is NULL we * choke if multiple extensions exist. * The "crit" variable is set to the critical value. * The return value is the decoded extension or NULL on * error. The actual error can have several different causes, * the value of *crit reflects the cause: * >= 0, extension found but not decoded (reflects critical value). * -1 extension not found. * -2 extension occurs more than once. */ void *X509V3_get_d2i(STACK_OF(X509_EXTENSION) *x, int nid, int *crit, int *idx) Only certain "standard" extensions have default "d2i" methods. The list is in: static const X509V3_EXT_METHOD *standard_exts[] in the same file, but some legacy NetScape extensions are defined in crypto/x509v3/v3_ia5.c: const X509V3_EXT_METHOD v3_ns_ia5_list[] -- Viktor. From pbellino at mrv.com Tue Sep 22 14:04:32 2015 From: pbellino at mrv.com (Philip Bellino) Date: Tue, 22 Sep 2015 14:04:32 +0000 Subject: [openssl-users] Key Deriviation Function Tests for TLS Message-ID: Hello, In pursuit of FIPS validation using OpenSSL 1.0.2a/ FIPS 2.0.9, we are required by our testing lab to perform KDF tests for TLS (see document NIST SP800-135, Rev 1 section 4.2). Could you please point us to where the source for the KDF TLS test(s) are available. Thank you, Phil Bellino [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Tue Sep 22 14:53:42 2015 From: marquess at openssl.com (Steve Marquess) Date: Tue, 22 Sep 2015 10:53:42 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: References: Message-ID: <56016B76.5000905@openssl.com> On 09/22/2015 10:04 AM, Philip Bellino wrote: > Hello, > > In pursuit of FIPS validation using OpenSSL 1.0.2a/ FIPS 2.0.9, we are > required by our testing lab to perform KDF tests for TLS (see document > NIST SP800-135, Rev 1 section 4.2). > > > > Could you please point us to where the source for the KDF TLS test(s) > are available. The OpenSSL FIPS Object Module 2.0 (validation certificate #1747 and #2398) preceded those KDF tests, and we're not allowed to add that type of functionality to existing validations (a prohibition that extends even to some vulnerability fixes). We'll address those and other new requirements (I.G. 9.10, FIPS 186-4, SP800-131A, Lucky 13, CVE-2014-0076, etc.) if and when we're in a position to tackle a new open source based validation to succeed #1747. In the meantime you'll need to roll your own code for your proprietary OpenSSL based "private label" validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From foleyj at cisco.com Tue Sep 22 23:26:09 2015 From: foleyj at cisco.com (John Foley (foleyj)) Date: Tue, 22 Sep 2015 23:26:09 +0000 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: References: Message-ID: <000f4249.20aa96261ea06347@cisco.com> Pull request 368 has KDF support for FIPS: https://github.com/openssl/openssl/pull/368 I've already updated libsrtp to use this API for FIPS compliance. We would like to contribute to other downstream projects as well. But it would help if OpenSSL accepted this pull request. ------ Original message------ From: Philip Bellino Date: Tue, Sep 22, 2015 10:38 AM To: openssl-users at openssl.org; Subject:[openssl-users] Key Deriviation Function Tests for TLS Hello, In pursuit of FIPS validation using OpenSSL 1.0.2a/ FIPS 2.0.9, we are required by our testing lab to perform KDF tests for TLS (see document NIST SP800-135, Rev 1 section 4.2). Could you please point us to where the source for the KDF TLS test(s) are available. Thank you, Phil Bellino [E-Banner] MRV Communications is a global supplier of packet and optical solutions that power the world's largest networks. Our products combine innovative hardware with intelligent software to make networks smarter, faster and more efficient. The contents of this message, together with any attachments, are intended only for the use of the person(s) to whom they are addressed and may contain confidential and/or privileged information. If you are not the intended recipient, immediately advise the sender, delete this message and any attachments and note that any distribution, or copying of this message, or any attachment, is prohibited. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Sep 23 11:09:24 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 23 Sep 2015 07:09:24 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <000f4249.20aa96261ea06347@cisco.com> References: <000f4249.20aa96261ea06347@cisco.com> Message-ID: <56028864.1030601@openssl.com> On 09/22/2015 07:26 PM, John Foley (foleyj) wrote: > Pull request 368 has KDF support for FIPS: > https://github.com/openssl/openssl/pull/368 > > > I've already updated libsrtp to use this API for FIPS compliance. We > would like to contribute to other downstream projects as well. But it > would help if OpenSSL accepted this pull request. > John, the problem is that we have no FIPS validation in which that can be used. We're not allowed to make such changes to existing validated modules, and have no immediate prospects of doing any new validation. IMHO there isn't much point in accepting and committing speculative code, i.e. code that we can't actually use in OpenSSL. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From marquess at openssl.com Wed Sep 23 12:16:26 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 23 Sep 2015 08:16:26 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <56028864.1030601@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> Message-ID: <5602981A.60107@openssl.com> On 09/23/2015 07:09 AM, Steve Marquess wrote: > On 09/22/2015 07:26 PM, John Foley (foleyj) wrote: >> Pull request 368 has KDF support for FIPS: >> https://github.com/openssl/openssl/pull/368 >> >> >> I've already updated libsrtp to use this API for FIPS compliance. We >> would like to contribute to other downstream projects as well. But it >> would help if OpenSSL accepted this pull request. >> > > John, the problem is that we have no FIPS validation in which that can > be used. We're not allowed to make such changes to existing validated > modules, and have no immediate prospects of doing any new validation. > IMHO there isn't much point in accepting and committing speculative > code, i.e. code that we can't actually use in OpenSSL. John, let me elaborate on my comment above by noting that the Cisco contribution includes a bunch of FIPS specific code for which there is no counterpart on the master branch (i.e. no place to put it). A version which worked on master with all the FIPS stuff stripped out and with tests via evp_test would be a lot more interesting. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From Newcomer83 at web.de Wed Sep 23 16:02:26 2015 From: Newcomer83 at web.de (Newcomer83 at web.de) Date: Wed, 23 Sep 2015 18:02:26 +0200 Subject: [openssl-users] The server's "SSL_write" freezes if invoked while client disconnects Message-ID: Hello everyone, I have an OpenSSL client (Windows) and server (Ubuntu). When my client tries to disconnect from the server, but the server happens to call SSL_write during the disconnect process by chance, then SSL_write freezes. I tried to check the socket via select and I tried to make it non-blocking before writing, but nothing worked. The function simply freezes (i.e. no return, even as a non-blocking socket), probably because the socket thinks that it is ready, even though it really isn't. Is there any function out there that can reliably tell me whether or not I can call SSL_write in this scenario? And if there isn't any way to do this, because I made some noobish mistake nobody who knows the first thing about OpenSSL should make: What is the proper way of dealing with this scenario? I simply have a scenario where both client and server can send messages at any time and the client can disconnect at any time. The latter is especially bad if it happens via network problems, because a user-invoked disconnect can be worked-around, e.g. the client tells the server "I'm going to disconnect soon, don't call SSL_write any more" and then it waits until the server is ready for disconnecting. Kind regards Alex From dlmeetei at gmail.com Thu Sep 24 15:16:57 2015 From: dlmeetei at gmail.com (Devchandra L Meetei) Date: Thu, 24 Sep 2015 20:46:57 +0530 Subject: [openssl-users] Getting role of SSL endpoint In-Reply-To: References: Message-ID: Hello all In a bid to use openssl's non blocking mode with bio pair, we are calling SSL_do_handshake to perform handshake and we would like to do callback based on role of SSL. Is there any API that can be used to get the role of SSL ptr? If not, will using the member, int server, in struct ssl_st help? If so please let us know if openssl community will be interested in patch, perhaps a macro to get the endpoint role. -------------- next part -------------- An HTML attachment was scrubbed... URL: From neil.carter at oracle.com Thu Sep 24 17:50:43 2015 From: neil.carter at oracle.com (neil carter) Date: Thu, 24 Sep 2015 12:50:43 -0500 Subject: [openssl-users] lib4758cca.bad Message-ID: <560437F3.50409@oracle.com> Greetings: I just completed compiling the openssl-1.0.2d bundle on 64-bit linux (OEL 5.8). I say completed, but I cheated somewhat. steps: ./config --prefix=/usr/local shared no-dso make make install When I ran the 'make install' the first time, it failed at the 4758cca section with several errors about all of the lib* files in the engines sub-directory. I no longer have the exact error message, but it basically stated that the lib4758cca.bad file, and ten other lib*.bad files, did not exist. OK, interesting. I cd'd to the engines sub-directory and looked, there were no lib*.bad files. On a lark, I touched all eleven of the missing lib*.bad filenames (one for each of the lib*.so files), cd'd back out of the engines sub-directory, and ran 'make install' again. This time it went further but then informed me that the engines/ccgost/libgost.bad file did not exist. I touched this filename, cd'd back out of the engines/ccgost sub-directory, ran 'make install' again and everything worked seemingly fine. I now have a working copy of openssl-1.0.2d on this system. At least I think I do. I'm relatively certain this is not a sanctioned work-around for this error. Can someone please explain what these lib*.bad files are supposed to be or what they signify? Thanks! Neil -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Sep 24 19:52:49 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 24 Sep 2015 19:52:49 +0000 Subject: [openssl-users] lib4758cca.bad In-Reply-To: <560437F3.50409@oracle.com> References: <560437F3.50409@oracle.com> Message-ID: <20150924195249.GR21942@mournblade.imrryr.org> On Thu, Sep 24, 2015 at 12:50:43PM -0500, neil carter wrote: > I just completed compiling the openssl-1.0.2d bundle on 64-bit linux (OEL > 5.8). I say completed, but I cheated somewhat. > > steps: > > ./config --prefix=/usr/local shared no-dso > make > make install > > When I ran the 'make install' the first time, it failed at the 4758cca > section with several errors about all of the lib* files in the engines > sub-directory. When you disable dynamic shared objects, you also need to disable engine support. Try: ./config --prefix=/usr/local shared no-dso no-engine make depend make (Building with no-engine does not seem to work on the "master" branch just now, but works for me with 1.0.2 from git, have not tried 1.0.2d). -- Viktor. From chengzju at qq.com Fri Sep 25 10:51:33 2015 From: chengzju at qq.com (=?gb18030?B?1qrstvTDvLo=?=) Date: Fri, 25 Sep 2015 18:51:33 +0800 Subject: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. Message-ID: Hi guys i want to write two programd to learn the details of ecdsa signature. program A read the private key from private.pem, sign a string, like "abcde1234", save the signature as sig.pem. program B read the public key from pub.pem, read the sig.pem, and verify the signature. can anybody provide me a example code? my implementation is as follow: 1, generate the ecc keys by "openssl ecparam -genkey -name secp256r1 -out private.pem" and extract the public key by "openssl ec -in private.pem -out public.pem -pubout" 2, read the private key by "PEM_read_PrivateKey()", and sign with "ECDSA_do_sign", there is no problem. program A works well. 3, the problem is how to read the public key from public.pem ? i find PEM_read_bio_PUBKEY from app/apps.c, but i can't find the source code. how can i verify the signature without knowing the private key? -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Fri Sep 25 17:32:22 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 25 Sep 2015 17:32:22 +0000 Subject: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. In-Reply-To: References: Message-ID: That's the whole point of private key encryption. You don't NEED to know the private key. What you do is write out the data (abcde1234). Then hash it (SHA-256), and encrypt the *HASH* with the private key. The recipient reads the data and encrypted hash. He then decrypts the hash with the public key, compares it to the hash of the data. If the two hashes match, the data is authentic. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of ???? Sent: Friday, September 25, 2015 3:52 AM To: openssl-users Subject: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. Hi guys i want to write two programd to learn the details of ecdsa signature. program A read the private key from private.pem, sign a string, like "abcde1234", save the signature as sig.pem. program B read the public key from pub.pem, read the sig.pem, and verify the signature. can anybody provide me a example code? my implementation is as follow: 1, generate the ecc keys by "openssl ecparam -genkey -name secp256r1 -out private.pem" and extract the public key by "openssl ec -in private.pem -out public.pem -pubout" 2, read the private key by "PEM_read_PrivateKey()", and sign with "ECDSA_do_sign", there is no problem. program A works well. 3, the problem is how to read the public key from public.pem ? i find PEM_read_bio_PUBKEY from app/apps.c, but i can't find the source code. how can i verify the signature without knowing the private key? -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Fri Sep 25 17:47:54 2015 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 25 Sep 2015 17:47:54 +0000 Subject: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. In-Reply-To: References: Message-ID: Ignore me. I completely misread your email. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Scott Neugroschl Sent: Friday, September 25, 2015 10:32 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. That's the whole point of private key encryption. You don't NEED to know the private key. What you do is write out the data (abcde1234). Then hash it (SHA-256), and encrypt the *HASH* with the private key. The recipient reads the data and encrypted hash. He then decrypts the hash with the public key, compares it to the hash of the data. If the two hashes match, the data is authentic. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of ???? Sent: Friday, September 25, 2015 3:52 AM To: openssl-users Subject: [openssl-users] How can i verify a signature without knowing the private key? not by openssl command but openssl function. Hi guys i want to write two programd to learn the details of ecdsa signature. program A read the private key from private.pem, sign a string, like "abcde1234", save the signature as sig.pem. program B read the public key from pub.pem, read the sig.pem, and verify the signature. can anybody provide me a example code? my implementation is as follow: 1, generate the ecc keys by "openssl ecparam -genkey -name secp256r1 -out private.pem" and extract the public key by "openssl ec -in private.pem -out public.pem -pubout" 2, read the private key by "PEM_read_PrivateKey()", and sign with "ECDSA_do_sign", there is no problem. program A works well. 3, the problem is how to read the public key from public.pem ? i find PEM_read_bio_PUBKEY from app/apps.c, but i can't find the source code. how can i verify the signature without knowing the private key? -------------- next part -------------- An HTML attachment was scrubbed... URL: From buba at luna-78.com Fri Sep 25 19:37:26 2015 From: buba at luna-78.com (Bubnov Dmitriy) Date: Fri, 25 Sep 2015 22:37:26 +0300 Subject: [openssl-users] Browsers SSL handshake issues with https://wiki.openssl.org Message-ID: <9AE36745-AD26-4AF6-8130-5AB8F68A47E9@luna-78.com> Hello, All. I have met an issue with different browsers behavior when opening a link https://wiki.openssl.org/. Investigations shows that it is SSL handshake issues. Is it possible to correct situation for Safari browser? Below is 'ssldump's and 'openssl version -a' logs. >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> osx10.6.8 + chrome 45.0.2454.101; SSL session is OK >>> New TCP connection #1: 192.168.0.1(59718) <-> 194.97.150.234(443) 1 1 0.0506 (0.0506) C>S V3.1(512) Handshake ClientHello Version 3.3 random[32]= d2 e1 13 ee 12 ed 4a cd 48 ab 9a 84 89 5e 68 65 6c 74 d1 47 16 b6 a8 59 20 78 1e 73 1c 29 08 40 resume [32]= 96 63 75 db a1 7d 41 71 5c 80 22 ae b0 2f 5d 8e 3c fc e8 0a d3 1d 0e 16 ea 17 17 de 30 29 f1 6d cipher suites Unknown value 0xcc14 Unknown value 0xcc13 Unknown value 0xcc15 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_EMPTY_RENEGOTIATION_INFO_SCSV compression methods NULL 1 2 0.1002 (0.0496) S>C V3.3(81) Handshake ServerHello Version 3.3 random[32]= 25 b5 71 fa 69 9c 64 26 91 48 e5 c1 6f 07 6c 4b 12 b7 22 a6 20 e6 fb 6d 80 00 dd a1 99 43 70 dc session_id[32]= 96 63 75 db a1 7d 41 71 5c 80 22 ae b0 2f 5d 8e 3c fc e8 0a d3 1d 0e 16 ea 17 17 de 30 29 f1 6d cipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 compressionMethod NULL 1 3 0.1002 (0.0000) S>C V3.3(1) ChangeCipherSpec 1 4 0.1002 (0.0000) S>C V3.3(40) Handshake 1 5 0.1017 (0.0014) C>S V3.3(1) ChangeCipherSpec 1 6 0.1017 (0.0000) C>S V3.3(40) Handshake 1 7 0.1024 (0.0006) C>S V3.3(521) application_data 1 8 0.2268 (0.1244) S>C V3.3(299) application_data 1 9 4.0905 (3.8636) C>S V3.3(426) application_data 1 10 4.1691 (0.0786) S>C V3.3(598) application_data 1 11 4.1737 (0.0046) C>S V3.3(495) application_data 1 12 4.2673 (0.0935) S>C V3.3(298) application_data 1 9.2750 (5.0077) S>C TCP FIN 1 14.2687 (4.9936) C>S TCP FIN >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> >>> osx10.6.8 safari5.1.10(6534.59.10); SSL session is BROKEN >>> New TCP connection #1: 192.168.0.1(59771) <-> 194.97.150.234(443) 1 1 0.0598 (0.0598) C>S V3.1(158) Handshake ClientHello Version 3.1 random[32]= 56 05 6d 21 f6 ef c5 31 be 10 7d ef e8 b4 78 cf a5 47 61 7a 23 42 29 30 a2 6e c3 dc e3 0f 67 4b cipher suites TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_ECDSA_WITH_RC4_128_SHA TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_RC4_128_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_RC4_128_SHA TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_RC4_128_SHA TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA TLS_RSA_EXPORT_WITH_RC4_40_MD5 TLS_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5 TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_DES_CBC_SHA TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_DES_CBC_SHA TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA compression methods NULL 1 0.1143 (0.0545) S>C TCP FIN 1 0.1158 (0.0014) C>S TCP FIN New TCP connection #2: 192.168.0.1(59773) <-> 194.97.150.234(443) 2 1 0.0569 (0.0569) C>S V3.0(81) Handshake ClientHello Version 3.0 random[32]= 56 05 6d 21 d2 ca b5 6f 97 90 79 52 f9 c6 af 40 20 77 73 28 de 7d 60 48 c0 58 fc d8 a8 df 9d d0 cipher suites SSL_RSA_WITH_AES_128_CBC_SHA SSL_RSA_WITH_RC4_128_SHA SSL_RSA_WITH_RC4_128_MD5 SSL_RSA_WITH_AES_256_CBC_SHA SSL_RSA_WITH_3DES_EDE_CBC_SHA SSL_RSA_WITH_DES_CBC_SHA SSL_RSA_EXPORT_WITH_RC4_40_MD5 SSL_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 SSL_DHE_DSS_WITH_AES_128_CBC_SHA SSL_DHE_RSA_WITH_AES_128_CBC_SHA SSL_DHE_DSS_WITH_AES_256_CBC_SHA SSL_DHE_RSA_WITH_AES_256_CBC_SHA SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA SSL_DHE_RSA_WITH_DES_CBC_SHA SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA SSL_DHE_DSS_WITH_DES_CBC_SHA SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA compression methods NULL 2 0.1077 (0.0507) S>C TCP FIN 2 0.1094 (0.0017) C>S TCP FIN >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> $ openssl version -a OpenSSL 1.0.1 14 Mar 2012 built on: Sun Mar 25 19:01:41 MSK 2012 platform: darwin64-x86_64-cc options: bn(64,64) rc4(ptr,char) des(idx,cisc,16,int) idea(int) blowfish(idx) compiler: /usr/bin/llvm-gcc-4.2 -fPIC -fno-common -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -arch x86_64 -O3 -DL_ENDIAN -Wall OPENSSLDIR: "/opt/local/etc/openssl" -- ? ????????????Mit freundlichen Gr??en???Best regards, Dmitriy Bubnov From neil.carter at oracle.com Fri Sep 25 21:28:05 2015 From: neil.carter at oracle.com (neil carter) Date: Fri, 25 Sep 2015 16:28:05 -0500 Subject: [openssl-users] openssl-users Digest, Vol 10, Issue 19 (lib4758cca.bad In-Reply-To: References: Message-ID: <5605BC65.7000602@oracle.com> I guess I missed that. Works perfectly now! Thanks, Viktor!! Neil On 9/25/2015 2:45 PM, openssl-users-request at openssl.org wrote: > Send openssl-users mailing list submissions to > openssl-users at openssl.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mta.openssl.org/mailman/listinfo/openssl-users > or, via email, send a message with subject or body 'help' to > openssl-users-request at openssl.org > > You can reach the person managing the list at > openssl-users-owner at openssl.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of openssl-users digest..." > > > Today's Topics: > > 1. Re: lib4758cca.bad (Viktor Dukhovni) > 2. How can i verify a signature without knowing the private key? > not by openssl command but openssl function. > (=?gb18030?B?1qrstvTDvLo=?=) > 3. Re: How can i verify a signature without knowing the private > key? not by openssl command but openssl function. (Scott Neugroschl) > 4. Re: How can i verify a signature without knowing the private > key? not by openssl command but openssl function. (Scott Neugroschl) > 5. Browsers SSL handshake issues with https://wiki.openssl.org > (Bubnov Dmitriy) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 24 Sep 2015 19:52:49 +0000 > From: Viktor Dukhovni > To: openssl-users at openssl.org > Subject: Re: [openssl-users] lib4758cca.bad > Message-ID: <20150924195249.GR21942 at mournblade.imrryr.org> > Content-Type: text/plain; charset=us-ascii > > On Thu, Sep 24, 2015 at 12:50:43PM -0500, neil carter wrote: > >> I just completed compiling the openssl-1.0.2d bundle on 64-bit linux (OEL >> 5.8). I say completed, but I cheated somewhat. >> >> steps: >> >> ./config --prefix=/usr/local shared no-dso >> make >> make install >> >> When I ran the 'make install' the first time, it failed at the 4758cca >> section with several errors about all of the lib* files in the engines >> sub-directory. > When you disable dynamic shared objects, you also need to disable > engine support. > > Try: > > ./config --prefix=/usr/local shared no-dso no-engine > make depend > make > > (Building with no-engine does not seem to work on the "master" > branch just now, but works for me with 1.0.2 from git, have not > tried 1.0.2d). > -------------- next part -------------- An HTML attachment was scrubbed... URL: From foleyj at cisco.com Mon Sep 28 13:13:55 2015 From: foleyj at cisco.com (John Foley) Date: Mon, 28 Sep 2015 09:13:55 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <5602981A.60107@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> Message-ID: <56093D13.8050305@cisco.com> On 09/23/2015 08:16 AM, Steve Marquess wrote: > John, let me elaborate on my comment above by noting that the Cisco > contribution includes a bunch of FIPS specific code for which there is > no counterpart on the master branch (i.e. no place to put it). A > version which worked on master with all the FIPS stuff stripped out > and with tests via evp_test would be a lot more interesting. -Steve M. Hi Steve, We can certainly submit a pull request on the master branch. It'll take a little time to prepare that. IMHO, there is value in accepting this pull request on the FIPS branch as well. There are OpenSSL users doing private label FIPS validations that would benefit. Pull request 368 contains the FIPS vector processing utility for KDF. None of the FIPS vector processing utilities reside in master. The pull request we prepare for master isn't going to include the KDF vector processing utility. Please let me know whether we should proceed with preparing a pull request on master. Thanks, John From marquess at openssl.com Mon Sep 28 14:17:24 2015 From: marquess at openssl.com (Steve Marquess) Date: Mon, 28 Sep 2015 10:17:24 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <56093D13.8050305@cisco.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> Message-ID: <56094BF4.30906@openssl.com> On 09/28/2015 09:13 AM, John Foley wrote: > On 09/23/2015 08:16 AM, Steve Marquess wrote: >> John, let me elaborate on my comment above by noting that the Cisco >> contribution includes a bunch of FIPS specific code for which there is >> no counterpart on the master branch (i.e. no place to put it). A >> version which worked on master with all the FIPS stuff stripped out >> and with tests via evp_test would be a lot more interesting. -Steve M. > Hi Steve, > > We can certainly submit a pull request on the master branch. It'll take > a little time to prepare that. IMHO, there is value in accepting this > pull request on the FIPS branch as well. There are OpenSSL users doing > private label FIPS validations that would benefit. Sure, value for the very small number of vendors with pockets deep enough to pursue their own proprietary validations that will benefit no one else. We're an open source organization with limited resources. We want to apply those resources effectively to benefit the greater community. Even though FIPS 140-2 is of significant interest to only part of the U.S. market, and of minimal interest to the rest of the world, the open source based validations see enough use[*] to justify the significant effort those consume. We can't justify that impact for a handful of U.S. vendors. Then there is the issue of code "ownership". We have dropped code for platforms we can't access and test ourselves. The real "test" for FIPS related code is whether the validation bureaucracy will approve it, and we know from long experience that we can't assume said approval; the "interop" test is a validation certificate. If we accept outside contributions of FIPS related code we'll have no way of knowing if that code will actually satisfy any particular attempt at validation. Your response to that will be that you'll only give us code that *you* have successfully validated, in a module that only you can use, but again we know from long experience that the exact same module can be submitted multiple times with very different results. Your successful private closed source validation is of minimal use to anyone else. An open source based validation, that everyone can use either directly or as the basis for copycat "private label" validations, is the correct answer. I see no benefit to us or the vast majority of our user base in committing speculative code that we can't verify and that most of our users can't use. > Pull request 368 > contains the FIPS vector processing utility for KDF. None of the FIPS > vector processing utilities reside in master. The pull request we > prepare for master isn't going to include the KDF vector processing utility. > > Please let me know whether we should proceed with preparing a pull > request on master. If it doesn't have any FIPS dependencies and is useful for the overall OpenSSL community outside of any FIPS context, sure. Thanks, -Steve M. [*] Many hundreds of vendors, most but not all small companies you never heard of. Those are the ones who use the #1747 validation directly, still more do copycat validations. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From openssl-users at dukhovni.org Tue Sep 29 14:43:35 2015 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 29 Sep 2015 14:43:35 +0000 Subject: [openssl-users] [openssl.org #4060] AutoReply: a crash happened inside SSL_Connect function In-Reply-To: References: <560A4AC2.8080309@openssl.org> Message-ID: <20150929144335.GA21942@mournblade.imrryr.org> On Tue, Sep 29, 2015 at 01:56:06PM +0000, Tiantian Liu via RT wrote: > Hi Matt & Vi > > I tried the SSLv23_method(), and precluded/excluded all SSLv2, SSLv3, TLSv1. I only enabled the TLSv1.2 by SSL_CTX_set_option(). > You can see my previous code: Why are you disabling TLSv1, there's little reason to do that at present. If the server supports TLS 1.2 you'll use that, otherwise you'll at least get TLS 1.0 > /*Only allow TLSv1.2 protocol*/ > SSL_CTX_set_options(ctx, SSL_OP_ALL | SSL_OP_NO_SSLv2 | SSL_OP_NO_SSLv3 | SSL_OP_NO_TLSv1); I would not disable TLSv1 at this time, just SSLv2 and SSLv3. > While the above code didn't work. I couldn't reach the server. Though the SSL_connect() didn't crash, it returned as: > > 17:49:12.939 [5499]- SSL_connect res : -1 And did you print the error stack? Look at a PCAP trace with wireshark? Connect to the server with "openssl s_client" and examine the negotiated protocol parameters? > I will continue to investigate, and keep updating the ticket. I > will adopt your idea to see if I can obtain more information during > crash. This thread does not belong on openssl-dev, cross-posting and redirecting to openssl-users. -- Viktor. From jb-openssl at wisemo.com Wed Sep 30 07:50:13 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 09:50:13 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <56094BF4.30906@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> Message-ID: <560B9435.5010501@wisemo.com> Dear Steve, Have you considered that their contribution may be of value to the next/future major version of the open source FIPS module (which would presumably involve a fresh submission under updated FIPS validation rules). This would obviously be a different code branch from maintenance/change letter updates to the current module. On 28/09/2015 16:17, Steve Marquess wrote: > On 09/28/2015 09:13 AM, John Foley wrote: >> On 09/23/2015 08:16 AM, Steve Marquess wrote: >>> John, let me elaborate on my comment above by noting that the Cisco >>> contribution includes a bunch of FIPS specific code for which there is >>> no counterpart on the master branch (i.e. no place to put it). A >>> version which worked on master with all the FIPS stuff stripped out >>> and with tests via evp_test would be a lot more interesting. -Steve M. >> Hi Steve, >> >> We can certainly submit a pull request on the master branch. It'll take >> a little time to prepare that. IMHO, there is value in accepting this >> pull request on the FIPS branch as well. There are OpenSSL users doing >> private label FIPS validations that would benefit. > Sure, value for the very small number of vendors with pockets deep > enough to pursue their own proprietary validations that will benefit no > one else. > > We're an open source organization with limited resources. We want to > apply those resources effectively to benefit the greater community. Even > though FIPS 140-2 is of significant interest to only part of the U.S. > market, and of minimal interest to the rest of the world, the open > source based validations see enough use[*] to justify the significant > effort those consume. We can't justify that impact for a handful of U.S. > vendors. > > Then there is the issue of code "ownership". We have dropped code for > platforms we can't access and test ourselves. The real "test" for FIPS > related code is whether the validation bureaucracy will approve it, and > we know from long experience that we can't assume said approval; the > "interop" test is a validation certificate. If we accept outside > contributions of FIPS related code we'll have no way of knowing if that > code will actually satisfy any particular attempt at validation. Your > response to that will be that you'll only give us code that *you* have > successfully validated, in a module that only you can use, but again we > know from long experience that the exact same module can be submitted > multiple times with very different results. Your successful private > closed source validation is of minimal use to anyone else. > > An open source based validation, that everyone can use either directly > or as the basis for copycat "private label" validations, is the correct > answer. I see no benefit to us or the vast majority of our user base in > committing speculative code that we can't verify and that most of our > users can't use. > >> Pull request 368 >> contains the FIPS vector processing utility for KDF. None of the FIPS >> vector processing utilities reside in master. The pull request we >> prepare for master isn't going to include the KDF vector processing utility. >> >> Please let me know whether we should proceed with preparing a pull >> request on master. > If it doesn't have any FIPS dependencies and is useful for the overall > OpenSSL community outside of any FIPS context, sure. > > Thanks, > > -Steve M. > > [*] Many hundreds of vendors, most but not all small companies you never > heard of. Those are the ones who use the #1747 validation directly, > still more do copycat validations. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From marquess at openssl.com Wed Sep 30 12:28:33 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 30 Sep 2015 08:28:33 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560B9435.5010501@wisemo.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> Message-ID: <560BD571.40701@openssl.com> On 09/30/2015 03:50 AM, Jakob Bohm wrote: > Dear Steve, > > Have you considered that their contribution may be of value > to the next/future major version of the open source FIPS > module (which would presumably involve a fresh submission > under updated FIPS validation rules). > > This would obviously be a different code branch from > maintenance/change letter updates to the current module. We have indeed. As noted already that code will be of no value until we can actually run it through a validation ourselves. Our days of committing speculative code that "might come in handy someday" are behind us. We also have plans for a significant rewrite of the FIPS module from its current form, and it's unlikely any third party submissions would fit that vision. Of course any third party (Cisco for instance) is free to publish patches or even a compete open source FIPS module themselves, and deal with the inevitable onslaught of requests for support. I get those almost daily, usually in the form of "we're trying to do our own validation and need a little help...". -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Wed Sep 30 13:18:01 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 15:18:01 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BD571.40701@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> Message-ID: <560BE109.2020409@wisemo.com> On 30/09/2015 14:28, Steve Marquess wrote: > On 09/30/2015 03:50 AM, Jakob Bohm wrote: >> Dear Steve, >> >> Have you considered that their contribution may be of value >> to the next/future major version of the open source FIPS >> module (which would presumably involve a fresh submission >> under updated FIPS validation rules). >> >> This would obviously be a different code branch from >> maintenance/change letter updates to the current module. > We have indeed. As noted already that code will be of no value until we > can actually run it through a validation ourselves. Our days of > committing speculative code that "might come in handy someday" are > behind us. For branches expected to be promoted to release "eventually" (like the non-fips master branch) this is good policy. However it is also good policy to have, outside such branches, a place to gather up snippets (own or contributed) that might come handy some day, such as a constant time memcmp (before it became needed in a recent security patch) or an implementation of an SHA-3 candidate (before NIST selected the final SHA-3) etc. For an open source project, such unpolished unintegrated code could live in the bugtracker or in a special "experiments" git branch. The code in such a place would have the common characteristic of fully clarified licensing (PD, BSD, classic OpenSSL/SSLeay, foundation contributed, etc.), such that if/when the need arises, there is no need to track down and negotiate with the original contributor (think of pre-Oracle Sun contributions or pre-RSA EAY contributions). Under the new "contribution agreement" scheme, publishing such items early would also make them available to users even if the UK's GCHQ suddenly imposes draconian restrictions on the UK-based foundation, as it would make them legally available to continuation projects based in different jurisdictions, just as the original EAY-style licenses made the code available for continuation projects outside Australia. > > We also have plans for a significant rewrite of the FIPS module from its > current form, and it's unlikely any third party submissions would fit > that vision. Interesting, I wonder if those plans include my previously posted ideas: - Having the FIPS module contain no direct system calls, only callbacks to its client. This would mean one FIPS blob per instruction set, not one per target platform. (Bureaucracy would still require enumeration of platform environments, but the change to add a new environment for the same instruction set would consist only of adding it to the list, no changes to policy or code). - Having the FIPS module be position independent, such that the integrity hash becomes immune to ASLR. - Having the FIPS blob be application independent, such that the correct integrity hash can be determined at FIPS module build time without using special application link steps. - Including the FIPS blob hash for known good compilers in the policy document, while still having the compilation-proven correspondence to source. > Of course any third party (Cisco for instance) is free to publish > patches or even a compete open source FIPS module themselves, and deal > with the inevitable onslaught of requests for support. I get those > almost daily, usually in the form of "we're trying to do our own > validation and need a little help...". > > -Steve M. > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Sep 30 13:34:39 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 30 Sep 2015 09:34:39 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BE109.2020409@wisemo.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> Message-ID: <560BE4EF.5010207@openssl.com> On 09/30/2015 09:18 AM, Jakob Bohm wrote: >... > > Under the new "contribution agreement" scheme, publishing such items > early would also make them available to users ... Publishing by someone else is fine, go for it. It would be nice to have someone else publish FIPS module code, or validation information of any kind for that matter. I think the validation process would be a lot less capricious with less of the secrecy that is the current norm. Anything we (OpenSSL) publish carries with it an implied support obligation, and that's the key problem with FIPS specific code: it can't be "verified" in any meaningful sense other than with an official formal FIPS 140-2 validation. The FIPS 140-2 requirements are more metaphysical and ideological than technical, and what's worse those requirements are applied very subjectively. By that I mean that on multiple occasions I've had the experience of taking very similar or even precisely identical code through parallel validations, with different end results. The presence of FIPS specific code in an OpenSSL repo would imply some sort of suitability for use with FIPS validations. No matter how many disclaimers and caveats we attached to that, there would still be vendors trying to use it to obtain validations and encountering problems. Guess who they're gonna call? That problem is avoided if we obtain an open source based validation -- one where the module is distributed in source code form -- that has been successfully validated. That validation then speaks for itself. >> ... >> We also have plans for a significant rewrite of the FIPS module >> from its current form, and it's unlikely any third party submissions >> would fit that vision. > > Interesting, I wonder if those plans include my previously > posted ideas: > ... There are some issues with those ideas, but now is not the time to get into details. We'll worry about it if and when we have an opportunity to do a new open source based validation. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Wed Sep 30 13:58:20 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 15:58:20 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BE4EF.5010207@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> Message-ID: <560BEA7C.5020300@wisemo.com> On 30/09/2015 15:34, Steve Marquess wrote: > On 09/30/2015 09:18 AM, Jakob Bohm wrote: >> ... >> >> Under the new "contribution agreement" scheme, publishing such items >> early would also make them available to users ... > Publishing by someone else is fine, go for it. It would be nice to have > someone else publish FIPS module code, or validation information of any > kind for that matter. I think the validation process would be a lot less > capricious with less of the secrecy that is the current norm. Point is that the contribution agreement contains a bug, whereby anything not published by the OpenSSL Foundation in the UK is not licensed to anyone. Having a publication procedure for things marked "This does NOT work in its current form, but we are giving you a license" works around that bug to the benefit of anyone recovering the project similar to how the original Australian project (SSLeay) was recovered by Dr. Henson in the UK as OpenSSL. > Anything we (OpenSSL) publish carries with it an implied support > obligation, and that's the key problem with FIPS specific code: it can't > be "verified" in any meaningful sense other than with an official formal > FIPS 140-2 validation. The FIPS 140-2 requirements are more metaphysical > and ideological than technical, and what's worse those requirements are > applied very subjectively. By that I mean that on multiple occasions > I've had the experience of taking very similar or even precisely > identical code through parallel validations, with different end results. > > The presence of FIPS specific code in an OpenSSL repo would imply some > sort of suitability for use with FIPS validations. No matter how many > disclaimers and caveats we attached to that, there would still be > vendors trying to use it to obtain validations and encountering > problems. Guess who they're gonna call? > > That problem is avoided if we obtain an open source based validation -- > one where the module is distributed in source code form -- that has been > successfully validated. That validation then speaks for itself. > >>> ... >>> We also have plans for a significant rewrite of the FIPS module >>> from its current form, and it's unlikely any third party submissions >>> would fit that vision. >> Interesting, I wonder if those plans include my previously >> posted ideas: >> ... > There are some issues with those ideas, but now is not the time to get > into details. We'll worry about it if and when we have an opportunity to > do a new open source based validation. Agreed, just making sure they were posted somewhere you could find them when the time comes. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From marquess at openssl.com Wed Sep 30 14:17:22 2015 From: marquess at openssl.com (Steve Marquess) Date: Wed, 30 Sep 2015 10:17:22 -0400 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BEA7C.5020300@wisemo.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> Message-ID: <560BEEF2.5030803@openssl.com> On 09/30/2015 09:58 AM, Jakob Bohm wrote: > On 30/09/2015 15:34, Steve Marquess wrote: >> On 09/30/2015 09:18 AM, Jakob Bohm wrote: >>> ... >>> >>> Under the new "contribution agreement" scheme, publishing such items >>> early would also make them available to users ... >> Publishing by someone else is fine, go for it. It would be nice to have >> someone else publish FIPS module code, or validation information of any >> kind for that matter. I think the validation process would be a lot less >> capricious with less of the secrecy that is the current norm. > > Point is that the contribution agreement contains a bug, whereby > anything not published by the OpenSSL Foundation in the UK is not > licensed to anyone. > > Having a publication procedure for things marked "This does NOT > work in its current form, but we are giving you a license" works > around that bug ... Speaking just for myself, and not my fellow team mates, I see no upside and a lot of downsides to our hosting of "does not work" code contributions. Especially for FIPS specific code. The originators of that code are free to give it to anyone else at any time; they don't need us to do so. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0x6D1892F5.asc From jb-openssl at wisemo.com Wed Sep 30 14:31:22 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 16:31:22 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BEEF2.5030803@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> <560BEEF2.5030803@openssl.com> Message-ID: <560BF23A.5030209@wisemo.com> On 30/09/2015 16:17, Steve Marquess wrote: > On 09/30/2015 09:58 AM, Jakob Bohm wrote: >> On 30/09/2015 15:34, Steve Marquess wrote: >>> On 09/30/2015 09:18 AM, Jakob Bohm wrote: >>>> ... >>>> >>>> Under the new "contribution agreement" scheme, publishing such items >>>> early would also make them available to users ... >>> Publishing by someone else is fine, go for it. It would be nice to have >>> someone else publish FIPS module code, or validation information of any >>> kind for that matter. I think the validation process would be a lot less >>> capricious with less of the secrecy that is the current norm. >> Point is that the contribution agreement contains a bug, whereby >> anything not published by the OpenSSL Foundation in the UK is not >> licensed to anyone. >> >> Having a publication procedure for things marked "This does NOT >> work in its current form, but we are giving you a license" works >> around that bug ... > Speaking just for myself, and not my fellow team mates, I see no upside > and a lot of downsides to our hosting of "does not work" code > contributions. Especially for FIPS specific code. The originators of > that code are free to give it to anyone else at any time; they don't > need us to do so. This is why I mentioned the historic contributions from Sun and Eay: They may be unable or unwilling to repeat the donation at a later date when it is actually needed. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 30 16:57:54 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 16:57:54 +0000 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560BEEF2.5030803@openssl.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> <560BEEF2.5030803@openssl.com> Message-ID: <5e4b2aa6f3c24354ac4ce87a713b0182@ustx2ex-dag1mb3.msg.corp.akamai.com> > Speaking just for myself, and not my fellow team mates, I see no upside and > a lot of downsides to our hosting of "does not work" code contributions. > Especially for FIPS specific code. The originators of that code are free to give > it to anyone else at any time; they don't need us to do so. Totally agree. Creating a downstream repo on GitHub (er, I mean a fork) is incredibly trivial to handle. Even I can do it :) And folks on the dev team will appreciate that, having suffered through all my naivete and errors. -- Senior Architect, Akamai Technologies IM: richsalz at jabber.at Twitter: RichSalz From jb-openssl at wisemo.com Wed Sep 30 17:17:33 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 19:17:33 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <5e4b2aa6f3c24354ac4ce87a713b0182@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> <560BEEF2.5030803@openssl.com> <5e4b2aa6f3c24354ac4ce87a713b0182@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <560C192D.6030300@wisemo.com> On 30/09/2015 18:57, Salz, Rich wrote: >> Speaking just for myself, and not my fellow team mates, I see no upside and >> a lot of downsides to our hosting of "does not work" code contributions. >> Especially for FIPS specific code. The originators of that code are free to give >> it to anyone else at any time; they don't need us to do so. > Totally agree. Creating a downstream repo on GitHub (er, I mean a fork) is incredibly trivial to handle. Even I can do it :) > And folks on the dev team will appreciate that, having suffered through all my naivete and errors. Did you miss the detail about the contribution agreement not granting any rights to third parties until the OpenSSL Foundation has "published" the contribution. In other words, if the only license provided in the Pull request is "this is a contribution", then there is no license for making that downstream repo. Also, isn't GitHub located in the country crypto folk always try to avoid for legal reasons? Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Sep 30 17:36:50 2015 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 30 Sep 2015 17:36:50 +0000 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <560C192D.6030300@wisemo.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> <560BEEF2.5030803@openssl.com> <5e4b2aa6f3c24354ac4ce87a713b0182@ustx2ex-dag1mb3.msg.corp.akamai.com> <560C192D.6030300@wisemo.com> Message-ID: <9f4702aca30e460c9235d7842eb27d4f@ustx2ex-dag1mb3.msg.corp.akamai.com> >Did you miss the detail about the contribution agreement not granting any rights to third parties until the OpenSSL Foundation has "published" the contribution. No I didn't. They are free to post code as apache 2 and frequently rebase against master. Or whatever they want. We don't have the resources, or interests, to be a general code repository for "related to openssl" things (any more). > In other words, if the only license provided in the Pull request is "this is a contribution", then there is no license for making that downstream repo. Then they will have to be careful and precise about how the licensed it. Same as if openssl were doing it. > Also, isn't GitHub located in the country crypto folk always try to avoid for legal reasons? Which one, there are so many of them these days :( It's a good point; perhaps you can host a repo? Denmark is relatively right-thinking on this issue. /r$ From jb-openssl at wisemo.com Wed Sep 30 17:45:37 2015 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 30 Sep 2015 19:45:37 +0200 Subject: [openssl-users] Key Deriviation Function Tests for TLS In-Reply-To: <9f4702aca30e460c9235d7842eb27d4f@ustx2ex-dag1mb3.msg.corp.akamai.com> References: <000f4249.20aa96261ea06347@cisco.com> <56028864.1030601@openssl.com> <5602981A.60107@openssl.com> <56093D13.8050305@cisco.com> <56094BF4.30906@openssl.com> <560B9435.5010501@wisemo.com> <560BD571.40701@openssl.com> <560BE109.2020409@wisemo.com> <560BE4EF.5010207@openssl.com> <560BEA7C.5020300@wisemo.com> <560BEEF2.5030803@openssl.com> <5e4b2aa6f3c24354ac4ce87a713b0182@ustx2ex-dag1mb3.msg.corp.akamai.com> <560C192D.6030300@wisemo.com> <9f4702aca30e460c9235d7842eb27d4f@ustx2ex-dag1mb3.msg.corp.akamai.com> Message-ID: <560C1FC1.9050200@wisemo.com> On 30/09/2015 19:36, Salz, Rich wrote: >> Did you miss the detail about the contribution agreement not granting any rights to third parties until the OpenSSL Foundation has "published" the contribution. > No I didn't. They are free to post code as apache 2 and frequently rebase against master. Or whatever they want. We don't have the resources, or interests, to be a general code repository for "related to openssl" things (any more). > >> In other words, if the only license provided in the Pull request is "this is a contribution", then there is no license for making that downstream repo. > Then they will have to be careful and precise about how the licensed it. Same as if openssl were doing it. > >> Also, isn't GitHub located in the country crypto folk always try to avoid for legal reasons? > Which one, there are so many of them these days :( It's a good point; perhaps you can host a repo? Denmark is relatively right-thinking on this issue. Unfortunately, that would be problematic due to potentially conflicting legal obligations. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded -------------- next part -------------- An HTML attachment was scrubbed... URL: