From minfrin at sharp.fm Fri Aug 2 12:21:06 2019 From: minfrin at sharp.fm (Graham Leggett) Date: Fri, 2 Aug 2019 14:21:06 +0200 Subject: During client cert verification: RSA_padding_check_PKCS1_type_1:block type is not 01 Message-ID: Hi all, I have a WIndows 10 system with a smartcard attached to it. Firefox+Smartcard works great. Edge using the smartcard to the same site returns the following: [Fri Aug 02 13:47:43.238262 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 [Fri Aug 02 13:47:43.238306 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed [Fri Aug 02 13:47:43.238356 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad signature What is the above trying to tell me? Am I right in assuming that Edge is trying to use the wrong cert with the wrong key? Regards, Graham ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3260 bytes Desc: not available URL: From Michael.Wojcik at microfocus.com Fri Aug 2 14:00:59 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Fri, 2 Aug 2019 14:00:59 +0000 Subject: bug in ghash-x86_64.pl for non-AVX assemblers? Message-ID: I'm trying to build 1.1.1b on an old RHEL 5.5 machine (for reasons too tiresome to explain). It has a rather ancient version of the Gnu assembler, 2.17.50, which ghash-x86_64.pl decides means it doesn't have AVX support. (The script looks for 2.20 or later, basically. I assume that's correct.) The problem is that it generates invalid assembly when AVX isn't available. The output from the assembler is: ----- crypto/modes/ghash-x86_64.s: Assembler messages: crypto/modes/ghash-x86_64.s:1311: Error: previous CFI entry not closed (missing .cfi_endproc) crypto/modes/ghash-x86_64.s:1374: Error: open CFI at the end of file; missing .cfi_endproc directive ----- Looking at ghash-x86_64.s, I can see that indeed there's no .cfi_endproc before line 1311. gcm_init_avx is missing its endproc. And looking at the script, the reason seems obvious, unless I'm missing something: ----- $code.=<<___; .globl gcm_init_avx .type gcm_init_avx,\@abi-omnipotent .align 32 gcm_init_avx: .cfi_startproc ___ if ($avx) { ... $code.=<<___; ret .cfi_endproc .size gcm_init_avx,.-gcm_init_avx ___ } else { $code.=<<___; jmp .L_init_clmul .size gcm_init_avx,.-gcm_init_avx ___ } ---- There's a .cfi_endproc in the here-doc on the if ($avx) branch, but none in the here-doc on the else branch. So if the assembler doesn't have AVX support, the script doesn't emit the .cfi_endproc directive. Same thing with gcm_ghash_avx. Is this a bug in ghash-x86_64.pl, or am I misinterpreting? I've just started looking at this, so apologies if it's a known issue that's already been fixed in a later release or on the master. Thanks, Michael Wojcik Distinguished Engineer, Micro Focus From levitte at openssl.org Fri Aug 2 16:06:55 2019 From: levitte at openssl.org (Richard Levitte) Date: Fri, 02 Aug 2019 18:06:55 +0200 Subject: bug in ghash-x86_64.pl for non-AVX assemblers? In-Reply-To: References: Message-ID: <14A1B012-8BAA-48FE-A762-0D54A24DEDAB@openssl.org> This bug was found a couple of days after 1.1.1b was released. The fix us found in commit dbb1340314fcec37662d79720e6566fdd5a232e8 The best thing you can do is to update your source to 1.1.1c, which has this fix and more. Cheers Richard Michael Wojcik skrev: (2 augusti 2019 16:00:59 CEST) >I'm trying to build 1.1.1b on an old RHEL 5.5 machine (for reasons too >tiresome to explain). It has a rather ancient version of the Gnu >assembler, 2.17.50, which ghash-x86_64.pl decides means it doesn't have >AVX support. (The script looks for 2.20 or later, basically. I assume >that's correct.) > >The problem is that it generates invalid assembly when AVX isn't >available. The output from the assembler is: > >----- >crypto/modes/ghash-x86_64.s: Assembler messages: >crypto/modes/ghash-x86_64.s:1311: Error: previous CFI entry not closed >(missing .cfi_endproc) >crypto/modes/ghash-x86_64.s:1374: Error: open CFI at the end of file; >missing .cfi_endproc directive >----- > >Looking at ghash-x86_64.s, I can see that indeed there's no >.cfi_endproc before line 1311. gcm_init_avx is missing its endproc. And >looking at the script, the reason seems obvious, unless I'm missing >something: > >----- >$code.=<<___; >.globl gcm_init_avx >.type gcm_init_avx,\@abi-omnipotent >.align 32 >gcm_init_avx: >.cfi_startproc >___ >if ($avx) { >... >$code.=<<___; > ret >.cfi_endproc >.size gcm_init_avx,.-gcm_init_avx >___ >} else { >$code.=<<___; > jmp .L_init_clmul >.size gcm_init_avx,.-gcm_init_avx >___ >} >---- > >There's a .cfi_endproc in the here-doc on the if ($avx) branch, but >none in the here-doc on the else branch. So if the assembler doesn't >have AVX support, the script doesn't emit the .cfi_endproc directive. > >Same thing with gcm_ghash_avx. > >Is this a bug in ghash-x86_64.pl, or am I misinterpreting? > >I've just started looking at this, so apologies if it's a known issue >that's already been fixed in a later release or on the master. > >Thanks, >Michael Wojcik >Distinguished Engineer, Micro Focus -- Richard by mobile From pdrotter at us.ibm.com Fri Aug 2 17:24:57 2019 From: pdrotter at us.ibm.com (Neptune) Date: Fri, 2 Aug 2019 10:24:57 -0700 (MST) Subject: 1.0.2 to 1.1 migration problem with verify_callback() Message-ID: <1564766697509-0.post@n7.nabble.com> I am in the process of migrating our code from the 1.0.2 library to 1.1 and have run across a situation that I am struggling to reconcile: The existing code utilizes the verify_callback() function in order to perform validation measures against a peer certificate. This callback performs validation such as checking the certificate against a CRL and doing wildcard matching. The reason we need to define our own callback and validation code is because, as I understand it, the built-in OpenSSL wildcard matching will only process one wildcard field prefix (*.domain.com) whereas our requirements allow for wildcard patterns beyond just a prefix (FOO.*.domain.com, FOO.B*R.domain.com, etc.). The problem arises when I attempt to access 'ssl->tlsext_hostname' which is understood because this structure is now opaque. I believe the accessor function for this is '__owur const char *SSL_SESSION_get0_hostname(const SSL_SESSION *s);' in ssl.h. However, within the context of the callback function I only have two arguments to work with: int verify_callback(int ok, X509_STORE_CTX *ctx) This does not provide me with a SSL_SESSION object to pass into the SSL_SESSION_get0_hostname accessor function, so... 1. Is SSL_SESSION_get0_hostname() the right accessor for this data? 2. If so, how can I call SSL_SESSION_get0_hostname() within verify_callback() without a SSL_SESSION object? 3. Has the validation code for the 1.1 (and future) branches been changed so that I would no longer need to define my own validation code? (He asks hopefully) Thanks in advance for your help. -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From deepak.redmi2 at gmail.com Fri Aug 2 17:05:47 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Fri, 2 Aug 2019 22:35:47 +0530 Subject: FIPS_mod_set() fails with reason 111 (Do_Dsa_Sign()) Message-ID: Hi, Can anyone help me with following? 1) Calling FIPS_mode_set() from inside a DLL just after SSL_library_init() fails with [error:2D06B06F:lib(45):func(107):reason(111)] 2) This DLL links to a] static libraries (libeay, libssl, libcompat)from FIPS capable OpenSSL. b] static libcurl which is again prepared using above static FIPS capable OpenSSL c] Includes fips_premain.c and preprocessor directive of HMACSHA=checksum of itself 3)This is done in order to achieve FIPS compliance for a windows service which loads above DLL for all its communications. 4) What am I missing? 5) Do I need to rebase the DLL to an address as per fipslink.pl? If yes, what would be input linker parameters to fipslink.pl? Appreciate your input on this. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Sat Aug 3 16:58:20 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 3 Aug 2019 16:58:20 +0000 Subject: bug in ghash-x86_64.pl for non-AVX assemblers? In-Reply-To: <14A1B012-8BAA-48FE-A762-0D54A24DEDAB@openssl.org> References: <14A1B012-8BAA-48FE-A762-0D54A24DEDAB@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Richard Levitte > Sent: Friday, August 02, 2019 12:07 > To: openssl-users at openssl.org > Subject: Re: bug in ghash-x86_64.pl for non-AVX assemblers? > > This bug was found a couple of days after 1.1.1b was released. The fix us > found in commit dbb1340314fcec37662d79720e6566fdd5a232e8 > > The best thing you can do is to update your source to 1.1.1c, which has this > fix and more. Excellent. Many thanks. I think we hadn't picked up 1.1.1c yet because it was non-critical and we were close to a product release when it came out, but there's no reason not to move to it now. -- Michael Wojcik Distinguished Engineer, Micro Focus From openssl-users at dukhovni.org Sat Aug 3 23:56:17 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 3 Aug 2019 19:56:17 -0400 Subject: During client cert verification: RSA_padding_check_PKCS1_type_1:block type is not 01 In-Reply-To: References: Message-ID: <4501AECE-A29D-4EC1-8834-B57FDC7337F1@dukhovni.org> > On Aug 2, 2019, at 8:21 AM, Graham Leggett wrote: > > Edge using the smartcard to the same site returns the following: > > [Fri Aug 02 13:47:43.238262 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:0407006A:rsa routines:RSA_padding_check_PKCS1_type_1:block type is not 01 > [Fri Aug 02 13:47:43.238306 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:04067072:rsa routines:RSA_EAY_PUBLIC_DECRYPT:padding check failed > [Fri Aug 02 13:47:43.238356 2019] [ssl:info] [pid 20742:tid 139771397486336] SSL Library Error: error:1408807B:SSL routines:SSL3_GET_CERT_VERIFY:bad signature > > What is the above trying to tell me? > > Am I right in assuming that Edge is trying to use the wrong cert with the wrong key? An RSA signature verification operation (block type 01) failed, typically because the public used to check the signature does not match the private key used to sign the data. Is this a server-side log or a client-side log? If the client is using the wrong private key or wrong certificate, then I'd expect to see this type of error on the server. -- Viktor. From minfrin at sharp.fm Sun Aug 4 09:45:57 2019 From: minfrin at sharp.fm (Graham Leggett) Date: Sun, 4 Aug 2019 11:45:57 +0200 Subject: During client cert verification: RSA_padding_check_PKCS1_type_1:block type is not 01 In-Reply-To: <4501AECE-A29D-4EC1-8834-B57FDC7337F1@dukhovni.org> References: <4501AECE-A29D-4EC1-8834-B57FDC7337F1@dukhovni.org> Message-ID: On 04 Aug 2019, at 01:56, Viktor Dukhovni wrote: > An RSA signature verification operation (block type 01) failed, > typically because the public used to check the signature does > not match the private key used to sign the data. Thanks for confirming this. > Is this a server-side log or a client-side log? If the client is > using the wrong private key or wrong certificate, then I'd expect > to see this type of error on the server. It?s a server side log of httpd linked to openssl. I have a MyEID smartcard with two certs and two keys on it. When the smartcard is used with Firefox and the OpenSC PKCS11 drivers, everything works fine. When the smartcard is used with Windows 10 + Edge and the native manufacturer drivers, the wrong key is chosen for the certificate, and access is denied as above. Regards, Graham ? -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3260 bytes Desc: not available URL: From matt at openssl.org Mon Aug 5 14:40:09 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 5 Aug 2019 15:40:09 +0100 Subject: 1.0.2 to 1.1 migration problem with verify_callback() In-Reply-To: <1564766697509-0.post@n7.nabble.com> References: <1564766697509-0.post@n7.nabble.com> Message-ID: On 02/08/2019 18:24, Neptune wrote: > I am in the process of migrating our code from the 1.0.2 library to 1.1 and > have run across a situation that I am struggling to reconcile: > > The existing code utilizes the verify_callback() function in order to > perform validation measures against a peer certificate. This callback > performs validation such as checking the certificate against a CRL and doing > wildcard matching. The reason we need to define our own callback and > validation code is because, as I understand it, the built-in OpenSSL > wildcard matching will only process one wildcard field prefix (*.domain.com) > whereas our requirements allow for wildcard patterns beyond just a prefix > (FOO.*.domain.com, FOO.B*R.domain.com, etc.). > > The problem arises when I attempt to access 'ssl->tlsext_hostname' which is > understood because this structure is now opaque. I believe the accessor > function for this is '__owur const char *SSL_SESSION_get0_hostname(const > SSL_SESSION *s);' in ssl.h. However, within the context of the callback > function I only have two arguments to work with: > > int verify_callback(int ok, X509_STORE_CTX *ctx) > > This does not provide me with a SSL_SESSION object to pass into the > SSL_SESSION_get0_hostname accessor function, so... >From within your callback you can do this to get hold of the SSL object: SSL *s = (SSL *)X509_STORE_CTX_get_ex_data(ctx, SSL_get_ex_data_X509_STORE_CTX_idx()); And then this to get hold of the hostname requested: const char *hostname = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name); Hope that helps, Matt From dbcassara at gmail.com Mon Aug 5 15:51:12 2019 From: dbcassara at gmail.com (Dawn Cassara) Date: Mon, 5 Aug 2019 10:51:12 -0500 Subject: installation Message-ID: <5d48506f.1c69fb81.84e04.2256@mx.google.com> Where would I find the easiest, most descriptive and most comprehensive installation info for Windows 2012 r2 server? Sent from Mail for Windows 10 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dbcassara at gmail.com Mon Aug 5 21:53:45 2019 From: dbcassara at gmail.com (Dawn Cassara) Date: Mon, 5 Aug 2019 16:53:45 -0500 Subject: documentation on installation Message-ID: Where would I find the easiest, most comprehensive installation instructions for Windows 2012 r2? -- Dawn Cassara 832-224-6826 / 314-332-0279 Houston / St. Louis Reputation Management http://HoustonRepManagement.com http://StLouisRepManagement.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesm at mcn.org Mon Aug 5 22:07:56 2019 From: charlesm at mcn.org (Charles Mills) Date: Mon, 05 Aug 2019 18:07:56 -0400 Subject: documentation on installation In-Reply-To: Message-ID: <20190805221445.05FB9E4C78@mta.openssl.org> Perhaps not on an OpenSSL list?You might try stackoverflow.comCharlesSent from a mobile; please excuse the brevity. -------- Original message --------From: Dawn Cassara Date: 8/5/19 5:53 PM (GMT-05:00) To: openssl-users at openssl.org Subject: documentation on installation Where would I find the easiest, most comprehensive installation instructions for Windows 2012 r2?-- Dawn Cassara832-224-6826 / 314-332-0279Houston / St. Louis Reputation Management http://HoustonRepManagement.com http://StLouisRepManagement.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 6 08:40:58 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 09:40:58 +0100 Subject: documentation on installation In-Reply-To: References: Message-ID: On 05/08/2019 22:53, Dawn Cassara wrote: > Where would I find the easiest, most comprehensive installation instructions for > Windows 2012 r2? I assume you mean installation of OpenSSL on that platform! Installation instructions are here: https://github.com/openssl/openssl/blob/master/INSTALL With Windows specific notes here: https://github.com/openssl/openssl/blob/master/NOTES.WIN Matt From chitrang.srivastava at gmail.com Tue Aug 6 08:42:25 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Tue, 6 Aug 2019 14:12:25 +0530 Subject: SSL Server setup DH/ECDH Message-ID: Hi, I am implementing HTTPs server using openssl 1.1.1b. Is it mandatory to setup these API's while creating ssl context ? SSL_CTX_set_tmp_ecdh SSL_CTX_set_tmp_dh Also any suggestion what all options one should set while setting up server like SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 6 09:34:21 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 10:34:21 +0100 Subject: SSL Server setup DH/ECDH In-Reply-To: References: Message-ID: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> On 06/08/2019 09:42, Chitrang Srivastava wrote: > Hi, > > I am implementing HTTPs server using openssl 1.1.1b. > Is it mandatory to setup these API's while creating ssl context ? > > SSL_CTX_set_tmp_ecdh > > SSL_CTX_set_tmp_dh By default OpenSSL will automatically use ECDH if appropriate and choose a suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() unless you want more control over which specific group is used. OpenSSL will not use DH unless you specifically configure it. If you want to make use of DH based ciphersuites then you must either call SSL_CTX_set_tmp_dh() or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the former enables you to configure any arbitrary DH group that you choose. Calling the latter will enable the built-in DH groups. It is not mandatory to call any of the above. > > Also any suggestion what all options one should set while setting up server like > SSL_CTX_set_options like?SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 Don't use the protocol version specific options at all. Use SSL_CTX_set_min_proto_version() if you want to specify a minimum protocol version. SSLv2 is no longer supported at all. SSLv3 is compiled out by default. Other options that are worth considering are SSL_OP_NO_RENEGOTIATION and (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need the others unless there is a specific problem you are trying to solve. Matt From chitrang.srivastava at gmail.com Tue Aug 6 10:07:26 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Tue, 6 Aug 2019 15:37:26 +0530 Subject: SSL Server setup DH/ECDH In-Reply-To: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> Message-ID: Thanks Matt, So now I have, which i believe is enough ? SSL_CTX_set_options(s_ctx, SSL_OP_NO_RENEGOTIATION | SSL_OP_CIPHER_SERVER_PREFERENCE); SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell wrote: > > > On 06/08/2019 09:42, Chitrang Srivastava wrote: > > Hi, > > > > I am implementing HTTPs server using openssl 1.1.1b. > > Is it mandatory to setup these API's while creating ssl context ? > > > > SSL_CTX_set_tmp_ecdh > > > > SSL_CTX_set_tmp_dh > > By default OpenSSL will automatically use ECDH if appropriate and choose a > suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() unless > you > want more control over which specific group is used. > > OpenSSL will not use DH unless you specifically configure it. If you want > to > make use of DH based ciphersuites then you must either call > SSL_CTX_set_tmp_dh() > or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the former > enables > you to configure any arbitrary DH group that you choose. Calling the > latter will > enable the built-in DH groups. > > It is not mandatory to call any of the above. > > > > > Also any suggestion what all options one should set while setting up > server like > > SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 > > Don't use the protocol version specific options at all. Use > SSL_CTX_set_min_proto_version() if you want to specify a minimum protocol > version. SSLv2 is no longer supported at all. SSLv3 is compiled out by > default. > > Other options that are worth considering are SSL_OP_NO_RENEGOTIATION and > (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need the > others > unless there is a specific problem you are trying to solve. > > Matt > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 6 10:11:46 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 11:11:46 +0100 Subject: SSL Server setup DH/ECDH In-Reply-To: References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> Message-ID: <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> On 06/08/2019 11:07, Chitrang Srivastava wrote: > Thanks Matt, > > So now I have, which i believe is enough ? > > SSL_CTX_set_options(s_ctx, ?SSL_OP_NO_RENEGOTIATION | > SSL_OP_CIPHER_SERVER_PREFERENCE); > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); This is fine although it obviously prevents connections from very old clients that don't support TLSv1.2. This might not be a problem for you depending on your situation. Matt > > On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell > wrote: > > > > On 06/08/2019 09:42, Chitrang Srivastava wrote: > > Hi, > > > > I am implementing HTTPs server using openssl 1.1.1b. > > Is it mandatory to setup these API's while creating ssl context ? > > > > SSL_CTX_set_tmp_ecdh > > > > SSL_CTX_set_tmp_dh > > By default OpenSSL will automatically use ECDH if appropriate and choose a > suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() unless you > want more control over which specific group is used. > > OpenSSL will not use DH unless you specifically configure it. If you want to > make use of DH based ciphersuites then you must either call SSL_CTX_set_tmp_dh() > or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the former enables > you to configure any arbitrary DH group that you choose. Calling the latter will > enable the built-in DH groups. > > It is not mandatory to call any of the above. > > > > > Also any suggestion what all options one should set while setting up > server like > > SSL_CTX_set_options like?SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 > > Don't use the protocol version specific options at all. Use > SSL_CTX_set_min_proto_version() if you want to specify a minimum protocol > version. SSLv2 is no longer supported at all. SSLv3 is compiled out by default. > > Other options that are worth considering are SSL_OP_NO_RENEGOTIATION and > (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need the others > unless there is a specific problem you are trying to solve. > > Matt > From chitrang.srivastava at gmail.com Tue Aug 6 10:21:23 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Tue, 6 Aug 2019 15:51:23 +0530 Subject: SSL Server setup DH/ECDH In-Reply-To: <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> Message-ID: Yes , since in my case mostly browser will be used to access webserver running on embedded platform. Another question, since my webserver is running on embedded platform and it has limited memory , I have disabled ARIA/CAMELLIA and few others, is that OK ? because I don't see any ciphers suites which is used in practice. On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell wrote: > > > On 06/08/2019 11:07, Chitrang Srivastava wrote: > > Thanks Matt, > > > > So now I have, which i believe is enough ? > > > > SSL_CTX_set_options(s_ctx, SSL_OP_NO_RENEGOTIATION | > > SSL_OP_CIPHER_SERVER_PREFERENCE); > > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); > > This is fine although it obviously prevents connections from very old > clients > that don't support TLSv1.2. This might not be a problem for you depending > on > your situation. > > Matt > > > > > On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell > > wrote: > > > > > > > > On 06/08/2019 09:42, Chitrang Srivastava wrote: > > > Hi, > > > > > > I am implementing HTTPs server using openssl 1.1.1b. > > > Is it mandatory to setup these API's while creating ssl context ? > > > > > > SSL_CTX_set_tmp_ecdh > > > > > > SSL_CTX_set_tmp_dh > > > > By default OpenSSL will automatically use ECDH if appropriate and > choose a > > suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() > unless you > > want more control over which specific group is used. > > > > OpenSSL will not use DH unless you specifically configure it. If you > want to > > make use of DH based ciphersuites then you must either call > SSL_CTX_set_tmp_dh() > > or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the > former enables > > you to configure any arbitrary DH group that you choose. Calling the > latter will > > enable the built-in DH groups. > > > > It is not mandatory to call any of the above. > > > > > > > > Also any suggestion what all options one should set while setting > up > > server like > > > SSL_CTX_set_options like SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 > > > > Don't use the protocol version specific options at all. Use > > SSL_CTX_set_min_proto_version() if you want to specify a minimum > protocol > > version. SSLv2 is no longer supported at all. SSLv3 is compiled out > by default. > > > > Other options that are worth considering are SSL_OP_NO_RENEGOTIATION > and > > (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need > the others > > unless there is a specific problem you are trying to solve. > > > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 6 10:23:24 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 11:23:24 +0100 Subject: SSL Server setup DH/ECDH In-Reply-To: References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> Message-ID: On 06/08/2019 11:21, Chitrang Srivastava wrote: > Yes , since in my case mostly browser will be used to access webserver running > on embedded platform. > Another question, since my webserver is running on embedded platform and it has > limited memory , I have disabled > ARIA/CAMELLIA? and few others, is that OK ? because I don't see any ciphers > suites which is used in practice. Yes, that should be fine. Matt > > > > On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell > wrote: > > > > On 06/08/2019 11:07, Chitrang Srivastava wrote: > > Thanks Matt, > > > > So now I have, which i believe is enough ? > > > > SSL_CTX_set_options(s_ctx, ?SSL_OP_NO_RENEGOTIATION | > > SSL_OP_CIPHER_SERVER_PREFERENCE); > > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); > > This is fine although it obviously prevents connections from very old clients > that don't support TLSv1.2. This might not be a problem for you depending on > your situation. > > Matt > > > > > On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell > > >> wrote: > > > > > > > >? ? ?On 06/08/2019 09:42, Chitrang Srivastava wrote: > >? ? ?> Hi, > >? ? ?> > >? ? ?> I am implementing HTTPs server using openssl 1.1.1b. > >? ? ?> Is it mandatory to setup these API's while creating ssl context ? > >? ? ?> > >? ? ?> SSL_CTX_set_tmp_ecdh > >? ? ?> > >? ? ?> SSL_CTX_set_tmp_dh > > > >? ? ?By default OpenSSL will automatically use ECDH if appropriate and choose a > >? ? ?suitable group so there is no need to call SSL_CTX_set_tmp_ecdh() > unless you > >? ? ?want more control over which specific group is used. > > > >? ? ?OpenSSL will not use DH unless you specifically configure it. If you > want to > >? ? ?make use of DH based ciphersuites then you must either call > SSL_CTX_set_tmp_dh() > >? ? ?or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). Calling the > former enables > >? ? ?you to configure any arbitrary DH group that you choose. Calling the > latter will > >? ? ?enable the built-in DH groups. > > > >? ? ?It is not mandatory to call any of the above. > > > >? ? ?> > >? ? ?> Also any suggestion what all options one should set while setting up > >? ? ?server like > >? ? ?> SSL_CTX_set_options like?SSL_OP_NO_SSLv2 |SSL_OP_NO_SSLv3 > > > >? ? ?Don't use the protocol version specific options at all. Use > >? ? ?SSL_CTX_set_min_proto_version() if you want to specify a minimum protocol > >? ? ?version. SSLv2 is no longer supported at all. SSLv3 is compiled out by > default. > > > >? ? ?Other options that are worth considering are SSL_OP_NO_RENEGOTIATION and > >? ? ?(possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. Generally you don't need > the others > >? ? ?unless there is a specific problem you are trying to solve. > > > >? ? ?Matt > > > From bill.c.roberts at gmail.com Tue Aug 6 15:34:53 2019 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 6 Aug 2019 10:34:53 -0500 Subject: i2d_ASN1_INTEGER zero pad Message-ID: Hi, I occasionally get spurious errors in my ECDSA signatures, and it appears that when the top byte is over 0x80 of either the R or S component, that I get a zero pad. I noticed all this when reading through the source, their was some comments (see below). I noticed a d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to create it. The zero pad seems to be the correct behavior, but it seems to be breaking things. I understand the ECDSA signature to be a der encoded: 0x30 (ASN1 sequence> 0x (byte len of sequence) 0x20 0x 0x20 0x Below we can see the zero pad on R where the first byte is 0xB2. pSignature is what's in question: 26: C_Sign 2019-08-06 02:51:15.252 [in] hSession = 0x100000000000000 [in] pData[ulDataLen] 00007ffe2dcc7520 / 32 00000000 A7 84 A1 44 7F 22 B3 52 98 D8 02 30 E3 7D 21 BD ...D^?".R...0.}!. 00000010 C9 78 3E 3B 9C 1B 53 BA FD 95 B7 93 A6 64 E5 4E .x>;..S......d.N [out] pSignature[*pulSignatureLen] 0000558c88c9b640 / 71 00000000 30 45 02 21 00 B2 F0 60 57 11 B3 63 83 94 FB 15 0E.!...`W..c.... 00000010 74 DC 8C DF A8 2E D9 29 35 89 F7 15 74 70 11 9D t......)5...tp.. 00000020 3A E1 3A BE 10 02 20 42 4A 99 54 2E 0D D5 32 92 :.:... BJ.T...2. 00000030 3B 7B 96 E9 2F B8 8B 24 77 38 2F 37 FD 13 98 35 ;{../..$w8/7...5 00000040 4E FC C1 D2 80 6E 46 N....nF Returned: 0 CKR_OK -- details and links -- This is the link to the issue request I got filed for more details: https://github.com/tpm2-software/tpm2-pkcs11/issues/277 https://docs.huihoo.com/doxygen/openssl/1.0.1c/a__int_8c_source.html 95 * Positive integers are no problem: they are almost the same as the DER 96 * encoding, except if the first byte is >= 0x80 we need to add a zero pad. 266 /* This is a version of d2i_ASN1_INTEGER that ignores the sign bit of 267 * ASN1 integers: some broken software can encode a positive INTEGER 268 * with its MSB set as negative (it doesn't add a padding zero). 269 */ 270 271 ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp, 272 long length) 273 { https://www.openssl.org/docs/man1.1.0/man3/d2i_ASN1_UINTEGER.html From matt at openssl.org Tue Aug 6 15:56:45 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 16:56:45 +0100 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: References: Message-ID: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> On 06/08/2019 16:34, William Roberts wrote: > Hi, > I occasionally get spurious errors in my ECDSA signatures, and it > appears that when the top byte is over 0x80 of either the R or S > component, that I get a zero pad. I noticed all this when reading > through the source, their was some comments (see below). I noticed a > d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to > create it. The zero pad seems to be the correct behavior, but it seems > to be breaking things. As you note the zero pad is the correct behaviour. > This is the link to the issue request I got filed for more details: > https://github.com/tpm2-software/tpm2-pkcs11/issues/277 This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to me what your question to openssl-users is? Matt From bill.c.roberts at gmail.com Tue Aug 6 16:00:49 2019 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 6 Aug 2019 11:00:49 -0500 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> References: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> Message-ID: On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote: > > > > On 06/08/2019 16:34, William Roberts wrote: > > Hi, > > I occasionally get spurious errors in my ECDSA signatures, and it > > appears that when the top byte is over 0x80 of either the R or S > > component, that I get a zero pad. I noticed all this when reading > > through the source, their was some comments (see below). I noticed a > > d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to > > create it. The zero pad seems to be the correct behavior, but it seems > > to be breaking things. > > As you note the zero pad is the correct behaviour. > > > > This is the link to the issue request I got filed for more details: > > https://github.com/tpm2-software/tpm2-pkcs11/issues/277 > > This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to > me what your question to openssl-users is? The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad issue, is their a i2d version, I couldn't find one. I guess a second question is, is their a better way to build an ECDSA signature from the R and S components, the code for ASNI sequence is something I never figured out, is their an example in ossl somewhere? > > Matt From matt at openssl.org Tue Aug 6 16:16:09 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 6 Aug 2019 17:16:09 +0100 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: References: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> Message-ID: <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> On 06/08/2019 17:00, William Roberts wrote: > On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote: >> >> >> >> On 06/08/2019 16:34, William Roberts wrote: >>> Hi, >>> I occasionally get spurious errors in my ECDSA signatures, and it >>> appears that when the top byte is over 0x80 of either the R or S >>> component, that I get a zero pad. I noticed all this when reading >>> through the source, their was some comments (see below). I noticed a >>> d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to >>> create it. The zero pad seems to be the correct behavior, but it seems >>> to be breaking things. >> >> As you note the zero pad is the correct behaviour. >> >> >>> This is the link to the issue request I got filed for more details: >>> https://github.com/tpm2-software/tpm2-pkcs11/issues/277 >> >> This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to >> me what your question to openssl-users is? > > The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad > issue, is their a i2d version, I couldn't find one. No, an i2d version does not exists. d2i_ASN1_UINTEGER exists only for interoperability with broken software. From the code (crypto/asn1/a_int.c): /* * This is a version of d2i_ASN1_INTEGER that ignores the sign bit of ASN1 * integers: some broken software can encode a positive INTEGER with its MSB * set as negative (it doesn't add a padding zero). */ ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp, long length) Sine we don't want to *create* knowingly broken DER we don't provide the equivalent function. > > I guess a second question is, is their a better way to build an ECDSA > signature from the R and S components, the code > for ASNI sequence is something I never figured out, is their an > example in ossl somewhere? If you have the r and s components in raw "binary" format then something like this should create an OpenSSL ECDSA_SIG object (totally untested): ECDSA_SIG *create_ecdsa_sig(unsigned char *r, size_t rlen, unsigned char *s, size_t slen) { ECDSA_SIG *sig = ECDSA_SIG_new(); if (sig == NULL) return NULL; sig->r = BN_bin2bn(r, rlen, NULL); sig->s = BN_bin2bn(s, slen, NULL); if (sig->r == NULL || sig->s == NULL) { ECDSA_SIG_free(sig); return NULL; } return sig; } Once you have the ECDSA_SIG structure then encoding it as DER is simply a call to i2d_ECDSA_SIG: https://www.openssl.org/docs/manmaster/man3/i2d_ECDSA_SIG.html Matt From bill.c.roberts at gmail.com Tue Aug 6 16:18:26 2019 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 6 Aug 2019 11:18:26 -0500 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> References: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> Message-ID: On Tue, Aug 6, 2019 at 11:16 AM Matt Caswell wrote: > > > > On 06/08/2019 17:00, William Roberts wrote: > > On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote: > >> > >> > >> > >> On 06/08/2019 16:34, William Roberts wrote: > >>> Hi, > >>> I occasionally get spurious errors in my ECDSA signatures, and it > >>> appears that when the top byte is over 0x80 of either the R or S > >>> component, that I get a zero pad. I noticed all this when reading > >>> through the source, their was some comments (see below). I noticed a > >>> d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to > >>> create it. The zero pad seems to be the correct behavior, but it seems > >>> to be breaking things. > >> > >> As you note the zero pad is the correct behaviour. > >> > >> > >>> This is the link to the issue request I got filed for more details: > >>> https://github.com/tpm2-software/tpm2-pkcs11/issues/277 > >> > >> This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to > >> me what your question to openssl-users is? > > > > The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad > > issue, is their a i2d version, I couldn't find one. > > No, an i2d version does not exists. d2i_ASN1_UINTEGER exists only for > interoperability with broken software. From the code (crypto/asn1/a_int.c): > > /* > * This is a version of d2i_ASN1_INTEGER that ignores the sign bit of ASN1 > * integers: some broken software can encode a positive INTEGER with its MSB > * set as negative (it doesn't add a padding zero). > */ > > ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp, > long length) > > Sine we don't want to *create* knowingly broken DER we don't provide the > equivalent function. > That's what I figured. > > > > > I guess a second question is, is their a better way to build an ECDSA > > signature from the R and S components, the code > > for ASNI sequence is something I never figured out, is their an > > example in ossl somewhere? > > If you have the r and s components in raw "binary" format then something like > this should create an OpenSSL ECDSA_SIG object (totally untested): > > ECDSA_SIG *create_ecdsa_sig(unsigned char *r, size_t rlen, unsigned char *s, > size_t slen) > { > ECDSA_SIG *sig = ECDSA_SIG_new(); > > if (sig == NULL) > return NULL; > > sig->r = BN_bin2bn(r, rlen, NULL); > sig->s = BN_bin2bn(s, slen, NULL); > > if (sig->r == NULL || sig->s == NULL) { > ECDSA_SIG_free(sig); > return NULL; > } > > return sig; > } > > Once you have the ECDSA_SIG structure then encoding it as DER is simply a call > to i2d_ECDSA_SIG: > > https://www.openssl.org/docs/manmaster/man3/i2d_ECDSA_SIG.html > That's what I am looking for, thanks! > > Matt > > > > > > From bill.c.roberts at gmail.com Tue Aug 6 20:26:30 2019 From: bill.c.roberts at gmail.com (William Roberts) Date: Tue, 6 Aug 2019 15:26:30 -0500 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: References: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> Message-ID: On Tue, Aug 6, 2019 at 11:18 AM William Roberts wrote: > > On Tue, Aug 6, 2019 at 11:16 AM Matt Caswell wrote: > > > > > > > > On 06/08/2019 17:00, William Roberts wrote: > > > On Tue, Aug 6, 2019 at 10:56 AM Matt Caswell wrote: > > >> > > >> > > >> > > >> On 06/08/2019 16:34, William Roberts wrote: > > >>> Hi, > > >>> I occasionally get spurious errors in my ECDSA signatures, and it > > >>> appears that when the top byte is over 0x80 of either the R or S > > >>> component, that I get a zero pad. I noticed all this when reading > > >>> through the source, their was some comments (see below). I noticed a > > >>> d2i_ASN1_UINTEGER, but I can't find a coresponding i2d_ version to > > >>> create it. The zero pad seems to be the correct behavior, but it seems > > >>> to be breaking things. > > >> > > >> As you note the zero pad is the correct behaviour. > > >> > > >> > > >>> This is the link to the issue request I got filed for more details: > > >>> https://github.com/tpm2-software/tpm2-pkcs11/issues/277 > > >> > > >> This seems to be a problem in tmp2-pkcs11 and not OpenSSL. So its not clear to > > >> me what your question to openssl-users is? > > > > > > The questions is their is a d2i_ASN1_UINTEGER exists for that zero pad > > > issue, is their a i2d version, I couldn't find one. > > > > No, an i2d version does not exists. d2i_ASN1_UINTEGER exists only for > > interoperability with broken software. From the code (crypto/asn1/a_int.c): > > > > /* > > * This is a version of d2i_ASN1_INTEGER that ignores the sign bit of ASN1 > > * integers: some broken software can encode a positive INTEGER with its MSB > > * set as negative (it doesn't add a padding zero). > > */ > > > > ASN1_INTEGER *d2i_ASN1_UINTEGER(ASN1_INTEGER **a, const unsigned char **pp, > > long length) > > > > Sine we don't want to *create* knowingly broken DER we don't provide the > > equivalent function. > > > > That's what I figured. > > > > > > > > > I guess a second question is, is their a better way to build an ECDSA > > > signature from the R and S components, the code > > > for ASNI sequence is something I never figured out, is their an > > > example in ossl somewhere? > > > > If you have the r and s components in raw "binary" format then something like > > this should create an OpenSSL ECDSA_SIG object (totally untested): > > > > ECDSA_SIG *create_ecdsa_sig(unsigned char *r, size_t rlen, unsigned char *s, > > size_t slen) > > { > > ECDSA_SIG *sig = ECDSA_SIG_new(); > > > > if (sig == NULL) > > return NULL; > > > > sig->r = BN_bin2bn(r, rlen, NULL); > > sig->s = BN_bin2bn(s, slen, NULL); > > > > if (sig->r == NULL || sig->s == NULL) { > > ECDSA_SIG_free(sig); > > return NULL; > > } > > > > return sig; > > } > > > > Once you have the ECDSA_SIG structure then encoding it as DER is simply a call > > to i2d_ECDSA_SIG: > > > > https://www.openssl.org/docs/manmaster/man3/i2d_ECDSA_SIG.html > > > > That's what I am looking for, thanks! > For completeness encase anyone else stumbles into this bit of lore, is that pkcs11 doesn't use the IETF ASN1 encoded scheme. While our code did occasionally suffer from this "UNINTEGER" issue, It actually uses a straight R + S concatenation. However, this code will fix our tpm2-tools code. > > > > Matt > > > > > > > > > > > > From deepak.redmi2 at gmail.com Tue Aug 6 22:24:48 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Wed, 7 Aug 2019 03:54:48 +0530 Subject: OPENSSL_thread_stop() equivalent Message-ID: Hi, Had to downgrade the OpenSSL used in an application from 1.1.0k to 1.0.2s. Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know the equivalent call in OpenSSL 1.0.2s? if applicable. Did try the documents, change history and source code for help but could not figure out much in short time spent. My assumption is that above call deallocates memory and other structures used by OpenSSL. Seems to be generic call to be used at end of threads. Could anyone please explain me this call and it's replacement? Or point me in the right direction? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Wed Aug 7 00:36:55 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 7 Aug 2019 00:36:55 +0000 Subject: OPENSSL_thread_stop() equivalent In-Reply-To: References: Message-ID: <5EFE2299-2BCE-4FDF-A9FE-4919E82CA432@akamai.com> * Had to downgrade the OpenSSL used in an application from 1.1.0k to 1.0.2s. That?s too bad, given 1.0.2 is going to become unsupported at year-end. Was it because the application wasn?t ready to handle opaque structures? >Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know the equivalent call in OpenSSL 1.0.2s? if applicable. 1.0.2 has no concept/support for threads, so you probably don?t need to do anything. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Johannes.Heinz at telekom.de Wed Aug 7 06:57:06 2019 From: Johannes.Heinz at telekom.de (Johannes.Heinz at telekom.de) Date: Wed, 7 Aug 2019 06:57:06 +0000 Subject: EVP_KEY_cmp and -_parameters issues Message-ID: I have a question to following situation with RSA and DH structures: I'm testing these in separated unit tests. Both test cases (each one for RSA and DH) are doing the same: I'm creating a new DH or RSA structure, filling it with my params (pqg ...) and convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => pkey1) Next step, I'm writing and reading this structure with these functions: PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() ) (with password) EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password) (or even without a password) Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for that I can use these two functions: EVP_PKEY_cmp(pkey1, pkey2) (compares components and params) EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params) Now the Problem: Even the tests work the same way, the one with RSA only accept the compare-function "EVP_PKEY_cmp" and not the other one. The one with DH is only with the "EVP_PKEY_cmp_parameters" successful. Question: Why can the first compare function find the components and params of the RSA structure (and even after the PEM_write_bio...) and not of the DH? Also, why it's with the second compare function (only params) the other way around (keys match in DH unit test and not in RSA unit test)? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From thulasi.goriparthi at gmail.com Wed Aug 7 07:42:17 2019 From: thulasi.goriparthi at gmail.com (Thulasi Goriparthi) Date: Wed, 7 Aug 2019 13:12:17 +0530 Subject: EVP_KEY_cmp and -_parameters issues In-Reply-To: References: Message-ID: RSA keys wouldn't have parameters that are separated from key components. So, EVP_PKEY_cmp() is applicable, but not EVP_PKEY_cmp_parameters(). DH keys, which are generally used for key exchange, are short lived, though the group parameters can be comparatively valid for longer duration (let's say for a whole session) and can be used to generate multiple DH keys. So, EVP_PKEY_cmp_parameters() is useful to validate peer's public key parameters during key exchange to confirm that both peers are working in the same group. Though EVP_PKEY_cmp() function can be extended to compare both parameters and key components for DH keys, it wouldn't be of much use as DH keys are ephemeral and we never need to compare two of them for their key components. Thanks, Thulasi. On Wed, 7 Aug 2019 at 12:27, wrote: > > I have a question to following situation with RSA and DH structures: > > I?m testing these in separated unit tests. > > Both test cases (each one for RSA and DH) are doing the same: > > > > I?m creating a new DH or RSA structure, filling it with my params (pqg ?) and convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => pkey1) > > Next step, I?m writing and reading this structure with these functions: > > PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() ) (with password) > > EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password) > > (or even without a password) > > > > Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for that I can use these two functions: > > EVP_PKEY_cmp(pkey1, pkey2) (compares components and params) > > EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params) > > > > Now the Problem: > > Even the tests work the same way, the one with RSA only accept the compare-function ?EVP_PKEY_cmp? and not the other one. > > The one with DH is only with the ?EVP_PKEY_cmp_parameters? successful. > > > > Question: > > Why can the first compare function find the components and params of the RSA structure (and even after the PEM_write_bio?) and not of the DH? > > Also, why it?s with the second compare function (only params) the other way around (keys match in DH unit test and not in RSA unit test)? > > > > Thanks From matt at openssl.org Wed Aug 7 08:06:09 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Aug 2019 09:06:09 +0100 Subject: i2d_ASN1_INTEGER zero pad In-Reply-To: <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> References: <3a4bf148-bde2-f8d1-cea2-d7388c8f2995@openssl.org> <0c457293-175a-352d-86c8-eecfabc36988@openssl.org> Message-ID: <1cbd6efd-fe23-ca33-257f-56fbccb8c024@openssl.org> On 06/08/2019 17:16, Matt Caswell wrote: > sig->r = BN_bin2bn(r, rlen, NULL); > sig->s = BN_bin2bn(s, slen, NULL); As a slight amendment to my earlier answer - a better way to do the above two lines would be to use the ECDSA_SIG_set0() function to set the r and s components rather than diving into the internals of the ECDSA_SIG structure. Matt From Johannes.Heinz at telekom.de Wed Aug 7 08:19:15 2019 From: Johannes.Heinz at telekom.de (Johannes.Heinz at telekom.de) Date: Wed, 7 Aug 2019 08:19:15 +0000 Subject: AW: EVP_KEY_cmp and -_parameters issues In-Reply-To: References: Message-ID: Now I've got it. Thank you very much. -----Urspr?ngliche Nachricht----- Von: Thulasi Goriparthi Gesendet: Mittwoch, 7. August 2019 09:42 An: Heinz, Johannes Cc: openssl-users at openssl.org Betreff: Re: EVP_KEY_cmp and -_parameters issues RSA keys wouldn't have parameters that are separated from key components. So, EVP_PKEY_cmp() is applicable, but not EVP_PKEY_cmp_parameters(). DH keys, which are generally used for key exchange, are short lived, though the group parameters can be comparatively valid for longer duration (let's say for a whole session) and can be used to generate multiple DH keys. So, EVP_PKEY_cmp_parameters() is useful to validate peer's public key parameters during key exchange to confirm that both peers are working in the same group. Though EVP_PKEY_cmp() function can be extended to compare both parameters and key components for DH keys, it wouldn't be of much use as DH keys are ephemeral and we never need to compare two of them for their key components. Thanks, Thulasi. On Wed, 7 Aug 2019 at 12:27, wrote: > > I have a question to following situation with RSA and DH structures: > > I?m testing these in separated unit tests. > > Both test cases (each one for RSA and DH) are doing the same: > > > > I?m creating a new DH or RSA structure, filling it with my params (pqg > ?) and convert it to an EVP_PKEY (for example: EVP_PKEY_assign_DH => > pkey1) > > Next step, I?m writing and reading this structure with these functions: > > PEM_write_bio_PrivateKey() (not PEM_write_bio_PrivateKey_traditional() > ) (with password) > > EVP_PKEY* pkey2 = PEM_read_bio_PrivateKey() (with same password) > > (or even without a password) > > > > Now I want to compare these two EVP_PKEY* variables (pkey1 and pkey2) and for that I can use these two functions: > > EVP_PKEY_cmp(pkey1, pkey2) (compares components and params) > > EVP_PKEY_cmp_parameters(pkey1, pkey2) (compares params) > > > > Now the Problem: > > Even the tests work the same way, the one with RSA only accept the compare-function ?EVP_PKEY_cmp? and not the other one. > > The one with DH is only with the ?EVP_PKEY_cmp_parameters? successful. > > > > Question: > > Why can the first compare function find the components and params of the RSA structure (and even after the PEM_write_bio?) and not of the DH? > > Also, why it?s with the second compare function (only params) the other way around (keys match in DH unit test and not in RSA unit test)? > > > > Thanks From matt at openssl.org Wed Aug 7 08:25:03 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Aug 2019 09:25:03 +0100 Subject: OPENSSL_thread_stop() equivalent In-Reply-To: <5EFE2299-2BCE-4FDF-A9FE-4919E82CA432@akamai.com> References: <5EFE2299-2BCE-4FDF-A9FE-4919E82CA432@akamai.com> Message-ID: On 07/08/2019 01:36, Salz, Rich via openssl-users wrote: >>Due to this I have to remove the usage of OPENSSL_thread_stop(), want to know > the equivalent call in OpenSSL 1.0.2s? if applicable. > > 1.0.2 has no concept/support for threads, so you probably don?t need to do anything. That's not entirely true. 1.0.2 does support threads, but does so through various callback mechanisms. It also has a pseudo thread local storage concept in the error mechanism. In 1.0.2, instead of OPENSSL_thread_stop(), you should call: ERR_remove_thread_state() However the conditions are slightly different in 1.0.2. 1.1.x will usually detect thread exit automatically and you don't need to call OPENSSL_thread_stop() at all. For all the details see the OPENSSL_thread_stop() man page: https://www.openssl.org/docs/man1.1.1/man3/OPENSSL_thread_stop.html None of the capability to automatically detect thread exit exists in 1.0.2. Matt From chitrang.srivastava at gmail.com Wed Aug 7 11:19:38 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Wed, 7 Aug 2019 16:49:38 +0530 Subject: SSL Server setup DH/ECDH In-Reply-To: <76563752-ec62-ba8a-4f70-ef58bb825abb@openssl.org> References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> <55b32408-490f-a716-4050-e82a6a8b4043@openssl.org> <76563752-ec62-ba8a-4f70-ef58bb825abb@openssl.org> Message-ID: Hi Matt, I tried following code but it is crashing @ *SSL_CTX_set_ciphersuites* s_ctx = SSL_CTX_new(TLS_method()); SSL_CTX_set_options(s_ctx, SSL_OP_NO_RENEGOTIATION | SSL_OP_CIPHER_SERVER_PREFERENCE); SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); SSL_CTX_set_ciphersuites(s_ctx, "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384"); In the debugger I noticed s_ctx :: cipher_list & cipher_list_by_id are both NULL However tls13_ciphersuites is populated. Further in update_cipher_list which is called by SSL_CTX_set_ciphersuites tries to delete this cipher_list and hence crash ? Any pointer what I am missing? -Thanks On Tue, Aug 6, 2019 at 7:48 PM Matt Caswell wrote: > > > On 06/08/2019 14:58, Chitrang Srivastava wrote: > > Yeah I mean TLS 1.3 cipher , sorry I haven't pasted exact names. > > So after SSL_OP_CIPHER_SERVER_PREFERENCE, server uses > > TLS_1_3_AES_256_SHA_384. > > While without that it uses TLS_1_3_AES_128_SHA_256, which is better in > terms of > > performance. > > Ah! Right - now I understand. > > So the option SSL_OP_CIPHER_SERVER_PREFERENCE means that the server > prefers the > server's ordering of ciphersuites compared to the clients. With that > option set > it will use the first ciphersuite that is in the server's list that is > also in > the client's list. Without the set it will use the first ciphersuite that > is in > the client's list that is also in the server's list. Server operators often > prefer this because it gives more control over which ciphersuite > ultimately gets > used. But that's only really useful if you also look at this list of > configured > ciphersuites and make sure they are in your preferred order! Otherwise the > option is fairly pointless! > > For TLSv1.3 the default list is: > > # define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \ > "TLS_CHACHA20_POLY1305_SHA256:" \ > "TLS_AES_128_GCM_SHA256" > > If you want a different order you can use the functions > SSL_CTX_set_ciphersuites() (or SSL_set_ciphersuites()) to amend it: > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ciphersuites.html > > Matt > > > > > Thanks very much, > > Chitrang > > > > Tuesday, August 6, 2019, Matt Caswell > > wrote: > > > > > > > > On 06/08/2019 12:20, Chitrang Srivastava wrote: > > > Noticed that if I set SSL_OP_CIPHER_SERVER_PREFERENCE, > > TLS_1_3_AES_256_SHA_384 > > > is being used while without that > > > AES_128_SHA256 is being used and I see client(Chrome) send this as > first > > preference. > > > Is there anyway where I can always prefer AES-128-SHA256 cipher > suite of > > TLS 1.3? > > > > Hmmm...are you sure? > > > > Those names don't look like OpenSSL names for those ciphersuites. I > guess you > > mean TLS_AES_256_GCM_SHA384 and AES128-SHA256. The former is a > TLSv1.3 > > ciphersuite and the latter is for TLSv1.2 and below. They are > mutually > > exclusive. If you negotiate TLSv1.3 then you can't use TLSv1.2 > ciphersuites and > > vice versa. > > > > SSL_OP_CIPHER_SERVER_PREFERENCE should not affect the protocol > version > > negotiated. OpenSSL negotiates the version *first* before deciding > what > > ciphersuite to use. So it should not be the case that > > SSL_OP_CIPHER_SERVER_PREFERENCE suddenly causes a TLSv1.3 > ciphersuite to be used > > when a TLSv1.2 ciphersuite was used without it. > > > > Matt > > > > > > > > > > On Tue, Aug 6, 2019 at 3:53 PM Matt Caswell > > > > >> wrote: > > > > > > > > > > > > On 06/08/2019 11:21, Chitrang Srivastava wrote: > > > > Yes , since in my case mostly browser will be used to access > > webserver running > > > > on embedded platform. > > > > Another question, since my webserver is running on embedded > platform and > > > it has > > > > limited memory , I have disabled > > > > ARIA/CAMELLIA and few others, is that OK ? because I don't > see any > > ciphers > > > > suites which is used in practice. > > > > > > Yes, that should be fine. > > > > > > Matt > > > > > > > > > > > > > > > > > > > On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell < > matt at openssl.org > > > > > > > > > > > > >>> wrote: > > > > > > > > > > > > > > > > On 06/08/2019 11:07, Chitrang Srivastava wrote: > > > > > Thanks Matt, > > > > > > > > > > So now I have, which i believe is enough ? > > > > > > > > > > SSL_CTX_set_options(s_ctx, SSL_OP_NO_RENEGOTIATION | > > > > > SSL_OP_CIPHER_SERVER_PREFERENCE); > > > > > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); > > > > > > > > This is fine although it obviously prevents connections > from > > very old > > > clients > > > > that don't support TLSv1.2. This might not be a problem > for you > > > depending on > > > > your situation. > > > > > > > > Matt > > > > > > > > > > > > > > On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell < > matt at openssl.org > > > > > > > > > > > > >> > > > > > > > > > > > > > >>>> wrote: > > > > > > > > > > > > > > > > > > > > On 06/08/2019 09:42, Chitrang Srivastava wrote: > > > > > > Hi, > > > > > > > > > > > > I am implementing HTTPs server using openssl > 1.1.1b. > > > > > > Is it mandatory to setup these API's while > creating ssl > > context ? > > > > > > > > > > > > SSL_CTX_set_tmp_ecdh > > > > > > > > > > > > SSL_CTX_set_tmp_dh > > > > > > > > > > By default OpenSSL will automatically use ECDH if > appropriate > > > and choose a > > > > > suitable group so there is no need to call > > SSL_CTX_set_tmp_ecdh() > > > > unless you > > > > > want more control over which specific group is > used. > > > > > > > > > > OpenSSL will not use DH unless you specifically > configure > > it. If you > > > > want to > > > > > make use of DH based ciphersuites then you must > either call > > > > SSL_CTX_set_tmp_dh() > > > > > or SSL_CTX_set_dh_auto() (or the SSL_* > equivalents). > > Calling the > > > > former enables > > > > > you to configure any arbitrary DH group that you > choose. > > Calling the > > > > latter will > > > > > enable the built-in DH groups. > > > > > > > > > > It is not mandatory to call any of the above. > > > > > > > > > > > > > > > > > Also any suggestion what all options one should > set while > > > setting up > > > > > server like > > > > > > SSL_CTX_set_options like SSL_OP_NO_SSLv2 > |SSL_OP_NO_SSLv3 > > > > > > > > > > Don't use the protocol version specific options at > all. Use > > > > > SSL_CTX_set_min_proto_version() if you want to > specify a > > minimum > > > protocol > > > > > version. SSLv2 is no longer supported at all. > SSLv3 is > > compiled > > > out by > > > > default. > > > > > > > > > > Other options that are worth considering are > > > SSL_OP_NO_RENEGOTIATION and > > > > > (possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. > Generally you > > don't need > > > > the others > > > > > unless there is a specific problem you are trying > to solve. > > > > > > > > > > Matt > > > > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Aug 7 12:35:39 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Aug 2019 13:35:39 +0100 Subject: SSL Server setup DH/ECDH In-Reply-To: References: <5961e967-fa03-44c6-0a74-204fa8493ecb@openssl.org> <1e94f9d9-00b5-ab0e-081e-fb65dae5f4f2@openssl.org> <55b32408-490f-a716-4050-e82a6a8b4043@openssl.org> <76563752-ec62-ba8a-4f70-ef58bb825abb@openssl.org> Message-ID: On 07/08/2019 12:19, Chitrang Srivastava wrote: > Hi Matt, > > I tried following code but it is crashing?@ *SSL_CTX_set_ciphersuites* > s_ctx = SSL_CTX_new(TLS_method()); > SSL_CTX_set_options(s_ctx, ?SSL_OP_NO_RENEGOTIATION | > SSL_OP_CIPHER_SERVER_PREFERENCE); > SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); > SSL_CTX_set_ciphersuites(s_ctx, > "TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384"); > > In the debugger I noticed? > > s_ctx :: cipher_list & cipher_list_by_id are both NULL Well, that is very strange. I just tried the code above and it works just fine for me. s_ctx->cipher_list, and s_ctx->cipher_lib_by_id should be populated in the SSL_CTX_new call: https://github.com/openssl/openssl/blob/c50fd0f959de5b256d8eefb8ad2a82fcdcb899c3/ssl/ssl_lib.c#L3091-L3101 So you should never have an SSL_CTX object without those things being set. Matt > However tls13_ciphersuites is populated. > Further in update_cipher_list which is called by SSL_CTX_set_ciphersuites tries > to delete this cipher_list and hence crash ? > > Any pointer what I am?missing? > > -Thanks > > > > On Tue, Aug 6, 2019 at 7:48 PM Matt Caswell > wrote: > > > > On 06/08/2019 14:58, Chitrang Srivastava wrote: > > Yeah I mean TLS 1.3 cipher , sorry I haven't pasted exact names. > > So after SSL_OP_CIPHER_SERVER_PREFERENCE, server uses? > > TLS_1_3_AES_256_SHA_384. > > While without that it uses TLS_1_3_AES_128_SHA_256, which is better in > terms of > > performance. > > Ah! Right - now I understand. > > So the option SSL_OP_CIPHER_SERVER_PREFERENCE means that the server prefers the > server's ordering of ciphersuites compared to the clients. With that option set > it will use the first ciphersuite that is in the server's list that is also in > the client's list. Without the set it will use the first ciphersuite that is in > the client's list that is also in the server's list. Server operators often > prefer this because it gives more control over which ciphersuite ultimately gets > used. But that's only really useful if you also look at this list of configured > ciphersuites and make sure they are in your preferred order! Otherwise the > option is fairly pointless! > > For TLSv1.3 the default list is: > > #? ?define TLS_DEFAULT_CIPHERSUITES "TLS_AES_256_GCM_SHA384:" \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "TLS_CHACHA20_POLY1305_SHA256:" \ > ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "TLS_AES_128_GCM_SHA256" > > If you want a different order you can use the functions > SSL_CTX_set_ciphersuites() (or SSL_set_ciphersuites()) to amend it: > > https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ciphersuites.html > > Matt > > > > > Thanks very much, > > Chitrang > > > > Tuesday, August 6, 2019, Matt Caswell > > >> wrote: > > > > > > > >? ? ?On 06/08/2019 12:20, Chitrang Srivastava wrote: > >? ? ?> Noticed that if I set? SSL_OP_CIPHER_SERVER_PREFERENCE, > >? ? ?TLS_1_3_AES_256_SHA_384 > >? ? ?> is being used while without that > >? ? ?> AES_128_SHA256 is being used and I see client(Chrome) send this as first > >? ? ?preference. > >? ? ?> Is there anyway where I can always prefer AES-128-SHA256 cipher suite of > >? ? ?TLS 1.3? > > > >? ? ?Hmmm...are you sure? > > > >? ? ?Those names don't look like OpenSSL names for those ciphersuites. I > guess you > >? ? ?mean TLS_AES_256_GCM_SHA384 and AES128-SHA256. The former is a TLSv1.3 > >? ? ?ciphersuite and the latter is for TLSv1.2 and below. They are mutually > >? ? ?exclusive. If you negotiate TLSv1.3 then you can't use TLSv1.2 > ciphersuites and > >? ? ?vice versa. > > > >? ? ?SSL_OP_CIPHER_SERVER_PREFERENCE should not affect the protocol version > >? ? ?negotiated. OpenSSL negotiates the version *first* before deciding what > >? ? ?ciphersuite to use. So it should not be the case that > >? ? ?SSL_OP_CIPHER_SERVER_PREFERENCE suddenly causes a TLSv1.3 ciphersuite > to be used > >? ? ?when a TLSv1.2 ciphersuite was used without it. > > > >? ? ?Matt > > > > > >? ? ?> > >? ? ?> On Tue, Aug 6, 2019 at 3:53 PM Matt Caswell > >? ? ?> > >? ? ?> > >>> wrote: > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?>? ? ?On 06/08/2019 11:21, Chitrang Srivastava wrote: > >? ? ?>? ? ?> Yes , since in my case mostly browser will be used to access > >? ? ?webserver running > >? ? ?>? ? ?> on embedded platform. > >? ? ?>? ? ?> Another question, since my webserver is running on embedded > platform and > >? ? ?>? ? ?it has > >? ? ?>? ? ?> limited memory , I have disabled > >? ? ?>? ? ?> ARIA/CAMELLIA? and few others, is that OK ? because I don't > see any > >? ? ?ciphers > >? ? ?>? ? ?> suites which is used in practice. > >? ? ?> > >? ? ?>? ? ?Yes, that should be fine. > >? ? ?> > >? ? ?>? ? ?Matt > >? ? ?> > >? ? ?>? ? ?> > >? ? ?>? ? ?> > >? ? ?>? ? ?> > >? ? ?>? ? ?> On Tue, Aug 6, 2019 at 3:42 PM Matt Caswell > >? ? ?> > >? ? ?>? ? ? > >> > >? ? ?>? ? ?> > > > >? ? ? > >>>> wrote: > >? ? ?>? ? ?> > >? ? ?>? ? ?> > >? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?On 06/08/2019 11:07, Chitrang Srivastava wrote: > >? ? ?>? ? ?>? ? ?> Thanks Matt, > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> So now I have, which i believe is enough ? > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> SSL_CTX_set_options(s_ctx, ?SSL_OP_NO_RENEGOTIATION | > >? ? ?>? ? ?>? ? ?> SSL_OP_CIPHER_SERVER_PREFERENCE); > >? ? ?>? ? ?>? ? ?> SSL_CTX_set_min_proto_version(s_ctx, TLS1_2_VERSION); > >? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?This is fine although it obviously prevents connections from > >? ? ?very old > >? ? ?>? ? ?clients > >? ? ?>? ? ?>? ? ?that don't support TLSv1.2. This might not be a problem > for you > >? ? ?>? ? ?depending on > >? ? ?>? ? ?>? ? ?your situation. > >? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?Matt > >? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> On Tue, Aug 6, 2019 at 3:04 PM Matt Caswell > > >? ? ?> > >? ? ?>? ? ? > >> > >? ? ?>? ? ?>? ? ? > > > >? ? ? > >>> > >? ? ?>? ? ?>? ? ?> > > > >? ? ? > >> > >? ? ?>? ? ? > > > >? ? ? > >>>>> wrote: > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?On 06/08/2019 09:42, Chitrang Srivastava wrote: > >? ? ?>? ? ?>? ? ?>? ? ?> Hi, > >? ? ?>? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?> I am implementing HTTPs server using openssl 1.1.1b. > >? ? ?>? ? ?>? ? ?>? ? ?> Is it mandatory to setup these API's while > creating ssl > >? ? ?context ? > >? ? ?>? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?> SSL_CTX_set_tmp_ecdh > >? ? ?>? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?> SSL_CTX_set_tmp_dh > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?By default OpenSSL will automatically use ECDH if > appropriate > >? ? ?>? ? ?and choose a > >? ? ?>? ? ?>? ? ?>? ? ?suitable group so there is no need to call > >? ? ?SSL_CTX_set_tmp_ecdh() > >? ? ?>? ? ?>? ? ?unless you > >? ? ?>? ? ?>? ? ?>? ? ?want more control over which specific group is used. > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?OpenSSL will not use DH unless you specifically > configure > >? ? ?it. If you > >? ? ?>? ? ?>? ? ?want to > >? ? ?>? ? ?>? ? ?>? ? ?make use of DH based ciphersuites then you must > either call > >? ? ?>? ? ?>? ? ?SSL_CTX_set_tmp_dh() > >? ? ?>? ? ?>? ? ?>? ? ?or SSL_CTX_set_dh_auto() (or the SSL_* equivalents). > >? ? ?Calling the > >? ? ?>? ? ?>? ? ?former enables > >? ? ?>? ? ?>? ? ?>? ? ?you to configure any arbitrary DH group that you choose. > >? ? ?Calling the > >? ? ?>? ? ?>? ? ?latter will > >? ? ?>? ? ?>? ? ?>? ? ?enable the built-in DH groups. > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?It is not mandatory to call any of the above. > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?> Also any suggestion what all options one should > set while > >? ? ?>? ? ?setting up > >? ? ?>? ? ?>? ? ?>? ? ?server like > >? ? ?>? ? ?>? ? ?>? ? ?> SSL_CTX_set_options like?SSL_OP_NO_SSLv2 > |SSL_OP_NO_SSLv3 > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?Don't use the protocol version specific options at > all. Use > >? ? ?>? ? ?>? ? ?>? ? ?SSL_CTX_set_min_proto_version() if you want to specify a > >? ? ?minimum > >? ? ?>? ? ?protocol > >? ? ?>? ? ?>? ? ?>? ? ?version. SSLv2 is no longer supported at all. SSLv3 is > >? ? ?compiled > >? ? ?>? ? ?out by > >? ? ?>? ? ?>? ? ?default. > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?Other options that are worth considering are > >? ? ?>? ? ?SSL_OP_NO_RENEGOTIATION and > >? ? ?>? ? ?>? ? ?>? ? ?(possibly) SSL_OP_CIPHER_SERVER_PREFERENCE. > Generally you > >? ? ?don't need > >? ? ?>? ? ?>? ? ?the others > >? ? ?>? ? ?>? ? ?>? ? ?unless there is a specific problem you are trying to > solve. > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?>? ? ?>? ? ?Matt > >? ? ?>? ? ?>? ? ?> > >? ? ?>? ? ?> > >? ? ?> > > > From uri at ll.mit.edu Wed Aug 7 14:48:00 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 7 Aug 2019 14:48:00 +0000 Subject: master branch: EC test broken AGAIN? Message-ID: Test Summary Report ------------------- ../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1) Failed test: 2 Non-zero exit status: 1 Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr 0.34 sys + 81.53 cusr 29.91 csys = 113.05 CPU) Result: FAIL Does it seem to have become repetitive? ;-) -- Regards, Uri -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From matt at openssl.org Wed Aug 7 14:49:50 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Aug 2019 15:49:50 +0100 Subject: master branch: EC test broken AGAIN? In-Reply-To: References: Message-ID: <5da518ff-c1c1-2ba9-272d-b8d088ea69be@openssl.org> On 07/08/2019 15:48, Blumenthal, Uri - 0553 - MITLL wrote: > Test Summary Report > > ------------------- > > ../test/recipes/15-test_ec.t ? ? ? ? ? ? ? ? ? ? (Wstat: 256 Tests: 5 Failed: 1) > > ? Failed test:? 2 > > ? Non-zero exit status: 1 > > Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr? 0.34 sys + 81.53 cusr > 29.91 csys = 113.05 CPU) > > Result: FAIL > > ? > > Does it seem to have become repetitive? ;-) Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix for this issue is here: https://github.com/openssl/openssl/pull/9546 Matt From matt at openssl.org Wed Aug 7 14:56:39 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 7 Aug 2019 15:56:39 +0100 Subject: master branch: EC test broken AGAIN? In-Reply-To: <5da518ff-c1c1-2ba9-272d-b8d088ea69be@openssl.org> References: <5da518ff-c1c1-2ba9-272d-b8d088ea69be@openssl.org> Message-ID: On 07/08/2019 15:49, Matt Caswell wrote: > > > On 07/08/2019 15:48, Blumenthal, Uri - 0553 - MITLL wrote: >> Test Summary Report >> >> ------------------- >> >> ../test/recipes/15-test_ec.t ? ? ? ? ? ? ? ? ? ? (Wstat: 256 Tests: 5 Failed: 1) >> >> ? Failed test:? 2 >> >> ? Non-zero exit status: 1 >> >> Files=174, Tests=1660, 122 wallclock secs ( 1.27 usr? 0.34 sys + 81.53 cusr >> 29.91 csys = 113.05 CPU) >> >> Result: FAIL >> >> ? >> >> Does it seem to have become repetitive? ;-) > > Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix for this > issue is here: > > https://github.com/openssl/openssl/pull/9546 ...now pushed to master. Matt From uri at ll.mit.edu Wed Aug 7 15:03:53 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 7 Aug 2019 15:03:53 +0000 Subject: master branch: EC test broken AGAIN? In-Reply-To: References: <5da518ff-c1c1-2ba9-272d-b8d088ea69be@openssl.org> Message-ID: On 8/7/19, 10:57 AM, "openssl-users on behalf of Matt Caswell" wrote: > >> ../test/recipes/15-test_ec.t (Wstat: 256 Tests: 5 Failed: 1) > > > > Assuming you are building with enable-ec_nistp_64_gcc_128 then the fix for this > > issue is here: > > > > https://github.com/openssl/openssl/pull/9546 > > ...now pushed to master. Thank you - yes the build was with "enable-ec_nistp_64_gcc_128", and I confirm that the fix works. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From deepak.redmi2 at gmail.com Wed Aug 7 21:57:02 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Thu, 8 Aug 2019 03:27:02 +0530 Subject: FIPS_selftest() Usage Message-ID: Hi, For an application linked to FIPS capable OpenSSL, 1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good practice to call FIPS_selftest()? Or is this redundant call? 2) Did come across documentation which only hinted that FIPS_mode_set() calls FIPS_selftest() internally. Is this correct? Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed Aug 7 22:41:57 2019 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 7 Aug 2019 22:41:57 +0000 Subject: AW: FIPS_selftest() Usage In-Reply-To: References: Message-ID: > For an application linked to FIPS capable OpenSSL,? > 1) After calls to FIPS_mode_set() and FIPS_mode() both succeed, is it good practice to call FIPS_selftest()? Or is this redundant call? > > 2) Did come across documentation which only hinted that FIPS_mode_set() calls FIPS_selftest() internally. Is this correct? > Regards. Indeed, FIPS_mode_set() calls FIPS_selftest() internally(*), and if the selftest fails, FIPS mode will not be enabled. So there is no need to run the selftest immediately after FIPS_mode_set() again. If your program is a long-running service, it might be a good idea to re-run the selftest on a regular base, but I have no particular recommendations about how often would be reasonable. (*) It is stated explicitly in the manual pages, which are printed in Appendix D.2 of the OpenSSL FIPS 2.0 User Guide: >Appendix D.2 FIPS_mode_set(), FIPS_selftest() > FIPS_mode_set() enables the FIPS mode of operation for applications > that have complied with all the provisions of the OpenSSL FIPS 140-2 Security > Policy. Successful execution of this function call with non-zero ONOFF is the > only way to enable FIPS mode. After verifying the integrity of the executable > object code using the stored digest FIPS_mode_set() performs the power-up self-test. https://www.openssl.org/docs/fips/UserGuide-2.0.pdf This document is the official documentation and most comprehensive guide for the OpenSSL FIPS 2.0 object module. Anything you need to know you should be able to find in there. Regards, Matthias From remy at lebeausoftware.org Thu Aug 8 01:27:23 2019 From: remy at lebeausoftware.org (Remy Lebeau) Date: Wed, 7 Aug 2019 18:27:23 -0700 Subject: 1.0.2 to 1.1 migration problem with verify_callback() In-Reply-To: References: <1564766697509-0.post@n7.nabble.com> Message-ID: In my verify callback (for 1.0.2, mind you), I use X509_STORE_CTX_get_app_data(ctx) to get the SSL* pointer. X509_STORE_CTX_get_app_data(ctx) is a macro in OpenSSL's "x509_vfy.h" header file that maps to X509_STORE_CTX_get_ex_data(ctx,0) (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?). Remy Lebeau Lebeau Software On 8/5/2019 7:40 AM, Matt Caswell wrote: > From within your callback you can do this to get hold of the SSL object: > > SSL *s = (SSL *)X509_STORE_CTX_get_ex_data(ctx, > SSL_get_ex_data_X509_STORE_CTX_idx()); > > And then this to get hold of the hostname requested: > > const char *hostname = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name); -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhamija_shalu at yahoo.com Thu Aug 8 10:00:44 2019 From: dhamija_shalu at yahoo.com (shalu dhamija) Date: Thu, 8 Aug 2019 10:00:44 +0000 (UTC) Subject: Query related to obtaining of temp key References: <1516886858.2688277.1565258444861.ref@mail.yahoo.com> Message-ID: <1516886858.2688277.1565258444861@mail.yahoo.com> Hi All, I have a query related to getting thetemporary key used during the key exchange. As a TLS client, I am able to getthe key using the API?SSL_get_peer_tmp_key().? But when acting as TLS Server, I usedAPI SSL_get_tmp_key(). ThisAPI is returning the temp key for TLS1.3 ciphers but for ECDHE and DHEalgorithm type,? the tmp key is not obtained. In the code, the tmp key is being cleared during the client key exchangeafter generating secrets. Is there any other way to obtain thetemporary key when acting as a server? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Aug 8 11:47:58 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 8 Aug 2019 11:47:58 +0000 Subject: 1.0.2 to 1.1 migration problem with verify_callback() In-Reply-To: References: <1564766697509-0.post@n7.nabble.com> Message-ID: <9A32E7C0-DC1B-44E3-90DC-EA99DD869F4E@akamai.com> > (why doesn't it use SSL_get_ex_data_X509_STORE_CTX_idx() instead of 0?). History; OpenSSL reserved some exdata indices for itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From upadhyay.manoj at live.com Fri Aug 9 05:30:26 2019 From: upadhyay.manoj at live.com (manoj upadhyay) Date: Fri, 9 Aug 2019 05:30:26 +0000 Subject: Issue Building OpenSSL with "enable-static-engine" for MD & MT Builds for x86 Message-ID: Hi All, I am trying to build OpenSSL DLLs for MD and MT for windows on X86 and x64. I am building it for Visual studio vs 2017, 2015 and 2013. When I configure the build using following command on Visual Studio2015 x86 command prompt , "namke" is throwing error But the same is working with Visual studio 2017 (32/64bit) and for Visual Studio 2015 x64. perl Configure VC-WIN32 no-asm enable-static-engine While searching for this Issue I came across following https://github.com/openssl/openssl/issues/560 "INSTALL.WIN configure option `enable-static-engine` appears to be ignored #560:" It seems it was supported viautil/mk1mf in older version of OpenSSSLBut now this file ans this flag is removed. Is there any way to resolve the Issue? What is the use of this flag "?enable-static-engine"? Why it was there and why it is removed now? I will be great if I can get some insight. Thanks In Advance. Regards, Manoj Upadhyay -------------- next part -------------- An HTML attachment was scrubbed... URL: From vvr.83 at yahoo.com Fri Aug 9 09:19:37 2019 From: vvr.83 at yahoo.com (Venkata Veldanda) Date: Fri, 9 Aug 2019 09:19:37 +0000 (UTC) Subject: Does BIO_read() behave differently on diff architectures? References: <1392749700.3168567.1565342377790.ref@mail.yahoo.com> Message-ID: <1392749700.3168567.1565342377790@mail.yahoo.com> Hi Experts, I am using openssl 1.0.2? I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read().? I read a 20bytes of data using BIO_read like following.. int? ? res = BIO_read(bio, buf, 20);char *ptr = buf; The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures.? For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result.?22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30 This is what I was getting on my PPC platform which is as expected with the same app code.22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30 Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so.? I print the above output using the following code.? INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,"? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x",? ? ? ? ? ? ? ? ? ? ?ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4),? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9),? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14),? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19)));? -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.lynch at atos.net Fri Aug 9 12:48:02 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Fri, 9 Aug 2019 12:48:02 +0000 Subject: Does BIO_read() behave differently on diff architectures? In-Reply-To: <1392749700.3168567.1565342377790@mail.yahoo.com> References: <1392749700.3168567.1565342377790.ref@mail.yahoo.com> <1392749700.3168567.1565342377790@mail.yahoo.com> Message-ID: <3f3cc5f9e61c4e458663b2856f7139d4@atos.net> Hi, Your issue is not with BIO_read(), but with the differing signedness of the char type on your two platforms. On your PPC platform the char type defaults to unsigned, on your x86 platform it is signed. The %x format expects an unsigned int, so on x86 the signed char values are being sign-extended to int which adds the ffffff to any values where the high bit is set (i.e. seen as negative). One possible fix: Change "char *ptr = buf;" to "unsigned char *ptr = buf;", then you should get the expected output. Regards, Andrew. From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Venkata Veldanda via openssl-users Sent: Friday, August 09, 2019 11:20 AM To: openssl-users at openssl.org Subject: Does BIO_read() behave differently on diff architectures? Hi Experts, I am using openssl 1.0.2 I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read(). I read a 20bytes of data using BIO_read like following.. int res = BIO_read(bio, buf, 20); char *ptr = buf; The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures. For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result. 22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30 This is what I was getting on my PPC platform which is as expected with the same app code. 22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30 Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so. I print the above output using the following code. INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x," "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x", ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4), *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9), *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14), *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19))); -------------- next part -------------- An HTML attachment was scrubbed... URL: From dheinz at softwarekey.com Fri Aug 9 13:33:05 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Fri, 9 Aug 2019 13:33:05 +0000 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue Message-ID: I have a static library using OpenSSL (built as static library with the no-pinshared parameter in the configuration) that is then included in a DLL that gets loaded and unloaded many times by the calling application. Now that the code is in 1.1.1c to allow me to manually shutdown the OpenSSL library, I've run into an issue when loading and unloading my DLL multiple times from the calling application. I am testing this on Windows 10. A summary of what I am doing: 1. Calling executable calls LoadLibrary to load the DLL containing the static library that uses OpenSSL. 2. Calling executable calls a function of the now loaded DLL. 3. The DLL function calls a function in the static library to initialize OpenSSL using: openssl_result = OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, NULL); 4. The DLL function calls a function in the static library to decrypt some data using the RSA_private_decrypt OpenSSL API. 5. The DLL function calls a function in the static library to shutdown OpenSSL using: OPENSSL_cleanup(); (required) and CRYPTO_cleanup_all_ex_data(); (not sure if this is needed). 6. The calling executable uses FreeLibrary to unload the DLL. 7. The calling executable goes to step 1 to repeat the process. Iterating through the above steps always fails on iteration 1077. OpenSLL reports the error: error:4088003:rsa routines:RSA_setup_binding:BN lib After some debugging, I see that the failure happens in the function CRYPTO_THREAD_init_local in threads_win.c. *key = TlsAlloc(); fails with the error TLS_OUT_OF_INDEXES. Is something not being freed? Is there something additional I need to do at shutdown? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Aug 9 13:51:16 2019 From: matt at openssl.org (Matt Caswell) Date: Fri, 9 Aug 2019 14:51:16 +0100 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: References: Message-ID: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> On 09/08/2019 14:33, Dan Heinz wrote: > I have a static library using OpenSSL (built as static library with the > no-pinshared parameter in the configuration) that is then included in a DLL that > gets loaded and unloaded many times by the calling application.? Now that the > code is in 1.1.1c to allow me to manually shutdown the OpenSSL library, I?ve run > into an issue when loading and unloading my DLL multiple times from the calling > application.? I am testing this on Windows 10.? A summary of what I am doing: > > 1. Calling executable calls LoadLibrary to load the DLL containing the static > library that uses OpenSSL. > 2. Calling executable calls a function of the now loaded DLL. > 3. The DLL function calls a function in the static library to initialize > OpenSSL using: openssl_result = OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, > NULL); > 4. The DLL function calls a function in the static library to decrypt some data > using the RSA_private_decrypt OpenSSL API. > 5. The DLL function calls a function in the static library to shutdown OpenSSL > using: OPENSSL_cleanup(); (required) ?and CRYPTO_cleanup_all_ex_data(); (not > sure if this is needed). > 6. The calling executable uses FreeLibrary to unload the DLL. > 7. The calling executable goes to step 1 to? repeat the process. > > Iterating through the above steps always fails on iteration 1077.? OpenSLL > reports the error: > error:4088003:rsa routines:RSA_setup_binding:BN lib > > ? > > After some debugging, I see that the failure happens in the function > CRYPTO_THREAD_init_local in threads_win.c.? *key = TlsAlloc(); fails with the > error TLS_OUT_OF_INDEXES. > > Is something not being freed? Is there something additional I need to do at > shutdown?? For every call of CRYPTO_THREAD_init_local() while the library is running you should see a matching call to CRYPTO_THREAD_cleanup_local() to cleanup the index (as a result of an OPENSSL_cleanup() call). If you don't see that then an index is leaking. Matt From OSAMAM at microsoft.com Fri Aug 9 19:42:05 2019 From: OSAMAM at microsoft.com (Osama Mazahir) Date: Fri, 9 Aug 2019 19:42:05 +0000 Subject: Serialize/Deserialize SSL state Message-ID: Is there a way to serialize and deserialize the ssl_st state (i.e. including any child objects)? Background: I would like to handoff all the SSL state (along my own managed state, file descriptors, etc) to another Linux running process (I will handle the IPC handoff). The connection already had its handshake completed, app data flow had already occurred (i.e. it is not a new or early'ish context). So, trying to see if it is possible to serialize the openssl state, shove it through a unix domain socket to the target process and then have the target process unpack the openssl state and resume IO. -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Fri Aug 9 20:01:37 2019 From: tshort at akamai.com (Short, Todd) Date: Fri, 9 Aug 2019 20:01:37 +0000 Subject: Serialize/Deserialize SSL state In-Reply-To: References: Message-ID: <0433E758-0B50-4DE2-A46F-CF844AC5F57D@akamai.com> Not without a lot of work. It?s not part of the current API. We have tried doing an internal implementation; it was over 1K of new code, and it wasn?t complete. -- -Todd Short // tshort at akamai.com // ?One if by land, two if by sea, threeif by the Internet." > On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users wrote: > > Is there a way to serialize and deserialize the ssl_st state (i.e. including any child objects)? > > Background: I would like to handoff all the SSL state (along my own managed state, file descriptors, etc) to another Linux running process (I will handle the IPC handoff). The connection already had its handshake completed, app data flow had already occurred (i.e. it is not a new or early?ish context). So, trying to see if it is possible to serialize the openssl state, shove it through a unix domain socket to the target process and then have the target process unpack the openssl state and resume IO. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2991 bytes Desc: not available URL: From felipe at felipegasper.com Fri Aug 9 21:21:34 2019 From: felipe at felipegasper.com (Felipe Gasper) Date: Fri, 9 Aug 2019 17:21:34 -0400 Subject: Serialize/Deserialize SSL state In-Reply-To: References: Message-ID: <12287103-603A-4A47-89C7-4EDD19AD7F19@felipegasper.com> > On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users wrote: > > Is there a way to serialize and deserialize the ssl_st state (i.e. including any child objects)? > > Background: I would like to handoff all the SSL state (along my own managed state, file descriptors, etc) to another Linux running process (I will handle the IPC handoff). The connection already had its handshake completed, app data flow had already occurred (i.e. it is not a new or early?ish context). So, trying to see if it is possible to serialize the openssl state, shove it through a unix domain socket to the target process and then have the target process unpack the openssl state and resume IO. For what it?s worth, I have also wished for something like this, where I could pass a file descriptor as well as the OpenSSL state over a socket to a separate process. -Felipe Gasper Mississauga, Ontario From jb-openssl at wisemo.com Sat Aug 10 09:03:25 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Sat, 10 Aug 2019 11:03:25 +0200 Subject: Serialize/Deserialize SSL state In-Reply-To: <12287103-603A-4A47-89C7-4EDD19AD7F19@felipegasper.com> References: <12287103-603A-4A47-89C7-4EDD19AD7F19@felipegasper.com> Message-ID: On 09/08/2019 23:21, Felipe Gasper wrote: >> On Aug 9, 2019, at 3:42 PM, Osama Mazahir via openssl-users wrote: >> >> Is there a way to serialize and deserialize the ssl_st state (i.e. including any child objects)? >> >> Background: I would like to handoff all the SSL state (along my own managed state, file descriptors, etc) to another Linux running process (I will handle the IPC handoff). The connection already had its handshake completed, app data flow had already occurred (i.e. it is not a new or early?ish context). So, trying to see if it is possible to serialize the openssl state, shove it through a unix domain socket to the target process and then have the target process unpack the openssl state and resume IO. > For what it?s worth, I have also wished for something like this, where I could pass a file descriptor as well as the OpenSSL state over a socket to a separate process. > A possible workaround is to run the SSL code in a dedicated process and hand around a pipe or unix domain socket carrying the plaintext. If this is server side, the SSL process could be run under a dedicated UID which has exclusive access to load the private key etc., but no access to the stored application data. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From astib at mag0.net Mon Aug 12 09:01:18 2019 From: astib at mag0.net (Astib) Date: Mon, 12 Aug 2019 11:01:18 +0200 Subject: structure reference counter read-only access Message-ID: <87552184-1aba-09a5-f18c-4d39059c7919@mag0.net> Hello list, how one can access OpenSSL structure reference counter using new API, please? My intention is not to change it, I am interested in reading that value only, for debugging purposes. For example,|I am looking for something like this:|||| const||int X509_get_ref(X509 *a); ... which returns current reference counter of 'a'. Maybe I am missing something. Thanks, Ales| || | | From matt at openssl.org Mon Aug 12 10:09:44 2019 From: matt at openssl.org (Matt Caswell) Date: Mon, 12 Aug 2019 11:09:44 +0100 Subject: structure reference counter read-only access In-Reply-To: <87552184-1aba-09a5-f18c-4d39059c7919@mag0.net> References: <87552184-1aba-09a5-f18c-4d39059c7919@mag0.net> Message-ID: <31ec5110-fe98-f0c5-658a-50602e59377a@openssl.org> On 12/08/2019 10:01, Astib wrote: > Hello list, > how one can access OpenSSL structure reference counter > using new API, please? > > My intention is not to change it, I am interested > in reading that value only, for debugging purposes. > > For example,|I am looking for something like this:|||| > > const||int X509_get_ref(X509 *a); > > ... which returns current reference counter of 'a'. > > Maybe I am missing something. This counter is considered internal data and is therefore not accessible via the API. Matt From astib at mag0.net Mon Aug 12 11:00:30 2019 From: astib at mag0.net (Astib) Date: Mon, 12 Aug 2019 13:00:30 +0200 Subject: structure reference counter read-only access In-Reply-To: <31ec5110-fe98-f0c5-658a-50602e59377a@openssl.org> References: <87552184-1aba-09a5-f18c-4d39059c7919@mag0.net> <31ec5110-fe98-f0c5-658a-50602e59377a@openssl.org> Message-ID: <456fcea6-91cc-febd-9345-3719477767d5@mag0.net> Hi Matt, thank you for response. I understand it's internal data. This is why I was looking for function which returns its value, without really exposing it outside. In my case it helped me many times to see reference counter to troubleshoot leaks and features of my project. Compared to enabling traces and other debugs, reference counters stats are cheap way to see if there is something happening or not. Maybe ... could you please consider to expose this integer via API? If so, I am prepared to help and contribute a patch for that. Thanks, Ales On 12. 08. 19 12:09, Matt Caswell wrote: > > > On 12/08/2019 10:01, Astib wrote: >> Hello list, >> how one can access OpenSSL structure reference counter >> using new API, please? >> >> My intention is not to change it, I am interested >> in reading that value only, for debugging purposes. >> >> For example,|I am looking for something like this:|||| >> >> const||int X509_get_ref(X509 *a); >> >> ... which returns current reference counter of 'a'. >> >> Maybe I am missing something. > > This counter is considered internal data and is therefore not accessible via the > API. > > Matt > From vvr.83 at yahoo.com Tue Aug 13 05:37:49 2019 From: vvr.83 at yahoo.com (Venkata Veldanda) Date: Tue, 13 Aug 2019 05:37:49 +0000 (UTC) Subject: Does BIO_read() behave differently on diff architectures? In-Reply-To: <3f3cc5f9e61c4e458663b2856f7139d4@atos.net> References: <1392749700.3168567.1565342377790.ref@mail.yahoo.com> <1392749700.3168567.1565342377790@mail.yahoo.com> <3f3cc5f9e61c4e458663b2856f7139d4@atos.net> Message-ID: @Andrew - Thanks for pointing that out. Indeed, that was the issue. Get Outlook for Android On Fri, Aug 9, 2019 at 6:18 PM +0530, "Lynch, Andrew" wrote: Hi, ? Your issue is not with BIO_read(), but with the differing signedness of the char type on your two platforms. ? On your PPC platform the char type defaults to unsigned, on your x86 platform it is signed.? The %x format expects an unsigned int, so on x86 the signed char values are being sign-extended to int which adds the ffffff to any values where the high bit is set (i.e. seen as negative). ? One possible fix:? Change "char *ptr = buf;" to "unsigned char *ptr = buf;", then you should get the expected output. Regards, Andrew. ? From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Venkata Veldanda via openssl-users Sent: Friday, August 09, 2019 11:20 AM To: openssl-users at openssl.org Subject: Does BIO_read() behave differently on diff architectures? ? Hi Experts, ? I am using openssl 1.0.2? ? I recently moved my app from a PPC to x86 platform (application is compiled on the respective platform) where I met an issue with BIO_read().? ? I read a 20bytes of data using BIO_read like following.. ? int? ? res = BIO_read(bio, buf, 20); char *ptr = buf; ? The content that I send as input is a signed file content that I get from a different source. The issue is that the output 'buf' is not as expected on my x86. The behavior is different on different architectures.? ? For e.g. on intel x86 platform I get the following output with additional 0xffffff padded.>> For me this is not the expected result.? 22,ffffff82,2b,28,06,09,2a,ffffff86,48,ffffff86,fffffff7,0d,02,09,02,ffffffa0,ffffff82,3b,12,30 ? This is what I was getting on my PPC platform which is as expected with the same app code. 22,82,2b,28,06,09,2a,86,48,86,f7,0d,02,09,02,a0,82,3b,12,30 ? Ofcourse, I need to further check on the source where/how the signed file was generated, but does anyone have any idea if BIO_read() has any specific handling with repsect to architectures?. I'd rule out the endianess factor as I would expect the entire byte order to be reversed if so.? ? I print the above output using the following code.? INFO( STR(" ..> Header@%02d: %02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x," ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? "%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x,%02x", ? ? ? ? ? ? ? ? ? ? ?ptr-buf, *(ptr+0),*(ptr+1),*(ptr+2),*(ptr+3),*(ptr+4), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+5),*(ptr+6),*(ptr+7),*(ptr+8),*(ptr+9), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+10),*(ptr+11),*(ptr+12),*(ptr+13),*(ptr+14), ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? *(ptr+15),*(ptr+16),*(ptr+17),*(ptr+18),*(ptr+19)));? ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.redmi2 at gmail.com Tue Aug 13 06:48:54 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Tue, 13 Aug 2019 12:18:54 +0530 Subject: OpenSSL FIPS mode for libcurl Message-ID: Hi, I am able to run an application using libcurl which in turn uses OpenSSL in FIPS mode with following configuration Help requested Need opinion from seniors who know OpenSSL and libcurl codebase if following is good from conceptual perspective with respect to OpenSSL, libcurl. a) Built static libcurl using 'FIPS capable OpenSSL'. These OpenSSL libs were generated earlier as static libraries. b) In my application, called SSL_Library_Init() followed by FIPS_mode_set() and other APIs to confirm that FIPS mode is on. c) Added curl API to do http post using the easy interface. d) Built my application by linking to static libcurl.lib in point (a) and static FIPS capable OpenSSL .libs. 3) Wireshark shows +be result. Questions - Q1) Conceptually, can libcurl work using the CipherSuites selected by FIPS capable OpenSSL in the above example? Thus, can we say that libcurl will always be using CipherSuites selected by the FIPS capable OpenSSL and thus is FIPS compliant.? Q2) Or are changes to libcurl source code an absolute must to run it in FIPS compliant mode for above configuration. Appreciate all inputs. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hareesh.sai at gmail.com Tue Aug 13 13:44:06 2019 From: hareesh.sai at gmail.com (Hareesh D) Date: Tue, 13 Aug 2019 19:14:06 +0530 Subject: About truncation in SM2 signature !! Message-ID: Can someone please tell me if Digest has to be Truncated while generating and verifying SM2 signatures. I see it has to be truncated in case of Ecdsa signature. Thanks !! -------------- next part -------------- An HTML attachment was scrubbed... URL: From dheinz at softwarekey.com Tue Aug 13 18:16:00 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Tue, 13 Aug 2019 18:16:00 +0000 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> Message-ID: On 09/08/2019 14:33, Dan Heinz wrote: >> I have a static library using OpenSSL (built as static library with >> the no-pinshared parameter in the configuration) that is then included >> in a DLL that gets loaded and unloaded many times by the calling >> application.? Now that the code is in 1.1.1c to allow me to manually >> shutdown the OpenSSL library, I've run into an issue when loading and >> unloading my DLL multiple times from the calling application.? I am testing this on Windows 10.? A summary of what I am doing: >> >> 1. Calling executable calls LoadLibrary to load the DLL containing the static >> library that uses OpenSSL. >> 2. Calling executable calls a function of the now loaded DLL. >> 3. The DLL function calls a function in the static library to initialize >> OpenSSL using: openssl_result = OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, >> NULL); >> 4. The DLL function calls a function in the static library to decrypt some data >> using the RSA_private_decrypt OpenSSL API. >> 5. The DLL function calls a function in the static library to shutdown OpenSSL >> using: OPENSSL_cleanup(); (required) ?and CRYPTO_cleanup_all_ex_data(); (not >> sure if this is needed). >> 6. The calling executable uses FreeLibrary to unload the DLL. >> 7. The calling executable goes to step 1 to? repeat the process. >> >> Iterating through the above steps always fails on iteration 1077.? >> OpenSLL reports the error: >> error:4088003:rsa routines:RSA_setup_binding:BN lib >> >> ? >> >> After some debugging, I see that the failure happens in the function >> CRYPTO_THREAD_init_local in threads_win.c.? *key = TlsAlloc(); fails >> with the error TLS_OUT_OF_INDEXES. >> >> Is something not being freed? Is there something additional I need to >> do at shutdown? >For every call of CRYPTO_THREAD_init_local() while the library is running you should see a matching call to CRYPTO_THREAD_cleanup_local() to cleanup the index (as a result of an OPENSSL_cleanup() call). If you don't see that then an >index is leaking. Thanks for the guidance, Matt. I added some code to output the counts of the calls to TlsAlloc and TlsFree. I see 4 allocations and 4 matching deallocations for each iteration of my tests. The allocations/deallocations are for: destructor_key.value in OPENSSL_cleanup() private_drbg (from CRYPTO_THREAD_init_local(&private_drbg, NULL)) public_drbg (from CRYPTO_THREAD_init_local(&public_drbg, NULL)) err_thread_local (fromCRYPTO_THREAD_init_local(&err_thread_local, NULL)) On the 1076th test iteration, I get the error (TLS_OUT_OF_INDEXES) from TlsAlloc. I checked for any errors from TlsFree during the tests and it always returns success. One thing I did notice is that the index value (from this line: *key = TlsAlloc()) is always incremented by 1 after each test iteration. The destructor_key.value always stayed the same number (7), but the other three allocations always incremented the value of the key variable. By the time my test reaches the 1076th iteration, the value of key is just under 2000. For example the indices from TlsAlloc might be 10,11, and 12 and the next iteration they are 11, 12, 13. MS documentation states "The maximum number of indexes per process is 1,088" which seems to coincide with the number of my test iterations. None of my code uses thread local storage. Any ideas? Here's some output from my tests (note the key values keep incrementing). Iteration: 1 *********************************************** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 9 TlsAlloc called. AllocationCount: 2 Key value: 10 TlsAlloc called. AllocationCount: 3 Key value: 11 TlsAlloc called. AllocationCount: 4 TlsFree called. AllocationCount: 3 TlsFree called. AllocationCount: 2 TlsFree called. AllocationCount: 1 TlsFree called. AllocationCount: 0 Iteration: 2 *********************************************** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 10 TlsAlloc called. AllocationCount: 2 Key value: 11 TlsAlloc called. AllocationCount: 3 Key value: 12 TlsAlloc called. AllocationCount: 4 TlsFree called. AllocationCount: 3 TlsFree called. AllocationCount: 2 TlsFree called. AllocationCount: 1 TlsFree called. AllocationCount: 0 ..... Iteration: 1076 *********************************************** Key value: 7 TlsAlloc called. AllocationCount: 1 Key value: 1086 TlsAlloc called. AllocationCount: 2 Key value: 1087 TlsAlloc called. AllocationCount: 3 Key value: 4294967295 (this is TLS_OUT_OF_INDEXES) From matt at openssl.org Tue Aug 13 18:48:43 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 13 Aug 2019 19:48:43 +0100 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> Message-ID: <8746a15d-e43c-1baa-a74e-49c5f59da1b7@openssl.org> On 13/08/2019 19:16, Dan Heinz wrote: > On 09/08/2019 14:33, Dan Heinz wrote: >>> I have a static library using OpenSSL (built as static library with the >>> no-pinshared parameter in the configuration) that is then included in a >>> DLL that gets loaded and unloaded many times by the calling application. >>> Now that the code is in 1.1.1c to allow me to manually shutdown the >>> OpenSSL library, I've run into an issue when loading and unloading my DLL >>> multiple times from the calling application. I am testing this on >>> Windows 10. A summary of what I am doing: >>> >>> 1. Calling executable calls LoadLibrary to load the DLL containing the >>> static library that uses OpenSSL. 2. Calling executable calls a function >>> of the now loaded DLL. 3. The DLL function calls a function in the static >>> library to initialize OpenSSL using: openssl_result = >>> OPENSSL_init_crypto(OPENSSL_INIT_NO_ATEXIT, NULL); 4. The DLL function >>> calls a function in the static library to decrypt some data using the >>> RSA_private_decrypt OpenSSL API. 5. The DLL function calls a function in >>> the static library to shutdown OpenSSL using: OPENSSL_cleanup(); >>> (required) and CRYPTO_cleanup_all_ex_data(); (not sure if this is >>> needed). 6. The calling executable uses FreeLibrary to unload the DLL. 7. >>> The calling executable goes to step 1 to repeat the process. >>> >>> Iterating through the above steps always fails on iteration 1077. OpenSLL >>> reports the error: error:4088003:rsa routines:RSA_setup_binding:BN lib >>> >>> >>> >>> After some debugging, I see that the failure happens in the function >>> CRYPTO_THREAD_init_local in threads_win.c. *key = TlsAlloc(); fails with >>> the error TLS_OUT_OF_INDEXES. >>> >>> Is something not being freed? Is there something additional I need to do >>> at shutdown? > >> For every call of CRYPTO_THREAD_init_local() while the library is running >> you should see a matching call to CRYPTO_THREAD_cleanup_local() to cleanup >> the index (as a result of an OPENSSL_cleanup() call). If you don't see that >> then an >index is leaking. > > > Thanks for the guidance, Matt. I added some code to output the counts of the > calls to TlsAlloc and TlsFree. I see 4 allocations and 4 matching > deallocations for each iteration of my tests. The allocations/deallocations > are for: > > destructor_key.value in OPENSSL_cleanup() private_drbg (from > CRYPTO_THREAD_init_local(&private_drbg, NULL)) public_drbg (from > CRYPTO_THREAD_init_local(&public_drbg, NULL)) err_thread_local > (fromCRYPTO_THREAD_init_local(&err_thread_local, NULL)) > > On the 1076th test iteration, I get the error (TLS_OUT_OF_INDEXES) from > TlsAlloc. > > I checked for any errors from TlsFree during the tests and it always returns > success. One thing I did notice is that the index value (from this line: *key > = TlsAlloc()) is always incremented by 1 after each test iteration. The > destructor_key.value always stayed the same number (7), but the other three > allocations always incremented the value of the key variable. That is quite strange behaviour. I can't think of a good reason why that particular index should always be the same while the others increment. I suppose the 4 deallocation calls that you see are deallocating the correct index? And that the TlsFree calls actually succeed? I'm not really a Windows programmer, so perhaps others who have more knowledge of Windows than I do can make some suggestions. Matt > By the time my > test reaches the 1076th iteration, the value of key is just under 2000. For > example the indices from TlsAlloc might be 10,11, and 12 and the next > iteration they are 11, 12, 13. MS documentation states "The maximum number > of indexes per process is 1,088" which seems to coincide with the number of > my test iterations. None of my code uses thread local storage. Any ideas? > > > Here's some output from my tests (note the key values keep incrementing). > Iteration: 1 *********************************************** Key value: 7 > TlsAlloc called. AllocationCount: 1 Key value: 9 TlsAlloc called. > AllocationCount: 2 Key value: 10 TlsAlloc called. AllocationCount: 3 Key > value: 11 TlsAlloc called. AllocationCount: 4 TlsFree called. > AllocationCount: 3 TlsFree called. AllocationCount: 2 TlsFree called. > AllocationCount: 1 TlsFree called. AllocationCount: 0 Iteration: 2 > *********************************************** Key value: 7 TlsAlloc called. > AllocationCount: 1 Key value: 10 TlsAlloc called. AllocationCount: 2 Key > value: 11 TlsAlloc called. AllocationCount: 3 Key value: 12 TlsAlloc called. > AllocationCount: 4 TlsFree called. AllocationCount: 3 TlsFree called. > AllocationCount: 2 TlsFree called. AllocationCount: 1 TlsFree called. > AllocationCount: 0 > > ..... > > Iteration: 1076 *********************************************** Key value: > 7 TlsAlloc called. AllocationCount: 1 Key value: 1086 TlsAlloc called. > AllocationCount: 2 Key value: 1087 TlsAlloc called. AllocationCount: 3 Key > value: 4294967295 (this is TLS_OUT_OF_INDEXES) > > > From Michael.Wojcik at microfocus.com Tue Aug 13 19:49:22 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Tue, 13 Aug 2019 19:49:22 +0000 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: <8746a15d-e43c-1baa-a74e-49c5f59da1b7@openssl.org> References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> <8746a15d-e43c-1baa-a74e-49c5f59da1b7@openssl.org> Message-ID: The output certainly suggests something is calling TlsAlloc between the call made for destructor_key.value and the one for private_drbg, and that index is never freed. You always get 7 when allocating destructor_key.value because that index was freed when you unloaded OpenSSL, and so it's the next available one when you load OpenSSL again. It may not be OpenSSL itself that's calling TlsAlloc and not releasing an index - it may be one of its dependencies. Have you duplicated this under a debugger, with a breakpoint on TlsAlloc? The earlier messages suggest that you may have, but it's not entirely clear from what you posted. You ought to be able to catch the offending call and get at least a partial traceback. If you're having trouble tracing it, you could try adding this: {int i; for (i=8; i Hey All Im trying to cross compile openssl for android using the *setenv-android.sh* script according to the steps on the wiki, It sets the environment variables correctly but when I run ./config from within the project it proceeds to target i686-apple-darwin instead of android. I had this working a few weeks back and took a break on the build and now the setenv-android script seems to be ignored, any tips to get the cross compile script working again? Thanks! -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From rgm at htt-consult.com Wed Aug 14 02:55:17 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 13 Aug 2019 22:55:17 -0400 Subject: IPv6 address encoding in commonName Message-ID: I am fiddling around with an intermediate CA signing cert that the CA's 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). For a client cert, it would be easy to put the HIT in subjectAltName per RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty subjectName. Thus all I want in this subjectName is commonName with the HIT. I am looking for examples of IPv6 addresses in commonName. My searches today have come up empty. Thank for any reference(s). From somkadam76 at gmail.com Wed Aug 14 03:29:25 2019 From: somkadam76 at gmail.com (Somshekar C Kadam) Date: Wed, 14 Aug 2019 08:59:25 +0530 Subject: Openssl and tls 1.2 In-Reply-To: References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> Message-ID: Hi , we are running java 1.6 (older build) and java 1.8(newer build) on the same arm target board with different builds. On 1.6 java we have Linux Kernel 2.6.35 and with Java 1.8 Linux kernel 4.x. version. so 2 environments and 2 use cases newer and older build. while we access https website link https://transparencyreport.google.com/https/overview?hl=en we see it takes less than 2 seconds using java 1.6. (older build) we see it takes 10 seconds using java 1.8 (newer build) On Java 1.8 did try disabling GCM ciphers and trying still we get the same 10 seconds delay. Attaching log of tls handshake for both. Not sure its to do with tls, may be java is causing the delay. I am not sure, please provide any pointers or feedback to rootcause it that will help to understand why we get 10seconds delay. One more info if just use curl on on newer build setup, it works fine within 2 seconds to access the https link. Regards Somshekar C Kadam 9036660538 > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- trigger seeding of SecureRandom done seeding SecureRandom Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false %% No cached client session *** ClientHello, TLSv1 RandomCookie: GMT: 1565589724 bytes = { 28, 22, 178, 239, 29, 7, 47, 174, 250, 171, 197, 25, 93, 255, 194, 202, 106, 235, 247, 232, 181, 51, 10, 143, 1, 145, 240, 220 } Session ID: {} Cipher Suites: [SSL_RSA_WITH_RC4_128_MD5, SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_AES_128_CBC_SHA, TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_128_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_DSS_WITH_AES_128_CBC_SHA, TLS_DHE_DSS_WITH_AES_256_CBC_SHA, SSL_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA, SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA, SSL_RSA_WITH_DES_CBC_SHA, SSL_DHE_RSA_WITH_DES_CBC_SHA, SSL_DHE_DSS_WITH_DES_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5, SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA, TLS_EMPTY_RENEGOTIATION_INFO_SCSV] Compression Methods: { 0 } *** main, WRITE: TLSv1 Handshake, length = 81 main, WRITE: SSLv2 client hello message, length = 110 main, READ: TLSv1 Handshake, length = 81 *** ServerHello, TLSv1 RandomCookie: GMT: 1565589726 bytes = { 95, 183, 13, 179, 158, 139, 220, 121, 126, 177, 252, 92, 190, 70, 216, 42, 44, 211, 170, 12, 68, 79, 87, 78, 71, 82, 68, 0 } Session ID: {218, 176, 53, 135, 9, 102, 98, 200, 249, 250, 100, 210, 61, 85, 125, 213, 80, 185, 85, 50, 109, 140, 181, 243, 66, 73, 21, 167, 101, 144, 37, 142} Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA Compression Method: 0 Extension renegotiation_info, renegotiated_connection: *** %% Created: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA] ** TLS_RSA_WITH_AES_128_CBC_SHA main, READ: TLSv1 Handshake, length = 3404 *** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=*.google.com, O=Google LLC, L=Mountain View, ST=California, C=US Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 24518014405162799800514059581807559995512519444155672709007122525608686599568979665780560905894859791170019462635081390454603906293405253903613762262663681232770891710819918152806000474026296132824236721211250098971359223037306490837258618004444391463235080498129497922762630417537181179971236829563281164338680992821081781099108672248557754696819438647721111035897640898641778595308067540309939544912886565922473092234490442592589841706182290746974282686920486312604695195928067536451594810730756448614586986400482653133247203222853000557785259166528637871490302752850099518899633231236493795050081835001646811083199 public exponent: 65537 Validity: [From: Tue Jul 30 00:14:13 GMT+05:30 2019, To: Mon Oct 21 23:53:00 GMT+05:30 2019] Issuer: CN=Google Internet Authority G3, O=Google Trust Services, C=US SerialNumber: [ 1b0b4c01 0d429a9d 993930f3 79310ee0] Certificate Extensions: 8 [1]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 4D 8A E9 66 E7 F5 44 6E 4F 22 BA DC 57 7B 00 26 M..f..DnO"..W..& 0010: 21 FE 73 91 !.s. ] ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 77 C2 B8 50 9A 67 76 76 B1 2D C2 86 D0 83 A0 7E w..P.gvv.-...... 0010: A6 7E BA 4B ...K ] ] [3]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.pki.goog/GTSGIAG3.crl] ]] [4]: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: *.google.com DNSName: *.android.com DNSName: *.appengine.google.com DNSName: *.cloud.google.com DNSName: *.crowdsource.google.com DNSName: *.g.co DNSName: *.gcp.gvt2.com DNSName: *.gcpcdn.gvt1.com DNSName: *.ggpht.cn DNSName: *.google-analytics.com DNSName: *.google.ca DNSName: *.google.cl DNSName: *.google.co.in DNSName: *.google.co.jp DNSName: *.google.co.uk DNSName: *.google.com.ar DNSName: *.google.com.au DNSName: *.google.com.br DNSName: *.google.com.co DNSName: *.google.com.mx DNSName: *.google.com.tr DNSName: *.google.com.vn DNSName: *.google.de DNSName: *.google.es DNSName: *.google.fr DNSName: *.google.hu DNSName: *.google.it DNSName: *.google.nl DNSName: *.google.pl DNSName: *.google.pt DNSName: *.googleadapis.com DNSName: *.googleapis.cn DNSName: *.googlecnapps.cn DNSName: *.googlecommerce.com DNSName: *.googlevideo.com DNSName: *.gstatic.cn DNSName: *.gstatic.com DNSName: *.gstaticcnapps.cn DNSName: *.gvt1.com DNSName: *.gvt2.com DNSName: *.metric.gstatic.com DNSName: *.urchin.com DNSName: *.url.google.com DNSName: *.youtube-nocookie.com DNSName: *.youtube.com DNSName: *.youtubeeducation.com DNSName: *.youtubekids.com DNSName: *.yt.be DNSName: *.ytimg.com DNSName: android.clients.google.com DNSName: android.com DNSName: developer.android.google.cn DNSName: developers.android.google.cn DNSName: g.co DNSName: ggpht.cn DNSName: goo.gl DNSName: google-analytics.com DNSName: google.com DNSName: googlecnapps.cn DNSName: googlecommerce.com DNSName: source.android.google.cn DNSName: urchin.com DNSName: www.goo.gl DNSName: youtu.be DNSName: youtube.com DNSName: youtubeeducation.com DNSName: youtubekids.com DNSName: yt.be ] [5]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [1.3.6.1.4.1.11129.2.5.3] [] ] [CertificatePolicyId: [2.23.140.1.2.2] [] ] ] [6]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth ] [7]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen: undefined ] [8]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: caIssuers accessLocation: URIName: http://pki.goog/gsr2/GTSGIAG3.crt, accessMethod: ocsp accessLocation: URIName: http://ocsp.pki.goog/GTSGIAG3] ] ] Algorithm: [SHA256withRSA] Signature: 0000: C5 6B 58 EA 3E 77 D3 57 B2 14 66 87 51 44 F2 57 .kX.>w.W..f.QD.W 0010: C8 30 4C E1 66 53 80 D9 1D 45 BA 4A E8 A2 7A 0E .0L.fS...E.J..z. 0020: AD 2A EE 81 C1 DD 53 CE 4D 1A 34 E2 C7 76 74 22 .*....S.M.4..vt" 0030: 4A 3B 33 E8 81 64 E2 7C 0D D4 89 77 7D 25 A6 8E J;3..d.....w.%.. 0040: 4C BA 62 E8 96 95 13 F3 98 C4 BB D9 84 39 AC 49 L.b..........9.I 0050: 10 A2 21 53 7A 55 D6 FB 0C F5 7F 0D 49 16 62 7E ..!SzU......I.b. 0060: 78 12 55 30 56 6F 6F 26 44 F8 9A 8E A7 95 C2 20 x.U0Voo&D...... 0070: 14 0B 6F 97 41 35 AD AD 38 66 4D 22 4C 3F E7 6C ..o.A5..8fM"L?.l 0080: A0 EE 26 1C 30 42 2D FD AF 2B 4B FD 5F 5F 4D B1 ..&.0B-..+K.__M. 0090: B0 02 5F BF 90 2E 4D EF B0 80 B3 32 12 24 4D 40 .._...M....2.$M@ 00A0: C7 29 5B 69 F8 96 B1 0E 86 91 9D 39 84 8B E4 46 .)[i.......9...F 00B0: EB E6 5B CC CE 4E 60 86 8E A2 B8 31 11 DF 77 62 ..[..N`....1..wb 00C0: C9 92 67 EE B6 6C CA 7A 6C 76 25 4F 3F C8 43 EB ..g..l.zlv%O?.C. 00D0: 1B 18 AB AD F9 9A 32 71 8E A4 A4 CF 53 1A F0 A2 ......2q....S... 00E0: 5E 8D 4E 27 55 F5 75 2B 9A 5A 41 70 7A 6D 1D 4D ^.N'U.u+.ZApzm.M 00F0: 13 5A A5 4B B0 0E 12 73 80 6E 9E AC CA 47 5C 92 .Z.K...s.n...G\. ] chain [1] = [ [ Version: V3 Subject: CN=Google Internet Authority G3, O=Google Trust Services, C=US Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 25540719540096549801967532215622388028057340978592080609141732382164154646816296526083121741669679112385237833865384918487699354232562775118368146858293595735927525741548199921580705526790385577846106238921439103492392479618335857028746954930496648766472236039621875919970487709839673576509420299423776077274146396625683921324935984297937024355312712214769839608906726548857225274820644855735385444361318783494335259738982362137265282486277074790515499222682891121616563234042637263891559249011361734853144492241992433528066411156317991355405830410464673595997849166914573354017491657353926030969623191808378512203827 public exponent: 65537 Validity: [From: Thu Jun 15 05:30:42 GMT+05:30 2017, To: Wed Dec 15 05:30:42 GMT+05:30 2021] Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 SerialNumber: [ 01e3a930 1cfc7206 383f9a53 1d] Certificate Extensions: 8 [1]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 77 C2 B8 50 9A 67 76 76 B1 2D C2 86 D0 83 A0 7E w..P.gvv.-...... 0010: A6 7E BA 4B ...K ] ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 9B E2 07 57 67 1C 1E C0 6A 06 DE 59 B4 9A 2D DF ...Wg...j..Y..-. 0010: DC 19 86 2E .... ] ] [3]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.pki.goog/gsr2/gsr2.crl] ]] [4]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [2.23.140.1.2.2] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 1C 68 74 74 70 73 3A 2F 2F 70 6B 69 2E 67 6F ..https://pki.go 0010: 6F 67 2F 72 65 70 6F 73 69 74 6F 72 79 2F og/repository/ ]] ] ] [5]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] [6]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] [7]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: ocsp accessLocation: URIName: http://ocsp.pki.goog/gsr2] ] [8]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:0 ] ] Algorithm: [SHA256withRSA] Signature: 0000: 1C B7 89 96 E4 53 ED BB EC DB A8 32 01 9F 2C A3 .....S.....2..,. 0010: CD 6D AD 42 12 77 B3 B8 E6 C9 03 52 60 20 7B 57 .m.B.w.....R` .W 0020: 27 C6 11 B5 3F 67 0D 99 2C 5B 5A CA 22 0A DD 9E '...?g..,[Z."... 0030: BB 1F 4B 48 3F 8F 02 3D 8B 21 84 45 1D 6D F5 FF ..KH?..=.!.E.m.. 0040: AC 68 89 CD 64 E2 D6 D6 5E 40 C2 8E 2A F7 EF 14 .h..d...^@..*... 0050: D3 36 A4 40 30 F5 32 15 15 92 76 FB 7E 9E 53 EA .6. at 0.2...v...S. 0060: C2 76 FC 39 AD 88 FE 66 92 26 E9 1C C4 38 CD 49 .v.9...f.&...8.I 0070: FA 43 87 F0 5D D6 56 4D 81 D7 7F F1 C2 DD B0 4D .C..].VM.......M 0080: FE C3 2A 6E 7C 9F 6E 5C ED 62 42 99 E1 F7 36 EE ..*n..n\.bB...6. 0090: 14 8C 2C 20 E3 46 97 5A 77 03 C0 A0 C6 4A 88 FD .., .F.Zw....J.. 00A0: 40 22 87 72 5A 18 EA 9C A5 C7 5A 08 8C E4 05 A4 @".rZ.....Z..... 00B0: 7D B9 84 35 5F 89 36 56 0E 40 3D 12 E8 BB 35 72 ...5_.6V.@=...5r 00C0: ED AF 08 56 4E B0 BB 2E A9 9B E4 FB 1D 3E 0B 63 ...VN........>.c 00D0: C8 9B 4B 91 44 66 57 C0 14 B4 96 F0 DC 2C 57 3F ..K.DfW......,W? 00E0: 52 04 AD 95 AA 7D 4D D0 F2 0C 9F 9C 40 E8 D6 55 R.....M..... at ..U 00F0: 73 BA 3C DF 90 CB 00 5B 21 11 67 C2 ED 32 1E DE s.<....[!.g..2.. ] *** main, READ: TLSv1 Handshake, length = 4 *** ServerHelloDone *** ClientKeyExchange, RSA PreMasterSecret, TLSv1 main, WRITE: TLSv1 Handshake, length = 262 SESSION KEYGEN: PreMaster Secret: 0000: 03 01 5A 46 75 DA BD 1D DA 18 4B 6E 1B 5C CC 54 ..ZFu.....Kn.\.T 0010: 63 08 65 EE 1B ED A7 AC 81 85 14 E3 22 FD 66 10 c.e.........".f. 0020: 65 3D 61 C2 AA FD B8 12 21 D9 D0 5C 28 D3 33 F0 e=a.....!..\(.3. CONNECTION KEYGEN: Client Nonce: 0000: 5D 51 01 DC 1C 16 B2 EF 1D 07 2F AE FA AB C5 19 ]Q......../..... 0010: 5D FF C2 CA 6A EB F7 E8 B5 33 0A 8F 01 91 F0 DC ]...j....3...... Server Nonce: 0000: 5D 51 01 DE 5F B7 0D B3 9E 8B DC 79 7E B1 FC 5C ]Q.._......y...\ 0010: BE 46 D8 2A 2C D3 AA 0C 44 4F 57 4E 47 52 44 00 .F.*,...DOWNGRD. Master Secret: 0000: 3B 6B C9 EC 18 09 83 C0 27 5F E5 E0 95 8C 4C F3 ;k......'_....L. 0010: EF E7 FC 9E C4 BA DD 2C E1 24 32 3B 70 1D A4 77 .......,.$2;p..w 0020: CE F1 33 FB D4 0D 3D F1 D4 E7 27 91 9E 84 4F 93 ..3...=...'...O. Client MAC write Secret: 0000: 63 C0 F6 BD 6E 04 E4 81 11 7F 66 E7 58 EC FB 13 c...n.....f.X... 0010: 0B 6C 01 42 .l.B Server MAC write Secret: 0000: 5D 71 C4 47 78 35 48 C5 BA 0F FB 35 AE 1B D0 F7 ]q.Gx5H....5.... 0010: 69 D4 28 17 i.(. Client write key: 0000: EB AF 42 FE B7 7B 96 1D C5 42 87 2B A7 9C 7C 44 ..B......B.+...D Server write key: 0000: 2F EE 19 AF 30 BA B3 07 5E FA AA 26 DE BF E7 63 /...0...^..&...c Client write IV: 0000: FE E7 8E 6D 99 AD 42 46 A2 1D 78 4E F4 AE 1F 81 ...m..BF..xN.... Server write IV: 0000: 2D 0B 1C B0 10 38 AB 21 81 24 7A 9D 4D 64 E5 E1 -....8.!.$z.Md.. main, WRITE: TLSv1 Change Cipher Spec, length = 1 *** Finished verify_data: { 7, 117, 76, 136, 80, 45, 35, 181, 237, 107, 142, 147 } *** main, WRITE: TLSv1 Handshake, length = 48 main, READ: TLSv1 Change Cipher Spec, length = 1 main, READ: TLSv1 Handshake, length = 48 *** Finished verify_data: { 165, 216, 82, 187, 250, 22, 139, 115, 28, 13, 50, 89 } *** %% Cached client session: [Session-1, TLS_RSA_WITH_AES_128_CBC_SHA] main, WRITE: TLSv1 Application Data, length = 224 main, READ: TLSv1 Application Data, length = 1408 Succesfull connected. Data: main, READ: TLSv1 Application Data, length = 1408 main, READ: TLSv1 Application Data, length = 512 Google Transparency Report -------------- next part -------------- Level: 4 trigger seeding of SecureRandom done seeding SecureRandom Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 Ignoring unavailable cipher suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA Ignoring unavailable cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 Allow unsafe renegotiation: false Allow legacy hello messages: true Is initial handshake: true Is secure renegotiation: false main, setSoTimeout(0) called Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1 Ignoring unsupported cipher suite: TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 for TLSv1.1 Ignoring unsupported cipher suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 for TLSv1.1 %% No cached client session *** ClientHello, TLSv1.2 RandomCookie: GMT: 1565523786 bytes = { 179, 93, 102, 222, 25, 182, 105, 17, 224, 14, 150, 154, 195, 24, 3, 14, 135, 190, 45, 60, 238, 209, 7} Session ID: {} Cipher Suites: [TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256, TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_ECDH_ECDS] Compression Methods: { 0 } Extension elliptic_curves, curve names: {secp256r1, sect163k1, sect163r2, secp192r1, secp224r1, sect233k1, sect233r1, sect283k1, sect283r1, se} Extension ec_point_formats, formats: [uncompressed] Extension signature_algorithms, signature_algorithms: SHA512withECDSA, SHA512withRSA, SHA384withECDSA, SHA384withRSA, SHA256withECDSA, SHA256wA Extension renegotiation_info, renegotiated_connection: *** main, WRITE: TLSv1.2 Handshake, length = 186 main, READ: TLSv1.2 Handshake, length = 87 *** ServerHello, TLSv1.2 RandomCookie: GMT: 1565523608 bytes = { 177, 25, 113, 195, 253, 50, 165, 172, 165, 35, 182, 83, 48, 169, 8, 77, 185, 126, 47, 27, 68, 79, 87,} Session ID: {49, 49, 2, 186, 216, 122, 147, 53, 84, 145, 221, 31, 92, 226, 216, 81, 148, 17, 250, 198, 213, 142, 188, 231, 215, 106, 37, 187,} Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 Compression Method: 0 Extension renegotiation_info, renegotiated_connection: Extension ec_point_formats, formats: [uncompressed] *** %% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] ** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 main, READ: TLSv1.2 Handshake, length = 3404 *** Certificate chain chain [0] = [ [ Version: V3 Subject: CN=*.google.com, O=Google LLC, L=Mountain View, ST=California, C=US Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 245180144051627998005140595818075599955125194441556727090071225256086865995689796657805609058948597911700194626350813904546039062939 public exponent: 65537 Validity: [From: Mon Jul 29 18:44:13 UTC 2019, To: Mon Oct 21 18:23:00 UTC 2019] Issuer: CN=Google Internet Authority G3, O=Google Trust Services, C=US SerialNumber: [ 1b0b4c01 0d429a9d 993930f3 79310ee0] Certificate Extensions: 8 [1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: caIssuers accessLocation: URIName: http://pki.goog/gsr2/GTSGIAG3.crt , accessMethod: ocsp accessLocation: URIName: http://ocsp.pki.goog/GTSGIAG3 ] ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 77 C2 B8 50 9A 67 76 76 B1 2D C2 86 D0 83 A0 7E w..P.gvv.-...... 0010: A6 7E BA 4B ...K ] ] [3]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:false PathLen: undefined ] [4]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.pki.goog/GTSGIAG3.crl] ]] [5]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [1.3.6.1.4.1.11129.2.5.3] [] ] [CertificatePolicyId: [2.23.140.1.2.2] [] ] ] [6]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth ] [7]: ObjectId: 2.5.29.17 Criticality=false SubjectAlternativeName [ DNSName: *.google.com DNSName: *.android.com DNSName: *.appengine.google.com DNSName: *.cloud.google.com DNSName: *.crowdsource.google.com DNSName: *.g.co DNSName: *.gcp.gvt2.com DNSName: *.gcpcdn.gvt1.com DNSName: *.ggpht.cn DNSName: *.google-analytics.com DNSName: *.google.ca DNSName: *.google.cl DNSName: *.google.co.in DNSName: *.google.co.jp DNSName: *.google.co.uk DNSName: *.google.com.ar DNSName: *.google.com.au DNSName: *.google.com.br DNSName: *.google.com.co DNSName: *.google.com.mx DNSName: *.google.com.tr DNSName: *.google.com.vn DNSName: *.google.de DNSName: *.google.es DNSName: *.google.fr DNSName: *.google.hu DNSName: *.google.it DNSName: *.google.nl DNSName: *.google.pl DNSName: *.google.pt DNSName: *.googleadapis.com DNSName: *.googleapis.cn DNSName: *.googlecnapps.cn DNSName: *.googlecommerce.com DNSName: *.googlevideo.com DNSName: *.gstatic.cn DNSName: *.gstatic.com DNSName: *.gstaticcnapps.cn DNSName: *.gvt1.com DNSName: *.gvt2.com DNSName: *.metric.gstatic.com DNSName: *.urchin.com DNSName: *.url.google.com DNSName: *.youtube-nocookie.com DNSName: *.youtube.com DNSName: *.youtubeeducation.com DNSName: *.youtubekids.com DNSName: *.yt.be DNSName: *.ytimg.com DNSName: android.clients.google.com DNSName: android.com DNSName: developer.android.google.cn DNSName: developers.android.google.cn DNSName: g.co DNSName: ggpht.cn DNSName: goo.gl DNSName: google-analytics.com DNSName: google.com DNSName: googlecnapps.cn DNSName: googlecommerce.com DNSName: source.android.google.cn DNSName: urchin.com DNSName: www.goo.gl DNSName: youtu.be DNSName: youtube.com DNSName: youtubeeducation.com DNSName: youtubekids.com DNSName: yt.be ] [8]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 4D 8A E9 66 E7 F5 44 6E 4F 22 BA DC 57 7B 00 26 M..f..DnO"..W..& 0010: 21 FE 73 91 !.s. ] ] ] Algorithm: [SHA256withRSA] Signature: 0000: C5 6B 58 EA 3E 77 D3 57 B2 14 66 87 51 44 F2 57 .kX.>w.W..f.QD.W 0010: C8 30 4C E1 66 53 80 D9 1D 45 BA 4A E8 A2 7A 0E .0L.fS...E.J..z. 0020: AD 2A EE 81 C1 DD 53 CE 4D 1A 34 E2 C7 76 74 22 .*....S.M.4..vt" 0030: 4A 3B 33 E8 81 64 E2 7C 0D D4 89 77 7D 25 A6 8E J;3..d.....w.%.. 0040: 4C BA 62 E8 96 95 13 F3 98 C4 BB D9 84 39 AC 49 L.b..........9.I 0050: 10 A2 21 53 7A 55 D6 FB 0C F5 7F 0D 49 16 62 7E ..!SzU......I.b. 0060: 78 12 55 30 56 6F 6F 26 44 F8 9A 8E A7 95 C2 20 x.U0Voo&D...... 0070: 14 0B 6F 97 41 35 AD AD 38 66 4D 22 4C 3F E7 6C ..o.A5..8fM"L?.l 0080: A0 EE 26 1C 30 42 2D FD AF 2B 4B FD 5F 5F 4D B1 ..&.0B-..+K.__M. 0090: B0 02 5F BF 90 2E 4D EF B0 80 B3 32 12 24 4D 40 .._...M....2.$M@ 00A0: C7 29 5B 69 F8 96 B1 0E 86 91 9D 39 84 8B E4 46 .)[i.......9...F 00B0: EB E6 5B CC CE 4E 60 86 8E A2 B8 31 11 DF 77 62 ..[..N`....1..wb 00C0: C9 92 67 EE B6 6C CA 7A 6C 76 25 4F 3F C8 43 EB ..g..l.zlv%O?.C. 00D0: 1B 18 AB AD F9 9A 32 71 8E A4 A4 CF 53 1A F0 A2 ......2q....S... 00E0: 5E 8D 4E 27 55 F5 75 2B 9A 5A 41 70 7A 6D 1D 4D ^.N'U.u+.ZApzm.M 00F0: 13 5A A5 4B B0 0E 12 73 80 6E 9E AC CA 47 5C 92 .Z.K...s.n...G\. ] chain [1] = [ [ Version: V3 Subject: CN=Google Internet Authority G3, O=Google Trust Services, C=US Signature Algorithm: SHA256withRSA, OID = 1.2.840.113549.1.1.11 Key: Sun RSA public key, 2048 bits modulus: 255407195400965498019675322156223880280573409785920806091417323821641546468162965260831217416696791123852378338653849184876993542327 public exponent: 65537 Validity: [From: Thu Jun 15 00:00:42 UTC 2017, To: Wed Dec 15 00:00:42 UTC 2021] Issuer: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2 SerialNumber: [ 01e3a930 1cfc7206 383f9a53 1d] Certificate Extensions: 8 [1]: ObjectId: 1.3.6.1.5.5.7.1.1 Criticality=false AuthorityInfoAccess [ [ accessMethod: ocsp accessLocation: URIName: http://ocsp.pki.goog/gsr2 ] ] [2]: ObjectId: 2.5.29.35 Criticality=false AuthorityKeyIdentifier [ KeyIdentifier [ 0000: 9B E2 07 57 67 1C 1E C0 6A 06 DE 59 B4 9A 2D DF ...Wg...j..Y..-. 0010: DC 19 86 2E .... ] ] [3]: ObjectId: 2.5.29.19 Criticality=true BasicConstraints:[ CA:true PathLen:0 ] [4]: ObjectId: 2.5.29.31 Criticality=false CRLDistributionPoints [ [DistributionPoint: [URIName: http://crl.pki.goog/gsr2/gsr2.crl] ]] [5]: ObjectId: 2.5.29.32 Criticality=false CertificatePolicies [ [CertificatePolicyId: [2.23.140.1.2.2] [PolicyQualifierInfo: [ qualifierID: 1.3.6.1.5.5.7.2.1 qualifier: 0000: 16 1C 68 74 74 70 73 3A 2F 2F 70 6B 69 2E 67 6F ..https://pki.go 0010: 6F 67 2F 72 65 70 6F 73 69 74 6F 72 79 2F og/repository/ ]] ] ] [6]: ObjectId: 2.5.29.37 Criticality=false ExtendedKeyUsages [ serverAuth clientAuth ] [7]: ObjectId: 2.5.29.15 Criticality=true KeyUsage [ DigitalSignature Key_CertSign Crl_Sign ] [8]: ObjectId: 2.5.29.14 Criticality=false SubjectKeyIdentifier [ KeyIdentifier [ 0000: 77 C2 B8 50 9A 67 76 76 B1 2D C2 86 D0 83 A0 7E w..P.gvv.-...... 0010: A6 7E BA 4B ...K ] ] ] Algorithm: [SHA256withRSA] Signature: 0000: 1C B7 89 96 E4 53 ED BB EC DB A8 32 01 9F 2C A3 .....S.....2..,. 0010: CD 6D AD 42 12 77 B3 B8 E6 C9 03 52 60 20 7B 57 .m.B.w.....R` .W 0020: 27 C6 11 B5 3F 67 0D 99 2C 5B 5A CA 22 0A DD 9E '...?g..,[Z."... 0030: BB 1F 4B 48 3F 8F 02 3D 8B 21 84 45 1D 6D F5 FF ..KH?..=.!.E.m.. 0040: AC 68 89 CD 64 E2 D6 D6 5E 40 C2 8E 2A F7 EF 14 .h..d...^@..*... 0050: D3 36 A4 40 30 F5 32 15 15 92 76 FB 7E 9E 53 EA .6. at 0.2...v...S. 0060: C2 76 FC 39 AD 88 FE 66 92 26 E9 1C C4 38 CD 49 .v.9...f.&...8.I 0070: FA 43 87 F0 5D D6 56 4D 81 D7 7F F1 C2 DD B0 4D .C..].VM.......M 0080: FE C3 2A 6E 7C 9F 6E 5C ED 62 42 99 E1 F7 36 EE ..*n..n\.bB...6. 0090: 14 8C 2C 20 E3 46 97 5A 77 03 C0 A0 C6 4A 88 FD .., .F.Zw....J.. 00A0: 40 22 87 72 5A 18 EA 9C A5 C7 5A 08 8C E4 05 A4 @".rZ.....Z..... 00B0: 7D B9 84 35 5F 89 36 56 0E 40 3D 12 E8 BB 35 72 ...5_.6V.@=...5r 00C0: ED AF 08 56 4E B0 BB 2E A9 9B E4 FB 1D 3E 0B 63 ...VN........>.c 00D0: C8 9B 4B 91 44 66 57 C0 14 B4 96 F0 DC 2C 57 3F ..K.DfW......,W? 00E0: 52 04 AD 95 AA 7D 4D D0 F2 0C 9F 9C 40 E8 D6 55 R.....M..... at ..U 00F0: 73 BA 3C DF 90 CB 00 5B 21 11 67 C2 ED 32 1E DE s.<....[!.g..2.. ] *** main, READ: TLSv1.2 Handshake, length = 333 *** ECDH ServerKeyExchange Signature Algorithm SHA256withRSA Server key: Sun EC public key, 256 bits public x coord: 62425338880862086862126070760967255929876848803250500731297499630365948408838 public y coord: 71786286434442664207501648716405965621228467874951735223121477290534740427215 parameters: secp256r1 [NIST P-256, X9.62 prime256v1] (1.2.840.10045.3.1.7) main, READ: TLSv1.2 Handshake, length = 4 *** ServerHelloDone *** ECDHClientKeyExchange ECDH Public value: { 4, 235, 156, 208, 86, 228, 75, 178, 227, 98, 189, 97, 180, 106, 55, 101, 225, 23, 141, 165, 25, 179, 85, 244, 181, 46, 1} main, WRITE: TLSv1.2 Handshake, length = 70 SESSION KEYGEN: PreMaster Secret: 0000: 48 A9 C2 F1 71 85 6A 7B A6 BD D9 B4 D8 F6 E9 DB H...q.j......... 0010: 2B 92 7F B3 A8 31 6A 5A D0 FD 54 0E 88 B8 64 92 +....1jZ..T...d. CONNECTION KEYGEN: Client Nonce: 0000: 5D 50 FF 4A B3 5D 66 DE 19 B6 69 11 E0 0E 96 9A ]P.J.]f...i..... 0010: C3 18 03 0E 87 BE 2D 3C EE D1 4E AD 0E 3F 4A 05 ......-<..N..?J. Server Nonce: 0000: 5D 50 FF 98 B1 19 71 C3 FD 32 A5 AC A5 23 B6 53 ]P....q..2...#.S 0010: 30 A9 08 4D B9 7E 2F 1B 44 4F 57 4E 47 52 44 01 0..M../.DOWNGRD. Master Secret: 0000: 20 BA 54 8A 11 CB 38 72 8A 5D 5D A6 3A 73 B3 91 .T...8r.]].:s.. 0010: 2E 14 E6 51 11 7A 50 E8 28 C8 AD 05 02 E6 37 DD ...Q.zP.(.....7. 0020: B5 86 CF AE 7C 53 96 1E 38 22 11 18 2D C5 FE C4 .....S..8"..-... ... no MAC keys used for this cipher Client write key: 0000: 0A EE 82 69 30 37 4E 81 3A D5 CC 18 07 FA 9C 00 ...i07N.:....... Server write key: 0000: C6 85 DB EA DC EA D5 F1 43 9A B7 E3 F9 60 A5 6E ........C....`.n Client write IV: 0000: DF 63 21 C8 .c!. Server write IV: 0000: 88 B0 73 31 ..s1 main, WRITE: TLSv1.2 Change Cipher Spec, length = 1 *** Finished verify_data: { 227, 236, 200, 235, 97, 150, 154, 160, 48, 12, 91, 139 } *** main, WRITE: TLSv1.2 Handshake, length = 40 main, READ: TLSv1.2 Change Cipher Spec, length = 1 main, READ: TLSv1.2 Handshake, length = 40 *** Finished verify_data: { 255, 109, 167, 115, 110, 56, 148, 28, 238, 104, 225, 186 } *** %% Cached client session: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256] main, WRITE: TLSv1.2 Application Data, length = 222 main, READ: TLSv1.2 Application Data, length = 1413 Succesfull connected. Data: main, READ: TLSv1.2 Application Data, length = 1413 main, READ: TLSv1.2 Application Data, length = 483 From openssl-users at dukhovni.org Wed Aug 14 04:13:22 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 14 Aug 2019 14:13:22 +1000 Subject: Openssl and tls 1.2 In-Reply-To: References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> Message-ID: <0DD8B014-2A4B-4086-B122-3D28C0E60BB6@dukhovni.org> Java's TLS library is not OpenSSL. This is not the right list for help with TLS in JDK8. Speculatively, the timeout might be related to IPv6 being enabled on the board with JDK8 and Linux 4.x. Perhaps you're trying the IPv6 address, timing out, and then failing over to IPv4. Or some middle-box is choking on larger client hellos. You'll need to analyze a packet capture. > On Aug 14, 2019, at 1:29 PM, Somshekar C Kadam wrote: > > Hi , > we are running java 1.6 (older build) and java 1.8(newer build) on the same arm target board with different builds. > On 1.6 java we have Linux Kernel 2.6.35 and with Java 1.8 Linux kernel 4.x. version. so 2 environments and 2 use cases newer and older build. > while we access https website link https://transparencyreport.google.com/https/overview?hl=en > > we see it takes less than 2 seconds using java 1.6. (older build) > we see it takes 10 seconds using java 1.8 (newer build) > > On Java 1.8 did try disabling GCM ciphers and trying still we get the same 10 seconds delay. > > Attaching log of tls handshake for both. Not sure its to do with tls, may be java is causing the delay. > > I am not sure, please provide any pointers or feedback to rootcause it that will help to understand why we get 10seconds delay. > > One more info if just use curl on on newer build setup, it works fine within 2 seconds to access the https link. Curl may well be using OpenSSL, but that's not where you're seeing a problem, so the help you'll get on this list is rather limited. Try wireshark or similar. -- Viktor. From somkadam76 at gmail.com Wed Aug 14 04:32:42 2019 From: somkadam76 at gmail.com (Somshekar C Kadam) Date: Wed, 14 Aug 2019 10:02:42 +0530 Subject: Openssl and tls 1.2 In-Reply-To: <0DD8B014-2A4B-4086-B122-3D28C0E60BB6@dukhovni.org> References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> <0DD8B014-2A4B-4086-B122-3D28C0E60BB6@dukhovni.org> Message-ID: Thanks Viktor for clarification Regards Somshekar C Kadam 9036660538 On Wed, Aug 14, 2019 at 9:43 AM Viktor Dukhovni wrote: > Java's TLS library is not OpenSSL. This is not the right list > for help with TLS in JDK8. Speculatively, the timeout might be > related to IPv6 being enabled on the board with JDK8 and Linux 4.x. > Perhaps you're trying the IPv6 address, timing out, and then failing > over to IPv4. Or some middle-box is choking on larger client hellos. > You'll need to analyze a packet capture. > > > On Aug 14, 2019, at 1:29 PM, Somshekar C Kadam > wrote: > > > > Hi , > > we are running java 1.6 (older build) and java 1.8(newer build) on the > same arm target board with different builds. > > On 1.6 java we have Linux Kernel 2.6.35 and with Java 1.8 Linux kernel > 4.x. version. so 2 environments and 2 use cases newer and older build. > > while we access https website link > https://transparencyreport.google.com/https/overview?hl=en > > > > we see it takes less than 2 seconds using java 1.6. (older build) > > we see it takes 10 seconds using java 1.8 (newer build) > > > > On Java 1.8 did try disabling GCM ciphers and trying still we get the > same 10 seconds delay. > > > > Attaching log of tls handshake for both. Not sure its to do with tls, > may be java is causing the delay. > > > > I am not sure, please provide any pointers or feedback to rootcause it > that will help to understand why we get 10seconds delay. > > > > One more info if just use curl on on newer build setup, it works fine > within 2 seconds to access the https link. > > Curl may well be using OpenSSL, but that's not where you're seeing > a problem, so the help you'll get on this list is rather limited. > Try wireshark or similar. > > -- > Viktor. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Wed Aug 14 10:06:01 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 06:06:01 -0400 Subject: Convert eddsa public key fro PEM to DER Message-ID: I googled how to convert a PEM public key to DER and only found examples for RSA keys.? Mine are ed25519.? I thought it would be a simple algorithm substitution: $ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >? -outform DER -out $dir/private/intermediate.key.der Invalid command 'ed25519'; type "help" for a list. So since my other commands use -algorithm, I tried: $ openssl -algorithm $algorithm -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >? -outform DER -out $dir/private/intermediate.key.der Invalid command '-algorithm'; type "help" for a list. So what is the command to convert an ed25519 public key from DER to PEM.? The command I used to create the key was: ?? openssl genpkey -aes256 -algorithm ed25519\ ?????? -outform pem -out $dir/private/intermediate.key.pem thanks From matt at openssl.org Wed Aug 14 10:22:22 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Aug 2019 11:22:22 +0100 Subject: Convert eddsa public key fro PEM to DER In-Reply-To: References: Message-ID: <08c4d304-91f5-cfe1-6fa2-da5aeab76ffa@openssl.org> On 14/08/2019 11:06, Robert Moskowitz wrote: > I googled how to convert a PEM public key to DER and only found examples for RSA > keys.? Mine are ed25519.? I thought it would be a simple algorithm substitution: > > $ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >>? -outform DER -out $dir/private/intermediate.key.der > > Invalid command 'ed25519'; type "help" for a list. > > So since my other commands use -algorithm, I tried: > > $ openssl -algorithm $algorithm -pubin -inform PEM -in > $dir/private/intermediate.key.pem\ >>? -outform DER -out $dir/private/intermediate.key.der > > Invalid command '-algorithm'; type "help" for a list. > > So what is the command to convert an ed25519 public key from DER to PEM.? The > command I used to create the key was: > > ?? openssl genpkey -aes256 -algorithm ed25519\ > ?????? -outform pem -out $dir/private/intermediate.key.pem Firstly, that command creates a private key not a public key. So if you want to convert the above *private* key into DER then: openssl pkey -in ed25519.pem -out ed25519.der -outform DER If on the other hand you want to read the above *private* key and output the associated *public* key in DER then: openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout Matt From rgm at htt-consult.com Wed Aug 14 12:21:03 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 08:21:03 -0400 Subject: Convert eddsa public key fro PEM to DER In-Reply-To: <08c4d304-91f5-cfe1-6fa2-da5aeab76ffa@openssl.org> References: <08c4d304-91f5-cfe1-6fa2-da5aeab76ffa@openssl.org> Message-ID: On 8/14/19 6:22 AM, Matt Caswell wrote: > > On 14/08/2019 11:06, Robert Moskowitz wrote: >> I googled how to convert a PEM public key to DER and only found examples for RSA >> keys.? Mine are ed25519.? I thought it would be a simple algorithm substitution: >> >> $ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >>> ? -outform DER -out $dir/private/intermediate.key.der >> Invalid command 'ed25519'; type "help" for a list. >> >> So since my other commands use -algorithm, I tried: >> >> $ openssl -algorithm $algorithm -pubin -inform PEM -in >> $dir/private/intermediate.key.pem\ >>> ? -outform DER -out $dir/private/intermediate.key.der >> Invalid command '-algorithm'; type "help" for a list. >> >> So what is the command to convert an ed25519 public key from DER to PEM.? The >> command I used to create the key was: >> >> ?? openssl genpkey -aes256 -algorithm ed25519\ >> ?????? -outform pem -out $dir/private/intermediate.key.pem > Firstly, that command creates a private key not a public key. The what does the following say: $??? openssl pkey -inform $format\ >??????? -in $dir/private/intermediate.key.pem -text -noout Enter pass phrase for /home/rgm/uasca/intermediate/private/intermediate.key.pem: ED25519 Private-Key: priv: ??? 70:71:84:2b:81:e8:78:cb:6b:9c:97:28:92:7f:72: ??? 16:0a:40:fd:7b:38:e6:71:f7:2e:ad:2d:19:8e:e6: ??? cf:58 pub: ??? a4:de:b3:3c:b7:bd:12:5b:1a:e5:ac:58:76:15:7e: ??? e8:98:2c:87:57:8b:c4:5b:98:33:d5:41:b5:e2:a4: ??? 54:db > > So if you want to convert the above *private* key into DER then: > > openssl pkey -in ed25519.pem -out ed25519.der -outform DER > > If on the other hand you want to read the above *private* key and output the > associated *public* key in DER then: > > openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout Yes. thanks.? That works. > > Matt > > From matt at openssl.org Wed Aug 14 12:42:39 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 14 Aug 2019 13:42:39 +0100 Subject: Convert eddsa public key fro PEM to DER In-Reply-To: References: <08c4d304-91f5-cfe1-6fa2-da5aeab76ffa@openssl.org> Message-ID: <882c6400-cc33-f04e-9954-c22fbe9e6d7a@openssl.org> On 14/08/2019 13:21, Robert Moskowitz wrote: > > > On 8/14/19 6:22 AM, Matt Caswell wrote: >> >> On 14/08/2019 11:06, Robert Moskowitz wrote: >>> I googled how to convert a PEM public key to DER and only found examples for RSA >>> keys.? Mine are ed25519.? I thought it would be a simple algorithm substitution: >>> >>> $ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >>>> ?? -outform DER -out $dir/private/intermediate.key.der >>> Invalid command 'ed25519'; type "help" for a list. >>> >>> So since my other commands use -algorithm, I tried: >>> >>> $ openssl -algorithm $algorithm -pubin -inform PEM -in >>> $dir/private/intermediate.key.pem\ >>>> ?? -outform DER -out $dir/private/intermediate.key.der >>> Invalid command '-algorithm'; type "help" for a list. >>> >>> So what is the command to convert an ed25519 public key from DER to PEM.? The >>> command I used to create the key was: >>> >>> ??? openssl genpkey -aes256 -algorithm ed25519\ >>> ??????? -outform pem -out $dir/private/intermediate.key.pem >> Firstly, that command creates a private key not a public key. > > The what does the following say: > > $??? openssl pkey -inform $format\ >>??????? -in $dir/private/intermediate.key.pem -text -noout > Enter pass phrase for /home/rgm/uasca/intermediate/private/intermediate.key.pem: > ED25519 Private-Key: > priv: It says in the two lines above that you have a private key. Every private key implicitly has an associated public key with it (which is also shown below). But the combined set is private, because it contains private data. By contrast if you just have a public key then there is no private portion and so the whole key is public. Matt > ??? 70:71:84:2b:81:e8:78:cb:6b:9c:97:28:92:7f:72: > ??? 16:0a:40:fd:7b:38:e6:71:f7:2e:ad:2d:19:8e:e6: > ??? cf:58 > pub: > ??? a4:de:b3:3c:b7:bd:12:5b:1a:e5:ac:58:76:15:7e: > ??? e8:98:2c:87:57:8b:c4:5b:98:33:d5:41:b5:e2:a4: > ??? 54:db > > >> >> So if you want to convert the above *private* key into DER then: >> >> openssl pkey -in ed25519.pem -out ed25519.der -outform DER >> >> If on the other hand you want to read the above *private* key and output the >> associated *public* key in DER then: >> >> openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout > > Yes. thanks.? That works. > >> >> Matt >> >> > From rgm at htt-consult.com Wed Aug 14 12:45:09 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 08:45:09 -0400 Subject: Convert eddsa public key fro PEM to DER In-Reply-To: <882c6400-cc33-f04e-9954-c22fbe9e6d7a@openssl.org> References: <08c4d304-91f5-cfe1-6fa2-da5aeab76ffa@openssl.org> <882c6400-cc33-f04e-9954-c22fbe9e6d7a@openssl.org> Message-ID: <109ccfc4-d62c-2f2a-ca48-07216966650b@htt-consult.com> On 8/14/19 8:42 AM, Matt Caswell wrote: > > On 14/08/2019 13:21, Robert Moskowitz wrote: >> >> On 8/14/19 6:22 AM, Matt Caswell wrote: >>> On 14/08/2019 11:06, Robert Moskowitz wrote: >>>> I googled how to convert a PEM public key to DER and only found examples for RSA >>>> keys.? Mine are ed25519.? I thought it would be a simple algorithm substitution: >>>> >>>> $ openssl ed25519 -pubin -inform PEM -in $dir/private/intermediate.key.pem\ >>>>> ?? -outform DER -out $dir/private/intermediate.key.der >>>> Invalid command 'ed25519'; type "help" for a list. >>>> >>>> So since my other commands use -algorithm, I tried: >>>> >>>> $ openssl -algorithm $algorithm -pubin -inform PEM -in >>>> $dir/private/intermediate.key.pem\ >>>>> ?? -outform DER -out $dir/private/intermediate.key.der >>>> Invalid command '-algorithm'; type "help" for a list. >>>> >>>> So what is the command to convert an ed25519 public key from DER to PEM.? The >>>> command I used to create the key was: >>>> >>>> ??? openssl genpkey -aes256 -algorithm ed25519\ >>>> ??????? -outform pem -out $dir/private/intermediate.key.pem >>> Firstly, that command creates a private key not a public key. >> The what does the following say: >> >> $??? openssl pkey -inform $format\ >>> ??????? -in $dir/private/intermediate.key.pem -text -noout >> Enter pass phrase for /home/rgm/uasca/intermediate/private/intermediate.key.pem: >> ED25519 Private-Key: >> priv: > It says in the two lines above that you have a private key. Every private key > implicitly has an associated public key with it (which is also shown below). But > the combined set is private, because it contains private data. By contrast if > you just have a public key then there is no private portion and so the whole key > is public. Thanks.? It is beginning to filter into my morning brain mush. > > Matt > > > >> ??? 70:71:84:2b:81:e8:78:cb:6b:9c:97:28:92:7f:72: >> ??? 16:0a:40:fd:7b:38:e6:71:f7:2e:ad:2d:19:8e:e6: >> ??? cf:58 >> pub: >> ??? a4:de:b3:3c:b7:bd:12:5b:1a:e5:ac:58:76:15:7e: >> ??? e8:98:2c:87:57:8b:c4:5b:98:33:d5:41:b5:e2:a4: >> ??? 54:db >> >> >>> So if you want to convert the above *private* key into DER then: >>> >>> openssl pkey -in ed25519.pem -out ed25519.der -outform DER >>> >>> If on the other hand you want to read the above *private* key and output the >>> associated *public* key in DER then: >>> >>> openssl pkey -in ed25519.pem -out ed25519-pub.der -outform DER -pubout >> Yes. thanks.? That works. >> >>> Matt >>> >>> From jb-openssl at wisemo.com Wed Aug 14 15:21:39 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 14 Aug 2019 17:21:39 +0200 Subject: IPv6 address encoding in commonName In-Reply-To: References: Message-ID: <335d070b-79e1-899c-2c0a-77a7afc1cbbf@wisemo.com> On 14/08/2019 04:55, Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the > CA's 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. > Actually a Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to > be revised soon). > > For a client cert, it would be easy to put the HIT in subjectAltName > per RFC 8002 (with a null subjectName), but a CA cert MUST have a > non-empty subjectName. > > Thus all I want in this subjectName is commonName with the HIT. > > I am looking for examples of IPv6 addresses in commonName. > > My searches today have come up empty. > If no one comes up with good established practice examples, here are some ideas you may work on. For CA certificates that are not self-signed end certs, it would be practical to use a CN that is intentionally different from the end certs, such as "Example corp HIP CA for 2001:db8::/48" . As the author of a proposal in this area, could you define a notation for IPv6 DNs, perhaps one that actually reflects the hierarchical nature of IPv6 addresses? You could take inspiration from the (unfortunately rarely used) hierarchical DN representation of DNS names (this used the DNS specific DC name components).? Overall the goal is to allow X.500 distinguished name restrictions to work correctly. In practice you could follow the nibble notation as already used for delegation of IPv6 reverse lookups in DNS. However for the CN in the end cert you could perhaps use the full DNS reverse IPv6 name "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" where the hex notation shall be the shortest form permitted by the IPv6 notation spec. Examples of boundaries where hierarchical divisions would be practical (if making a new design, it should be useful outside the HIT/HIP standards): 1. After the 1st nibble to cater for IANA design assignments (0 is ? special, 2 and 3 used for current live assignments, f used for ? special transmission modes such as multicast and local segment). 2. After the 2nd to 4th nibble to reflect assignments to continents ? (RIRs).? Different continents may operate under conflicting legal ? regimes for internal purposes, such as certificate privacy. 3. After the 4th to 6th nibble to reflect typical operator (LIR) ? assignments. 4. After the 6th to 8th nibble to reflect customer or other specific ? net assignments. 5. After the 14th nibble to reflect a single IEEE assigned MAC prefix ? (For example fe80:0:0:0:3a94:ed00::/88 would match the net local ? addresses of NETGEAR hardware using the 38-94-ED OUI block). 6. After the 18th nibble to reflect a single IEEE assigned MAC ? prefix excluding similar-looking non-MAC addresses (For example ? fe80:0:0:0:3a94:edff:fe00:/104 for that same block). 7. Even later nibbles to reflect assignment of part of an OUI block ? to a factory or production line that generates certificates for ? devices as they are manufactured. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From rsalz at akamai.com Wed Aug 14 19:26:15 2019 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 14 Aug 2019 19:26:15 +0000 Subject: IPv6 address encoding in commonName In-Reply-To: References: Message-ID: <08A61B0A-5494-428D-B4DA-99155C3CA151@akamai.com> RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty subjectName. Non-empty subjectName or non-empty commonName within the subject name? Shrug. Doesn't matter, I guess. Just populate it with the string version of the HIT name, something like CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj ? > My searches today have come up empty. I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25 This is not surprising since I would not expect any public CA's to have this kind of thing. From rgm at htt-consult.com Wed Aug 14 19:55:44 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 15:55:44 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: <335d070b-79e1-899c-2c0a-77a7afc1cbbf@wisemo.com> References: <335d070b-79e1-899c-2c0a-77a7afc1cbbf@wisemo.com> Message-ID: <1835423d-c59a-60b4-007f-afe4545089d9@htt-consult.com> On 8/14/19 11:21 AM, Jakob Bohm via openssl-users wrote: > On 14/08/2019 04:55, Robert Moskowitz wrote: >> I am fiddling around with an intermediate CA signing cert that the >> CA's 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. >> Actually a Hierarchical HIT as in draft-moskowitz-hierarchical-hip >> (to be revised soon). >> >> For a client cert, it would be easy to put the HIT in subjectAltName >> per RFC 8002 (with a null subjectName), but a CA cert MUST have a >> non-empty subjectName. >> >> Thus all I want in this subjectName is commonName with the HIT. >> >> I am looking for examples of IPv6 addresses in commonName. >> >> My searches today have come up empty. >> > If no one comes up with good established practice examples, here are > some ideas you may work on. > > For CA certificates that are not self-signed end certs, it would be > practical to use a CN that is intentionally different from the end > certs, such as "Example corp HIP CA for 2001:db8::/48" . I am working with a 2-tier pki.? The root CA cert will have some sort of standard DN for subjectName, naming the owner of the pki. The intermediate signing CA certs are for the agencies that actually register and, to some degree, manage these devices.? All these agencies will be 'named' by the HHIT (draft-moskowitz-hierarchical-hip) derived from the ed25519 key of their signing cert.? Well they are named by their /64 per the draft.?? And perhaps that is better, as over the years there will be new signing certs with different keys, but the same HHIT prefix. Hmmm. Also size of the DN is important as it is the issuerName in the client cert which may get transmitted over a very constrained (e.g. BT4) link.? The intermediate CA cert has ITS issuerName of the root cert that identifies the pki for this purpose.? So the CN could simply be: CN=2001:24:28:24/64 This would be for a HHIT HDA 20 in RRA 10 that is using HIT Suite 4.? Makes perfect sense.? :) > > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? The challenge with this is there is an ASSuMption that it looks like an IPv6 prefix so that is what is intended.? It might have to be more explicit like: CN=IPv6::2001:24:28:24/64 Or something close to that. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components).? Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. > > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. > > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > > or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. I am striving for smallness so that the client issuerName is small. This is scary long.? The routing prefix style is probably best for my purpose. > > Examples of boundaries where hierarchical divisions would be practical > (if making a new design, it should be useful outside the HIT/HIP > standards): That is why the standard IPv6 prefix notation is best.? People are use to it. > > 1. After the 1st nibble to cater for IANA design assignments (0 is > ? special, 2 and 3 used for current live assignments, f used for > ? special transmission modes such as multicast and local segment). > > 2. After the 2nd to 4th nibble to reflect assignments to continents > ? (RIRs).? Different continents may operate under conflicting legal > ? regimes for internal purposes, such as certificate privacy. > > 3. After the 4th to 6th nibble to reflect typical operator (LIR) > ? assignments. > > 4. After the 6th to 8th nibble to reflect customer or other specific > ? net assignments. > > 5. After the 14th nibble to reflect a single IEEE assigned MAC prefix > ? (For example fe80:0:0:0:3a94:ed00::/88 would match the net local > ? addresses of NETGEAR hardware using the 38-94-ED OUI block). > > 6. After the 18th nibble to reflect a single IEEE assigned MAC > ? prefix excluding similar-looking non-MAC addresses (For example > ? fe80:0:0:0:3a94:edff:fe00:/104 for that same block). > > 7. Even later nibbles to reflect assignment of part of an OUI block > ? to a factory or production line that generates certificates for > ? devices as they are manufactured. The CA goes as long in the prefix as needed.? Parsing it follows the 'known' rules. > Enjoy > > Jakob Oh, I am.? ;) From rgm at htt-consult.com Wed Aug 14 20:04:57 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 16:04:57 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: <08A61B0A-5494-428D-B4DA-99155C3CA151@akamai.com> References: <08A61B0A-5494-428D-B4DA-99155C3CA151@akamai.com> Message-ID: <11136ea4-ab5e-5c98-7d69-acf34d75141c@htt-consult.com> On 8/14/19 3:26 PM, Salz, Rich wrote: > RFC 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > > Non-empty subjectName or non-empty commonName within the subject name? > > Shrug. Doesn't matter, I guess. Just populate it with the string version of the HIT name, something like > CN=IP Address 2001:27:dcfc:cb8:d53g:5364:48bj > ? That is what I am coming to see.? Always 'nice' to follow existing practice.? But given now, set the precedence! > >> My searches today have come up empty. > > I tried crt.sh and also came up empty; https://crt.sh/?CAName=%25%3A%25 This is not surprising since I would not expect any public CA's to have this kind of thing. > > > From rgm at htt-consult.com Wed Aug 14 21:11:37 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 14 Aug 2019 17:11:37 -0400 Subject: openssl req error with DN having a / in it Message-ID: Developing saga on creating an intermediate CA cert with only CN and said CN should be: CN=IPv6::2001:24:28:24/64 Note that / in CN that seems to be a challenge. ?? commonName="/CN=IPv6::2001:24:28:24/64" ?? DN=$commonName ?? echo $DN ?? openssl req -config $cadir/openssl-root.cnf\ ?????? -key $dir/private/intermediate.key.pem \ ?????? -keyform pem -outform $format -subj "$DN" -new\ ?????? -out $dir/csr/intermediate.csr.pem req: Hit end of string before finding the equals. problems making Certificate Request Then I tried: ?? commonName="/CN=IPv6::2001:24:28:24//64" ?? DN=$commonName ?? echo $DN guessing that / was acting as an escape designator, tried the command again and got the same req: Hit end of string before finding the equals. problems making Certificate Request So how do I get that / into the CN? thanks From openssl at jordan.maileater.net Wed Aug 14 22:33:23 2019 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 14 Aug 2019 22:33:23 +0000 Subject: openssl req error with DN having a / in it In-Reply-To: References: Message-ID: <0101016c9243a5fc-f07f71af-01ac-4006-a084-f1d7b7112e66-000000@us-west-2.amazonses.com> On 8/14/2019 2:11 PM, Robert Moskowitz wrote: > [...] > ?? commonName="/CN=IPv6::2001:24:28:24/64" > [...] > req: Hit end of string before finding the equals. > problems making Certificate Request Some systems present distinguished names using slashes as separators.? I assume that that's what you're running into here, that your string is being processed as a valid RDN "CN=IPv6::2001:24:28:24" and an invalid RDN "64". You'll need to quote the slash.? I don't happen to know how, but my bet would be either \/ or %2F. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Wed Aug 14 22:47:41 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Wed, 14 Aug 2019 18:47:41 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: References: Message-ID: <16901.1565822861@localhost> Robert Moskowitz wrote: > I am fiddling around with an intermediate CA signing cert that the CA's > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > subjectName. > Thus all I want in this subjectName is commonName with the HIT. > I am looking for examples of IPv6 addresses in commonName. I thought that RFC3779 did exactly what you want, but it does not define new Subject DN, but rather a new extension that will be bound to the Subject. (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but I guess it preceeded the SIDR working group, and occured in PKIX) In ANIMA's ACP document, we have an abomination that leverages rfc822Name, mostly because we figure the odds of getting anything else through off-the-shelf CAs is nil. Note to consumed with things in your stomach: https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 Jakob Bohm via openssl-users wrote: > As the author of a proposal in this area, could you define a notation > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > of IPv6 addresses? RFC3779 does some of that, but not in the DN itself. > You could take inspiration from the (unfortunately rarely used) > hierarchical DN representation of DNS names (this used the DNS > specific DC name components).? Overall the goal is to allow X.500 > distinguished name restrictions to work correctly. Yes, we could abuse the DC component. Were you thinking about: DC=2001/DC=0db8 > In practice you could follow the nibble notation as already used > for delegation of IPv6 reverse lookups in DNS. so more correctly: DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > However for the CN in the end cert you could perhaps use the full > DNS reverse IPv6 name > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" > where the hex notation shall be the shortest form permitted by the > IPv6 notation spec. Bob, this seems like the best immediate hack to me. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From jb-openssl at wisemo.com Thu Aug 15 01:09:38 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 15 Aug 2019 03:09:38 +0200 Subject: openssl req error with DN having a / in it In-Reply-To: <0101016c9243a5fc-f07f71af-01ac-4006-a084-f1d7b7112e66-000000@us-west-2.amazonses.com> References: <0101016c9243a5fc-f07f71af-01ac-4006-a084-f1d7b7112e66-000000@us-west-2.amazonses.com> Message-ID: <8d4bffef-3062-9fe3-a3a2-a72f8272ae57@wisemo.com> On 15/08/2019 00:33, Jordan Brown wrote: > On 8/14/2019 2:11 PM, Robert Moskowitz wrote: >> [...] >> ?? commonName="/CN=IPv6::2001:24:28:24/64" >> [...] >> req: Hit end of string before finding the equals. >> problems making Certificate Request > > Some systems present distinguished names using slashes as separators.? > I assume that that's what you're running into here, that your string > is being processed as a valid RDN "CN=IPv6::2001:db8:28:24" and an > invalid RDN "64". > > You'll need to quote the slash.? I don't happen to know how, but my > bet would be either \/ or %2F. > This is why my mail proposed CN=[2001:24:28:24::9] with no slashes for an end cert with a specific IP and a human readable name that would sort with related names in the CA's CN element. Also note that the "IPv6:" notation might confuse OpenSSL or OpenSSL derived string parsing code. Certificates for Bluetooth MAC addresses would be a different notation such as CN=DC-BA-98-76-54-32 for a 48-bit MAC address, or (to reuse name restrictions on via IPv6 SANs), the equivalent [fe80::dcba:98ff:fe76:5432]. I don't understand what use case Moskowitz wants for a subnet mask length such as /64 in an end cert. P.S. 2001:db8::/32 is the official prefix for use in examples. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From levitte at openssl.org Thu Aug 15 05:38:04 2019 From: levitte at openssl.org (Richard Levitte) Date: Thu, 15 Aug 2019 07:38:04 +0200 Subject: IPv6 address encoding in commonName In-Reply-To: <16901.1565822861@localhost> References: <16901.1565822861@localhost> Message-ID: <87ef1nf0oz.wl-levitte@openssl.org> On Thu, 15 Aug 2019 00:47:41 +0200, Michael Richardson wrote: > > > Robert Moskowitz wrote: > > I am fiddling around with an intermediate CA signing cert that the CA's > > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > > > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > > subjectName. > > > Thus all I want in this subjectName is commonName with the HIT. > > I am looking for examples of IPv6 addresses in commonName. > > I thought that RFC3779 did exactly what you want, but it does not define new > Subject DN, but rather a new extension that will be bound to the Subject. > (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but > I guess it preceeded the SIDR working group, and occured in PKIX) OpenSSL does support that extension... crypto/x509v3/v3_addr.c (moved to crypto/x509/v3_addr.c in next major version) is all about that as far as I can see. Thanks for bringing that up. Trying to infer some kind of meaning into commonName would be a mistake (isn't previous such hacks the very reason we have the subjectAltName extension?) > > In practice you could follow the nibble notation as already used > > for delegation of IPv6 reverse lookups in DNS. > > so more correctly: > DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > > > However for the CN in the end cert you could perhaps use the full > > DNS reverse IPv6 name > > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > > or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" > > where the hex notation shall be the shortest form permitted by the > > IPv6 notation spec. > > Bob, this seems like the best immediate hack to me. "hack" would be the operative word here. While it's true that this would fulfill the objective, I frankly wouldn't like to see such a cert. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From mcr at sandelman.ca Thu Aug 15 13:34:00 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 15 Aug 2019 09:34:00 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: <87ef1nf0oz.wl-levitte@openssl.org> References: <16901.1565822861@localhost> <87ef1nf0oz.wl-levitte@openssl.org> Message-ID: <5553.1565876040@localhost> Richard Levitte wrote: > On Thu, 15 Aug 2019 00:47:41 +0200, Michael Richardson wrote: >> >> >> Robert Moskowitz wrote: > I am fiddling around >> with an intermediate CA signing cert that the CA's > 'name' is it HIP >> (RFC 7401) HIT which is a valid IPv6 address. Actually a > >> Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised >> soon). >> >> > For a client cert, it would be easy to put the HIT in subjectAltName >> per RFC > 8002 (with a null subjectName), but a CA cert MUST have a >> non-empty > subjectName. >> >> > Thus all I want in this subjectName is commonName with the HIT. > I >> am looking for examples of IPv6 addresses in commonName. >> >> I thought that RFC3779 did exactly what you want, but it does not >> define new Subject DN, but rather a new extension that will be bound >> to the Subject. (I was surprised that RFC3779 was not in the SIDR >> WG's list of documents,but I guess it preceeded the SIDR working >> group, and occured in PKIX) > OpenSSL does support that extension... crypto/x509v3/v3_addr.c (moved > to crypto/x509/v3_addr.c in next major version) is all about that as > far as I can see. > Thanks for bringing that up. Trying to infer some kind of meaning into > commonName would be a mistake (isn't previous such hacks the very > reason we have the subjectAltName extension?) Yes, but we didn't let (intermediate) CAs have an empty subject DN, SAN-only, because we don't have an IssuerAltName for the next level. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From rgm at htt-consult.com Thu Aug 15 16:49:07 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 15 Aug 2019 12:49:07 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: <16901.1565822861@localhost> References: <16901.1565822861@localhost> Message-ID: <6106fef6-8b48-ae34-a600-b4c8ba931844@htt-consult.com> On 8/14/19 6:47 PM, Michael Richardson wrote: > Robert Moskowitz wrote: > > I am fiddling around with an intermediate CA signing cert that the CA's > > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. Actually a > > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be revised soon). > > > For a client cert, it would be easy to put the HIT in subjectAltName per RFC > > 8002 (with a null subjectName), but a CA cert MUST have a non-empty > > subjectName. > > > Thus all I want in this subjectName is commonName with the HIT. > > I am looking for examples of IPv6 addresses in commonName. > > I thought that RFC3779 did exactly what you want, but it does not define new > Subject DN, but rather a new extension that will be bound to the Subject. > (I was surprised that RFC3779 was not in the SIDR WG's list of documents,but > I guess it preceeded the SIDR working group, and occured in PKIX) > > In ANIMA's ACP document, we have an abomination that leverages rfc822Name, > mostly because we figure the odds of getting anything else through > off-the-shelf CAs is nil. > Note to consumed with things in your stomach: > https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 > > Jakob Bohm via openssl-users wrote: > > As the author of a proposal in this area, could you define a notation > > for IPv6 DNs, perhaps one that actually reflects the hierarchical nature > > of IPv6 addresses? > > RFC3779 does some of that, but not in the DN itself. > > > You could take inspiration from the (unfortunately rarely used) > > hierarchical DN representation of DNS names (this used the DNS > > specific DC name components).? Overall the goal is to allow X.500 > > distinguished name restrictions to work correctly. > > Yes, we could abuse the DC component. > Were you thinking about: > DC=2001/DC=0db8 This looks closest to what is needed here, as the prefix for HHITs is currently proposed at /64. So it would be DC=2001/DC=0024/DC=0028/DC=0014 But the OID for DC is bigggg: 0.9.2342.19200300.100.1.25 Ouch. So I will research this more, but for this early stage in the development I will use: CN=2001:24:28:14::/64 Thanks for all the comments here. > > > In practice you could follow the nibble notation as already used > > for delegation of IPv6 reverse lookups in DNS. > > so more correctly: > DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 > > > However for the CN in the end cert you could perhaps use the full > > DNS reverse IPv6 name > > "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" > > or the URL/Mail notation "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" > > where the hex notation shall be the shortest form permitted by the > > IPv6 notation spec. > > Bob, this seems like the best immediate hack to me. From andrew.lynch at atos.net Thu Aug 15 17:11:33 2019 From: andrew.lynch at atos.net (Lynch, Andrew) Date: Thu, 15 Aug 2019 17:11:33 +0000 Subject: Difference ASN1_item_d2i_bio / ASN1_d2i_bio_of ? Message-ID: <60673c6a22d94c1ea8c0b3c8c7b0dd94@atos.net> Hi, I want to read several bespoke ASN1 types from a BIO. DECLARE_ASN1_FUNCTIONS does not include d2i bio routines, so what is the best way to define them? I have seen both ASN1_item_d2i_bio() and ASN1_d2i_bio_of() and it is not clear to me why one might be used over the other. E.g. cms_io.c has a one-line function calling ASN1_item_d2i_bio(): CMS_ContentInfo *d2i_CMS_bio(BIO *bp, CMS_ContentInfo **cms) { return ASN1_item_d2i_bio(ASN1_ITEM_rptr(CMS_ContentInfo), bp, cms); } Whereas ocsp.h has a macro using ASN1_d2i_bio_of, which itself is defined in terms of ASN1_d2i_bio(): # define d2i_OCSP_REQUEST_bio(bp,p) ASN1_d2i_bio_of(OCSP_REQUEST,OCSP_REQUEST_new,d2i_OCSP_REQUEST,bp,p) Regards, Andrew. From dheinz at softwarekey.com Thu Aug 15 17:18:44 2019 From: dheinz at softwarekey.com (Dan Heinz) Date: Thu, 15 Aug 2019 17:18:44 +0000 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> <8746a15d-e43c-1baa-a74e-49c5f59da1b7@openssl.org> Message-ID: >The output certainly suggests something is calling TlsAlloc between the call made for destructor_key.value and the one for private_drbg, and that index is never freed. You always get 7 when allocating destructor_key.value because that >index was freed when you unloaded OpenSSL, and so it's the next available one when you load OpenSSL again. > >It may not be OpenSSL itself that's calling TlsAlloc and not releasing an index - it may be one of its dependencies. > >Have you duplicated this under a debugger, with a breakpoint on TlsAlloc? The earlier messages suggest that you may have, but it's not entirely clear from what you posted. You ought to be able to catch the offending call and get at >least a partial traceback. > >If you're having trouble tracing it, you could try adding this: > >{int i; for (i=8; i >right after the code that calls TlsAlloc for private_drbg, and seeing what blows up. Not entirely conventional, but it might be revealing. After some further debugging, it appears there is an unknown TSAlloc called which returned index 8. OpenSSL was allocating index 7, then the index 8 was allocated somewhere outside the OpenSSL library, and finally OpenSSL allocated indexes 9, 10, and 11. I was able to call TlsFree(8) in my DLLMain when my DLL is unloaded and I didn't have any more issues. Obviously, that is not a fix and I was further able to track down at least where the allocation was happening. It is actually in a call to libxml2 and does not appear to be related to OpenSSL. Now I just need to figure out why libxml2 is not freeing it. Thank you Matt and Michael for you help. :-) From Michael.Wojcik at microfocus.com Thu Aug 15 18:53:16 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 15 Aug 2019 18:53:16 +0000 Subject: OPENSSL_init_crypto with OPENSSL_INIT_NO_ATEXIT issue In-Reply-To: References: <34ac1a1e-d6da-96f8-d20b-1ba589ef3d48@openssl.org> <8746a15d-e43c-1baa-a74e-49c5f59da1b7@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of > Dan Heinz > Sent: Thursday, August 15, 2019 13:19 > blows up. Not entirely conventional, but it might be revealing. > > It is actually in a call to libxml2 and does not > appear to be related to OpenSSL. Now I just need to figure out why libxml2 > is not freeing it. Some quick online searching (I don't have the source for libxml2 handy on this machine) suggests it may be the globalkey variable, allocated in xmlOnceInit. Some old messages from the libxml2 mailing list suggest it ought to be TlsFree'd in the DLL_PROCESS_DETACH case of libxml2's DllMain. If I were investigating this, I'd grab the libxml2 sources and build it for debug, then debug the process at fault with breakpoints set appropriately. -- Michael Wojcik Distinguished Engineer, Micro Focus From rgm at htt-consult.com Thu Aug 15 20:06:48 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 15 Aug 2019 16:06:48 -0400 Subject: client certs with no subjectName only SAN Message-ID: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> There are a number of things I am not clear on, and so far my searching and reading is coming up short. If there is no subjectName, only subjectAltName, is the subjectName still present in the cert only empty or is it totally gone. I have found that if I put -subj / in the openssl req, I end up with an empty subjectName.? Or is there someway to totally remove this from the cert? For the subjectAltName, is it suppose to be flagged critical?? I have seen references of: subjectAltName=critical,email:certtest at example.com Is this correct and the way to set SAN as critical? thanks The cert I have made so far is: $openssl x509 -noout -text -in $dir/certs/device1.cert.pem Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: ??????????? c9:8f:b2:7b:e1:95:74:cf ??????? Signature Algorithm: ED25519 ??????? Issuer: CN = 2001:24:28:14::/64 ??????? Validity ??????????? Not Before: Aug 15 19:51:17 2019 GMT ??????????? Not After : Aug 24 19:51:17 2020 GMT ??????? Subject: ??????? Subject Public Key Info: ??????????? Public Key Algorithm: ED25519 ??????????????? ED25519 Public-Key: ??????????????? pub: ??????????????????? 7a:a6:f2:7d:14:8f:fd:a9:55:d9:6f:d6:04:a1:e6: ??????????????????? 6d:9e:34:1f:d3:2b:59:80:cc:2f:4c:83:4f:81:a0: ??????????????????? 10:36 ??????? X509v3 extensions: ??????????? X509v3 Basic Constraints: ??????????????? CA:FALSE ??????????? Netscape Cert Type: ??????????????? SSL Client, S/MIME ??????????? Netscape Comment: ??????????????? OpenSSL Generated Client Certificate ??????????? X509v3 Subject Key Identifier: 97:B0:DC:A2:74:93:CF:76:5E:82:6C:08:9C:46:73:83:D3:86:8E:9A ??????????? X509v3 Authority Key Identifier: keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA ??????????? X509v3 Key Usage: critical ??????????????? Digital Signature, Non Repudiation, Key Encipherment ??????????? X509v3 Extended Key Usage: ??????????????? TLS Web Client Authentication, E-mail Protection ??????????? X509v3 Subject Alternative Name: ??????????????? IP Address:2001:24:28:14:B8AF:2789:CBB9:F7AC ??? Signature Algorithm: ED25519 ???????? 32:2e:7d:4d:ad:4d:87:4c:57:1a:df:ef:e3:ec:2b:b5:a7:fe: ???????? 2f:48:73:32:72:1a:b6:4a:cd:e4:88:75:98:4d:b0:9a:79:48: ???????? 2b:2c:12:68:0f:c0:86:bd:d9:4e:4b:85:fb:f3:91:68:f4:ec: ???????? 18:99:dd:7e:d5:f8:b6:f0:08:0e From rsalz at akamai.com Thu Aug 15 20:13:19 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 15 Aug 2019 20:13:19 +0000 Subject: client certs with no subjectName only SAN In-Reply-To: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> Message-ID: subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. From rgm at htt-consult.com Thu Aug 15 20:27:22 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 15 Aug 2019 16:27:22 -0400 Subject: client certs with no subjectName only SAN In-Reply-To: References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> Message-ID: <1370549b-af63-9903-48d3-889930973f86@htt-consult.com> On 8/15/19 4:13 PM, Salz, Rich wrote: > subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" Fine with me. > I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. It does seem empty with that -subj / command line option. I am not seeing subjectName in this dump of the cert: $??? openssl asn1parse -i -in $dir/certs/device1.cert.pem ??? 0:d=0? hl=4 l= 439 cons: SEQUENCE ??? 4:d=1? hl=4 l= 361 cons:? SEQUENCE ??? 8:d=2? hl=2 l=?? 3 cons:?? cont [ 0 ] ?? 10:d=3? hl=2 l=?? 1 prim:??? INTEGER?????????? :02 ?? 13:d=2? hl=2 l=?? 9 prim:?? INTEGER?????????? :C98FB27BE19574CF ?? 24:d=2? hl=2 l=?? 5 cons:?? SEQUENCE ?? 26:d=3? hl=2 l=?? 3 prim:??? OBJECT??????????? :ED25519 ?? 31:d=2? hl=2 l=? 29 cons:?? SEQUENCE ?? 33:d=3? hl=2 l=? 27 cons:??? SET ?? 35:d=4? hl=2 l=? 25 cons:???? SEQUENCE ?? 37:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :commonName ?? 42:d=5? hl=2 l=? 18 prim:????? UTF8STRING :2001:24:28:14::/64 ?? 62:d=2? hl=2 l=? 30 cons:?? SEQUENCE ?? 64:d=3? hl=2 l=? 13 prim:??? UTCTIME?????????? :190815195117Z ?? 79:d=3? hl=2 l=? 13 prim:??? UTCTIME?????????? :200824195117Z ?? 94:d=2? hl=2 l=?? 0 cons:?? SEQUENCE ?? 96:d=2? hl=2 l=? 42 cons:?? SEQUENCE ?? 98:d=3? hl=2 l=?? 5 cons:??? SEQUENCE ? 100:d=4? hl=2 l=?? 3 prim:???? OBJECT??????????? :ED25519 ? 105:d=3? hl=2 l=? 33 prim:??? BIT STRING ? 140:d=2? hl=3 l= 226 cons:?? cont [ 3 ] ? 143:d=3? hl=3 l= 223 cons:??? SEQUENCE ? 146:d=4? hl=2 l=?? 9 cons:???? SEQUENCE ? 148:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Basic Constraints ? 153:d=5? hl=2 l=?? 2 prim:????? OCTET STRING????? [HEX DUMP]:3000 ? 157:d=4? hl=2 l=? 17 cons:???? SEQUENCE ? 159:d=5? hl=2 l=?? 9 prim:????? OBJECT??????????? :Netscape Cert Type ? 170:d=5? hl=2 l=?? 4 prim:????? OCTET STRING????? [HEX DUMP]:030205A0 ? 176:d=4? hl=2 l=? 51 cons:???? SEQUENCE ? 178:d=5? hl=2 l=?? 9 prim:????? OBJECT??????????? :Netscape Comment ? 189:d=5? hl=2 l=? 38 prim:????? OCTET STRING????? [HEX DUMP]:16244F70656E53534C2047656E65726174656420436C69656E74204365727469666963617465 ? 229:d=4? hl=2 l=? 29 cons:???? SEQUENCE ? 231:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Subject Key Identifier ? 236:d=5? hl=2 l=? 22 prim:????? OCTET STRING????? [HEX DUMP]:041497B0DCA27493CF765E826C089C467383D3868E9A ? 260:d=4? hl=2 l=? 31 cons:???? SEQUENCE ? 262:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Authority Key Identifier ? 267:d=5? hl=2 l=? 24 prim:????? OCTET STRING????? [HEX DUMP]:30168014B145189B33826C7429692A15933B1C31D237D6CA ? 293:d=4? hl=2 l=? 14 cons:???? SEQUENCE ? 295:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Key Usage ? 300:d=5? hl=2 l=?? 1 prim:????? BOOLEAN?????????? :255 ? 303:d=5? hl=2 l=?? 4 prim:????? OCTET STRING????? [HEX DUMP]:030205E0 ? 309:d=4? hl=2 l=? 29 cons:???? SEQUENCE ? 311:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Extended Key Usage ? 316:d=5? hl=2 l=? 22 prim:????? OCTET STRING????? [HEX DUMP]:301406082B0601050507030206082B06010505070304 ? 340:d=4? hl=2 l=? 27 cons:???? SEQUENCE ? 342:d=5? hl=2 l=?? 3 prim:????? OBJECT??????????? :X509v3 Subject Alternative Name ? 347:d=5? hl=2 l=? 20 prim:????? OCTET STRING????? [HEX DUMP]:301287102001002400280014B8AF2789CBB9F7AC ? 369:d=1? hl=2 l=?? 5 cons:? SEQUENCE ? 371:d=2? hl=2 l=?? 3 prim:?? OBJECT??????????? :ED25519 ? 376:d=1? hl=2 l=? 65 prim:? BIT STRING From jb-openssl at wisemo.com Thu Aug 15 21:39:46 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 15 Aug 2019 23:39:46 +0200 Subject: IPv6 address encoding in commonName In-Reply-To: <6106fef6-8b48-ae34-a600-b4c8ba931844@htt-consult.com> References: <16901.1565822861@localhost> <6106fef6-8b48-ae34-a600-b4c8ba931844@htt-consult.com> Message-ID: <582eba61-2856-fba8-33d2-13cd87d5d87f@wisemo.com> [Top posting to match] Note that the actual DC name element is still used for actual domains when interacting with Microsoft Active Directory authentication, including associated X.509 certificates.? So it shouldn't be used for something contrary. The shortest useful form in terms of certificate size would probably be: Put an informal (but fixed format) description of the address scope in the user readable CN in certificates at all levels (rootCA, itemCA and end cert).? Put appropriate human readable organization name or equivalent in the O name element in rootCA and itemCA.? Make the end cert DN as short as possible. For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for [...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" to represent the device might be in any country). Put the actual address in the appropriate SAN in the end cert (this will be a binary address). Put name restrictions in the all the CAs (intermediary and special purpose root), these will be a binary address and length for the allowed type and the appropriate "nothing" notation for all the other defined name restriction types except the distinguished name type. Do not include ID number fields except the certificate serial number, which also protects the signature hash algorithm via randomization (since SHA-1 phase out began, but potentially useful for modern algorithms). Use a short offline-compatible revocation URL such as "ex.th/xy.crl" for hierarchies run by the hypothetical EXample conglomerate in THailand, where the xy part is a very short name assigned by that conglomerate to the issuing central CA or factory intermCA. On 15/08/2019 18:49, Robert Moskowitz wrote: > > > On 8/14/19 6:47 PM, Michael Richardson wrote: >> Robert Moskowitz wrote: >> ???? > I am fiddling around with an intermediate CA signing cert that >> the CA's >> ???? > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 address. >> Actually a >> ???? > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to be >> revised soon). >> >> ???? > For a client cert, it would be easy to put the HIT in >> subjectAltName per RFC >> ???? > 8002 (with a null subjectName), but a CA cert MUST have a >> non-empty >> ???? > subjectName. >> >> ???? > Thus all I want in this subjectName is commonName with the HIT. >> ???? > I am looking for examples of IPv6 addresses in commonName. >> >> I thought that RFC3779 did exactly what you want, but it does not >> define new >> Subject DN, but rather a new extension that will be bound to the Subject. >> (I was surprised that RFC3779 was not in the SIDR WG's list of >> documents,but >> I guess it preceeded the SIDR working group, and occured in PKIX) >> >> In ANIMA's ACP document, we have an abomination that leverages >> rfc822Name, >> mostly because we figure the odds of getting anything else through >> off-the-shelf CAs is nil. >> Note to consumed with things in your stomach: >> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 >> >> Jakob Bohm via openssl-users wrote: >> ???? > As the author of a proposal in this area, could you define a >> notation >> ???? > for IPv6 DNs, perhaps one that actually reflects the >> hierarchical nature >> ???? > of IPv6 addresses? >> >> RFC3779 does some of that, but not in the DN itself. >> >> ???? > You could take inspiration from the (unfortunately rarely used) >> ???? > hierarchical DN representation of DNS names (this used the DNS >> ???? > specific DC name components).? Overall the goal is to allow X.500 >> ???? > distinguished name restrictions to work correctly. >> >> Yes, we could abuse the DC component. >> Were you thinking about: >> ????? DC=2001/DC=0db8 > > This looks closest to what is needed here, as the prefix for HHITs is > currently proposed at /64. > > So it would be DC=2001/DC=0024/DC=0028/DC=0014 > > But the OID for DC is bigggg: 0.9.2342.19200300.100.1.25 > > Ouch. > > So I will research this more, but for this early stage in the > development I will use: > > CN=2001:24:28:14::/64 > > Thanks for all the comments here. > >> >> ???? > In practice you could follow the nibble notation as already used >> ???? > for delegation of IPv6 reverse lookups in DNS. >> >> so more correctly: >> ????? DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 >> >> ???? > However for the CN in the end cert you could perhaps use the full >> ???? > DNS reverse IPv6 name >> ???? > >> "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" >> ???? > or the URL/Mail notation >> "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" >> ???? > where the hex notation shall be the shortest form permitted by the >> ???? > IPv6 notation spec. >> >> Bob, this seems like the best immediate hack to me. Enjoy Jakob Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From rgm at htt-consult.com Thu Aug 15 22:00:48 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 15 Aug 2019 18:00:48 -0400 Subject: IPv6 address encoding in commonName In-Reply-To: <582eba61-2856-fba8-33d2-13cd87d5d87f@wisemo.com> References: <16901.1565822861@localhost> <6106fef6-8b48-ae34-a600-b4c8ba931844@htt-consult.com> <582eba61-2856-fba8-33d2-13cd87d5d87f@wisemo.com> Message-ID: <9d0fd9b6-7851-41d8-5d16-7b44a3a649c3@htt-consult.com> Jackob, I thank you for all this.? I will be studying it over the coming week(s). Bob On 8/15/19 5:39 PM, Jakob Bohm via openssl-users wrote: > [Top posting to match] > > Note that the actual DC name element is still used for actual domains > when interacting with Microsoft Active Directory authentication, > including associated X.509 certificates.? So it shouldn't be used for > something contrary. > > The shortest useful form in terms of certificate size would probably be: > > Put an informal (but fixed format) description of the address scope in > the user readable CN in certificates at all levels (rootCA, itemCA and > end cert).? Put appropriate human readable organization name or > equivalent in the O name element in rootCA and itemCA.? Make the end > cert DN as short as possible. > > For example "CN=HIT CA 2 example corp,O=example corp,C=TH" -> "CN=HIT > factory CA xy,O=Example Chon Buri plant,C=TH" -> "CN=HIT CA for > [...],O=In your device,C=XX" -> "CN=[2001:db8:a:b::],C=XX" (Using "XX" > to represent the device might be in any country). > > Put the actual address in the appropriate SAN in the end cert (this > will be a binary address). > > Put name restrictions in the all the CAs (intermediary and special > purpose root), these will be a binary address and length for the > allowed type and the appropriate "nothing" notation for all the other > defined name restriction types except the distinguished name type. > > Do not include ID number fields except the certificate serial number, > which also protects the signature hash algorithm via randomization > (since SHA-1 phase out began, but potentially useful for modern > algorithms). > > Use a short offline-compatible revocation URL such as "ex.th/xy.crl" > for hierarchies run by the hypothetical EXample conglomerate in > THailand, where the xy part is a very short name assigned by that > conglomerate to the issuing central CA or factory intermCA. > > On 15/08/2019 18:49, Robert Moskowitz wrote: >> >> >> On 8/14/19 6:47 PM, Michael Richardson wrote: >>> Robert Moskowitz wrote: >>> ???? > I am fiddling around with an intermediate CA signing cert >>> that the CA's >>> ???? > 'name' is it HIP (RFC 7401) HIT which is a valid IPv6 >>> address. Actually a >>> ???? > Hierarchical HIT as in draft-moskowitz-hierarchical-hip (to >>> be revised soon). >>> >>> ???? > For a client cert, it would be easy to put the HIT in >>> subjectAltName per RFC >>> ???? > 8002 (with a null subjectName), but a CA cert MUST have a >>> non-empty >>> ???? > subjectName. >>> >>> ???? > Thus all I want in this subjectName is commonName with the HIT. >>> ???? > I am looking for examples of IPv6 addresses in commonName. >>> >>> I thought that RFC3779 did exactly what you want, but it does not >>> define new >>> Subject DN, but rather a new extension that will be bound to the >>> Subject. >>> (I was surprised that RFC3779 was not in the SIDR WG's list of >>> documents,but >>> I guess it preceeded the SIDR working group, and occured in PKIX) >>> >>> In ANIMA's ACP document, we have an abomination that leverages >>> rfc822Name, >>> mostly because we figure the odds of getting anything else through >>> off-the-shelf CAs is nil. >>> Note to consumed with things in your stomach: >>> https://tools.ietf.org/html/draft-ietf-anima-autonomic-control-plane-20#section-6.1.2 >>> >>> >>> Jakob Bohm via openssl-users wrote: >>> ???? > As the author of a proposal in this area, could you define a >>> notation >>> ???? > for IPv6 DNs, perhaps one that actually reflects the >>> hierarchical nature >>> ???? > of IPv6 addresses? >>> >>> RFC3779 does some of that, but not in the DN itself. >>> >>> ???? > You could take inspiration from the (unfortunately rarely used) >>> ???? > hierarchical DN representation of DNS names (this used the DNS >>> ???? > specific DC name components).? Overall the goal is to allow >>> X.500 >>> ???? > distinguished name restrictions to work correctly. >>> >>> Yes, we could abuse the DC component. >>> Were you thinking about: >>> ????? DC=2001/DC=0db8 >> >> This looks closest to what is needed here, as the prefix for HHITs is >> currently proposed at /64. >> >> So it would be DC=2001/DC=0024/DC=0028/DC=0014 >> >> But the OID for DC is bigggg: 0.9.2342.19200300.100.1.25 >> >> Ouch. >> >> So I will research this more, but for this early stage in the >> development I will use: >> >> CN=2001:24:28:14::/64 >> >> Thanks for all the comments here. >> >>> >>> ???? > In practice you could follow the nibble notation as already used >>> ???? > for delegation of IPv6 reverse lookups in DNS. >>> >>> so more correctly: >>> ????? DC=2/DC=0/DC=0/DC=1/DC=d/DC=b/DC=8 >>> >>> ???? > However for the CN in the end cert you could perhaps use the >>> full >>> ???? > DNS reverse IPv6 name >>> ???? > >>> "x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.x.ip6.arpa" >>> ???? > or the URL/Mail notation >>> "[xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx]" >>> ???? > where the hex notation shall be the shortest form permitted >>> by the >>> ???? > IPv6 notation spec. >>> >>> Bob, this seems like the best immediate hack to me. > > > Enjoy > > Jakob > > Enjoy > > Jakob From chitrang.srivastava at gmail.com Fri Aug 16 09:26:42 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Fri, 16 Aug 2019 14:56:42 +0530 Subject: Acquire Entropy for embedded platform Message-ID: Hi, I am working on an embedded platform and now ported openssl 1.1.1b TLS 1.2/1.3 is working fine. While analysing random number , Rand pool initialization calls where I am returning like this , size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) { return rand_pool_entropy_available(pool); } As noticed that *rand_unix.c* has an implementation wcih samples 2 bits of RTC, would that give enough entropy or any other recommendation to have enough entropy for embedded platforms? Thanks, -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Fri Aug 16 09:31:10 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 16 Aug 2019 05:31:10 -0400 Subject: Acquire Entropy for embedded platform In-Reply-To: References: Message-ID: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> On 8/16/19 5:26 AM, Chitrang Srivastava wrote: > Hi, > > I am working on an embedded platform and now ported openssl 1.1.1b > TLS 1.2/1.3 is working fine. > While analysing random number , Rand pool initialization calls where I > am returning like this , > size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) > { > ?? ? ? ?return rand_pool_entropy_available(pool); > } > As noticed that *rand_unix.c* has an implementation wcih samples 2 > bits of RTC, would that give enough entropy or any other > recommendation to have enough entropy for embedded platforms? Check out:??? https://issihosts.com/haveged I talk about it here: http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Aug 16 09:33:11 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 16 Aug 2019 19:33:11 +1000 Subject: Acquire Entropy for embedded platform In-Reply-To: References: Message-ID: Two bits of RTC is nowhere near enough entropy. I could break two bits by hand in a few seconds ? there are only four possibilities. The best outcome is an hardware random number generator. These are often not readily available. Next would be waiting for enough entropy from interrupts, timers and the like. You didn?t specify what operating system/kernel you are using so further advise is less than useful. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava wrote: > > Hi, > > I am working on an embedded platform and now ported openssl 1.1.1b > TLS 1.2/1.3 is working fine. > While analysing random number , Rand pool initialization calls where I am returning like this , > size_t rand_pool_acquire_entropy(RAND_POOL *pool) > { > return rand_pool_entropy_available(pool); > } > As noticed that rand_unix.c has an implementation wcih samples 2 bits of RTC, would that give enough entropy or any other recommendation to have enough entropy for embedded platforms? > > Thanks, > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Aug 16 09:44:42 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 16 Aug 2019 19:44:42 +1000 Subject: Acquire Entropy for embedded platform In-Reply-To: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> Message-ID: I investigated HAVEGE fairly deeply a couple of years ago. I am completely in agreement with the basis of this source, however the sticking point was the ?expansion? phase. Essentially, every bit of entropy gathered is turned into (just under) thirty two bits of ?entropy?. This is logically and physically impossible. As a source, it appears reasonable to the usual tests (i.e. dieharder), although TestU01 does pick up on it being less than ideal. I would, however, recommend Stephan M?ller's CPU Jitter . The gathering is well researched and performed, no hidden tricks are present and the bits produces are equiprobable. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 16 Aug 2019, at 7:31 pm, Robert Moskowitz wrote: > > > > On 8/16/19 5:26 AM, Chitrang Srivastava wrote: >> Hi, >> >> I am working on an embedded platform and now ported openssl 1.1.1b >> TLS 1.2/1.3 is working fine. >> While analysing random number , Rand pool initialization calls where I am returning like this , >> size_t rand_pool_acquire_entropy(RAND_POOL *pool) >> { >> return rand_pool_entropy_available(pool); >> } >> As noticed that rand_unix.c has an implementation wcih samples 2 bits of RTC, would that give enough entropy or any other recommendation to have enough entropy for embedded platforms? > > > Check out: https://issihosts.com/haveged > > I talk about it here: http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chitrang.srivastava at gmail.com Fri Aug 16 10:28:32 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Fri, 16 Aug 2019 15:58:32 +0530 Subject: Acquire Entropy for embedded platform In-Reply-To: References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> Message-ID: Thanks Pauli, I did checked CPU Jitter and it looks promising. It has openssl engine support too. So i guess I have to add this add provide OS specific calls and it should work. Will keep you posted. Thanks, On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale wrote: > I investigated HAVEGE fairly deeply a couple of years ago. I am > completely in agreement with the basis of this source, however the sticking > point was the ?expansion? phase. Essentially, every bit of entropy > gathered is turned into (just under) thirty two bits of ?entropy?. This is > logically and physically impossible. As a source, it appears reasonable to > the usual tests (i.e. dieharder), although TestU01 > does pick up on it being less > than ideal. > > I would, however, recommend Stephan M?ller's CPU Jitter > . The gathering > is well researched and performed, no hidden tricks are present and the bits > produces are equiprobable. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 16 Aug 2019, at 7:31 pm, Robert Moskowitz wrote: > > > > On 8/16/19 5:26 AM, Chitrang Srivastava wrote: > > Hi, > > I am working on an embedded platform and now ported openssl 1.1.1b > TLS 1.2/1.3 is working fine. > While analysing random number , Rand pool initialization calls where I am > returning like this , > size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) > { > return rand_pool_entropy_available(pool); > } > As noticed that *rand_unix.c* has an implementation wcih samples 2 bits > of RTC, would that give enough entropy or any other recommendation to have > enough entropy for embedded platforms? > > > > Check out: https://issihosts.com/haveged > > I talk about it here: > http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Fri Aug 16 10:34:51 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 16 Aug 2019 20:34:51 +1000 Subject: Acquire Entropy for embedded platform In-Reply-To: References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> Message-ID: <047AAC59-79C5-4F8B-AF01-11C12C81F76A@oracle.com> Honestly, I?d like to add CPU Jitter to OpenSSL as one of its default entropy sources. I dread the effort that this would entail. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava wrote: > > Thanks Pauli, > > I did checked CPU Jitter and it looks promising. It has openssl engine support too. > So i guess I have to add this add provide OS specific calls and it should work. > Will keep you posted. > > Thanks, > > > On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale > wrote: > I investigated HAVEGE fairly deeply a couple of years ago. I am completely in agreement with the basis of this source, however the sticking point was the ?expansion? phase. Essentially, every bit of entropy gathered is turned into (just under) thirty two bits of ?entropy?. This is logically and physically impossible. As a source, it appears reasonable to the usual tests (i.e. dieharder), although TestU01 does pick up on it being less than ideal. > > I would, however, recommend Stephan M?ller's CPU Jitter . The gathering is well researched and performed, no hidden tricks are present and the bits produces are equiprobable. > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz > wrote: >> >> >> >> On 8/16/19 5:26 AM, Chitrang Srivastava wrote: >>> Hi, >>> >>> I am working on an embedded platform and now ported openssl 1.1.1b >>> TLS 1.2/1.3 is working fine. >>> While analysing random number , Rand pool initialization calls where I am returning like this , >>> size_t rand_pool_acquire_entropy(RAND_POOL *pool) >>> { >>> return rand_pool_entropy_available(pool); >>> } >>> As noticed that rand_unix.c has an implementation wcih samples 2 bits of RTC, would that give enough entropy or any other recommendation to have enough entropy for embedded platforms? >> >> >> Check out: https://issihosts.com/haveged >> >> I talk about it here: http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Aug 16 10:42:02 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 16 Aug 2019 12:42:02 +0200 Subject: Acquire Entropy for embedded platform In-Reply-To: References: Message-ID: [Top posting for consistency] More than OS dependency, this depends on the exact hardware on the platform: CPU, support chips, peripheral chips.?? Usually some of these can provide much more randomness than the highly predictable time of day/year RTC clock. ?And if none do, there are simple RNG hardware designs that could be added in a corner of the circuit, either on a plugin board or as part of a board already customized to the application. On 16/08/2019 11:33, Dr Paul Dale wrote: > Two bits of RTC is nowhere near enough entropy. ?I could break two > bits by hand in a few seconds ? there are only four possibilities. > > The best outcome is an hardware random number generator. ?These are > often not readily available. > > Next would be waiting for enough entropy from interrupts, timers and > the like. > > You didn?t specify what operating system/kernel you are using so > further advise is less than useful. > > >> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava >> > > wrote: >> >> Hi, >> >> I am working on an embedded platform and now ported openssl 1.1.1b >> TLS 1.2/1.3 is working fine. >> While analysing random number , Rand pool initialization calls where >> I am returning like this , >> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) >> { >> ?? ? ? ?return rand_pool_entropy_available(pool); >> } >> As noticed that *rand_unix.c* has an implementation wcih samples 2 >> bits of RTC, would that give enough entropy or any other >> recommendation to have enough entropy for embedded platforms? >> >> Thanks, >> >> >> >> >> > Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From chitrang.srivastava at gmail.com Fri Aug 16 10:44:02 2019 From: chitrang.srivastava at gmail.com (Chitrang Srivastava) Date: Fri, 16 Aug 2019 16:14:02 +0530 Subject: Acquire Entropy for embedded platform In-Reply-To: <047AAC59-79C5-4F8B-AF01-11C12C81F76A@oracle.com> References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> <047AAC59-79C5-4F8B-AF01-11C12C81F76A@oracle.com> Message-ID: from the git repo of cpu jitter i see few files only so may be easy to compile at least. Yeah it can be added to openssl source with macro to enable it. On Fri, Aug 16, 2019 at 4:05 PM Dr Paul Dale wrote: > Honestly, I?d like to add CPU Jitter to OpenSSL as one of its default > entropy sources. > I dread the effort that this would entail. > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > > On 16 Aug 2019, at 8:28 pm, Chitrang Srivastava < > chitrang.srivastava at gmail.com> wrote: > > Thanks Pauli, > > I did checked CPU Jitter and it looks promising. It has openssl engine > support too. > So i guess I have to add this add provide OS specific calls and it should > work. > Will keep you posted. > > Thanks, > > > On Fri, Aug 16, 2019 at 3:15 PM Dr Paul Dale wrote: > >> I investigated HAVEGE fairly deeply a couple of years ago. I am >> completely in agreement with the basis of this source, however the sticking >> point was the ?expansion? phase. Essentially, every bit of entropy >> gathered is turned into (just under) thirty two bits of ?entropy?. This is >> logically and physically impossible. As a source, it appears reasonable to >> the usual tests (i.e. dieharder), although TestU01 >> does pick up on it being less >> than ideal. >> >> I would, however, recommend Stephan M?ller's CPU Jitter >> . The gathering >> is well researched and performed, no hidden tricks are present and the bits >> produces are equiprobable. >> >> >> Pauli >> -- >> Dr Paul Dale | Distinguished Architect | Cryptographic Foundations >> Phone +61 7 3031 7217 >> Oracle Australia >> >> >> >> >> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz wrote: >> >> >> >> On 8/16/19 5:26 AM, Chitrang Srivastava wrote: >> >> Hi, >> >> I am working on an embedded platform and now ported openssl 1.1.1b >> TLS 1.2/1.3 is working fine. >> While analysing random number , Rand pool initialization calls where I am >> returning like this , >> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) >> { >> return rand_pool_entropy_available(pool); >> } >> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits >> of RTC, would that give enough entropy or any other recommendation to have >> enough entropy for embedded platforms? >> >> >> >> Check out: https://issihosts.com/haveged >> >> I talk about it here: >> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Erwann.Abalea at docusign.com Fri Aug 16 10:47:10 2019 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Fri, 16 Aug 2019 10:47:10 +0000 Subject: client certs with no subjectName only SAN In-Reply-To: References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> Message-ID: Bonjour, In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL. Cordialement, Erwann Abalea ?Le 15/08/2019 22:13, ? openssl-users au nom de Salz, Rich via openssl-users ? a ?crit : subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. From paul.dale at oracle.com Fri Aug 16 10:53:57 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Fri, 16 Aug 2019 20:53:57 +1000 Subject: Acquire Entropy for embedded platform In-Reply-To: References: Message-ID: <9719B1B9-FD13-4626-B466-62B29B744103@oracle.com> I agree. Using internal hardware in the processor for entropy depends on everything. Each processor needs to be independently quantified and not doing so becomes a risk assessment. As for hardware sources, they are essentially black boxes and could contain anything. It is extremely difficult, if not impossible, to tell if the hardware RNG is good or not. This doesn?t mean that they should not be used, it just means that using them involves another risk assessment. Pauli -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users wrote: > > [Top posting for consistency] > > More than OS dependency, this depends on the exact hardware on the platform: > CPU, support chips, peripheral chips. Usually some of these can provide > much more randomness than the highly predictable time of day/year RTC clock. > And if none do, there are simple RNG hardware designs that could be added > in a corner of the circuit, either on a plugin board or as part of a board > already customized to the application. > > > On 16/08/2019 11:33, Dr Paul Dale wrote: >> Two bits of RTC is nowhere near enough entropy. I could break two bits by hand in a few seconds ? there are only four possibilities. >> >> The best outcome is an hardware random number generator. These are often not readily available. >> >> Next would be waiting for enough entropy from interrupts, timers and the like. >> >> You didn?t specify what operating system/kernel you are using so further advise is less than useful. >> >> >>> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava > wrote: >>> >>> Hi, >>> >>> I am working on an embedded platform and now ported openssl 1.1.1b >>> TLS 1.2/1.3 is working fine. >>> While analysing random number , Rand pool initialization calls where I am returning like this , >>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) >>> { >>> return rand_pool_entropy_available(pool); >>> } >>> As noticed that *rand_unix.c* has an implementation wcih samples 2 bits of RTC, would that give enough entropy or any other recommendation to have enough entropy for embedded platforms? >>> >>> Thanks, >>> >>> >>> >>> >>> >> > > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Fri Aug 16 11:05:46 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 16 Aug 2019 13:05:46 +0200 Subject: Acquire Entropy for embedded platform In-Reply-To: <9719B1B9-FD13-4626-B466-62B29B744103@oracle.com> References: <9719B1B9-FD13-4626-B466-62B29B744103@oracle.com> Message-ID: <5c14728e-b993-4344-1206-4d2f35634b0a@wisemo.com> Not just dedicated black box rngs in verious chips (such as multifunction I/O chips or the old Intel BIOS chip), but also general hardware that happens to have plenty of inherent randomness due to its design or implementation. The simple easy to add RNG circuits include some completely open discrete designs if that's desired. On 16/08/2019 12:53, Dr Paul Dale wrote: > I agree. ?Using internal hardware in the processor for entropy depends > on everything. ?Each processor needs to be independently quantified > and not doing so becomes a risk assessment. > > As for hardware sources, they are essentially black boxes and could > contain anything. ?It is extremely difficult, if not impossible, to > tell if the hardware RNG is good or not. ?This doesn?t mean that they > should not be used, it just means that using them involves another > risk assessment. > > > >> On 16 Aug 2019, at 8:42 pm, Jakob Bohm via openssl-users >> > wrote: >> >> [Top posting for consistency] >> >> More than OS dependency, this depends on the exact hardware on the >> platform: >> CPU, support chips, peripheral chips.?? Usually some of these can provide >> much more randomness than the highly predictable time of day/year RTC >> clock. >> ?And if none do, there are simple RNG hardware designs that could be >> added >> in a corner of the circuit, either on a plugin board or as part of a >> board >> already customized to the application. >> >> >> On 16/08/2019 11:33, Dr Paul Dale wrote: >>> Two bits of RTC is nowhere near enough entropy. ?I could break two >>> bits by hand in a few seconds ? there are only four possibilities. >>> >>> The best outcome is an hardware random number generator. ?These are >>> often not readily available. >>> >>> Next would be waiting for enough entropy from interrupts, timers and >>> the like. >>> >>> You didn?t specify what operating system/kernel you are using so >>> further advise is less than useful. >>> >>> >>>> On 16 Aug 2019, at 7:26 pm, Chitrang Srivastava >>>> >>> >>>> > wrote: >>>> >>>> Hi, >>>> >>>> I am working on an embedded platform and now ported openssl 1.1.1b >>>> TLS 1.2/1.3 is working fine. >>>> While analysing random number , Rand pool initialization calls >>>> where I am returning like this , >>>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) >>>> { >>>> ?? ? ? ?return rand_pool_entropy_available(pool); >>>> } >>>> As noticed that *rand_unix.c* has an implementation wcih samples 2 >>>> bits of RTC, would that give enough entropy or any other >>>> recommendation to have enough entropy for embedded platforms? >>>> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From rsalz at akamai.com Fri Aug 16 11:56:57 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Aug 2019 11:56:57 +0000 Subject: Acquire Entropy for embedded platform In-Reply-To: <047AAC59-79C5-4F8B-AF01-11C12C81F76A@oracle.com> References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> <047AAC59-79C5-4F8B-AF01-11C12C81F76A@oracle.com> Message-ID: <07E021E2-B96D-416E-AF34-57CD554C0755@akamai.com> * Honestly, I?d like to add CPU Jitter to OpenSSL as one of its default entropy sources. * I dread the effort that this would entail. Open an issue and maybe someone with an older platform will work on doing it. I don?t think the project has any need to support such things. (Members of the project working for companies, perhaps) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Fri Aug 16 11:58:37 2019 From: rsalz at akamai.com (Salz, Rich) Date: Fri, 16 Aug 2019 11:58:37 +0000 Subject: client certs with no subjectName only SAN In-Reply-To: References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> Message-ID: <276827C7-2AAE-42D6-94CC-54C1A569CCE8@akamai.com> > In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." > It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL. You are of course correct. Thanks Erwann. (He has forgotten more about ASN1 than I ever knew :) From rgm at htt-consult.com Fri Aug 16 12:20:18 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 16 Aug 2019 08:20:18 -0400 Subject: client certs with no subjectName only SAN In-Reply-To: <276827C7-2AAE-42D6-94CC-54C1A569CCE8@akamai.com> References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> <276827C7-2AAE-42D6-94CC-54C1A569CCE8@akamai.com> Message-ID: On 8/16/19 7:58 AM, Salz, Rich wrote: >> In the same paragraph, the sentence before the one you're quoting says "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." > I will run another test today and see if it is as easy as claimed to flag SAN critical. >> It's not possible to have a missing subject name in a certificate, the field is not OPTIONAL. I was wondering more the construction of the cert when 'no subjectName'.? You confirmed that the object is there. Probably length 0.? I will have to look at that asnparse listing more critically. > > You are of course correct. Thanks Erwann. (He has forgotten more about ASN1 than I ever knew :) > Why I ask, perhaps seemingly dumb questions, here.? Those that really know the stuff are still around. I learned enough ASN1 to get by with x.509 and snmp and have forgotten much of what I learned ~20 years ago.? I do have an iana enterprise number that I used in some of my OID proposals in both way back then. The failing read access really bites. thanks both of you. From rgm at htt-consult.com Fri Aug 16 12:22:17 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 16 Aug 2019 08:22:17 -0400 Subject: Acquire Entropy for embedded platform In-Reply-To: References: <5a963c25-9b5d-a78d-3c4b-095045ac4cac@htt-consult.com> Message-ID: On 8/16/19 5:44 AM, Dr Paul Dale wrote: > I investigated HAVEGE fairly deeply a couple of years ago. ?I am > completely in agreement with the basis of this source, however the > sticking point was the ?expansion? phase. ?Essentially, every bit of > entropy gathered is turned into (just under) thirty two bits of > ?entropy?. ?This is logically and physically impossible. ?As a source, > it appears reasonable to the usual tests (i.e. dieharder), although > TestU01 ?does pick up on it > being less than ideal. > > I would, however, recommend Stephan M?ller's CPU Jitter > . ?The > gathering is well researched and performed, no hidden tricks are > present and the bits produces are equiprobable. Thanks.? I will take a look at CPU Jitter.? Entropy can be an issue on some of my armv7 boards.? I run CentOS on them, so all I need to find are rpms for something to test it out... > > > Pauli > -- > Dr Paul Dale | Distinguished Architect | Cryptographic Foundations > Phone +61 7 3031 7217 > Oracle Australia > > > > >> On 16 Aug 2019, at 7:31 pm, Robert Moskowitz > > wrote: >> >> >> >> On 8/16/19 5:26 AM, Chitrang Srivastava wrote: >>> Hi, >>> >>> I am working on an embedded platform and now ported openssl 1.1.1b >>> TLS 1.2/1.3 is working fine. >>> While analysing random number , Rand pool initialization calls where >>> I am returning like this , >>> size_t *rand_pool_acquire_entropy*(RAND_POOL *pool) >>> { >>> ?? ? ? ?return rand_pool_entropy_available(pool); >>> } >>> As noticed that *rand_unix.c* has an implementation wcih samples 2 >>> bits of RTC, would that give enough entropy or any other >>> recommendation to have enough entropy for embedded platforms? >> >> >> Check out: https://issihosts.com/haveged >> >> I talk about it here: >> http://www.htt-consult.com/CentOS7-armv7.html#RANDOMNESS >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Fri Aug 16 12:41:37 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Fri, 16 Aug 2019 22:41:37 +1000 Subject: client certs with no subjectName only SAN In-Reply-To: References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> Message-ID: <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> > On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users wrote: > > subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" This is wrong. When the subject DN is empty, the subjectAltName should be marked as critical. IIRC some Java implementations reject the certificate otherwise. > I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. OpenSSL supports empty (empty RDN sequence) subject DNs. The "-subj /" option is one way to make that happen. Empty is of course different from "absent", which is not possible, since the subject DN is a required component of an X.509 certificate. -- Viktor. From rgm at htt-consult.com Fri Aug 16 15:10:29 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 16 Aug 2019 11:10:29 -0400 Subject: client certs with no subjectName only SAN In-Reply-To: <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> Message-ID: Viktor, On 8/16/19 8:41 AM, Viktor Dukhovni wrote: >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users wrote: >> >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" > This is wrong. When the subject DN is empty, the subjectAltName should be > marked as critical. IIRC some Java implementations reject the certificate > otherwise. I have just created a client cert with empty subjectName and critical subjectAltName.? Interestingly, it is 4 bytes larger than the earlier non-critical SAN cert.? See below for the output of the cert. >> I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. > OpenSSL supports empty (empty RDN sequence) subject DNs. > The "-subj /" option is one way to make that happen. > > Empty is of course different from "absent", which is not > possible, since the subject DN is a required component of > an X.509 certificate. I now have it clear that Empty SN is NOT a cert with NO SN.? It is there with null content. Thank you all. $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem Certificate: ??? Data: ??????? Version: 3 (0x2) ??????? Serial Number: ??????????? c9:8f:b2:7b:e1:95:74:d0 ??????? Signature Algorithm: ED25519 ??????? Issuer: CN = 2001:24:28:14::/64 ??????? Validity ??????????? Not Before: Aug 16 14:54:58 2019 GMT ??????????? Not After : Aug 25 14:54:58 2020 GMT ??????? Subject: ??????? Subject Public Key Info: ??????????? Public Key Algorithm: ED25519 ??????????????? ED25519 Public-Key: ??????????????? pub: ??????????????????? 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50: ??????????????????? c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8: ??????????????????? 4c:a5 ??????? X509v3 extensions: ??????????? X509v3 Basic Constraints: ??????????????? CA:FALSE ??????????? Netscape Cert Type: ??????????????? SSL Client, S/MIME ??????????? Netscape Comment: ??????????????? OpenSSL Generated Client Certificate ??????????? X509v3 Subject Key Identifier: 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD ??????????? X509v3 Authority Key Identifier: keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA ??????????? X509v3 Key Usage: critical ??????????????? Digital Signature, Non Repudiation, Key Encipherment ??????????? X509v3 Extended Key Usage: ??????????????? TLS Web Client Authentication, E-mail Protection ??????????? X509v3 Subject Alternative Name: critical ??????????????? IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C ??? Signature Algorithm: ED25519 ???????? 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1: ???????? 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46: ???????? dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a: ???????? ba:1a:b4:17:c0:bb:0f:da:be:02 From Erwann.Abalea at docusign.com Fri Aug 16 16:34:00 2019 From: Erwann.Abalea at docusign.com (Erwann Abalea) Date: Fri, 16 Aug 2019 16:34:00 +0000 Subject: client certs with no subjectName only SAN In-Reply-To: References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> Message-ID: <98309B52-D421-461F-A1FB-99F9DE7FFA2F@docusign.com> Bonjour, Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size. Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default). If size is a hard constraint: - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 octets). Depending on your use-case, you may need to tweak the EKU (or remove it completely). - SKI and AKI extensions may not be necessary - Key Usage may be marked as non critical (it's a SHOULD in PKIX) A quick reading of RFC8002 tells me that you may need to include the IssuerAltName extension as well? Cordialement, Erwann Abalea ?Le 16/08/2019 17:11, ? openssl-users au nom de Robert Moskowitz ? a ?crit : Viktor, On 8/16/19 8:41 AM, Viktor Dukhovni wrote: >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users wrote: >> >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" > This is wrong. When the subject DN is empty, the subjectAltName should be > marked as critical. IIRC some Java implementations reject the certificate > otherwise. I have just created a client cert with empty subjectName and critical subjectAltName. Interestingly, it is 4 bytes larger than the earlier non-critical SAN cert. See below for the output of the cert. >> I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. > OpenSSL supports empty (empty RDN sequence) subject DNs. > The "-subj /" option is one way to make that happen. > > Empty is of course different from "absent", which is not > possible, since the subject DN is a required component of > an X.509 certificate. I now have it clear that Empty SN is NOT a cert with NO SN. It is there with null content. Thank you all. $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem Certificate: Data: Version: 3 (0x2) Serial Number: c9:8f:b2:7b:e1:95:74:d0 Signature Algorithm: ED25519 Issuer: CN = 2001:24:28:14::/64 Validity Not Before: Aug 16 14:54:58 2019 GMT Not After : Aug 25 14:54:58 2020 GMT Subject: Subject Public Key Info: Public Key Algorithm: ED25519 ED25519 Public-Key: pub: 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50: c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8: 4c:a5 X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Cert Type: SSL Client, S/MIME Netscape Comment: OpenSSL Generated Client Certificate X509v3 Subject Key Identifier: 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD X509v3 Authority Key Identifier: keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA X509v3 Key Usage: critical Digital Signature, Non Repudiation, Key Encipherment X509v3 Extended Key Usage: TLS Web Client Authentication, E-mail Protection X509v3 Subject Alternative Name: critical IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C Signature Algorithm: ED25519 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1: 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46: dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a: ba:1a:b4:17:c0:bb:0f:da:be:02 From rgm at htt-consult.com Fri Aug 16 16:48:59 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 16 Aug 2019 12:48:59 -0400 Subject: client certs with no subjectName only SAN In-Reply-To: <98309B52-D421-461F-A1FB-99F9DE7FFA2F@docusign.com> References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> <98309B52-D421-461F-A1FB-99F9DE7FFA2F@docusign.com> Message-ID: <7748b796-b7bc-f6d8-3961-3489f3ed2fb7@htt-consult.com> On 8/16/19 12:34 PM, Erwann Abalea wrote: > Bonjour, > > Having a critical extension adds 3 octets (the BOOLEAN tag, length=1, value=0xff). It may, as a side effect, enlarge the number of octets necessary to encode some structure size. > > Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default). > > If size is a hard constraint: > - you can probably remove the emailProtection EKU (it's an OID, you'll gain 10 octets). Depending on your use-case, you may need to tweak the EKU (or remove it completely). > - SKI and AKI extensions may not be necessary > - Key Usage may be marked as non critical (it's a SHOULD in PKIX) I will look at this and figure out what to change in my .cnf.? I have been using what I have in my: draft-moskowitz-eddsa-pki > A quick reading of RFC8002 tells me that you may need to include the IssuerAltName extension as well? That is the 8002 SHOULD.? But following rfc 2119 on SHOULD, since I can calculate the Issuer HHIT from the prefix in issuerName and the Issuer's Public Key (not carried in the client cert, got to go up the chain to get that), I am avoiding at this stage of development to closely follow 8002.? Still thinking on all this. Thank you on your help > > Cordialement, > Erwann Abalea > > ?Le 16/08/2019 17:11, ? openssl-users au nom de Robert Moskowitz ? a ?crit : > > Viktor, > > > On 8/16/19 8:41 AM, Viktor Dukhovni wrote: > >> On Aug 16, 2019, at 6:13 AM, Salz, Rich via openssl-users wrote: > >> > >> subjectAltName is rarely marked as critical; sec 4.2.1.6 of PKIX says "SHOULD mark subjectAltName as non-critical" > > This is wrong. When the subject DN is empty, the subjectAltName should be > > marked as critical. IIRC some Java implementations reject the certificate > > otherwise. > > I have just created a client cert with empty subjectName and critical > subjectAltName. Interestingly, it is 4 bytes larger than the earlier > non-critical SAN cert. See below for the output of the cert. > > >> I can believe that OpenSSL doesn't support empty subjectName's. An empty one, with no relative disintuished name components, is not the same as not present. > > OpenSSL supports empty (empty RDN sequence) subject DNs. > > The "-subj /" option is one way to make that happen. > > > > Empty is of course different from "absent", which is not > > possible, since the subject DN is a required component of > > an X.509 certificate. > > I now have it clear that Empty SN is NOT a cert with NO SN. It is there > with null content. > > Thank you all. > > $ openssl x509 -noout -text -in $dir/certs/device2.cert.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: > c9:8f:b2:7b:e1:95:74:d0 > Signature Algorithm: ED25519 > Issuer: CN = 2001:24:28:14::/64 > Validity > Not Before: Aug 16 14:54:58 2019 GMT > Not After : Aug 25 14:54:58 2020 GMT > Subject: > Subject Public Key Info: > Public Key Algorithm: ED25519 > ED25519 Public-Key: > pub: > 69:4f:1c:77:56:69:3a:cd:86:c4:3a:b0:67:b9:50: > c3:12:9c:6f:85:65:a0:8f:fa:b5:74:b1:c4:56:f8: > 4c:a5 > X509v3 extensions: > X509v3 Basic Constraints: > CA:FALSE > Netscape Cert Type: > SSL Client, S/MIME > Netscape Comment: > OpenSSL Generated Client Certificate > X509v3 Subject Key Identifier: > 8A:8D:18:B6:F7:70:7D:17:64:AA:2F:C7:FF:1F:C2:30:E2:D8:56:DD > X509v3 Authority Key Identifier: > keyid:B1:45:18:9B:33:82:6C:74:29:69:2A:15:93:3B:1C:31:D2:37:D6:CA > > X509v3 Key Usage: critical > Digital Signature, Non Repudiation, Key Encipherment > X509v3 Extended Key Usage: > TLS Web Client Authentication, E-mail Protection > X509v3 Subject Alternative Name: critical > IP Address:2001:24:28:14:2B6E:2C43:A2D8:507C > Signature Algorithm: ED25519 > 01:54:3e:d2:21:36:27:57:f2:da:d7:ee:42:ec:8f:05:99:b1: > 4b:de:2c:c4:3b:95:6f:ba:f6:25:a5:10:bb:2d:5c:9b:15:46: > dc:67:ea:b4:74:df:a6:52:60:6f:cd:06:af:f4:69:5f:37:1a: > ba:1a:b4:17:c0:bb:0f:da:be:02 > > > > From kgoldman at us.ibm.com Fri Aug 16 19:56:58 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Fri, 16 Aug 2019 15:56:58 -0400 Subject: Add ECDSA signature R and S to X509 structure Message-ID: I have an ECDSA signature supplied to me as R and S byte arrays and lengths (from an HSM). How do I add them to the X509 structure? Is there an API, a set of calls, or do you have any hints? ~~ For RSA, I simply filled in the ASN1_BIT_STRING length, data, and flags, but an RSA signature is a simply BIT_STRING. For ECDSA, the BIT_STRING is a SEQUENCE of two INTEGERs. I could construct the SEQUENCE DER manually and then add it as with RSA, but that seems like a hack. Is there a better way? Is there a better way for RSA? I suspect that peering inside the ASN1_BIT_STRING will break for openssl 1.1. From bbrumley at gmail.com Sat Aug 17 12:35:02 2019 From: bbrumley at gmail.com (Billy Brumley) Date: Sat, 17 Aug 2019 15:35:02 +0300 Subject: Add ECDSA signature R and S to X509 structure In-Reply-To: References: Message-ID: Hey Ken, > I have an ECDSA signature supplied to me as R and S byte arrays and > lengths (from an HSM). > > How do I add them to the X509 structure? > > Is there an API, a set of calls, or do you have any hints? You might be looking for ECDSA_SIG_set0: https://www.openssl.org/docs/man1.1.0/man3/ECDSA_SIG_set0.html You might find some snippets in ecdsatest.c. Hope it helps, BBB From deepak.redmi2 at gmail.com Sun Aug 18 22:50:37 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Mon, 19 Aug 2019 04:20:37 +0530 Subject: FIPS object module with /MT Message-ID: Dear Experts, Why can one not build the OpenSSL FIPS object module (FOM) with /MT on windows officially? I read that modifying any flags / steps while building FOM is not allowed. Is there any complaint workaround for using FOM with an application which is built with /MT? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From deepak.redmi2 at gmail.com Mon Aug 19 11:07:05 2019 From: deepak.redmi2 at gmail.com (Dipak B) Date: Mon, 19 Aug 2019 16:37:05 +0530 Subject: Can we build FOM with static runtime on win32? Message-ID: Dear Experts, Can we build the FIPS object module with static CRT (/MT) on windows? Can I run 'perl configure' before calling ms/do_fips.bat while building FOM? Could not infer this from the documents. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Mon Aug 19 16:17:37 2019 From: openssl at jordan.maileater.net (Jordan Brown) Date: Mon, 19 Aug 2019 16:17:37 +0000 Subject: client certs with no subjectName only SAN In-Reply-To: <98309B52-D421-461F-A1FB-99F9DE7FFA2F@docusign.com> References: <7d1d818c-d21c-c506-a9fd-c546fb2c3b68@htt-consult.com> <14FFEBE3-A887-4DA9-85C9-ADC20456C416@dukhovni.org> <98309B52-D421-461F-A1FB-99F9DE7FFA2F@docusign.com> Message-ID: <0101016caaab6d8e-cfa5e24f-88b6-477f-8820-84eff624f0e0-000000@us-west-2.amazonses.com> On 8/16/2019 9:34 AM, Erwann Abalea via openssl-users wrote: > Remove the 2 Netscape extensions, they're way obsolete (don't know why OpenSSL keeps them by default). > Is there a preferred alternative to the "Netscape Comment"?? That seems like a useful attribute, and I don't find anything more generic. -- Jordan Brown, Oracle ZFS Storage Appliance, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From ranier_gyn at hotmail.com Mon Aug 19 17:30:41 2019 From: ranier_gyn at hotmail.com (Ranier VF) Date: Mon, 19 Aug 2019 17:30:41 +0000 Subject: Server(TomCat) disconnect client(ECDHE-RSA-AES128-SHA) openssl-1.1.1c Message-ID: Hi, I have a trouble with use of openssl-1.1.1c when connects with homologacao.sefaz.mt.gov.br: Server Cipher suites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Client is setup with: SSL_set_cipher_list(tls, "ALL") Server disconnects connection. 1.Why, session cipher select by client is: ECDHE-RSA-AES128-SHA 2.How configure client to use server ciphers? Logs: DTLS: no protocol: TLSv1.3 cipher name: (NONE) DTLS: no protocol: TLSv1.3 cipher name: (NONE) SSL_connect:before SSL initialization DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server done DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client key exchange DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSL negotiation finished successfully DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSL negotiation finished successfully DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read hello request DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate request DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server done DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write certificate verify DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL3 alert read:fatal:handshake failure DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:error in error SSL_read failed:: WSAError: 0 SSL State: SSLERR SSL Error: -1 1 error:00000001:lib(0):func(0):reason(1) SSL Error: -1 336151568 error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read finished SSL_read failed:: WSAError: 10054 SSL State: SSLOK SSL Error: -1 5 error:00000005:lib(0):func(0):DH lib From ranier_gyn at hotmail.com Mon Aug 19 18:10:08 2019 From: ranier_gyn at hotmail.com (Ranier VF) Date: Mon, 19 Aug 2019 18:10:08 +0000 Subject: Server(TomCat) disconnect client(ECDHE-RSA-AES128-SHA) openssl-1.1.1c In-Reply-To: References: Message-ID: Hi, There a list ciphers compiled in openssl-1.11.c ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:DHE-RSA-AES256-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA None support CBC. How compile openssl with CBC support? best regards Ranier Vilela ________________________________________ De: Ranier VF Enviado: segunda-feira, 19 de agosto de 2019 17:30 Para: openssl-users at openssl.org Assunto: Server(TomCat) disconnect client(ECDHE-RSA-AES128-SHA) openssl-1.1.1c Hi, I have a trouble with use of openssl-1.1.1c when connects with homologacao.sefaz.mt.gov.br: Server Cipher suites: TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 (0xc027) ECDH secp256r1 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 (0xc028) ECDH secp256r1 TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_CAMELLIA_128_CBC_SHA TLS_RSA_WITH_CAMELLIA_256_CBC_SHA TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA Client is setup with: SSL_set_cipher_list(tls, "ALL") Server disconnects connection. 1.Why, session cipher select by client is: ECDHE-RSA-AES128-SHA 2.How configure client to use server ciphers? Logs: DTLS: no protocol: TLSv1.3 cipher name: (NONE) DTLS: no protocol: TLSv1.3 cipher name: (NONE) SSL_connect:before SSL initialization DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server done DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client key exchange DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSL negotiation finished successfully DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSL negotiation finished successfully DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read hello request DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write client hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server hello DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server certificate request DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS read server done DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client certificate DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write client key exchange DTLS: no protocol: TLSv1.2 cipher name: (NONE) SSL_connect:SSLv3/TLS write certificate verify DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS write finished DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL3 alert read:fatal:handshake failure DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:error in error SSL_read failed:: WSAError: 0 SSL State: SSLERR SSL Error: -1 1 error:00000001:lib(0):func(0):reason(1) SSL Error: -1 336151568 error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec DTLS: no protocol: TLSv1.2 cipher name: ECDHE-RSA-AES128-SHA SSL_connect:SSLv3/TLS read finished SSL_read failed:: WSAError: 10054 SSL State: SSLOK SSL Error: -1 5 error:00000005:lib(0):func(0):DH lib From chris.fahlin at tee2.org Mon Aug 19 21:26:18 2019 From: chris.fahlin at tee2.org (Chris Fahlin) Date: Mon, 19 Aug 2019 14:26:18 -0700 Subject: fipsld in CMake Message-ID: Hello, I am trying to compile an openSSL wrapper for use on android, using fipsld to generate a fips compliant so file. It seems that android favors cmake now, so I was wondering if anyone got the fipsld steps working within cmake successfully and can give any pointers Thanks From tim.j.culhane at gmail.com Wed Aug 21 11:41:04 2019 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Wed, 21 Aug 2019 12:41:04 +0100 Subject: how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN Message-ID: <000801d55815$53115520$f933ff60$@gmail.com> Hi all, I'm writing tests to verify how our mail server handles tls errors returned from the OpenSSL library when verifying a certificate during tls negotiation. The test works by sending a message to a source mail server which then relays the message to the destination mail server. The operation of relaying the message is done over a secure connection using port 465. I want to reproduce a scenario where when the source mailserver opens a connection to the destination server and carries out a tls negotiation that the error returned is X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN. However, no matter what way I try it I always get the similar but different error: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The OpenSSL library version I'm using is 1.1.1c running on a CentOS 7 server. My current steps are as follows: Create our own root CA public/private key pair Then set up two intermediate certs: For the first intermediate cert create its CA and private key. Sign it using the root CA's key. Do the same thin for the second intermediate key but sign it with the first intermediate key. I then generate a certificate request for each of the mail servers . I self sign the certificates and generate the server certificates. I append the intermediate certificates to the file containing the host certificate. These are then installed on each server. I copy various options of the root CA certificate and the intermediate certificates into the CACertificates directory of my source mail server. These will be used when the mail server attempts to negotiate a secure connection to the destination server. However, no matter what I try I don't get the X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN returned. As an experiment I ran the command: Openssl verify -verbose -untrusted And that does reproduce the correct error. Any idea how I can get OpenSSL to return my dsired error? Hopefully my above description makes sense. Many thanks, Tim From doctor at doctor.nl2k.ab.ca Fri Aug 23 11:54:44 2019 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 23 Aug 2019 05:54:44 -0600 Subject: Error on 20190823 release Message-ID: <20190823115444.GB50529@doctor.nl2k.ab.ca> Found this during the tests ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 162 Failed: 1) Failed test: 161 Non-zero exit status: 1 What informationh do you require? -- Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising! https://www.empire.kred/ROOTNK?t=94a1f39b Look at Psalms 14 and 53 on Atheism Manitoba - Vote Liberal to Give Palliser and Scheer a message on 10 Sept 2019 ! From rgm at htt-consult.com Fri Aug 23 13:01:09 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Fri, 23 Aug 2019 09:01:09 -0400 Subject: cSHAKE support Message-ID: Does openssl (and the CLI) support cSHAKE (NIST SP800-185)? Or is there a way to use the SHAKE support to get cSHAKE behavior? thanks From pete at pragmatika.net Sat Aug 24 17:09:53 2019 From: pete at pragmatika.net (Pete Cooper) Date: Sat, 24 Aug 2019 18:09:53 +0100 Subject: Compiling OpenSSL 1.1 - certs directory is empty, how to obtain? Message-ID: I?m successfully compiling OpenSSL 1.1.1c from source for PHP-FPM to use in preference to the system-native OpenSSL (1.0.*). I?m installing OpenSSL 1.1.1c to /etc/php/shared/openssl with the following configure flags (split for clarity): ./config \ --openssldir=/etc/php/shared/openssl \ --prefix=/etc/php/shared/openssl \ -fstack-protector-strong \ -Wl,-rpath,/etc/php/shared/openssl/lib \ no-ssl2 \ no-ssl3 \ no-weak-ssl-ciphers \ shared The `config` and subsequent `make` complete without any visible issues shown. However, /etc/php/shared/openssl/certs is an empty directory. The system-native OpenSSL uses /etc/ssl/certs for its *.pem files, and there are >250 of them in that directory. Are there OpenSSL compile flags to explicitly build or obtain the current up-to-date *.pem files for my PHP-only OpenSSL build, or should be looking elsewhere? Thank you in advance, and best wishes. -- Pete Cooper pete at pragmatika.net https://pragmatika.net Please note: my working hours may not be your working hours. Please do not feel obligated to reply outside of your normal work schedule. -------------- next part -------------- An HTML attachment was scrubbed... URL: From forston_shi at trendmicro.com Mon Aug 26 09:24:29 2019 From: forston_shi at trendmicro.com (forston_shi at trendmicro.com) Date: Mon, 26 Aug 2019 09:24:29 +0000 Subject: question about certificate verify Message-ID: <1fe26870bdf6474a8d5b0e9a9f74893b@trendmicro.com> Hi Openssl team, I have a question about certificate verify. We check a sub-certificate with a lot of root certificates. We don't want to check sub-certificate's expire time, but we want to get an error when root certificate expired. I try to verify it by following option, X509_VERIFY_PARAM* pm = X509_STORE_CTX_get0_param(xstore_ctx); X509_VERIFY_PARAM_set_flags(pm, X509_V_FLAG_NO_CHECK_TIME); iret = X509_verify_cert(xstore_ctx); But it also will ignore root certificate's expire. So, can you give me some suggestion for my question. Best regards Forston Shi (RD-CN) 
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.

For details about what personal information we collect and why, please see our Privacy Notice on our website at: [ https://www.trendmicro.com/privacy]
-------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Aug 26 13:59:40 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Aug 2019 09:59:40 -0400 Subject: question about certificate verify In-Reply-To: <1fe26870bdf6474a8d5b0e9a9f74893b@trendmicro.com> References: <1fe26870bdf6474a8d5b0e9a9f74893b@trendmicro.com> Message-ID: > On Aug 26, 2019, at 5:24 AM, forston_shi at trendmicro.com wrote: > > We check a sub-certificate with a lot of root certificates. > We don?t want to check sub-certificate?s expire time, but we want to get an error when root certificate expired. > > I try to verify it by following option, > X509_VERIFY_PARAM* pm = X509_STORE_CTX_get0_param(xstore_ctx); > X509_VERIFY_PARAM_set_flags(pm, X509_V_FLAG_NO_CHECK_TIME); > > iret = X509_verify_cert(xstore_ctx); > > But it also will ignore root certificate?s expire. > > So, can you give me some suggestion for my question. To ignore expiration of only the leaf certificate, you need a verification callback that checks the error reason at depth 0 and if it is expiration, returns "ok = 1" anyway. -- Viktor. From uri at ll.mit.edu Mon Aug 26 14:39:40 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 26 Aug 2019 14:39:40 +0000 Subject: question about certificate verify In-Reply-To: References: <1fe26870bdf6474a8d5b0e9a9f74893b@trendmicro.com> Message-ID: <8511ACAA-85A5-4FFD-9D68-DA34EF29D087@ll.mit.edu> Is there a potential problem - if a certificate has multiple issues, such as bad signature and certificate expired? Would all of these conditions be reported, or only the first one detected? Regards, Uri Sent from my iPhone On Aug 26, 2019, at 10:11, Viktor Dukhovni wrote: >> On Aug 26, 2019, at 5:24 AM, forston_shi at trendmicro.com wrote: >> >> We check a sub-certificate with a lot of root certificates. >> We don?t want to check sub-certificate?s expire time, but we want to get an error when root certificate expired. >> >> I try to verify it by following option, >> X509_VERIFY_PARAM* pm = X509_STORE_CTX_get0_param(xstore_ctx); >> X509_VERIFY_PARAM_set_flags(pm, X509_V_FLAG_NO_CHECK_TIME); >> >> iret = X509_verify_cert(xstore_ctx); >> >> But it also will ignore root certificate?s expire. >> >> So, can you give me some suggestion for my question. > > To ignore expiration of only the leaf certificate, you > need a verification callback that checks the error > reason at depth 0 and if it is expiration, returns > "ok = 1" anyway. > > -- > Viktor. > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5821 bytes Desc: not available URL: From kgoldman at us.ibm.com Mon Aug 26 14:45:49 2019 From: kgoldman at us.ibm.com (Ken Goldman) Date: Mon, 26 Aug 2019 10:45:49 -0400 Subject: Add ECDSA signature R and S to X509 structure In-Reply-To: References: Message-ID: On 8/17/2019 5:35 AM, Billy Brumley wrote: > Hey Ken, > >> I have an ECDSA signature supplied to me as R and S byte arrays and >> lengths (from an HSM). >> >> How do I add them to the X509 structure? >> >> Is there an API, a set of calls, or do you have any hints? > > You might be looking for ECDSA_SIG_set0: > > https://www.openssl.org/docs/man1.1.0/man3/ECDSA_SIG_set0.html > > You might find some snippets in ecdsatest.c. > > Hope it helps, I think so. This seems to work. Does it make sense? Is there a better way? - convert R and S, bin to bignum - use ECDSA_SIG_set0 to create an ECDSA_SIG - use i2d to convert the ECDSA_SIG to DER - memcpy the DER into X509->signature->data From openssl-users at dukhovni.org Mon Aug 26 14:46:16 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 26 Aug 2019 10:46:16 -0400 Subject: question about certificate verify In-Reply-To: <8511ACAA-85A5-4FFD-9D68-DA34EF29D087@ll.mit.edu> References: <1fe26870bdf6474a8d5b0e9a9f74893b@trendmicro.com> <8511ACAA-85A5-4FFD-9D68-DA34EF29D087@ll.mit.edu> Message-ID: <20190826144616.GJ24255@straasha.imrryr.org> On Mon, Aug 26, 2019 at 02:39:40PM +0000, Blumenthal, Uri - 0553 - MITLL wrote: > > To ignore expiration of only the leaf certificate, you > > need a verification callback that checks the error > > reason at depth 0 and if it is expiration, returns > > "ok = 1" anyway. > > Is there a potential problem - if a certificate has multiple issues, such > as bad signature and certificate expired? Would all of these conditions > be reported, or only the first one detected? The verification callback is called separately for each error condition (and at least once on success if no errors are seen). It is therefore possible to ignore *just* the expiration of a particular chain element without ignoring other errors. -- Viktor. From bill.c.roberts at gmail.com Mon Aug 26 14:52:21 2019 From: bill.c.roberts at gmail.com (William Roberts) Date: Mon, 26 Aug 2019 09:52:21 -0500 Subject: Add ECDSA signature R and S to X509 structure In-Reply-To: References: Message-ID: This thread actually has some code on it for doing this: https://www.mail-archive.com/openssl-users at openssl.org/msg86672.html Bill On Mon, Aug 26, 2019 at 9:46 AM Ken Goldman wrote: > > On 8/17/2019 5:35 AM, Billy Brumley wrote: > > Hey Ken, > > > >> I have an ECDSA signature supplied to me as R and S byte arrays and > >> lengths (from an HSM). > >> > >> How do I add them to the X509 structure? > >> > >> Is there an API, a set of calls, or do you have any hints? > > > > You might be looking for ECDSA_SIG_set0: > > > > https://www.openssl.org/docs/man1.1.0/man3/ECDSA_SIG_set0.html > > > > You might find some snippets in ecdsatest.c. > > > > Hope it helps, > > I think so. This seems to work. Does it make sense? Is there a better way? > > - convert R and S, bin to bignum > - use ECDSA_SIG_set0 to create an ECDSA_SIG > - use i2d to convert the ECDSA_SIG to DER > - memcpy the DER into X509->signature->data > > From cable.an at gmail.com Mon Aug 26 17:36:02 2019 From: cable.an at gmail.com (Caleb An) Date: Mon, 26 Aug 2019 10:36:02 -0700 Subject: Question about picking PRF when storing a private key Message-ID: Hi openssl team & community, When using the i2d_PKCS8PrivateKey functions to encode a private key, is there a way to also select the PBKDF2 PRF? Thanks so much! - Caleb An -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Tue Aug 27 12:54:50 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Aug 2019 13:54:50 +0100 Subject: Error on 20190823 release In-Reply-To: <20190823115444.GB50529@doctor.nl2k.ab.ca> References: <20190823115444.GB50529@doctor.nl2k.ab.ca> Message-ID: <60b8f804-dcb4-2360-6831-e02fb97dd683@openssl.org> On 23/08/2019 12:54, The Doctor wrote: > > > Found this during the tests > > ../test/recipes/20-test_enc.t (Wstat: 256 Tests: 162 Failed: 1) > Failed test: 161 > Non-zero exit status: 1 > > > What informationh do you require? > Please provide the output from: make TESTS=test_enc V=1 test Regards Matt From weber at infotech.de Tue Aug 27 16:24:34 2019 From: weber at infotech.de (weber at infotech.de) Date: Tue, 27 Aug 2019 18:24:34 +0200 Subject: ASN1_EX_COMBINE in OpenSSL 1.1.1c? Message-ID: <9098993e-c0fc-fcd0-9e8a-e6a81325b100@infotech.de> Dear users, during migration from version 1.0.2s to 1.1.1c we are missing the makro ASN1_EX_COMBINE. It was used to embed a choice in a sequence as follows: > ASN1_CHOICE(X509AT_ATTRIBUTE_SET) = { > ?? ?ASN1_SET_OF(X509AT_ATTRIBUTE, value.set, ASN1_ANY), > ?? ?ASN1_SIMPLE(X509AT_ATTRIBUTE, value.single, ASN1_ANY) > } ASN1_CHOICE_END_selector(X509AT_ATTRIBUTE, X509AT_ATTRIBUTE_SET, single) > > ASN1_SEQUENCE(X509AT_ATTRIBUTE) = { > ?? ?ASN1_SIMPLE(X509AT_ATTRIBUTE, object, ASN1_OBJECT), > ?? ?/* CHOICE type merged with parent */ > ??? ASN1_EX_COMBINE(0, 0, X509AT_ATTRIBUTE_SET) > } ASN1_SEQUENCE_END(X509AT_ATTRIBUTE) What's the proper substitute in 1.1.1c? Thanks in advance -- Christian Weber From matt at openssl.org Tue Aug 27 22:32:55 2019 From: matt at openssl.org (Matt Caswell) Date: Tue, 27 Aug 2019 23:32:55 +0100 Subject: ASN1_EX_COMBINE in OpenSSL 1.1.1c? In-Reply-To: <9098993e-c0fc-fcd0-9e8a-e6a81325b100@infotech.de> References: <9098993e-c0fc-fcd0-9e8a-e6a81325b100@infotech.de> Message-ID: On 27/08/2019 17:24, weber at infotech.de wrote: > Dear users, > > during migration from version 1.0.2s to 1.1.1c we are missing the makro > ASN1_EX_COMBINE. > > It was used to embed a choice in a sequence as follows: >> ASN1_CHOICE(X509AT_ATTRIBUTE_SET) = { >> ?? ?ASN1_SET_OF(X509AT_ATTRIBUTE, value.set, ASN1_ANY), >> ?? ?ASN1_SIMPLE(X509AT_ATTRIBUTE, value.single, ASN1_ANY) >> } ASN1_CHOICE_END_selector(X509AT_ATTRIBUTE, X509AT_ATTRIBUTE_SET, single) >> >> ASN1_SEQUENCE(X509AT_ATTRIBUTE) = { >> ?? ?ASN1_SIMPLE(X509AT_ATTRIBUTE, object, ASN1_OBJECT), >> ?? ?/* CHOICE type merged with parent */ >> ??? ASN1_EX_COMBINE(0, 0, X509AT_ATTRIBUTE_SET) >> } ASN1_SEQUENCE_END(X509AT_ATTRIBUTE) > > What's the proper substitute in 1.1.1c? Support for ASN1_EX_COMBINE was removed by commit ee9d76371ae which had this description: Remove combine option from ASN.1 code. Remove the combine option. This was used for compatibility with some non standard behaviour in ancient versions of OpenSSL: specifically the X509_ATTRIBUTE and DSAPublicKey handling. Since these have now been revised it is no longer needed. For your application you might draw some inspiration from commit e20b57270d which removed the use of this from X509_ATTRIBUTE internally in OpenSSL: commit e20b57270dece66ce2c68aeb5d14dd6d9f3c5d68 Author: Dr. Stephen Henson AuthorDate: Wed Mar 25 15:08:55 2015 +0000 Commit: Dr. Stephen Henson CommitDate: Wed Mar 25 15:46:54 2015 +0000 Remove X509_ATTRIBUTE hack. The X509_ATTRIBUTE structure includes a hack to tolerate malformed attributes that encode as the type instead of SET OF type. This form is never created by OpenSSL and shouldn't be needed any more. Reviewed-by: Rich Salz Reviewed-by: Richard Levitte You might also look at commit ea6b07b54 which removed it for the DSAPublicKey handling. Regards Matt From lein360 at gmail.com Wed Aug 28 08:51:22 2019 From: lein360 at gmail.com (=?UTF-8?B?0KHQtdGA0LPQtdC5INCu0L3QsNC60L7QstGB0LrQuNC5?=) Date: Wed, 28 Aug 2019 10:51:22 +0200 Subject: Question regarding lock of the master drbg during the fork Message-ID: Hello, I have a question regarding the usage of the master DRBG during the fork operation. As far as I understand from the source code and articles, during the fork the library will perform the lock of the master DRBG to obtain the entropy for public and private DRBG. However, the library does not perform the check of the lock state itself and it is unclear for me, what will happen if the master DRBG is locked during the creation of the fork process. Additionally, what was the purpose of such complicated scheme for DRBGs except for NIST requirements? Is it possible to solve fork problem without implementing the chain of DRBGs? Can you please help with this? Articles: https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ https://wiki.openssl.org/index.php/Random_fork-safety Here is the code from the rand_lib.c: rand_drbg_lock(drbg->parent); if (RAND_DRBG_generate(drbg->parent, buffer, bytes_needed, prediction_resistance, NULL, 0) != 0) bytes = bytes_needed; drbg->reseed_next_counter = tsan_load(&drbg->parent->reseed_prop_counter); rand_drbg_unlock(drbg->parent); -------------- next part -------------- An HTML attachment was scrubbed... URL: From paul.dale at oracle.com Wed Aug 28 10:55:52 2019 From: paul.dale at oracle.com (Dr Paul Dale) Date: Wed, 28 Aug 2019 20:55:52 +1000 Subject: Question regarding lock of the master drbg during the fork In-Reply-To: References: Message-ID: <97533E1B-78BA-47FC-A772-CA0BB5422E2A@oracle.com> ?????? , We are aware that we do not handle the fork(2) system call perfectly. My advice would be to not hold a lock while calling fork(2). OpenSSL, as of 1.1.0, does hold per-process locks itself. The locking callbacks were present in 1.0.2 and before but are now obsolete. Even if it isn?t perfect, OpenSSL does attempt to reseed the DRBG chains when fork(2) is called. This is not designed to meet any of the NIST requirements. Rather it is to ensure that the parent and child processes have different random seed material. High quality random numbers are critical to security ? they are the foundation upon which everything else is based. OpenSSL tries to not take any shortcuts here. The DRBG chains are part of the considered solution ? the public and private DRBGs are distinct and a compromise of one shouldn?t impact the other; they are also per thread which shouldn?t negatively impact performance (by locking). ???????, Pauli (my ??????? is very rusty) -- Dr Paul Dale | Distinguished Architect | Cryptographic Foundations Phone +61 7 3031 7217 Oracle Australia > On 28 Aug 2019, at 6:51 pm, ?????? ?????????? wrote: > > Hello, > I have a question regarding the usage of the master DRBG during the fork operation. As far as I understand from the source code and articles, during the fork the library will perform the lock of the master DRBG to obtain the entropy for public and private DRBG. > However, the library does not perform the check of the lock state itself and it is unclear for me, what will happen if the master DRBG is locked during the creation of the fork process. > > Additionally, what was the purpose of such complicated scheme for DRBGs except for NIST requirements? Is it possible to solve fork problem without implementing the chain of DRBGs? > > Can you please help with this? > > Articles: > https://www.openssl.org/docs/man1.1.1/man7/RAND_DRBG.html > http://emboss.github.io/blog/2013/08/21/openssl-prng-is-not-really-fork-safe/ > https://wiki.openssl.org/index.php/Random_fork-safety > > Here is the code from the rand_lib.c: > rand_drbg_lock(drbg->parent); > if (RAND_DRBG_generate(drbg->parent, > buffer, bytes_needed, > prediction_resistance, > NULL, 0) != 0) > bytes = bytes_needed; > drbg->reseed_next_counter > = tsan_load(&drbg->parent->reseed_prop_counter); > rand_drbg_unlock(drbg->parent); -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Aug 28 13:01:53 2019 From: matt at openssl.org (Matt Caswell) Date: Wed, 28 Aug 2019 14:01:53 +0100 Subject: Missing enable-tlsext configuration In-Reply-To: References: Message-ID: <01cf836c-f5c8-19f4-043c-0eb018d9498b@openssl.org> On 28/08/2019 13:46, Dan Heinz wrote: > We're moving from the 1.0.x branch to the 1.1.1 branch of OpenSSL. When > building OpenSSL 1.1.1c, I get an error that there is not an enable-tlsext > configuration parameter. I can't seem to find any information on when or why > this was removed. Is this enabled by default now? > It was always enabled by default (at least for all recent OpenSSL versions - I can't speak for ancient ones). In 1.0.2 you could disable extensions support with disable-tlsext. TLSv1.2 will *work* without extensions but it really is not recommended. TLSv1.3 requires extensions. There really is no reason to disable them, and it added significant maintenance overhead keeping that option working - so it was removed in 1.1.0. Matt From rgm at htt-consult.com Wed Aug 28 13:48:18 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 28 Aug 2019 09:48:18 -0400 Subject: Format and standard for CSR Message-ID: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> I am writing an Internet Draft that will include transmission of a CSR, so I need to reference the proper source.? No more sloppy, "well it works...". Some digging said it is in PKCS#10 - CSR.? But I did not stop with that. A bit more googling lead me to RFC 4211... When I create a CSR with: ?? openssl req -config openssl-intermediate.cnf\ ?????? -key ./private/client.key.pem \ ?????? -subj "$DN" -new -out ./csr/client.csr.pem What format is this?? Are there better, more concise formats (e.g. DER?) for transmission over constrained networks? I can dump it with ?? openssl req -text -noout -verify -in ./csr/client.csr.pem But that does not really tell me the format, only what is in the cert. Thanks From rgm at htt-consult.com Wed Aug 28 14:25:37 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 28 Aug 2019 10:25:37 -0400 Subject: Format and standard for CSR In-Reply-To: <7E687841-1759-4DF7-8460-FF818F241F83@amazon.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <7E687841-1759-4DF7-8460-FF818F241F83@amazon.com> Message-ID: <49b2984c-dff1-54f6-bdc4-ae11b4e3f1ae@htt-consult.com> Peter, thank you for the response. On 8/28/19 10:09 AM, Bowen, Peter wrote: > I think you want RFC 2986 (https://tools.ietf.org/html/rfc2986 ). That is the most recent "PKCS #10" specification that I have seen and should align with what `openssl req` creates. Adding '-outform DER' to your command will output in DER; the default output is PEM which is defined in RFC 7468 (https://tools.ietf.org/html/rfc7468 ). This will be within a HIP registration exchange (rfc 8003), so PKCS #10 in DER seems best. > Depending on your use case, you may want to consider using a SPKAC formatted request instead. See `openssl spkac` and https://en.wikipedia.org/wiki/SPKAC for more info. Considering the process, the PKCS10 fits better. thanks for the references. > > ?On 8/28/19, 6:49 AM, "openssl-users on behalf of Robert Moskowitz" wrote: > > I am writing an Internet Draft that will include transmission of a CSR, > so I need to reference the proper source. No more sloppy, "well it > works...". > > Some digging said it is in PKCS#10 - CSR. But I did not stop with that. > > A bit more googling lead me to RFC 4211... > > When I create a CSR with: > > openssl req -config openssl-intermediate.cnf\ > -key ./private/client.key.pem \ > -subj "$DN" -new -out ./csr/client.csr.pem > > What format is this? Are there better, more concise formats (e.g. DER?) > for transmission over constrained networks? > > I can dump it with > > openssl req -text -noout -verify -in ./csr/client.csr.pem > > But that does not really tell me the format, only what is in the cert. > > Thanks > > > From marcelolauxen16 at gmail.com Wed Aug 28 21:20:49 2019 From: marcelolauxen16 at gmail.com (Marcelo Lauxen) Date: Wed, 28 Aug 2019 18:20:49 -0300 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small Message-ID: Our server runs with DH key size of 2048 bits and we are trying to make requests with httparty(https://github.com/jnunemaker/httparty) to a server that uses DH key size of 1024 bits, i want to now for what reason we are getting this error SSL_connect returned=1 errno=0 state=error: dh key too small, it's because different DH key sizes? ? We haven't control of the server who are using DH key size of 1048 bits. I've opened the same issue on httparty https://github.com/jnunemaker/httparty/issues/664, but seems not a problem with httparty and something with OpenSSL. Currently our server is using *OpenSSL 1.1.1c*, but before we was using *OpenSSL 1.1.0j* and this error doesn't happen. Is OpenSSL blocking the communication between our server who uses DH 2048 bits and the other server who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in somewhere? Our server SSL Labs results: https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br&latest Server who we are trying make requests: https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br&latest How we can handle with this? I would be happy if anyone can help me with this. :( Att, Marcelo. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kudzu at tenebras.com Wed Aug 28 21:23:01 2019 From: kudzu at tenebras.com (Michael Sierchio) Date: Wed, 28 Aug 2019 14:23:01 -0700 Subject: Format and standard for CSR In-Reply-To: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> Message-ID: I don't see the point in DER encoding for a CSR ? The RA and CA decide the composition of the cert, based on the rules and CPA that they follow, and of course any cert issued will be in DER format, and may include reordering or modified/expanded extensions and key use restrictions. A CSR is basically an assertion that includes pubkey, proof of possession of the private key, and any request elements required by policy. It's a one-time document that needs to be validated precisely once. On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz wrote: > I am writing an Internet Draft that will include transmission of a CSR, > so I need to reference the proper source. No more sloppy, "well it > works...". > > Some digging said it is in PKCS#10 - CSR. But I did not stop with that. > > A bit more googling lead me to RFC 4211... > > When I create a CSR with: > > openssl req -config openssl-intermediate.cnf\ > -key ./private/client.key.pem \ > -subj "$DN" -new -out ./csr/client.csr.pem > > What format is this? Are there better, more concise formats (e.g. DER?) > for transmission over constrained networks? > > I can dump it with > > openssl req -text -noout -verify -in ./csr/client.csr.pem > > But that does not really tell me the format, only what is in the cert. > > Thanks > > -- "Well," Brahm? said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Wed Aug 28 21:48:41 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 28 Aug 2019 17:48:41 -0400 Subject: Format and standard for CSR In-Reply-To: References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> Message-ID: <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> CSR is an object in a container that goes over a 'wire'.?? Sometimes the wire is very small (BT4) so the container needs to be tightly designed. It should be a standard, not something totally off the wall.? Well I could do it in CBOR, and probably will at some point, but for now something more common in PKIX world should work. Mangle it, stuff it down the wire, de-mangle it and use it.? For now I am referencing RFC 2986. What do you suggest.? Please reference documents that can be referenced in the document. Thanks On 8/28/19 5:23 PM, Michael Sierchio wrote: > > I don't see the point in DER encoding for a CSR ? The RA and CA decide > the composition of the cert, based on the rules and CPA that they > follow, and of course any cert issued will be in DER format, and may > include reordering or modified/expanded extensions and key use > restrictions.? A CSR is basically an assertion that includes pubkey, > proof of possession of the private key, and any request elements > required by policy.? It's a one-time document that needs to be > validated precisely once. > > > On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz > wrote: > > I am writing an Internet Draft that will include transmission of a > CSR, > so I need to reference the proper source.? No more sloppy, "well it > works...". > > Some digging said it is in PKCS#10 - CSR.? But I did not stop with > that. > > A bit more googling lead me to RFC 4211... > > When I create a CSR with: > > ??? openssl req -config openssl-intermediate.cnf\ > ??????? -key ./private/client.key.pem \ > ??????? -subj "$DN" -new -out ./csr/client.csr.pem > > What format is this?? Are there better, more concise formats (e.g. > DER?) > for transmission over constrained networks? > > I can dump it with > > ??? openssl req -text -noout -verify -in ./csr/client.csr.pem > > But that does not really tell me the format, only what is in the cert. > > Thanks > > > > -- > > "Well,"?Brahm??said, "even after ten thousand explanations, a fool is > no wiser, but an intelligent person requires only two thousand five > hundred." > > - The Mah?bh?rata -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Wed Aug 28 22:09:11 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 28 Aug 2019 22:09:11 +0000 Subject: Format and standard for CSR In-Reply-To: <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> Message-ID: <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> Do you have an ASN.1 definition fit the content of CSR, or are you willing to create one? IMHO, DER would be a pretty good choice, fat better than something home-brewed and non-standard. Regards, Uri Sent from my iPhone > On Aug 28, 2019, at 17:49, Robert Moskowitz wrote: > > CSR is an object in a container that goes over a 'wire'. Sometimes the wire is very small (BT4) so the container needs to be tightly designed. > > It should be a standard, not something totally off the wall. Well I could do it in CBOR, and probably will at some point, but for now something more common in PKIX world should work. > > Mangle it, stuff it down the wire, de-mangle it and use it. For now I am referencing RFC 2986. > > What do you suggest. Please reference documents that can be referenced in the document. > > Thanks > > >> On 8/28/19 5:23 PM, Michael Sierchio wrote: >> >> I don't see the point in DER encoding for a CSR ? The RA and CA decide the composition of the cert, based on the rules and CPA that they follow, and of course any cert issued will be in DER format, and may include reordering or modified/expanded extensions and key use restrictions. A CSR is basically an assertion that includes pubkey, proof of possession of the private key, and any request elements required by policy. It's a one-time document that needs to be validated precisely once. >> >> >>> On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz wrote: >>> I am writing an Internet Draft that will include transmission of a CSR, >>> so I need to reference the proper source. No more sloppy, "well it >>> works...". >>> >>> Some digging said it is in PKCS#10 - CSR. But I did not stop with that. >>> >>> A bit more googling lead me to RFC 4211... >>> >>> When I create a CSR with: >>> >>> openssl req -config openssl-intermediate.cnf\ >>> -key ./private/client.key.pem \ >>> -subj "$DN" -new -out ./csr/client.csr.pem >>> >>> What format is this? Are there better, more concise formats (e.g. DER?) >>> for transmission over constrained networks? >>> >>> I can dump it with >>> >>> openssl req -text -noout -verify -in ./csr/client.csr.pem >>> >>> But that does not really tell me the format, only what is in the cert. >>> >>> Thanks >>> >> >> >> -- >> >> "Well," Brahm? said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." >> >> - The Mah?bh?rata > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5821 bytes Desc: not available URL: From rgm at htt-consult.com Wed Aug 28 23:13:15 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Wed, 28 Aug 2019 19:13:15 -0400 Subject: Format and standard for CSR In-Reply-To: <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> Message-ID: <6489bd0c-98fc-fb60-0570-22719a85a3ed@htt-consult.com> Uri, Greetings! On 8/28/19 6:09 PM, Blumenthal, Uri - 0553 - MITLL wrote: > Do you have an ASN.1 definition fit the content of CSR, or are you > willing to create one? For now working with ASN.1. > IMHO, DER would be a pretty good choice, fat better than something > home-brewed and non-standard. take a look at rfc 7049.? This is the standard for data objects over constrained networks.? Then look at draft-birkholz-core-coid For work being done to define by a good team to meld x.509 stuff with CBOR. "The wonderful thing about standards is there are so many to choose from." There was a reference point to Grace Hopper saying this in '58. > > Regards, > Uri > > Sent from my iPhone > > On Aug 28, 2019, at 17:49, Robert Moskowitz > wrote: > >> CSR is an object in a container that goes over a 'wire'. Sometimes >> the wire is very small (BT4) so the container needs to be tightly >> designed. >> >> It should be a standard, not something totally off the wall.? Well I >> could do it in CBOR, and probably will at some point, but for now >> something more common in PKIX world should work. >> >> Mangle it, stuff it down the wire, de-mangle it and use it. For now I >> am referencing RFC 2986. >> >> What do you suggest.? Please reference documents that can be >> referenced in the document. >> >> Thanks >> >> >> On 8/28/19 5:23 PM, Michael Sierchio wrote: >>> >>> I don't see the point in DER encoding for a CSR ? The RA and CA >>> decide the composition of the cert, based on the rules and CPA that >>> they follow, and of course any cert issued will be in DER format, >>> and may include reordering or modified/expanded extensions and key >>> use restrictions.? A CSR is basically an assertion that includes >>> pubkey, proof of possession of the private key, and any request >>> elements required by policy.? It's a one-time document that needs to >>> be validated precisely once. >>> >>> >>> On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz >>> > wrote: >>> >>> I am writing an Internet Draft that will include transmission of >>> a CSR, >>> so I need to reference the proper source.? No more sloppy, "well it >>> works...". >>> >>> Some digging said it is in PKCS#10 - CSR.? But I did not stop >>> with that. >>> >>> A bit more googling lead me to RFC 4211... >>> >>> When I create a CSR with: >>> >>> ??? openssl req -config openssl-intermediate.cnf\ >>> ??????? -key ./private/client.key.pem \ >>> ??????? -subj "$DN" -new -out ./csr/client.csr.pem >>> >>> What format is this?? Are there better, more concise formats >>> (e.g. DER?) >>> for transmission over constrained networks? >>> >>> I can dump it with >>> >>> ??? openssl req -text -noout -verify -in ./csr/client.csr.pem >>> >>> But that does not really tell me the format, only what is in the >>> cert. >>> >>> Thanks >>> >>> >>> >>> -- >>> >>> "Well,"?Brahm??said, "even after ten thousand explanations, a fool >>> is no wiser, but an intelligent person requires only two thousand >>> five hundred." >>> >>> - The Mah?bh?rata >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Thu Aug 29 01:30:01 2019 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 29 Aug 2019 01:30:01 +0000 Subject: Format and standard for CSR In-Reply-To: <6489bd0c-98fc-fb60-0570-22719a85a3ed@htt-consult.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> <6489bd0c-98fc-fb60-0570-22719a85a3ed@htt-consult.com> Message-ID: <0458432D-0909-43BA-A3CA-5BF8998E6AFB@ll.mit.edu> > Uri, Greetings! Hello there! ;-) > On 8/28/19 6:09 PM, Blumenthal, Uri - 0553 - MITLL wrote: > > Do you have an ASN.1 definition fit the content of CSR, or are you willing to create one? > > For now working with ASN.1. In that case, I would use one of the available defined standards, which are well-supported by already existing Open Source software. If you don?t have any extreme need for compactness of the binary representation ? DER has been around long enough, is understood well enough, and the codecs are reasonably-well debugged. That would be my first choice. If you do have a very austere link, perhaps UPER or OER, as they provide a tighter/more-compact encoding. In addition to ASN.1, I found XER to be a good format for documenting examples (sample packets/messages), but I wouldn?t send it over the wire (though some people do that ? I won?t say what I think of them). > > IMHO, DER would be a pretty good choice, fat better than something home-brewed and non-standard. > > take a look at rfc 7049.? This is the standard for data objects over constrained networks.? Then look at > draft-birkholz-core-coid I did. They favor schema-less data. I abhor it. But then, I knew some people who didn't like to sit down and think before starting to write code. ;-) Their argument against PER is Few (if any) IETF protocols have adopted one of the several variants of Packed Encoding Rules (PER). There could be many reasons for this, but one that is commonly stated is that PER makes use of the schema even for parsing the surface structure of the data stream, requiring significant tool support. There are different versions of the ASN.1 schema language in use, which has also hampered adoption. I'm not sure I agree with the "significant tool support" above. I use https://github.com/vlm/asn1c.git, and it provides all I need (actually, I use the https://github.com/mouse07410/asn1c.git fork, as I also use APER, which it supports ;). I'm also surprised that they did not provide encoding comparison with one of the PER variants (UPER, APER), or OER. It would've been far more instructive, IMHO, than comparing CBOR and BER to BSON. > For work being done to define by a good team to meld x.509 stuff with CBOR. [Un?]fortunately, I don't have time to invent a new encoding standard, implement + debug it, and some time down the road find that I need to extend it because it doesn't cover the case I didn't think of back then. IMHO, the problem with X.509 is not with DER encoding, so I don't see much benefit in expressing it in CBOR instead. > "The wonderful thing about standards is there are so many to choose from." Which is yet another reason to stop and check whether really none of the existing ones could satisfy your needs. ;-) Thanks! P.S. You mentioned that CSR is in PEM. PEM (Privacy Enhanced Mail) is a base64 encoding of (typically) DER. PEM is your payment by space for your DER not being mangled en-route by mail servers. You may base64-encode any binary format, if you suspect it would traverse binary-data-unfriendly links. If you want to dump CSR content, first convert it to DER (strip PEM encoding) via, e.g., "base64 --decode -i my.csr -o my.der", and then dump DER content with, e.g., "dumpasn1 my.der". P.P.S. Re. CSR being a one-time document - that's true more often than not, but unless you only intend to use *one* CA that you control, it might make sense to stick to publicly-accepted formats, or at least something that can be easily/automatically converted to them. -- Regards, Uri Sent from my iPhone On Aug 28, 2019, at 17:49, Robert Moskowitz wrote: CSR is an object in a container that goes over a 'wire'.?? Sometimes the wire is very small (BT4) so the container needs to be tightly designed. It should be a standard, not something totally off the wall.? Well I could do it in CBOR, and probably will at some point, but for now something more common in PKIX world should work. Mangle it, stuff it down the wire, de-mangle it and use it.? For now I am referencing RFC 2986. What do you suggest.? Please reference documents that can be referenced in the document. Thanks On 8/28/19 5:23 PM, Michael Sierchio wrote: I don't see the point in DER encoding for a CSR ? The RA and CA decide the composition of the cert, based on the rules and CPA that they follow, and of course any cert issued will be in DER format, and may include reordering or modified/expanded extensions and key use restrictions.? A CSR is basically an assertion that includes pubkey, proof of possession of the private key, and any request elements required by policy.? It's a one-time document that needs to be validated precisely once. On Wed, Aug 28, 2019 at 6:49 AM Robert Moskowitz wrote: I am writing an Internet Draft that will include transmission of a CSR, so I need to reference the proper source.? No more sloppy, "well it works...". Some digging said it is in PKCS#10 - CSR.? But I did not stop with that. A bit more googling lead me to RFC 4211... When I create a CSR with: ??? openssl req -config openssl-intermediate.cnf\ ??????? -key ./private/client.key.pem \ ??????? -subj "$DN" -new -out ./csr/client.csr.pem What format is this?? Are there better, more concise formats (e.g. DER?) for transmission over constrained networks? I can dump it with ??? openssl req -text -noout -verify -in ./csr/client.csr.pem But that does not really tell me the format, only what is in the cert. Thanks -- "Well,"?Brahm??said, "even after ten thousand explanations, a fool is no wiser, but an intelligent person requires only two thousand five hundred." - The Mah?bh?rata -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From openssl-users at dukhovni.org Thu Aug 29 10:37:28 2019 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 29 Aug 2019 06:37:28 -0400 Subject: Format and standard for CSR In-Reply-To: <0458432D-0909-43BA-A3CA-5BF8998E6AFB@ll.mit.edu> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> <6489bd0c-98fc-fb60-0570-22719a85a3ed@htt-consult.com> <0458432D-0909-43BA-A3CA-5BF8998E6AFB@ll.mit.edu> Message-ID: <9D36C664-CD7E-4CD1-A9F2-98BE909A1601@dukhovni.org> > On Aug 28, 2019, at 9:30 PM, Blumenthal, Uri - 0553 - MITLL wrote: > >>> Do you have an ASN.1 definition fit the content of CSR, or are you willing to create one? >> >> For now working with ASN.1. > > In that case, I would use one of the available defined standards, which are well-supported by already existing Open Source software. CSRs are signed objects (proof of possession). The signature is over the DER form of the RequestInfo. Therefore, the only natural encoding for CSR is DER, or base64-encoded DER wrapped in PEM ASCII armour. Adding X.509 extensions to CSRs is sadly rather more complex than one might have hoped for, but that's only an issue if you have to write low-level library code to construct CSRs. If you have such a library, just serialize to DER and you're done. -- Viktor. From mcr at sandelman.ca Thu Aug 29 13:20:02 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 29 Aug 2019 09:20:02 -0400 Subject: Format and standard for CSR In-Reply-To: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> Message-ID: <31871.1567084802@localhost> Robert Moskowitz wrote: > I am writing an Internet Draft that will include transmission of a CSR, so I > need to reference the proper source.? No more sloppy, "well it works...". > Some digging said it is in PKCS#10 - CSR.? But I did not stop with > that. RFC2986 is PKCS10. RFC7030 references that, I don't think that there is anything newer. But, maybe I've mis-understood your question? -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ From rgm at htt-consult.com Thu Aug 29 14:04:49 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 29 Aug 2019 10:04:49 -0400 Subject: Format and standard for CSR In-Reply-To: <31871.1567084802@localhost> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <31871.1567084802@localhost> Message-ID: <2cf098d5-fa8a-45bd-f603-0195a89bc09f@htt-consult.com> On 8/29/19 9:20 AM, Michael Richardson wrote: > Robert Moskowitz wrote: > > I am writing an Internet Draft that will include transmission of a CSR, so I > > need to reference the proper source.? No more sloppy, "well it works...". > > > Some digging said it is in PKCS#10 - CSR.? But I did not stop with > > that. > > RFC2986 is PKCS10. > RFC7030 references that, I don't think that there is anything newer. > But, maybe I've mis-understood your question? To bring up 7030, yes you have. 7030 is not something you want to run over a highly constrained network, involving a highly constrained device.? It does provide some good guidelines for 'completeness'.? Is ANIMA using it?? And ANIMA is not just constrained devices. For this project there are strong arguments to do all registration stuff within HIP messages.? At least for initial design. It is not my job in this project to declare a winner in best CSR format design.? For the initial specification, I need to do a best effort on current practice.? PKCS#10 seems to be that. You may be one of the parties at the Hackathon.?? And perhaps the only one on this list. From hkario at redhat.com Thu Aug 29 15:05:48 2019 From: hkario at redhat.com (Hubert Kario) Date: Thu, 29 Aug 2019 17:05:48 +0200 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small In-Reply-To: References: Message-ID: <9447154.QSkP0O941a@pintsize.usersys.redhat.com> On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: > Our server runs with DH key size of 2048 bits and we are trying to make > requests with httparty(https://github.com/jnunemaker/httparty) to a server > that uses DH key size of 1024 bits, i want to now for what reason we are > getting this error SSL_connect returned=1 errno=0 state=error: dh key too > small, it's because different DH key sizes? ? > > We haven't control of the server who are using DH key size of 1048 bits. > > I've opened the same issue on httparty > https://github.com/jnunemaker/httparty/issues/664, but seems not a problem > with httparty and something with OpenSSL. > > Currently our server is using *OpenSSL 1.1.1c*, but before we was > using *OpenSSL > 1.1.0j* and this error doesn't happen. Is OpenSSL blocking the > communication between our server who uses DH 2048 bits and the other server > who uses DH 1024 bits (weak Diffie-Hellman)? If yes, is it reported in > somewhere? > > Our server SSL Labs results: > https://www.ssllabs.com/ssltest/analyze.html?d=web.monde.com.br&latest > > Server who we are trying make requests: > https://www.ssllabs.com/ssltest/analyze.html?d=webservices.voeazul.com.br&la > test that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA instead of trying to make 1024 bit work ? it really is weak and should not be used (see also: LOGJAM) -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web: www.cz.redhat.com Red Hat Czech s.r.o., Purky?ova 115, 612 00 Brno, Czech Republic -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part. URL: From rsalz at akamai.com Thu Aug 29 15:20:40 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Aug 2019 15:20:40 +0000 Subject: Format and standard for CSR In-Reply-To: <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> Message-ID: A CSR is most commonly a PKCS#10 object and therefore defined in ASN.1 and encoded in DER. https://github.com/openssl/openssl/blob/master/crypto/include/internal/x509_int.h#L53 -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Aug 29 15:38:46 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Aug 2019 15:38:46 +0000 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small In-Reply-To: References: Message-ID: * We haven't control of the server who are using DH key size of 1048 bits. In order to work with this kind of server (terribly poor security characteristics), you need to add ?@SECLEVEL=0? to your OpenSSL configuration. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Thu Aug 29 15:43:26 2019 From: rgm at htt-consult.com (Robert Moskowitz) Date: Thu, 29 Aug 2019 11:43:26 -0400 Subject: Format and standard for CSR In-Reply-To: References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <771d3d68-7136-aa0b-4957-7768282fa4e0@htt-consult.com> <6F416D99-3A19-4E8F-A25B-DA3074BC8ABC@ll.mit.edu> Message-ID: <01c62323-a6fb-7831-9ca1-669469284f73@htt-consult.com> On 8/29/19 11:20 AM, Salz, Rich wrote: > > A CSR is most commonly a PKCS#10 object and therefore defined in ASN.1 > and encoded in DER. > > https://github.com/openssl/openssl/blob/master/crypto/include/internal/x509_int.h#L53 > thanks, Rich It all fits together now -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcelolauxen16 at gmail.com Thu Aug 29 17:14:18 2019 From: marcelolauxen16 at gmail.com (Marcelo Lauxen) Date: Thu, 29 Aug 2019 14:14:18 -0300 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small In-Reply-To: References: Message-ID: Thank you guys for the answers! I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? On Thu, Aug 29, 2019 at 12:38 PM Salz, Rich wrote: > > - We haven't control of the server who are using DH key size of 1048 > bits. > > In order to work with this kind of server (terribly poor security > characteristics), you need to add ?@SECLEVEL=0? to your OpenSSL > configuration. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Thu Aug 29 17:19:34 2019 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 29 Aug 2019 17:19:34 +0000 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small In-Reply-To: References: Message-ID: <465EF21B-3E1F-4474-AAD2-F841A7A52D67@akamai.com> * I've another question, based on your suggestion Salz Rich, this config @SECLEVEL can be set per host/domain, or is it impossible? It totally depends on which webserver you are running and what it?s configuration allows. I?m not able to answer webserver config questions BTW. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Thu Aug 29 18:49:59 2019 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 29 Aug 2019 20:49:59 +0200 Subject: Subject: SSL_connect returned=1 errno=0 state=error: dh key too small In-Reply-To: <9447154.QSkP0O941a@pintsize.usersys.redhat.com> References: <9447154.QSkP0O941a@pintsize.usersys.redhat.com> Message-ID: <10ed348e-984e-4fba-ca53-3f1735022a00@wisemo.com> On 29/08/2019 17:05, Hubert Kario wrote: > On Wednesday, 28 August 2019 23:20:49 CEST Marcelo Lauxen wrote: >> ... > that server is willing to negotiate ECDHE_RSA ciphers, you'd be better off > disabling ciphers that use DHE and RSA key exchange and using ECDHE_RSA > instead of trying to make 1024 bit work ? it really is weak and should not be > used (see also: LOGJAM) > > Where in the LOGJAM papers does it say that 1024 bit DH is too little, provided the group is not shared among millions of servers? Where, does it reliably say that ECDH with a choice of very few published groups is more secure than DH with random group parameters shared among a much smaller number of connections and servers? Also note that the following factors make it necessary to support traditional DHE for compatibility: 1. Red Hat OpenSSL builds until a few years ago disabled EC support. 2. Microsoft (and the TLS protocol specs themselves) until fairly ? recently allowed ECDHE only with (EC)DSA server certificates, which ? are not as easily available as RSA certs. 3. The "supported groups" TLS extension cannot be used without jamming ? the TLS clients into a short list of fixed DH groups.? Thus servers ? have to ignore that extension and use heuristic guesses to choose the ? DH strength. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jgh at wizmail.org Thu Aug 29 22:31:48 2019 From: jgh at wizmail.org (Jeremy Harris) Date: Thu, 29 Aug 2019 23:31:48 +0100 Subject: SSL_get_certificate Message-ID: <50968caa-f7a5-5632-d074-a2d66f66f914@wizmail.org> I have a note from 2017 in my code to the effect that SSL_get_certificate() is broken in that it returns the last cert loaded rather than the one passed out to the client (on the server). Is this still the case? I can't track down any obvious fix in the OpenSSL git. I'd like to use it to pick the right stapling to use, in a dual RSA/EC server cert installation. -- Cheers, Jeremy From mcr at sandelman.ca Fri Aug 30 00:47:07 2019 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 29 Aug 2019 20:47:07 -0400 Subject: Format and standard for CSR In-Reply-To: <2cf098d5-fa8a-45bd-f603-0195a89bc09f@htt-consult.com> References: <6dcd7e27-5596-f7c8-aa83-88f288d80781@htt-consult.com> <31871.1567084802@localhost> <2cf098d5-fa8a-45bd-f603-0195a89bc09f@htt-consult.com> Message-ID: <3257.1567126027@localhost> Robert Moskowitz wrote: > On 8/29/19 9:20 AM, Michael Richardson wrote: >> Robert Moskowitz wrote: >> > I am writing an Internet Draft that will include transmission of a CSR, so I >> > need to reference the proper source.? No more sloppy, "well it works...". >> >> > Some digging said it is in PKCS#10 - CSR.? But I did not stop with >> > that. >> >> RFC2986 is PKCS10. >> RFC7030 references that, I don't think that there is anything newer. >> But, maybe I've mis-understood your question? > To bring up 7030, yes you have. > 7030 is not something you want to run over a highly constrained network, > involving a highly constrained device.? It does provide some good guidelines > for 'completeness'.? Is ANIMA using it?? And ANIMA is not just constrained > devices. ANIMA BRSKI is an RFC7030 extension. ANIMA constrained-BRSKI (draft-ietf-anima-constrained-voucher) is an extension of ACE's draft-ietf-ace-coaps-est, which is a constrained version of 7030. [Yes, I'm an author on all of those] It still uses CSRs (binary DER, never PEM encoded). > For this project there are strong arguments to do all registration stuff > within HIP messages.? At least for initial design. > It is not my job in this project to declare a winner in best CSR format > design.? For the initial specification, I need to do a best effort on current > practice.? PKCS#10 seems to be that. We are going to be using CSR until we have something like CoID. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr at sandelman.ca http://www.sandelman.ca/ | ruby on rails [ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From tim.j.culhane at gmail.com Fri Aug 30 06:59:29 2019 From: tim.j.culhane at gmail.com (tim.j.culhane at gmail.com) Date: Fri, 30 Aug 2019 07:59:29 +0100 Subject: FW: how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN In-Reply-To: <000801d55815$53115520$f933ff60$@gmail.com> References: <000801d55815$53115520$f933ff60$@gmail.com> Message-ID: <005201d55f00$78ad9c20$6a08d460$@gmail.com> Hi, Anybody have any suggestions on my below query. I've not made myself clear please let me know what extra info would help. Thanks, Tim -----Original Message----- From: tim.j.culhane at gmail.com Sent: Wednesday 21 August 2019 12:41 To: openssl-users at openssl.org Subject: how to reproduce the error X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN Hi all, I'm writing tests to verify how our mail server handles tls errors returned from the OpenSSL library when verifying a certificate during tls negotiation. The test works by sending a message to a source mail server which then relays the message to the destination mail server. The operation of relaying the message is done over a secure connection using port 465. I want to reproduce a scenario where when the source mailserver opens a connection to the destination server and carries out a tls negotiation that the error returned is X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN. However, no matter what way I try it I always get the similar but different error: X509_V_ERR_DEPTH_ZERO_SELF_SIGNED_CERT The OpenSSL library version I'm using is 1.1.1c running on a CentOS 7 server. My current steps are as follows: Create our own root CA public/private key pair Then set up two intermediate certs: For the first intermediate cert create its CA and private key. Sign it using the root CA's key. Do the same thin for the second intermediate key but sign it with the first intermediate key. I then generate a certificate request for each of the mail servers . I self sign the certificates and generate the server certificates. I append the intermediate certificates to the file containing the host certificate. These are then installed on each server. I copy various options of the root CA certificate and the intermediate certificates into the CACertificates directory of my source mail server. These will be used when the mail server attempts to negotiate a secure connection to the destination server. However, no matter what I try I don't get the X509_V_ERR_SELF_SIGNED_CERT_IN_CHAIN returned. As an experiment I ran the command: Openssl verify -verbose -untrusted And that does reproduce the correct error. Any idea how I can get OpenSSL to return my dsired error? Hopefully my above description makes sense. Many thanks, Tim From matthew.goulart at gmail.com Sat Aug 31 03:05:50 2019 From: matthew.goulart at gmail.com (Matthew) Date: Fri, 30 Aug 2019 23:05:50 -0400 Subject: BIO_read fails when performing DTLS handshake Message-ID: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> Hello everyone! This is my first "post" to the mailing list. I have been working on an OSSL wrapper for C# for several months, and am currently implementing the DTLS portion. I've succeeded in establishing a DTLS session with cookie exchange, sending and receiving data, and gracefully closing the connection. I've appended a snippet of the C# for those who may be curious. Once I got the ugly bits working, I started chipping away at building a nice API. This is where my problem started. I've spend hours debugging and I think I've hit the limit of my abilities. I have 2 unit tests in C# (at the end of this mail). The first one (BasicDtlsTest) is a strightforward echo of one client's data. The second (BasicListenerTest) is essentially the same, only wrapped in a friendlier API. Specifically, my problem is that the second unit test fails to reply to a ClientHello /with/ a cookie (it successfully send the HelloVerifyRequest with the cookie). I have traced the problem to where I /think/ things go wrong. I followed the call stack starting from SSL_do_handshake. SSL_do_handshake -> ossl_statem_accept -> state_machine -> read_state_machine -> dtls_get_message -> dtls_get_reassembled_message -> dtls1_read_bytes -> dtls1_get_record -> ssl3_read_n. I stepped through both the /working/ unit test and the /non-working/ one in order to find differences in the result. What I have found is that, in ssl3_read_n, the call to BIO_read (line 300 in rec_layer_s3.c) returns -1. ret = BIO_read(s->rbio, pkt + len + left, max - left); At this line, pkt is a char[8], len and left = 0 and max = 16717 I'm curious as to why the "data" argument is not a pointer to a buffer, but rather the result of an addition. Maybe my C isnt strong enough... Going even further down the stack, I finally end up at the bottom: static int mem_read(BIO *b, char *out, int outl) And this is where the -1 that is a thorn in my side originates: ret = (outl >= 0 && (size_t)outl > bm->length) ? (int)bm->length : outl; At this line, (size_t)outl is 16717 and bm->length is 0, so ret = (int)bm->length. Then, a little further: if ((out != NULL) && (ret > 0)) { memcpy(out, bm->data, ret); bm->length -= ret; bm->max -= ret; bm->data += ret; } else if (bm->length == 0) { ret = b->num; if (ret != 0) BIO_set_retry_read(b); } return ret; At this point, ret = -1 and that just gets propagated all the way back up, causing the entire record to be thrown out and ignored. The client keeps sending ClientHellos with the cookie and the server keeps ignoring them. I really have no idea what is happening. You can see my entire source code here:https://gitlab.com/matthew.goulart/openssl.net I realize it's a lot to ask you to read all of my code, so if anyone has suggestions as to what I might try next, I'm open! Thanks! [TestMethod] public async Task BasicDtlsTest() { var socket =new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp); socket.SetSocketOption(SocketOptionLevel.Socket,SocketOptionName.ReuseAddress,true); socket.Bind(new IPEndPoint(IPAddress.Loopback,1114)); var ctx =new Context(SslMethod.DTLS); ctx.UseCertificateFile("certs/cert.crt",CertificateType.PEM); ctx.UsePrivateKeyFile("certs/key.key",CertificateType.PEM); ctx.SetVerify(SslVerificationKind.SSL_VERIFY_PEER |SslVerificationKind.SSL_VERIFY_CLIENT_ONCE, VerifyCert); ctx.SetGenerateCookieCallback(GenerateCookie); ctx.SetVerifyCookieCallback(VerifyCookie); ctx.SetOptions(SslOptions.SSL_OP_COOKIE_EXCHANGE); var ssl =new Ssl(ctx,new MemoryBio(),new MemoryBio()); var remoteEp =new IPEndPoint(IPAddress.Any,0); var owner =MemoryPool.Shared.Rent(4096); var mem = owner.Memory; MemoryMarshal.TryGetArray(mem,out ArraySegment seg); var buf = seg.Array; SocketReceiveFromResult rcv; BioAddress bioAddr =new BioAddress(); rcv =await socket.ReceiveFromAsync(seg,SocketFlags.None,new IPEndPoint(IPAddress.Any,0)); ssl.ReadBio.Write(buf, rcv.ReceivedBytes); Ssl.DtlsListen(ssl, bioAddr); var bytesRead = ssl.WriteBio.Read(buf,Ssl.TLS_MAX_RECORD_SIZE); await socket.SendToAsync(seg.Slice(0, bytesRead),SocketFlags.None, rcv.RemoteEndPoint); rcv =await socket.ReceiveFromAsync(seg,SocketFlags.None,new IPEndPoint(IPAddress.Any,0)); ssl.ReadBio.Write(buf, rcv.ReceivedBytes); Assert.IsTrue(Ssl.DtlsListen(ssl, bioAddr)); socket.Close(); var clientSock =new Socket(AddressFamily.InterNetwork,SocketType.Dgram,ProtocolType.Udp); clientSock.SetSocketOption(SocketOptionLevel.Socket,SocketOptionName.ReuseAddress,true); clientSock.Bind(new IPEndPoint(IPAddress.Loopback,1114)); clientSock.Connect(rcv.RemoteEndPoint); while (!ssl.IsInitFinished) { Debug.WriteLine($"Current handshake state is {ssl.HandshakeState}"); int bytesRcvd =await clientSock.ReceiveAsync(mem,SocketFlags.None); Debug.WriteLine($"{bytesRcvd} bytes read from socket."); int bytesWritten = ssl.ReadBio.Write(buf, bytesRcvd); Debug.WriteLine($"{bytesWritten} bytes written to SSL"); Debug.Assert(bytesRcvd == bytesWritten); int acc = ssl.Accept(); SslError result = ssl.GetError(acc); if (result ==SslError.SSL_ERROR_SYSCALL)throw new SslException(ErrorHandler.GetError()); Debug.WriteLine($"Auth result was: {result}"); if (ssl.WriteBio.BytesPending >0) { Debug.WriteLine($"{ssl.WriteBio.BytesPending} bytes pending in write bio"); bytesRead = ssl.WriteBio.Read(buf,4096); Debug.WriteLine($"{bytesRead} bytes read from write bio"); int bytesSent =await clientSock.SendAsync(mem.Slice(0, bytesRead),SocketFlags.None); Debug.WriteLine($"{bytesSent} bytes sent to client"); } } ssl.Shutdown(); if (ssl.WriteBio.BytesPending >0) { Debug.WriteLine($"{ssl.WriteBio.BytesPending} bytes pending in write bio"); bytesRead = ssl.WriteBio.Read(buf,4096); Debug.WriteLine($"{bytesRead} bytes read from write bio"); int bytesSent =await clientSock.SendAsync(mem.Slice(0, bytesRead),SocketFlags.None); Debug.WriteLine($"{bytesSent} bytes sent to client"); } } [TestMethod] public async Task BasicListenerTest() { var listener =new DtlsListener(new IPEndPoint(IPAddress.Loopback,1114),"certs/cert.crt", "certs/key.key"); listener.Start(); Debug.WriteLine("Server => Signalling ready to accept client"); var client =await listener.AcceptClientAsync(); Debug.WriteLine($"Server => Client session started"); await client.AuthenticateAsServerAsync(); Debug.WriteLine("Server => Client successfully authenticated"); var msg =await client.ReceiveAsync(); Assert.IsTrue(msg.Length >=4 && msg.Length <=5); Assert.AreEqual("test",Encoding.Default.GetString(msg.Span.Slice(0,4))); await client.SendAsync(MemoryMarshal.AsMemory(msg)); await listener.Stop(); } } -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Sat Aug 31 14:51:58 2019 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Sat, 31 Aug 2019 14:51:58 +0000 Subject: BIO_read fails when performing DTLS handshake In-Reply-To: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> References: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthew > Sent: Friday, August 30, 2019 23:06 Welcome to the list. When posting, please remember to tell us what version of OpenSSL you're using, and what platform you're on. Since you're talking about C#, I'll assume the platform is Windows. And I'll assume you're working with OpenSSL 1.1.1c, because that would be the sensible thing to do. But it would be better if I didn't have to make either assumption. > I stepped through both the working unit test and the non-working one in order to find > differences in the result. What I have found is that, in ssl3_read_n, the call to > BIO_read (line 300 in rec_layer_s3.c) returns -1. > ret = BIO_read(s->rbio, pkt + len + left, max - left); > At this line, pkt is a char[8], len and left = 0 and max = 16717 I don't think pkt is a char[8]. It's defined at the top of ssl3_read_n as unsigne char *pkt. And it had better not be a char[8], since 1) plain char and unsigned char are not the same type, and 2) if max - left is 16717, then you have potential for a massive buffer overflow. > I'm curious as to why the "data" argument is not a pointer to a buffer, but rather > the result of an addition. Maybe my C isnt strong enough... It's a pointer into a buffer (specifically, in this case, a pointer to the start of a buffer). In C, adding an integer type to a pointer results in a pointer value. That is, in fact, basic C. (At least you're only reading C, not writing it. I have in recent days seen C code posted by people who really need to put the language down and back away slowly. C should not be used by people who don't know the language very well.) > Going even further down the stack, I finally end up at the bottom: > static int mem_read(BIO *b, char *out, int outl) > ... > } else if (bm->length == 0) { > ret = b->num; > if (ret != 0) > BIO_set_retry_read(b); > } > return ret; > At this point, ret = -1... So b->num == -1 when you arrived here with bm->length == 0. The num field is initialized to -1 when a memory BIO is initialized (mem_init in bss_mem.c). And the length is 0, which means there's no data in the BIO. I don't know (without reading through your code, which I don't have time to do right now) why you're using a memory BIO, or how you've initialized it. It looks like you've simply never put any data into it. -- Michael Wojcik Distinguished Engineer, Micro Focus From matthew.goulart at gmail.com Sat Aug 31 18:40:29 2019 From: matthew.goulart at gmail.com (Matthew) Date: Sat, 31 Aug 2019 14:40:29 -0400 Subject: BIO_read fails when performing DTLS handshake In-Reply-To: References: <2b72244c-7179-5f82-1ae5-13d1af453849@gmail.com> Message-ID: Hi Michael, Of course I should have provided a version: 1.1.1c, on linux-x64 (dotnet core 2.2) Just a quick question while I prepare a clearer, more contextual and concise email about my problem; Is it normal for an SSL's readBio to be empty /right/ after DTLSv1_listen? I noticed that after calling DTLSv1_listen, and it returning 1, the SSL's readBio's bytes pending = 0. Would this not force the client to send a second hello with cookie? Or does DTLSv1_listen perform the clientHello processing and then let SSL_accept send the response? On 2019-08-31 10:51 a.m., Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matthew >> Sent: Friday, August 30, 2019 23:06 > Welcome to the list. When posting, please remember to tell us what version of OpenSSL you're using, and what platform you're on. > > Since you're talking about C#, I'll assume the platform is Windows. And I'll assume you're working with OpenSSL 1.1.1c, because that would be the sensible thing to do. But it would be better if I didn't have to make either assumption. > >> I stepped through both the working unit test and the non-working one in order to find >> differences in the result. What I have found is that, in ssl3_read_n, the call to >> BIO_read (line 300 in rec_layer_s3.c) returns -1. >> ret = BIO_read(s->rbio, pkt + len + left, max - left); >> At this line, pkt is a char[8], len and left = 0 and max = 16717 > I don't think pkt is a char[8]. It's defined at the top of ssl3_read_n as unsigne char *pkt. > > And it had better not be a char[8], since 1) plain char and unsigned char are not the same type, and 2) if max - left is 16717, then you have potential for a massive buffer overflow. > >> I'm curious as to why the "data" argument is not a pointer to a buffer, but rather >> the result of an addition. Maybe my C isnt strong enough... > It's a pointer into a buffer (specifically, in this case, a pointer to the start of a buffer). In C, adding an integer type to a pointer results in a pointer value. That is, in fact, basic C. > > (At least you're only reading C, not writing it. I have in recent days seen C code posted by people who really need to put the language down and back away slowly. C should not be used by people who don't know the language very well.) > >> Going even further down the stack, I finally end up at the bottom: >> static int mem_read(BIO *b, char *out, int outl) >> ... >> } else if (bm->length == 0) { >> ret = b->num; >> if (ret != 0) >> BIO_set_retry_read(b); >> } >> return ret; >> At this point, ret = -1... > So b->num == -1 when you arrived here with bm->length == 0. > > The num field is initialized to -1 when a memory BIO is initialized (mem_init in bss_mem.c). And the length is 0, which means there's no data in the BIO. > > I don't know (without reading through your code, which I don't have time to do right now) why you're using a memory BIO, or how you've initialized it. It looks like you've simply never put any data into it. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: