From openssl at jordan.maileater.net Sat Sep 1 01:14:25 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Fri, 31 Aug 2018 18:14:25 -0700 Subject: [openssl-users] Version negotiation failure failure? Message-ID: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> We're trying to nail down error reporting for TLS version mismatches, and we're seeing a couple of puzzling behaviors. First, and most puzzling... assume these two command lines: $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1 $ openssl s_client -connect zel.us.oracle.com:4433 -tls1 That is, I have a server that won't accept TLSv1.0, and a client that will only accept TLSv1.0. On the server side I see 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol:s23_srvr.c:605: which makes perfect sense.? On the client side I see 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659: which isn't as good, but is still sort of sensible.? But when I look at the packets exchanged, I see that the client sends a Client Hello, and the server responds with an ACK and then a FIN-ACK, with no data.? It just hangs up the phone.? This seems to violate RFC 5246 section E.1:? "If server supports (or is willing to use) only versions greater than client_version, it MUST send a "protocol_version" alert message and close the connection.".? Where's my protocol version alert? Of course my real case does not involve the sample client and server - it involves my own clients and servers - but I seem to see the same behavior with several servers (notably including the Apache httpd). This looks like it's the same as https://rt.openssl.org/Ticket/Display.html?id=2777 .? I'm using 1.0.2o.? (But I don't see anything relevant-looking in the 1.0.2p changes.)? I've seen similar behavior from 1.0.2o-fips. Am I missing something here, or is this a server-side bug? And then, on the client side... SSL_connect returns zero.? Exactly how that failure differs from a less-than-zero error is not clear, but OK.? The docs say to call SSL_get_error().? SSL_get_error() returns 5, SSL_ERROR_SYSCALL.? (That seems a little strange, since I don't think there's any system call errors here.)? The docs say to consult the error queue and errno.? ERR_peek_last_error( ) returns zero.? Errno is zero.? It failed, but nobody will tell me why. Am I missing something here, or is this a client library bug? (I have not tracked down exactly how the s_client tool ends up with a message.? It seems to use a more intricate mechanism than SSL_connect.) -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinskip at gmail.com Sun Sep 2 08:51:32 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Sun, 2 Sep 2018 01:51:32 -0700 Subject: [openssl-users] Engines on Mac OS X Message-ID: Hi. I am trying to develop an engine for OpenSSL. To this effect I have built OpenSSL 1.1.0i for Darwin. However, when I try to load any engine, including capi, which is installed as part of OpenSSL, I get the following: *openssl* engine -t -c capi 140735831704448:error:260B606D:engine routines:dynamic_load:init failed:crypto/engine/eng_dyn.c:485: 140735831704448:error:2606A074:engine routines:ENGINE_by_id:no such engine:crypto/engine/eng_list.c:339:id=capi Now, before I go digging too deep, I was wondering if anyone else has dealt with this issue and might be able to throw me a bone. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinskip at gmail.com Sun Sep 2 09:09:12 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Sun, 2 Sep 2018 02:09:12 -0700 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: References: Message-ID: Never mind. My binding entry point was misbehaving. The capi engine is still broken, however. On Sun, Sep 2, 2018 at 1:51 AM Thom?s Inskip wrote: > Hi. > > I am trying to develop an engine for OpenSSL. To this effect I have built > OpenSSL 1.1.0i for Darwin. However, when I try to load any engine, > including capi, which is installed as part of OpenSSL, I get the following: > > *openssl* engine -t -c capi > > 140735831704448:error:260B606D:engine routines:dynamic_load:init > failed:crypto/engine/eng_dyn.c:485: > > 140735831704448:error:2606A074:engine routines:ENGINE_by_id:no such > engine:crypto/engine/eng_list.c:339:id=capi > > Now, before I go digging too deep, I was wondering if anyone else has > dealt with this issue and might be able to throw me a bone. > > Thanks! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randomnoise058 at gmail.com Sun Sep 2 11:48:09 2018 From: randomnoise058 at gmail.com (Jim Dutton) Date: Sun, 2 Sep 2018 06:48:09 -0500 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key Message-ID: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> It appears that the (PHP) openssl_encrypt function will accept a string of random bytes as the encryption key in place of a generated private key. It works without any errors or warnings. So does the openssl_decrypt function. This begs the question: what does openssl_encrypt actually do with just a string of random bytes passed as the "key". I can't find anything in the OpenSSL or PHP/openssl source code that clearly identifies any particular action specifically related to a string of random bytes used as the encryption key, other than requiring a correct key length. Does it fall back to some internal default? If so - I cannot find it. From rsalz at akamai.com Sun Sep 2 21:22:12 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 2 Sep 2018 21:22:12 +0000 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: References: Message-ID: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> >The capi engine is still broken, however That is windows-only, using the MSFT CryptoAPI. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sun Sep 2 21:53:57 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sun, 2 Sep 2018 21:53:57 +0000 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> Message-ID: <8456D6C8-ADFE-4EAA-B29D-ADCD7D8FD172@akamai.com> > This begs the question: what does openssl_encrypt actually do with just a string of random bytes passed as the "key". I can't find anything in the OpenSSL or PHP/openssl source code that clearly identifies any particular action There is no such name (git grep -I openssl_encrypt) in the OpenSSL source. This is some PHP function that is calling underlying OpenSSL. I would ask on the PHP forum(s) what it's doing. From openssl-users at dukhovni.org Sun Sep 2 22:08:33 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 2 Sep 2018 18:08:33 -0400 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> Message-ID: <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> > On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: > > It appears that the (PHP) openssl_encrypt function will accept a string of > random bytes as the encryption key in place of a generated private key. This is an interface to data encryption with the OpenSSL *symmetric* encryption algorithms, and so the concept of a "private key" does not apply in this context. For most of these algorithms a key is just a random bit-string of the correct length. Some algorithms like DES had parity bits and weak keys, but DES is obsolete, and more modern algorithms don't have these features. > It > works without any errors or warnings. So does the openssl_decrypt function. Keep in mind that without a MAC, this interface does not provide much by way of integrity protection ("padding" gives false positives with non-negligible probability). > This begs the question: what does openssl_encrypt actually do with just a string > of random bytes passed as the "key". It encrypts the data as requested with the given key and IV or authentication tag. http://php.net/manual/en/function.openssl-encrypt.php -- Viktor. From tinskip at gmail.com Sun Sep 2 22:43:15 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Sun, 2 Sep 2018 15:43:15 -0700 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> Message-ID: Gotcha. But why doesn't it work on Mac? On Sun, Sep 2, 2018, 2:22 PM Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > *>*The capi engine is still broken, however > > > > That is windows-only, using the MSFT CryptoAPI. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From randomnoise058 at gmail.com Sun Sep 2 22:51:14 2018 From: randomnoise058 at gmail.com (Jim Dutton) Date: Sun, 2 Sep 2018 17:51:14 -0500 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> Message-ID: <8DD611A3-43B4-4944-B19C-E357A78F05C5@gmail.com> OK - thanks for the feedback. It is interesting to note that the openssl_private_encrypt function appears to require a "true" private key and either expects or defaults to RSA. In both cases neither PHP-OpenSSL nor OpenSSL documentation make these distinctions between the two "encrypt" functions. Sent from my iPad (on iOS11 with only a few lost apps) - J.Dutton > On Sep 2, 2018, at 5:08 PM, Viktor Dukhovni wrote: > > > >> On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: >> >> It appears that the (PHP) openssl_encrypt function will accept a string of >> random bytes as the encryption key in place of a generated private key. > > This is an interface to data encryption with the OpenSSL *symmetric* > encryption algorithms, and so the concept of a "private key" does not > apply in this context. For most of these algorithms a key is just a > random bit-string of the correct length. > > Some algorithms like DES had parity bits and weak keys, but DES is > obsolete, and more modern algorithms don't have these features. > >> It >> works without any errors or warnings. So does the openssl_decrypt function. > > Keep in mind that without a MAC, this interface does not provide much by > way of integrity protection ("padding" gives false positives with non-negligible > probability). > >> This begs the question: what does openssl_encrypt actually do with just a string >> of random bytes passed as the "key". > > It encrypts the data as requested with the given key and IV or authentication > tag. > > http://php.net/manual/en/function.openssl-encrypt.php > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl-users at dukhovni.org Sun Sep 2 22:57:11 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 2 Sep 2018 18:57:11 -0400 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <8DD611A3-43B4-4944-B19C-E357A78F05C5@gmail.com> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> <8DD611A3-43B4-4944-B19C-E357A78F05C5@gmail.com> Message-ID: > On Sep 2, 2018, at 6:51 PM, Jim Dutton wrote: > > It is interesting to note that the openssl_private_encrypt function appears > to require a "true" private key and either expects or defaults to RSA. Not surprising, given the name and brief documentation. > In both cases neither PHP-OpenSSL nor OpenSSL documentation make these > distinctions between the two "encrypt" functions. Private key encryption is a low-level primitive that is fragile in non-expert hands. Avoid if you're not steeped in cryptographic lore. Use a higher-level protocol that makes use of such primitives internally. -- Viktor. From randomnoise058 at gmail.com Sun Sep 2 23:41:17 2018 From: randomnoise058 at gmail.com (Jim Dutton) Date: Sun, 2 Sep 2018 18:41:17 -0500 Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> <5125EF34-4306-4932-A037-3C5DC846C962@dukhovni.org> Message-ID: <2b2c225f-fe6d-9a36-8b2e-2f2f4713532c@gmail.com> I have been using the examples given in the PHP-openssl_encrypt documentation for AEAD with PHP 7 or a suitable emulation of that using HMAC with PHP 5. Being very familiar with security issues and functionality I automatically started using an elliptical curve private key as the "key" after reading about the benefits of EC keys versus RSA and the like. Then thinking about this, doing some experimentation, and looking at source code and documentation, began to realize that the usage of "key" in these examples and documentation may not have always/really intended to mean "generated private key". Somewhat of a semantic ambiguity. On 09/02/2018 17:08, Viktor Dukhovni wrote: > > >> On Sep 2, 2018, at 7:48 AM, Jim Dutton wrote: >> >> It appears that the (PHP) openssl_encrypt function will accept a string of >> random bytes as the encryption key in place of a generated private key. > > This is an interface to data encryption with the OpenSSL *symmetric* > encryption algorithms, and so the concept of a "private key" does not > apply in this context. For most of these algorithms a key is just a > random bit-string of the correct length. > > Some algorithms like DES had parity bits and weak keys, but DES is > obsolete, and more modern algorithms don't have these features. > >> It >> works without any errors or warnings. So does the openssl_decrypt function. > > Keep in mind that without a MAC, this interface does not provide much by > way of integrity protection ("padding" gives false positives with non-negligible > probability). > >> This begs the question: what does openssl_encrypt actually do with just a string >> of random bytes passed as the "key". > > It encrypts the data as requested with the given key and IV or authentication > tag. > > http://php.net/manual/en/function.openssl-encrypt.php > From rsalz at akamai.com Mon Sep 3 00:02:12 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 3 Sep 2018 00:02:12 +0000 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> Message-ID: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> * Gotcha. But why doesn't it work on Mac? The CAPI engine uses Microsoft libraries that are part of windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Mon Sep 3 02:22:18 2018 From: uri at ll.mit.edu (Uri Blumenthal) Date: Sun, 2 Sep 2018 22:22:18 -0400 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> Message-ID: <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> On Sep 2, 2018, at 20:02, Salz, Rich via openssl-users wrote: > Gotcha. But why doesn't it work on Mac? > > The CAPI engine uses Microsoft libraries that are part of windows. Gotcha. In that case why does it get built on Mac? I.e., why doesn?t the build process exclude it automatically? -------------- next part -------------- An HTML attachment was scrubbed... URL: From tinskip at gmail.com Mon Sep 3 03:45:16 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Sun, 2 Sep 2018 20:45:16 -0700 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> Message-ID: What's Windows? Why doesn't it work like my Mac? (I wasnt serious but thanks for being a sport) On Sep 2, 2018 5:02 PM, "Salz, Rich" wrote: - Gotcha. But why doesn't it work on Mac? The CAPI engine uses Microsoft libraries that are part of windows. -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Sep 3 03:48:17 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 03 Sep 2018 05:48:17 +0200 (CEST) Subject: [openssl-users] Using random bytes only in openssl_encrypt versus real private key In-Reply-To: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> References: <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60@gmail.com> Message-ID: <20180903.054817.837802303090630436.levitte@openssl.org> In message <6126f3d3-91a0-02b3-20e8-ab26dbf8bc60 at gmail.com> on Sun, 2 Sep 2018 06:48:09 -0500, Jim Dutton said: > It appears that the (PHP) openssl_encrypt function will accept a string of > random bytes as the encryption key in place of a generated private key. It > works without any errors or warnings. So does the openssl_decrypt function. > > This begs the question: what does openssl_encrypt actually do with just a string > of random bytes passed as the "key". I can't find anything in the OpenSSL or > PHP/openssl source code that clearly identifies any particular action > specifically related to a string of random bytes used as the encryption key, > other than requiring a correct key length. openssl_encrypt (and openssl_decrypt) does symmetric encryption, not asymmetric, so private / public keys aren't involved, just an encryption key that, as you noticed, can be any random bytes (although they are usually generated from a passphrase using a secure key derivation function). For more information, I suggest you read the PHP docs (which is essentially what I did): http://php.net/manual/en/function.openssl-encrypt.php Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From sanjay at ziffusion.com Mon Sep 3 12:33:32 2018 From: sanjay at ziffusion.com (Sanjay Bhandari) Date: Mon, 3 Sep 2018 08:33:32 -0400 Subject: [openssl-users] curl and wget not working with https sites after upgrade to ubuntu 18.04.1 Message-ID: Seems to be a openssl related issue. Anyone have any ideas as to what this is? Note that the url works in a browser. With wget: # wget -d https://deb.nodesource.com/setup_8.x DEBUG output created by Wget 1.19.4 on linux-gnu. Reading HSTS entries from /home/user/.wget-hsts URI encoding = ?UTF-8? Converted file name 'setup_8.x' (UTF-8) -> 'setup_8.x' (UTF-8) --2018-09-02 19:54:06-- https://deb.nodesource.com/setup_8.x Could not seed PRNG; consider using --random-file. OpenSSL: error:2406F07A:random number generator:RAND_load_file:Not a regular file Disabling SSL due to encountered errors. With curl: # curl -v -L https://deb.nodesource.com/setup_8.x * Trying 205.251.207.2... * TCP_NODELAY set * Connected to deb.nodesource.com (205.251.207.2) port 443 (#0) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Mon Sep 3 13:56:41 2018 From: rsalz at akamai.com (Salz, Rich) Date: Mon, 3 Sep 2018 13:56:41 +0000 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> Message-ID: <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> >Gotcha. In that case why does it get built on Mac? I.e., why doesn?t the build process exclude it automatically? Beats me. It ends up being a zero-length object file, more or less. Perhaps Richard Levitte knows. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 3 14:05:41 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 3 Sep 2018 15:05:41 +0100 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> References: <3B941B6A-F6C3-42FB-BC71-8F00030D0203@akamai.com> <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> Message-ID: <8df69ec5-23f9-1ab1-3941-65fc0d75380f@openssl.org> On 03/09/18 14:56, Salz, Rich via openssl-users wrote: > *>*Gotcha. In that case why does it get built on Mac? I.e., why doesn?t > the build process exclude it automatically? > > ? > > Beats me.? It ends up being a zero-length object file, more or less.? > Perhaps Richard Levitte knows. It skips building it completely if configured with no-engine, no-dynamic-engine or no-capieng. Otherwise it will attempt the build. Inside e_capi.c it performs various compile time checks to determine whether its got everything it needs to produce the engine. If it doesn't then it just ends up building a dummy engine that doesn't do anything. Matt From levitte at openssl.org Mon Sep 3 16:26:42 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 03 Sep 2018 18:26:42 +0200 (CEST) Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> References: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> Message-ID: <20180903.182642.2140282159240275750.levitte@openssl.org> In message <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0 at akamai.com> on Mon, 3 Sep 2018 13:56:41 +0000, "Salz, Rich" said: > > Gotcha. In that case why does it get built on Mac? I.e., why > > doesn?t the build process exclude it automatically? > > Beats me. It ends up being a zero-length object file, more or > less. Perhaps Richard Levitte knows. We've made it conditional in the source file rather than the build configuration, so on non-MSWindows platforms, it becomes a minimal shared object with an entry point that fails unconditionally. We should obviously rethink that strategy... Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From uri at ll.mit.edu Mon Sep 3 18:30:24 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 3 Sep 2018 18:30:24 +0000 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: <20180903.182642.2140282159240275750.levitte@openssl.org> References: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> <20180903.182642.2140282159240275750.levitte@openssl.org> Message-ID: If it builds a dummy engine - then shouldn't a dummy engine respond gracefully to requests with something like "sorry I can't do anything useful", instead of spitting outa puke of error messages in response to "openssl engine -t capi"? Regards, Uri Sent from my iPhone > On Sep 3, 2018, at 12:27, Richard Levitte wrote: > > In message <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0 at akamai.com> on Mon, 3 Sep 2018 13:56:41 +0000, "Salz, Rich" said: > >>> Gotcha. In that case why does it get built on Mac? I.e., why >>> doesn?t the build process exclude it automatically? >> >> Beats me. It ends up being a zero-length object file, more or >> less. Perhaps Richard Levitte knows. > > We've made it conditional in the source file rather than the build > configuration, so on non-MSWindows platforms, it becomes a minimal > shared object with an entry point that fails unconditionally. > > We should obviously rethink that strategy... > > Cheers, > Richard > > -- > Richard Levitte levitte at openssl.org > OpenSSL Project http://www.openssl.org/~levitte/ > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From uri at ll.mit.edu Mon Sep 3 18:41:43 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 3 Sep 2018 18:41:43 +0000 Subject: [openssl-users] Engines on Mac OS X In-Reply-To: References: <5EDB705B-3869-461E-80DD-99A5D785C34B@akamai.com> <2733CF75-EE88-4B2D-B6B7-E4242AB6D40D@ll.mit.edu> <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0@akamai.com> <20180903.182642.2140282159240275750.levitte@openssl.org> Message-ID: Ouch... Spelling Corrector doing is best. The text below should've been: "... spitting out a pile of error..." Oh well. Hard to admit, but sometimes automatic correctors are even more eloquent than me, and seem freeer in their choice of words too. ;-) Regards, Uri Sent from my iPhone > On Sep 3, 2018, at 14:31, Blumenthal, Uri - 0553 - MITLL wrote: > > If it builds a dummy engine - then shouldn't a dummy engine respond gracefully to requests with something like "sorry I can't do anything useful", instead of spitting outa puke of error messages in response to "openssl engine -t capi"? > > Regards, > Uri > > Sent from my iPhone > >> On Sep 3, 2018, at 12:27, Richard Levitte wrote: >> >> In message <62B8AA9B-D6D2-4F33-94C5-7BFE11E465A0 at akamai.com> on Mon, 3 Sep 2018 13:56:41 +0000, "Salz, Rich" said: >> >>>> Gotcha. In that case why does it get built on Mac? I.e., why >>>> doesn?t the build process exclude it automatically? >>> >>> Beats me. It ends up being a zero-length object file, more or >>> less. Perhaps Richard Levitte knows. >> >> We've made it conditional in the source file rather than the build >> configuration, so on non-MSWindows platforms, it becomes a minimal >> shared object with an entry point that fails unconditionally. >> >> We should obviously rethink that strategy... >> >> Cheers, >> Richard >> >> -- >> Richard Levitte levitte at openssl.org >> OpenSSL Project http://www.openssl.org/~levitte/ >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From tinskip at gmail.com Mon Sep 3 19:05:04 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Mon, 3 Sep 2018 12:05:04 -0700 Subject: [openssl-users] build.info Message-ID: Does anyone know how I can specify that a specific shared library (in this case an engine) is dependent on a system-installed shared library (i.e. not built along with openssl)?. Basically the equivalent of LDFLAGS += -lsomelib -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michal.Trojnara at stunnel.org Mon Sep 3 20:46:19 2018 From: Michal.Trojnara at stunnel.org (Michal Trojnara) Date: Mon, 3 Sep 2018 22:46:19 +0200 Subject: [openssl-users] stunnel 5.49 released Message-ID: <9de53b0c-b9bd-6236-2b42-187da0a44e67@stunnel.org> Dear Users, I have released version 5.49 of stunnel. Version 5.49, 2018.09.03, urgency: MEDIUM * New features ? - Performance optimizations. ? - Logging of negotiated or resumed TLS session IDs (thx ??? to ANSSI - National Cybersecurity Agency of France). ? - Merged Debian 10-enabled.patch and 11-killproc.patch ??? (thx to Peter Pentchev). ? - OpenSSL DLLs updated to version 1.0.2p. ? - PKCS#11 engine DLL updated to version 0.4.9. * Bugfixes ? - Fixed a crash in the session persistence implementation. ? - Fixed syslog identifier after configuration file reload. ? - Fixed non-interactive "make check" invocations. ? - Fixed reloading syslog configuration. ? - stunnel.pem created with SHA-256 instead of SHA-1. ? - SHA-256 "make check" certificates. Home page: https://www.stunnel.org/ Download: https://www.stunnel.org/downloads.html SHA-256 hashes: 3d6641213a82175c19f23fde1c3d1c841738385289eb7ca1554f4a58b96d955e? stunnel-5.49.tar.gz 459bbb212baf0b9821c80e0664c830246ef6e97c7329fb08160e87ff11ae9692? stunnel-5.49-win32-installer.exe 72416c6664106ad815a8da67a525c6593247fc06cbca3b8918ffc87ae92595e8? stunnel-5.49-android.zip Best regards, ??? Mike -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From joebrowning99 at gmail.com Mon Sep 3 22:07:48 2018 From: joebrowning99 at gmail.com (Joe Browning) Date: Mon, 03 Sep 2018 18:07:48 -0400 Subject: [openssl-users] build.info In-Reply-To: References: Message-ID: Using the linux env var LD_PRELOAD, maybe? ?Sent from BlueMail ? On Sep 3, 2018, 15:05, at 15:05, "Thom?s Inskip" wrote: >Does anyone know how I can specify that a specific shared library (in >this >case an engine) is dependent on a system-installed shared library (i.e. >not >built along with openssl)?. Basically the equivalent of LDFLAGS += >-lsomelib > > >------------------------------------------------------------------------ > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlbrown at bordo.com.au Tue Sep 4 04:16:09 2018 From: jlbrown at bordo.com.au (James Brown) Date: Tue, 4 Sep 2018 14:16:09 +1000 Subject: [openssl-users] OpenSSL version 1.1.0i make test fails - 80-test_cms.t Message-ID: <53A41B4D-D805-4A5A-A4C4-B7D34FB1C5DD@bordo.com.au> Running ?make test? for 1.1.0i fails with: Test Summary Report ------------------- ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) Failed test: 4 Non-zero exit status: 1 Files=99, Tests=561, 83 wallclock secs ( 0.94 usr 0.23 sys + 49.59 cusr 22.30 csys = 73.06 CPU) Result: FAIL make[1]: *** [_tests] Error 1 make: *** [tests] Error 2 I first ran: ./Configure --prefix=/usr/local shared darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 then make depend then: make test macOS X 10.7.5 Any suggestions? Thanks, James. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 4 04:42:30 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 Sep 2018 00:42:30 -0400 Subject: [openssl-users] OpenSSL version 1.1.0i make test fails - 80-test_cms.t In-Reply-To: <53A41B4D-D805-4A5A-A4C4-B7D34FB1C5DD@bordo.com.au> References: <53A41B4D-D805-4A5A-A4C4-B7D34FB1C5DD@bordo.com.au> Message-ID: <2F57AEB3-8DB8-4D46-A5C0-52E99930A09C@dukhovni.org> > On Sep 4, 2018, at 12:16 AM, James Brown via openssl-users wrote: > > Running ?make test? for 1.1.0i fails with: > > Test Summary Report > ------------------- > ../test/recipes/80-test_cms.t (Wstat: 256 Tests: 4 Failed: 1) > Failed test: 4 > Non-zero exit status: 1 > Files=99, Tests=561, 83 wallclock secs ( 0.94 usr 0.23 sys + 49.59 cusr 22.30 csys = 73.06 CPU) > Result: FAIL > make[1]: *** [_tests] Error 1 > make: *** [tests] Error 2 > > I first ran: > > ./Configure --prefix=/usr/local shared darwin64-x86_64-cc enable-ec_nistp_64_gcc_128 no-ssl2 no-ssl3 > > then > > make depend The "make depend" should not be necessary with "1.1.0" builds. > then: make test > > macOS X 10.7.5 > > Any suggestions? I'm using MacOS X 10.13.6 (aka Darwin 17.7.0), and all tests pass. You could try "make V=1 test" and report more details from the test failure, but first consider skipping "make depend" and perhaps a less ancient MacOS X version. -- Viktor. From mksarav at gmail.com Tue Sep 4 05:28:35 2018 From: mksarav at gmail.com (M K Saravanan) Date: Tue, 4 Sep 2018 13:28:35 +0800 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? Message-ID: Hi, When using openssl with X25519, why it shows the server temp key as 253 bits? Example: --- No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA Server Temp Key: X25519, 253 bits --- I thought Curve25519 is using 256 bit keys. Why 253 instead of 256? with regards, Saravanan From wouter.verhelst at bosa.fgov.be Tue Sep 4 06:55:33 2018 From: wouter.verhelst at bosa.fgov.be (Wouter Verhelst) Date: Tue, 4 Sep 2018 08:55:33 +0200 Subject: [openssl-users] build.info In-Reply-To: References: Message-ID: <577e355d-3fc1-aaf5-62ef-30ecd83ce379@bosa.fgov.be> On 9/3/18 9:05 PM, Thom?s Inskip wrote: > Does anyone know how I can specify that a specific shared library (in > this case an engine) is dependent on a system-installed shared library > (i.e. not built along with openssl)?.? Basically the equivalent of > LDFLAGS?+= -lsomelib The GNU runtime dynamic library will honor DT_NEEDED flags of libraries, too. That is,? you can just do LDFLAGS += -lsomelib on a library target and it will work. Check libgtk-3.so, for instance: objdump -x /usr/lib/x86_64-linux-gnu/libgtk-3.so will show a bunch of lines like... Dynamic Section: ? NEEDED?????????????? libgdk-3.so.0 ? NEEDED?????????????? libgmodule-2.0.so.0 ? NEEDED?????????????? libpangocairo-1.0.so.0 ? NEEDED?????????????? libX11.so.6 ? NEEDED?????????????? libXi.so.6 ? NEEDED?????????????? libXcomposite.so.1 ? NEEDED?????????????? libXdamage.so.1 (...) Meaning, all these libraries need to be loaded for libgtk-3.so to work. Beware gotchas: - Not all rtdl implementations do so, so if you're not using a GNU platform (e.g., Linux), then check the documentation of your runtime dynamic linker. - This works for shared libraries, but not for static ones. Regards, -------------- next part -------------- An HTML attachment was scrubbed... URL: From jisoza at gmail.com Tue Sep 4 07:09:10 2018 From: jisoza at gmail.com (Juan Isoza) Date: Tue, 4 Sep 2018 09:09:10 +0200 Subject: [openssl-users] openssl 1.1.1 release In-Reply-To: References: Message-ID: Hello, Have you more info ? regards Le lun. 27 ao?t 2018 ? 15:12, Matt Caswell a ?crit : > > > > We are hoping that pre 9 will be the last beta and the next release will > be the final one. > > > We have tentatively discussed 11th September as a possible release date > - but no definitive decisions on this yet. > > Matt > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 4 07:11:43 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 4 Sep 2018 09:11:43 +0200 Subject: [openssl-users] build.info In-Reply-To: <577e355d-3fc1-aaf5-62ef-30ecd83ce379@bosa.fgov.be> References: <577e355d-3fc1-aaf5-62ef-30ecd83ce379@bosa.fgov.be> Message-ID: <23276129-d774-2086-ee2c-51dca57b6276@wisemo.com> On 04/09/2018 08:55, Wouter Verhelst wrote: > On 9/3/18 9:05 PM, Thom?s Inskip wrote: >> Does anyone know how I can specify that a specific shared library (in >> this case an engine) is dependent on a system-installed shared >> library (i.e. not built along with openssl)?.? Basically the >> equivalent of LDFLAGS?+= -lsomelib > The GNU runtime dynamic library will honor DT_NEEDED flags of > libraries, too. That is,? you can just do LDFLAGS += -lsomelib on a > library target and it will work. Check libgtk-3.so, for instance: > > objdump -x /usr/lib/x86_64-linux-gnu/libgtk-3.so > > will show a bunch of lines like... > > Dynamic Section: > ? NEEDED?????????????? libgdk-3.so.0 > ? NEEDED?????????????? libgmodule-2.0.so.0 > ? NEEDED?????????????? libpangocairo-1.0.so.0 > ? NEEDED?????????????? libX11.so.6 > ? NEEDED?????????????? libXi.so.6 > ? NEEDED?????????????? libXcomposite.so.1 > ? NEEDED?????????????? libXdamage.so.1 > (...) > > Meaning, all these libraries need to be loaded for libgtk-3.so to work. > > Beware gotchas: > > - Not all rtdl implementations do so, so if you're not using a GNU > platform (e.g., Linux), then check the documentation of your runtime > dynamic linker. > - This works for shared libraries, but not for static ones. > > Regards, > Please note that the OP is apparently asking how to specify -lsomelib using the OpenSSL-specific build system, not the general meaning of using shared libraries on POSIX systems. 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 Matthias.St.Pierre at ncp-e.com Tue Sep 4 08:17:19 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 4 Sep 2018 08:17:19 +0000 Subject: [openssl-users] openssl 1.1.1 release In-Reply-To: References: Message-ID: <8c37f5257ee94e0abfeedb410b2aaed6@Ex13.ncp.local> Final release is still scheduled for September 11, see also the discussion on openssl-project https://mta.openssl.org/pipermail/openssl-project/2018-September/001010.html HTH, Matthias Von: openssl-users Im Auftrag von Juan Isoza Gesendet: Dienstag, 4. September 2018 09:09 An: openssl-users at openssl.org Betreff: Re: [openssl-users] openssl 1.1.1 release Hello, Have you more info ? regards Le lun. 27 ao?t 2018 ? 15:12, Matt Caswell > a ?crit : > We are hoping that pre 9 will be the last beta and the next release will be the final one. > We have tentatively discussed 11th September as a possible release date - but no definitive decisions on this yet. Matt -------------- next part -------------- An HTML attachment was scrubbed... URL: From aerowolf at gmail.com Tue Sep 4 12:00:29 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Tue, 4 Sep 2018 05:00:29 -0700 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: References: Message-ID: Probably because the definition of X25519 requires that bits 0, 1, and 2 of the first byte of the private key are set to 0 before being used, and OpenSSL counts the number of bits including the highest-order set bit. (Really, there's an additional 2 bits that are also set to known values: bit 6 of the last byte is set, and bit 7 of the last byte is cleared. In my view, this actually reduces the necessary brute-force search space from 256 bits to 251 bits. However, literally any 32-byte string can be used as a public key. Apparently, djb views this as sufficient to call it a 256-bit strength function.) For the specification, please see the subsection entitled "Responsibilities of the User" in section 3 of https://cr.yp.to/ecdh/curve25519-20060209.pdf . -Kyle H On Mon, Sep 3, 2018, 22:29 M K Saravanan wrote: > Hi, > > When using openssl with X25519, why it shows the server temp key as 253 > bits? > > Example: > > --- > No client certificate CA names sent > Peer signing digest: SHA256 > Peer signature type: RSA > Server Temp Key: X25519, 253 bits > --- > > I thought Curve25519 is using 256 bit keys. > > Why 253 instead of 256? > > with regards, > Saravanan > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rgm at htt-consult.com Tue Sep 4 13:43:08 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 4 Sep 2018 09:43:08 -0400 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: References: Message-ID: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> And I seem to recall that one bit is for compact representation. That is, is y positive or negative.? With p256, you have to transmit x and y or deal with the compact representation patent. On 09/04/2018 08:00 AM, Kyle Hamilton wrote: > Probably because the definition of X25519 requires that bits 0, 1, and > 2 of the first byte of the private key are set to 0 before being used, > and OpenSSL counts the number of bits including the highest-order set > bit.? (Really, there's an additional 2 bits that are also set to known > values: bit 6 of the last byte is set, and bit 7 of the last byte is > cleared.? In my view, this actually reduces the necessary brute-force > search space from 256 bits to 251 bits. However, literally any 32-byte > string can be used as a public key.? Apparently, djb views this as > sufficient to call it a 256-bit strength function.) > > For the specification, please see the subsection entitled > "Responsibilities of the User" in section 3 of > https://cr.yp.to/ecdh/curve25519-20060209.pdf . > > -Kyle H > > > > > > On Mon, Sep 3, 2018, 22:29 M K Saravanan > wrote: > > Hi, > > When using openssl with X25519, why it shows the server temp key > as 253 bits? > > Example: > > --- > No client certificate CA names sent > Peer signing digest: SHA256 > Peer signature type: RSA > Server Temp Key: X25519, 253 bits > --- > > I thought Curve25519 is using 256 bit keys. > > Why 253 instead of 256? > > with regards, > Saravanan > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 4 14:19:25 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 4 Sep 2018 16:19:25 +0200 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> Message-ID: On 04/09/2018 15:43, Robert Moskowitz wrote: > And I seem to recall that one bit is for compact representation. That > is, is y positive or negative.? With p256, you have to transmit x and > y or deal with the compact representation patent. > Not sure if this applies do X25519 and Ed255 which use different techniques than the traditional curves. Those two are also intended to avoid data-dependent if() statements (because of side channel attacks), but remain vulnerable on CPUs where division or multiplication instructions have data-dependent time and/or power consumption (which is unfortunately most of the common ones). > On 09/04/2018 08:00 AM, Kyle Hamilton wrote: >> Probably because the definition of X25519 requires that bits 0, 1, >> and 2 of the first byte of the private key are set to 0 before being >> used, and OpenSSL counts the number of bits including the >> highest-order set bit. (Really, there's an additional 2 bits that are >> also set to known values: bit 6 of the last byte is set, and bit 7 of >> the last byte is cleared.? In my view, this actually reduces the >> necessary brute-force search space from 256 bits to 251 bits. >> However, literally any 32-byte string can be used as a public key.? >> Apparently, djb views this as sufficient to call it a 256-bit >> strength function.) >> >> For the specification, please see the subsection entitled >> "Responsibilities of the User" in section 3 of >> https://cr.yp.to/ecdh/curve25519-20060209.pdf . >> >> -Kyle H >> >> >> >> >> >> On Mon, Sep 3, 2018, 22:29 M K Saravanan > > wrote: >> >> Hi, >> >> When using openssl with X25519, why it shows the server temp key >> as 253 bits? >> >> Example: >> >> --- >> No client certificate CA names sent >> Peer signing digest: SHA256 >> Peer signature type: RSA >> Server Temp Key: X25519, 253 bits >> --- >> >> I thought Curve25519 is using 256 bit keys. >> >> Why 253 instead of 256? >> >> with regards, >> Saravanan >> 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 Tue Sep 4 14:24:51 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Tue, 4 Sep 2018 10:24:51 -0400 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> Message-ID: <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> My source is Dr. Lange at the IETF meeting in Toronto when the IETF selected EC25519. A curve point needs an x and a y.? But do you need the y for the computation.? Do you only need its sign?? I don't know.? I am not a mathematician. I may have misunderstood her at the time. On 09/04/2018 10:19 AM, Jakob Bohm wrote: > On 04/09/2018 15:43, Robert Moskowitz wrote: >> And I seem to recall that one bit is for compact representation. That >> is, is y positive or negative. With p256, you have to transmit x and >> y or deal with the compact representation patent. >> > Not sure if this applies do X25519 and Ed255 which use different > techniques than the traditional curves. > > Those two are also intended to avoid data-dependent if() statements > (because of side channel attacks), but remain vulnerable on CPUs > where division or multiplication instructions have data-dependent > time and/or power consumption (which is unfortunately most of the > common ones). > >> On 09/04/2018 08:00 AM, Kyle Hamilton wrote: >>> Probably because the definition of X25519 requires that bits 0, 1, >>> and 2 of the first byte of the private key are set to 0 before being >>> used, and OpenSSL counts the number of bits including the >>> highest-order set bit. (Really, there's an additional 2 bits that >>> are also set to known values: bit 6 of the last byte is set, and bit >>> 7 of the last byte is cleared.? In my view, this actually reduces >>> the necessary brute-force search space from 256 bits to 251 bits. >>> However, literally any 32-byte string can be used as a public key.? >>> Apparently, djb views this as sufficient to call it a 256-bit >>> strength function.) >>> >>> For the specification, please see the subsection entitled >>> "Responsibilities of the User" in section 3 of >>> https://cr.yp.to/ecdh/curve25519-20060209.pdf . >>> >>> -Kyle H >>> >>> >>> >>> >>> >>> On Mon, Sep 3, 2018, 22:29 M K Saravanan >> > wrote: >>> >>> ??? Hi, >>> >>> ??? When using openssl with X25519, why it shows the server temp key >>> ??? as 253 bits? >>> >>> ??? Example: >>> >>> ??? --- >>> ??? No client certificate CA names sent >>> ??? Peer signing digest: SHA256 >>> ??? Peer signature type: RSA >>> ??? Server Temp Key: X25519, 253 bits >>> ??? --- >>> >>> ??? I thought Curve25519 is using 256 bit keys. >>> >>> ??? Why 253 instead of 256? >>> >>> ??? with regards, >>> ??? Saravanan >>> > > Enjoy > > Jakob From jb-openssl at wisemo.com Tue Sep 4 14:31:42 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 4 Sep 2018 16:31:42 +0200 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> Message-ID: <2c3bffb7-9338-7105-997b-978b32558e11@wisemo.com> On 04/09/2018 16:24, Robert Moskowitz wrote: > My source is Dr. Lange at the IETF meeting in Toronto when the IETF > selected EC25519. > > A curve point needs an x and a y.? But do you need the y for the > computation.? Do you only need its sign?? I don't know.? I am not a > mathematician. > > I may have misunderstood her at the time. Ok, she (if anyone) should know. I expect the papers, sample code etc. by Bernstein, Lange et al to provide all the details of this. > > On 09/04/2018 10:19 AM, Jakob Bohm wrote: >> On 04/09/2018 15:43, Robert Moskowitz wrote: >>> And I seem to recall that one bit is for compact representation. That >>> is, is y positive or negative. With p256, you have to transmit x and >>> y or deal with the compact representation patent. >>> >> Not sure if this applies do X25519 and Ed255 which use different >> techniques than the traditional curves. >> >> Those two are also intended to avoid data-dependent if() statements >> (because of side channel attacks), but remain vulnerable on CPUs >> where division or multiplication instructions have data-dependent >> time and/or power consumption (which is unfortunately most of the >> common ones). >> >>> On 09/04/2018 08:00 AM, Kyle Hamilton wrote: >>>> Probably because the definition of X25519 requires that bits 0, 1, >>>> and 2 of the first byte of the private key are set to 0 before being >>>> used, and OpenSSL counts the number of bits including the >>>> highest-order set bit. (Really, there's an additional 2 bits that >>>> are also set to known values: bit 6 of the last byte is set, and bit >>>> 7 of the last byte is cleared.? In my view, this actually reduces >>>> the necessary brute-force search space from 256 bits to 251 bits. >>>> However, literally any 32-byte string can be used as a public key. >>>> Apparently, djb views this as sufficient to call it a 256-bit >>>> strength function.) >>>> >>>> For the specification, please see the subsection entitled >>>> "Responsibilities of the User" in section 3 of >>>> https://cr.yp.to/ecdh/curve25519-20060209.pdf . >>>> >>>> -Kyle H >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Sep 3, 2018, 22:29 M K Saravanan >>> > wrote: >>>> >>>> ??? Hi, >>>> >>>> ??? When using openssl with X25519, why it shows the server temp key >>>> ??? as 253 bits? >>>> >>>> ??? Example: >>>> >>>> ??? --- >>>> ??? No client certificate CA names sent >>>> ??? Peer signing digest: SHA256 >>>> ??? Peer signature type: RSA >>>> ??? Server Temp Key: X25519, 253 bits >>>> ??? --- >>>> >>>> ??? I thought Curve25519 is using 256 bit keys. >>>> >>>> ??? Why 253 instead of 256? >>>> >>>> ??? with regards, >>>> ??? Saravanan >>>> Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From openssl-users at dukhovni.org Tue Sep 4 14:50:53 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 Sep 2018 10:50:53 -0400 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> Message-ID: With curve25519, the scalar multiplication function: (x, y) -> n * (x, y) = (x', y') -> x' has the property that for valid points on the extended curve (degree two extension of F(p) that gives a y for every x in F(p)), x' depends only on x, and can be effectively computed from x alone, and this can be done for all x in F(p) since all "x" values are either on the curve or its "twist". Therefore, the X25519 key agreement protocol only uses the x-coordinate. IIRC, Ed25519 signatures do require a y-coordinate sign, and so the signature representation is not x-only. > On Sep 4, 2018, at 10:24 AM, Robert Moskowitz wrote: > > My source is Dr. Lange at the IETF meeting in Toronto when the IETF selected EC25519. > > A curve point needs an x and a y. But do you need the y for the computation. Do you only need its sign? I don't know. I am not a mathematician. -- Viktor. From ilya.golosovsky at gmail.com Tue Sep 4 15:06:52 2018 From: ilya.golosovsky at gmail.com (Eli Golosovsky) Date: Tue, 4 Sep 2018 18:06:52 +0300 Subject: [openssl-users] passing CA bundle as buffer, instead of file path, to X509_STORE_CTX_ functions In-Reply-To: References: Message-ID: Is there an option, in *OpenSSL 1.1.1*, to load a CA bundle from memory (buffer / string) instead of loading it from a file? >From my experience, loading a CA bundle can be achieved by using the *X509_STORE_CTX_* functions, on an *X509_STORE_CTX* object, representing the certificate, and finalizing with *X509_verify_cert*. But I know of no way to load the CA bundle not from disk. Thanks in advance, Ilya Golosovsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Tue Sep 4 15:11:05 2018 From: d3ck0r at gmail.com (J Decker) Date: Tue, 4 Sep 2018 08:11:05 -0700 Subject: [openssl-users] passing CA bundle as buffer, instead of file path, to X509_STORE_CTX_ functions In-Reply-To: References: Message-ID: You can use a BIO_new( BIO_s_mem() ) to feed the memory through BIO_writeand PEM_read_bio_X509 something like ... https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L780 On Tue, Sep 4, 2018 at 8:07 AM Eli Golosovsky wrote: > Is there an option, in *OpenSSL 1.1.1*, to load a CA bundle from memory > (buffer / string) instead of loading it from a file? > > From my experience, loading a CA bundle can be achieved by using the > *X509_STORE_CTX_* functions, on an *X509_STORE_CTX* object, representing > the certificate, and finalizing with *X509_verify_cert*. But I know of no > way to load the CA bundle not from disk. > > Thanks in advance, > Ilya Golosovsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcr at sandelman.ca Tue Sep 4 16:10:04 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Tue, 04 Sep 2018 12:10:04 -0400 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> Message-ID: <24960.1536077404@localhost> Robert Moskowitz wrote: > A curve point needs an x and a y.? But do you need the y for the > computation.? Do you only need its sign?? I don't know.? I am not a > mathematician. My understanding is that you need x and y to do the computation. (And I observe this in code) However, since x and y have to be on the curve, if you know x, then that constrained y to be one or two values... so you need to know the *sign* of y, which is transmitted as a single bit. Then you can calculate y. The fundamental reason behind this is because sqrt(4) = 2, and sqrt(4) = -2... Since some bits of the x are required to be 0, it's possible to encode the sign of Y into the encoded X bit-stream... -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | network 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 tinskip at gmail.com Tue Sep 4 18:05:27 2018 From: tinskip at gmail.com (=?UTF-8?Q?Thom=C3=A1s_Inskip?=) Date: Tue, 4 Sep 2018 11:05:27 -0700 Subject: [openssl-users] build.info In-Reply-To: <23276129-d774-2086-ee2c-51dca57b6276@wisemo.com> References: <577e355d-3fc1-aaf5-62ef-30ecd83ce379@bosa.fgov.be> <23276129-d774-2086-ee2c-51dca57b6276@wisemo.com> Message-ID: Thanks. That is correct. I'd like to specify -lsomellib for just one engine target in engines/build.info. On Tue, Sep 4, 2018 at 12:12 AM Jakob Bohm wrote: > On 04/09/2018 08:55, Wouter Verhelst wrote: > > On 9/3/18 9:05 PM, Thom?s Inskip wrote: > >> Does anyone know how I can specify that a specific shared library (in > >> this case an engine) is dependent on a system-installed shared > >> library (i.e. not built along with openssl)?. Basically the > >> equivalent of LDFLAGS += -lsomelib > > The GNU runtime dynamic library will honor DT_NEEDED flags of > > libraries, too. That is, you can just do LDFLAGS += -lsomelib on a > > library target and it will work. Check libgtk-3.so, for instance: > > > > objdump -x /usr/lib/x86_64-linux-gnu/libgtk-3.so > > > > will show a bunch of lines like... > > > > Dynamic Section: > > NEEDED libgdk-3.so.0 > > NEEDED libgmodule-2.0.so.0 > > NEEDED libpangocairo-1.0.so.0 > > NEEDED libX11.so.6 > > NEEDED libXi.so.6 > > NEEDED libXcomposite.so.1 > > NEEDED libXdamage.so.1 > > (...) > > > > Meaning, all these libraries need to be loaded for libgtk-3.so to work. > > > > Beware gotchas: > > > > - Not all rtdl implementations do so, so if you're not using a GNU > > platform (e.g., Linux), then check the documentation of your runtime > > dynamic linker. > > - This works for shared libraries, but not for static ones. > > > > Regards, > > > Please note that the OP is apparently asking how to specify > -lsomelib using the OpenSSL-specific build system, not the > general meaning of using shared libraries on POSIX systems. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 4 22:23:26 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 4 Sep 2018 18:23:26 -0400 Subject: [openssl-users] X25519 - why openssl shows server temp key as 253 bits? In-Reply-To: <24960.1536077404@localhost> References: <5aa1ea8d-c001-9cce-e84a-360946833183@htt-consult.com> <748209e2-bf8f-66e7-2fd2-3e56fffb446b@htt-consult.com> <24960.1536077404@localhost> Message-ID: <1859FD5F-CDA5-4CB2-80B5-A508C3ED53FF@dukhovni.org> > On Sep 4, 2018, at 12:10 PM, Michael Richardson wrote: > > My understanding is that you need x and y to do the computation. > (And I observe this in code) The Y coordinate is not needed for X25519 and X448 Diffie-Helman key agreement, these operate on the X (sometimes called "u") coordinate only. The Ed25519 and Ed448 algorithms do use compressed-encodings with one bit used to disambiguate the choice of square-root for one of the coordinates. With Edwards form the choice of which to to compress is arbitrary, the curve is invariant under exchange of x and y or change of either sign. https://tools.ietf.org/html/rfc8032#section-5.1.2 https://tools.ietf.org/html/rfc8032#section-5.2.2 -- -- Viktor. From levitte at openssl.org Tue Sep 4 22:48:55 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 05 Sep 2018 00:48:55 +0200 (CEST) Subject: [openssl-users] build.info In-Reply-To: References: <577e355d-3fc1-aaf5-62ef-30ecd83ce379@bosa.fgov.be> <23276129-d774-2086-ee2c-51dca57b6276@wisemo.com> Message-ID: <20180905.004855.2041077330650286292.levitte@openssl.org> We currently don't have per-engine support of the kind. The cleanest you can do is probably having a private config looking something like this: our %targets = ( 'mytarget' => { inherit_from => [ 'whatever' ], dso_ldflags => '-lsomelib' } ); Cheers, Richard In message on Tue, 4 Sep 2018 11:05:27 -0700, Thom?s Inskip said: > Thanks. That is correct. I'd like to specify -lsomellib for just one engine target in engines/build.info. > > On Tue, Sep 4, 2018 at 12:12 AM Jakob Bohm wrote: > > On 04/09/2018 08:55, Wouter Verhelst wrote: > > On 9/3/18 9:05 PM, Thom?s Inskip wrote: > >> Does anyone know how I can specify that a specific shared library (in > >> this case an engine) is dependent on a system-installed shared > >> library (i.e. not built along with openssl)?. Basically the > >> equivalent of LDFLAGS += -lsomelib > > The GNU runtime dynamic library will honor DT_NEEDED flags of > > libraries, too. That is, you can just do LDFLAGS += -lsomelib on a > > library target and it will work. Check libgtk-3.so, for instance: > > > > objdump -x /usr/lib/x86_64-linux-gnu/libgtk-3.so > > > > will show a bunch of lines like... > > > > Dynamic Section: > > NEEDED libgdk-3.so.0 > > NEEDED libgmodule-2.0.so.0 > > NEEDED libpangocairo-1.0.so.0 > > NEEDED libX11.so.6 > > NEEDED libXi.so.6 > > NEEDED libXcomposite.so.1 > > NEEDED libXdamage.so.1 > > (...) > > > > Meaning, all these libraries need to be loaded for libgtk-3.so to work. > > > > Beware gotchas: > > > > - Not all rtdl implementations do so, so if you're not using a GNU > > platform (e.g., Linux), then check the documentation of your runtime > > dynamic linker. > > - This works for shared libraries, but not for static ones. > > > > Regards, > > > Please note that the OP is apparently asking how to specify > -lsomelib using the OpenSSL-specific build system, not the > general meaning of using shared libraries on POSIX systems. > > Enjoy > > Jakob > -- > Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com > Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 > This public discussion message is non-binding and may contain errors. > WiseMo - Remote Service Management for PCs, Phones and Embedded > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From lintamaria194 at gmail.com Wed Sep 5 11:36:14 2018 From: lintamaria194 at gmail.com (Linta Maria) Date: Wed, 5 Sep 2018 17:06:14 +0530 Subject: [openssl-users] Default salt and padding for signature Message-ID: Hi, Can you please let me know default salt and padding used for signature generation in open ssl as we are not able to get the info . Regards, Linta -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Wed Sep 5 14:01:40 2018 From: hkario at redhat.com (Hubert Kario) Date: Wed, 05 Sep 2018 16:01:40 +0200 Subject: [openssl-users] Wrapper script for creating PKI with openssl Was: OpenSSL version 1.1.1 pre release 9 published In-Reply-To: References: <20180821123602.GA29908@openssl.org> <1719876.rvBO8iizTT@pintsize.usersys.redhat.com> Message-ID: <3301154.2kfJHkcgrF@pintsize.usersys.redhat.com> On Wednesday, 29 August 2018 14:49:52 CEST Bear Giles wrote: > This is a total aside but I prototyped a PostgreSQL extension that > implemented the PKI infrastructure using OpenSSL. (The OpenSSL C API... > shudder.) The database server already had it present, for SSL support, so I > could piggyback on that and not worry about export restrictions since > anyone that couldn't use OpenSSL couldn't run my extension either. > > It was a hobby project and I largely dropped it for various reasons. Some > of it was specific to PostgreSQL (migrating away from OpenSSL) but a lot of > it was because there was already enough "good enough" solutions that the > perceived need had gone away. Many open source projects had documentation > for EasyRSA, but now they have integrated support for LetsEncrypt. > > Anyway the point is that these type of projects have to be careful that > they don't invent a better mousetrap in a world where nobody is looking for > one. It's a fun project where you can learn a lot but it won't get much > traction unless it's a totally new approach. The existing solutions may > have flaws but most of the places where you need a CA already have > documentation on how to use EasyRSA, if not outright integration with a > solution. To be honest, I don't expect it this script to take the world over. EasyRSA was not usable for my use case, so I created a new one, designed specifically for interoperability testing between different implementations. It definitely is not and should not be used in production environments. If somebody wants to use it for the same use case, it will be awesome, if they decide to contribute to it, I'll be overjoyed. But I don't expect it to fit the needs of many people (hell, most interoperability testing can be performed with a certificate generated with a openssl one-liner: openssl req -x509 -newkey rsa -keyout localhost.key -out localhost.crt \ -subj /CN=localhost -nodes -batch the problem starts when you need anything more complex). > On Mon, Aug 27, 2018 at 4:18 PM Hubert Kario wrote: > > Changing Subject to help googlability :) > > > > On Monday, 27 August 2018 22:38:24 CEST Robert Moskowitz wrote: > > > On 08/27/2018 04:07 PM, Hubert Kario wrote: > > > > now, for generating testing certificates (and what's more important, > > > > the > > > > > > whole PKI) we are using this script to provide sensible defaults and > > > > easy > > > > > > way to generate certificates with just few options departing from > > > > those > > > > defaults: https://github.com/redhat-qe-security/certgen > > > > > > I will take a look at this. It did not come up in my google searches a > > > year ago. Guess just not asking the right question or github is > > > protected from google... > > > > definitely isn't; most of the visits on my other repos come from google > > (if > > github stats are to be believed) > > > > likely because similar scripts are not uncommon (e.g. OpenVPN ships with > > something similar) and this one is hardly well known, so it got delegated > > to > > "2nd page" > > > > > > to get a PKI you run those commands: > > > > source certgen/lib.sh > > > > x509KeyGen ca > > > > x509KeyGen server > > > > x509SelfSign ca > > > > x509CertSign --CA ca server > > > > > > > > The private key file will be printed by use of: > > > > x509Key server > > > > to get certificate file name you run: > > > > x509Cert server > > > > > > In testing situations I have been in, intermediate CAs, revocation, the > > > like are needed. > > > > it allows you to create arbitrarily complex CA structure, this is just the > > simplest example; there is also support for generating client > > certificates, > > OCSP reponder certificates, subject alternative names, etc. > > > > to get an intermediate you have to run the following commands: > > x509KeyGen subca > > x509CertSign --CA ca -t CA subca" > > > > the you can use 'subca' instead of 'ca' for signing the server cert: > > x509CertSign --CA subca server > > > > (the -t of 'webserver' is simply the default) > > > > revocation is not implemented yet, but as the tool keeps all the > > information > > about CA's signed certificates (it does use internally the `openssl ca` > > tool), > > adding it shouldn't be too hard... (and you can always do it manually) > > > > > Plus getting more interest in 802.1AR certs with vendors (can't get > > > certs to test out my product design). > > > > that I'm not familiar with > > > > > > (easy switches are also provided to get DER files or PKCS#12 files > > > > instead > > > > > > of the default PEM format) > > > > > > I will be interested to see how you handle DER, as I found cases where > > > the command line was broken. Read my caveat section. In some cases you > > > have to make the file in PEM then convert to DER. Plus there is no DER > > > way to handle cert chains as was discussed here a year ago. So I will > > > be interested to see how you handle cert chains non-PEM. > > > > The scripts internally keep everything as PEM files; DER, PKCS#12, etc. > > are > > for export only. > > > > If you want cert chains you have to create them manually. As I started to > > work > > on this script for the CA cross-signing, the built-in assumption was that > > there is no One True Cert Chain?. So it considers all CAs as stand-alone. > > If > > you want a cert chain you have to assemble it yourself. > > > > > > to get ecdsa certificate, you just need to change one of the above > > > > lines > > > > > > with x509KeyGen to have `-t ecdsa` specified. Want RSA-PSS > > > > certificate? do > > > > > > `-t rsa-pss`. > > > > > > > > See runtest.sh for other examples. > > > > > > I will take a look. > > > > Limited time offer! Call now and get Ed25519 support completely free! ;) > > https://github.com/redhat-qe-security/certgen/commit/ > > 4b71e0a7d77929d944cc20f16f2ccf9514d6d94d > > > > > > It is compatible with all versions of openssl since RHEL-4 (so 0.9.7), > > > > if > > > > > > a > > > > given feature is supported in that version of openssl. > > > > > > > > (while ed25519 support is not yet there, it will be in few weeks, I > > > > was > > > > running just basic tests of it, without involving full PKI) > > > > > > Nice. See https://github.com/rgmhtt/draft-moskowitz-ecdsa-pki > > > > > > I am right now adding an algorithm variable to support ed488. > > > > > > This actually does not work right with 1.1.1-pre9, as PR 6901 did not > > > make that build, so I have to do my command and .cnf patches still. > > > > yes, there are quite a few warts you need to worry about when working with > > different versions of OpenSSL, then there is the problem of updating it as > > recommended key sizes or hashes change... > > > > reading that draft feels like reading a heavily commented script ? not a > > criticism, rather observation about the problem at hand > > > > -- > > 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-- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 sam.habiel at gmail.com Wed Sep 5 14:04:32 2018 From: sam.habiel at gmail.com (Sam Habiel) Date: Wed, 5 Sep 2018 10:04:32 -0400 Subject: [openssl-users] Problems with man page code example at EVP_EncryptInit Message-ID: First time poster. I hope I am writing to the right place. Example for "General encryption and decryption function example using FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot of time trying to figure out what I did wrong for a while... 1. ctx is already a pointer; it does not need to be indirected to get the pointer. EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); should say: EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); 2. ciphertext length is not used to update write position: if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen)) and if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen)) should say (what worked for me): if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen, inbuf, inlen)) and if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen)) It would be nice if there is a complete example that compiles and has a main() to run it. --Sam From sam.habiel at gmail.com Wed Sep 5 14:18:06 2018 From: sam.habiel at gmail.com (Sam Habiel) Date: Wed, 5 Sep 2018 10:18:06 -0400 Subject: [openssl-users] Problems with man page code example at EVP_EncryptInit In-Reply-To: References: Message-ID: I had to double check something--I was wrong about something--&outlen is not incremented inside of openssl--so you have to keep another variable to which you add outlen and use that to set the read/write pointer in outbuf. --Sam On Wed, Sep 5, 2018 at 10:04 AM Sam Habiel wrote: > > First time poster. I hope I am writing to the right place. > > Example for "General encryption and decryption function example using > FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot > of time trying to figure out what I did wrong for a while... > > 1. ctx is already a pointer; it does not need to be indirected to get > the pointer. > > EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, > do_encrypt); > > should say: > > EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); > > 2. ciphertext length is not used to update write position: > > if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen)) > and > > if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen)) > > should say (what worked for me): > > if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen, > inbuf, inlen)) > > and > if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen)) > > It would be nice if there is a complete example that compiles and has > a main() to run it. > > --Sam From tshort at akamai.com Wed Sep 5 14:45:42 2018 From: tshort at akamai.com (Short, Todd) Date: Wed, 5 Sep 2018 14:45:42 +0000 Subject: [openssl-users] Problems with man page code example at EVP_EncryptInit In-Reply-To: References: Message-ID: PRs on GitHub to fix documentation are always welcome. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 5, 2018, at 10:18 AM, Sam Habiel > wrote: I had to double check something--I was wrong about something--&outlen is not incremented inside of openssl--so you have to keep another variable to which you add outlen and use that to set the read/write pointer in outbuf. --Sam On Wed, Sep 5, 2018 at 10:04 AM Sam Habiel > wrote: First time poster. I hope I am writing to the right place. Example for "General encryption and decryption function example using FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot of time trying to figure out what I did wrong for a while... 1. ctx is already a pointer; it does not need to be indirected to get the pointer. EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); should say: EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); 2. ciphertext length is not used to update write position: if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen)) and if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen)) should say (what worked for me): if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen, inbuf, inlen)) and if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen)) It would be nice if there is a complete example that compiles and has a main() to run it. --Sam -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.habiel at gmail.com Wed Sep 5 14:49:53 2018 From: sam.habiel at gmail.com (Sam Habiel) Date: Wed, 5 Sep 2018 10:49:53 -0400 Subject: [openssl-users] Problems with man page code example at EVP_EncryptInit In-Reply-To: References: Message-ID: Todd, What is the correct repo on Github? --Sam On Wed, Sep 5, 2018 at 10:46 AM Short, Todd via openssl-users wrote: > > PRs on GitHub to fix documentation are always welcome. > -- > -Todd Short > // tshort at akamai.com > // "One if by land, two if by sea, three if by the Internet." > > On Sep 5, 2018, at 10:18 AM, Sam Habiel wrote: > > I had to double check something--I was wrong about something--&outlen > is not incremented inside of openssl--so you have to keep another > variable to which you add outlen and use that to set the read/write > pointer in outbuf. > > --Sam > On Wed, Sep 5, 2018 at 10:04 AM Sam Habiel wrote: > > > First time poster. I hope I am writing to the right place. > > Example for "General encryption and decryption function example using > FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot > of time trying to figure out what I did wrong for a while... > > 1. ctx is already a pointer; it does not need to be indirected to get > the pointer. > > EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, > do_encrypt); > > should say: > > EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); > > 2. ciphertext length is not used to update write position: > > if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen)) > and > > if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen)) > > should say (what worked for me): > > if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen, > inbuf, inlen)) > > and > if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen)) > > It would be nice if there is a complete example that compiles and has > a main() to run it. > > --Sam > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From sam.habiel at gmail.com Wed Sep 5 14:54:07 2018 From: sam.habiel at gmail.com (Sam Habiel) Date: Wed, 5 Sep 2018 10:54:07 -0400 Subject: [openssl-users] Problems with man page code example at EVP_EncryptInit In-Reply-To: References: Message-ID: Never mind. Easy google search away: https://github.com/openssl/openssl On Wed, Sep 5, 2018 at 10:49 AM Sam Habiel wrote: > > Todd, > > What is the correct repo on Github? > > --Sam > On Wed, Sep 5, 2018 at 10:46 AM Short, Todd via openssl-users > wrote: > > > > PRs on GitHub to fix documentation are always welcome. > > -- > > -Todd Short > > // tshort at akamai.com > > // "One if by land, two if by sea, three if by the Internet." > > > > On Sep 5, 2018, at 10:18 AM, Sam Habiel wrote: > > > > I had to double check something--I was wrong about something--&outlen > > is not incremented inside of openssl--so you have to keep another > > variable to which you add outlen and use that to set the read/write > > pointer in outbuf. > > > > --Sam > > On Wed, Sep 5, 2018 at 10:04 AM Sam Habiel wrote: > > > > > > First time poster. I hope I am writing to the right place. > > > > Example for "General encryption and decryption function example using > > FILE I/O and AES128 with a 128-bit key" has two errors. I spent a lot > > of time trying to figure out what I did wrong for a while... > > > > 1. ctx is already a pointer; it does not need to be indirected to get > > the pointer. > > > > EVP_CipherInit_ex(&ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, > > do_encrypt); > > > > should say: > > > > EVP_CipherInit_ex(ctx, EVP_aes_128_cbc(), NULL, NULL, NULL, do_encrypt); > > > > 2. ciphertext length is not used to update write position: > > > > if(!EVP_CipherUpdate(ctx, outbuf, &outlen, inbuf, inlen)) > > and > > > > if(!EVP_CipherFinal_ex(ctx, outbuf, &outlen)) > > > > should say (what worked for me): > > > > if(!EVP_CipherUpdate(ctx, outbuf + outlen, &outlen, > > inbuf, inlen)) > > > > and > > if(!EVP_CipherFinal_ex(ctx, outbuf + outlen, &outlen)) > > > > It would be nice if there is a complete example that compiles and has > > a main() to run it. > > > > --Sam > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From openssl at jordan.maileater.net Wed Sep 5 15:19:26 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Wed, 5 Sep 2018 08:19:26 -0700 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> Message-ID: <3bd9c549-e89e-9fa7-f80b-1b0bc1b31248@jordan.maileater.net> Any thoughts here? On 8/31/2018 6:14 PM, Jordan Brown wrote: > > We're trying to nail down error reporting for TLS version mismatches, > and we're seeing a couple of puzzling behaviors. > > First, and most puzzling... assume these two command lines: > > $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key > -no_tls1 > > $ openssl s_client -connect zel.us.oracle.com:4433 -tls1 > > That is, I have a server that won't accept TLSv1.0, and a client that > will only accept TLSv1.0. > > On the server side I see > > 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported > protocol:s23_srvr.c:605: > > which makes perfect sense.? On the client side I see > > 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl > handshake failure:s3_pkt.c:659: > > which isn't as good, but is still sort of sensible.? But when I look > at the packets exchanged, I see that the client sends a Client Hello, > and the server responds with an ACK and then a FIN-ACK, with no data.? > It just hangs up the phone.? This seems to violate RFC 5246 section > E.1:? "If server supports (or is willing to use) only versions greater > than client_version, it MUST send a "protocol_version" alert message > and close the connection.".? Where's my protocol version alert? > > Of course my real case does not involve the sample client and server - > it involves my own clients and servers - but I seem to see the same > behavior with several servers (notably including the Apache httpd). > > This looks like it's the same as > https://rt.openssl.org/Ticket/Display.html?id=2777 .? I'm using > 1.0.2o.? (But I don't see anything relevant-looking in the 1.0.2p > changes.)? I've seen similar behavior from 1.0.2o-fips. > > Am I missing something here, or is this a server-side bug? > > > And then, on the client side... > > SSL_connect returns zero.? Exactly how that failure differs from a > less-than-zero error is not clear, but OK.? The docs say to call > SSL_get_error().? SSL_get_error() returns 5, SSL_ERROR_SYSCALL.? (That > seems a little strange, since I don't think there's any system call > errors here.)? The docs say to consult the error queue and errno.? > ERR_peek_last_error( ) returns zero.? Errno is zero.? It failed, but > nobody will tell me why. > > Am I missing something here, or is this a client library bug? > > > (I have not tracked down exactly how the s_client tool ends up with a > message.? It seems to use a more intricate mechanism than SSL_connect.) > > > -- > Jordan Brown, Oracle Solaris > > -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From alessandro.gherardi at yahoo.com Thu Sep 6 02:18:38 2018 From: alessandro.gherardi at yahoo.com (Alessandro Gherardi) Date: Thu, 6 Sep 2018 02:18:38 +0000 (UTC) Subject: [openssl-users] FIPS mode on Windows References: <905508722.260236.1536200318972.ref@mail.yahoo.com> Message-ID: <905508722.260236.1536200318972@mail.yahoo.com> I have a question: On Windows, should OpenSSL FIPS automatically enable FIPS mode (FIPS_mode_set(1)) if the FIPS registry entry?HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled is set to 1? This is to emulate the Linux behavior - if I understand correctly, if Linux is configured for FIPS mode, OpenSSL automatically enables FIPS mode. Thanks in advance,Alessandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerhard.jahn at atos.net Fri Sep 7 08:16:52 2018 From: gerhard.jahn at atos.net (Jahn, Gerhard) Date: Fri, 7 Sep 2018 08:16:52 +0000 Subject: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK Message-ID: Hi, We are using OpenSSl 1.0.2n in our server running on LINUX. We call SSL_connect() on async socket (after TCP connect completion) to establish a secure connection. According to DOC SSL_get_error(() has to be called if SSL_connect() returns <=0 We do not understand what to do if SSL_get_error(() returns SSL_ERROR_SYSCALL and errno is EWOULDBLOCK If SSL_get_error returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to do... (we set the socket descriptor either in the readfds or writefds and call select to wait until the socket becomes readable or writeable (or times-out) But when EWOULDBLOCK is indicated, we do not know whether to wait for readable/writeable...... (setting both might be an idea but could easily lead to a live-loop as we suppose that the handshake either waits for a read or for a write but not both... Any ideas? Thanks Mit freundlichen Gr??en/Best regards, ____________ Gerhard Jahn Identity and Access Management Phone: +49 (211) 399-33276 Phone: +49 (211) 399-22891 Email: gerhard.jahn at atos.net Otto-Hahn-Ring 6 81739 M?nchen, Germany de.atos.net [cid:231545806 at 16122011-2476] Atos Information Technology GmbH; Gesch?ftsf?hrung: Winfried Holz, Udo Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: M?nchen; Registergericht: M?nchen, HRB 235509. Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche Informationen, die ausschlie?lich f?r den Empf?nger bestimmt sind. Sollten Sie diese E-Mail irrt?mlich erhalten haben, benachrichtigen Sie bitte unverz?glich den Absender per Antwort-Mail und l?schen Sie diese E-Mail nebst Anlagen von Ihrem System. Da die Integrit?t innerhalb des Internets nicht zu gew?hrleisten ist, kann die Atos Gruppe f?r die Inhalte der Nachricht kein Haftung ?bernehmen. Obwohl der Absender anstrebt ein virusfreies Computernetzwerk sicherzustellen, kann der Absender nicht gew?hrleisten, dass diese E-Mail virusfrei ist und wird damit keine Haftung bei Sch?den auf Grund einer Virus?bermittlung ?bernehmen. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Atos group liability cannot be triggered for the message content. Although the sender endeavors to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Picture (Device Independent Bitmap) 1.jpg Type: image/jpeg Size: 2148 bytes Desc: Picture (Device Independent Bitmap) 1.jpg URL: From matt at openssl.org Fri Sep 7 09:24:28 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 7 Sep 2018 10:24:28 +0100 Subject: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK In-Reply-To: References: Message-ID: <2b2ef05f-1ffd-ba64-0ac8-d3a9d3ab0ecd@openssl.org> On 07/09/18 09:16, Jahn, Gerhard wrote: > Hi, > ? > We are using OpenSSl 1.0.2n in our server running on LINUX. > We call SSL_connect() on async socket (after TCP connect completion) to > establish a secure connection. > According to DOC SSL_get_error(() has to be called if SSL_connect() > returns <=0 > ? > We do not understand what to do if SSL_get_error(() returns > SSL_ERROR_SYSCALLand errno is EWOULDBLOCK > If SSL_get_error returns SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it > pretty clear what to do? > (we set the socket descriptor either in the readfds or writefds and call > select to wait until the socket becomes readable or writeable (or times-out) > But when EWOULDBLOCK is indicated, we do not know whether to wait for > readable/writeable?? > (setting both might be an idea but could easily lead to a live-loop as > we suppose that the handshake either waits for a read or for a write but > not both? That's quite a surprising result. Possibly intervening code somewhere between the sys call and where you check errno has changed its value? The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. Have you checked the openssl error stack for any reported issues? Matt > ? > Any ideas? > Thanks > ? > Mit freundlichen Gr??en/Best regards, > *____________ > **Gerhard Jahn* > > Identity and Access Management > ? > Phone:? +49 (211) 399-33276 > Phone:? +49 (211) 399-22891 > Email: _gerhard.jahn at atos.net_ > Otto-Hahn-Ring 6 > 81739 M?nchen, Germany > de.atos.net > > Atos Information Technology GmbH; Gesch?ftsf?hrung: Winfried Holz, Udo > Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: > M?nchen; Registergericht: M?nchen, HRB 235509. > > Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche > Informationen, die ausschlie?lich f?r den Empf?nger bestimmt sind. > Sollten Sie diese E-Mail irrt?mlich erhalten haben, benachrichtigen Sie > bitte unverz?glich den Absender per Antwort-Mail und l?schen Sie diese > E-Mail nebst Anlagen von Ihrem System. Da die Integrit?t innerhalb des > Internets nicht zu gew?hrleisten ist, kann die Atos Gruppe f?r die > Inhalteder Nachricht kein Haftung ?bernehmen. Obwohl der Absender > anstrebt ein virusfreies Computernetzwerk sicherzustellen, kann der > Absender nicht gew?hrleisten, dass diese E-Mail virusfrei ist und wird > damit keine Haftung bei Sch?den auf Grund einer Virus?bermittlung > ?bernehmen. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > ? > ? > ? > ? > > From jisoza at gmail.com Fri Sep 7 07:00:10 2018 From: jisoza at gmail.com (Juan Isoza) Date: Fri, 7 Sep 2018 09:00:10 +0200 Subject: [openssl-users] Using Windows system certficate store for server authentication Message-ID: It's a good idea using openssl under windows (with new openssl 1.1.1, we will be able to use TLS 1.3 under Windows, from 7/2008 to 10/2016) instead internal windows crypto.. But, by example, curl build for windows with openssl need a --insecure parameters or a custom root certificate file. What about using the Windows certificate store ? I found info at https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store/15451831 There is some code in openssl (in engines\e_capi.c) which deal with Windows certificate store, but this seem not solve the problem -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Fri Sep 7 12:59:00 2018 From: hkario at redhat.com (Hubert Kario) Date: Fri, 07 Sep 2018 14:59:00 +0200 Subject: [openssl-users] FIPS mode on Windows In-Reply-To: <905508722.260236.1536200318972@mail.yahoo.com> References: <905508722.260236.1536200318972.ref@mail.yahoo.com> <905508722.260236.1536200318972@mail.yahoo.com> Message-ID: <26054975.tAFZWagaeR@pintsize.usersys.redhat.com> On Thursday, 6 September 2018 04:18:38 CEST Alessandro Gherardi via openssl- users wrote: > I have a question: On Windows, should OpenSSL FIPS automatically enable FIPS > mode (FIPS_mode_set(1)) if the FIPS registry > entry HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\FipsAlgorithm > Policy\Enabled is set to 1? > > This is to emulate the Linux behavior - if I understand correctly, if Linux > is configured for FIPS mode, OpenSSL automatically enables FIPS mode. > Thanks in advance,Alessandro putting Linux kernel to fips mode (adding `fips=1` to kernel command line) not necessarily puts the whole system (and thus OpenSSL) into fips mode please check the module's Security Policy on the NIST Cryptographic Module Validation Program website to find the authoritative instructions on how to ensure FIPS mandated behaviour of the module -- 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 alessandro.gherardi at yahoo.com Fri Sep 7 14:18:48 2018 From: alessandro.gherardi at yahoo.com (Alessandro Gherardi) Date: Fri, 7 Sep 2018 14:18:48 +0000 (UTC) Subject: [openssl-users] FIPS mode on Windows In-Reply-To: <26054975.tAFZWagaeR@pintsize.usersys.redhat.com> References: <905508722.260236.1536200318972.ref@mail.yahoo.com> <905508722.260236.1536200318972@mail.yahoo.com> <26054975.tAFZWagaeR@pintsize.usersys.redhat.com> Message-ID: <871352764.1102405.1536329928228@mail.yahoo.com> Thank you for your reply. Looking at the OpenSSL FIPS Security Policy?https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-validation-program/documents/security-policies/140sp1747.pdf, I see the following statement: "The?Module?requires?an?initialization?sequence?(see?IG?9.5):?the?calling?application?invokes FIPS_mode_set(),?which?returns?a??1??for?success?and??0??for?failure.??If?FIPS_mode_set() fails?then?all?cryptographic?services?fail?from?then?on.??The?application?can?test?to?see?if?FIPS? mode?has?been?successfully?performed." Therefore, for OpenSSL to switch to FIPS mode, it is required that the application call FIPS_mode_set(1). Can you please confirm that my understanding is now correct? -------------- next part -------------- An HTML attachment was scrubbed... URL: From hkario at redhat.com Fri Sep 7 16:42:24 2018 From: hkario at redhat.com (Hubert Kario) Date: Fri, 07 Sep 2018 18:42:24 +0200 Subject: [openssl-users] FIPS mode on Windows In-Reply-To: <871352764.1102405.1536329928228@mail.yahoo.com> References: <905508722.260236.1536200318972.ref@mail.yahoo.com> <26054975.tAFZWagaeR@pintsize.usersys.redhat.com> <871352764.1102405.1536329928228@mail.yahoo.com> Message-ID: <4772032.K47y1oBqfg@pintsize.usersys.redhat.com> On Friday, 7 September 2018 16:18:48 CEST Alessandro Gherardi wrote: > Thank you for your reply. > Looking at the OpenSSL FIPS Security > Policy https://csrc.nist.gov/CSRC/media/projects/cryptographic-module-valid > ation-program/documents/security-policies/140sp1747.pdf, I see the following > statement: > "The Module requires an initialization sequence (see IG 9.5): the calling a > pplication invokes > FIPS_mode_set(), which returns a ?1? for success and ?0? for failure. If F > IPS_mode_set() > fails then all cryptographic services fail from then on. The application c > an test to see if FIPS mode has been successfully performed." Therefore, > for OpenSSL to switch to FIPS mode, it is required that the application > call FIPS_mode_set(1). Can you please confirm that my understanding is now > correct? If you are using that specific openssl module, then yes, you have to manually call FIPS_mode_set() from application code. But please note that's not the only openssl FIPS module in existence, and other modules may behave differently (I know that some not only _may_ , but _will_ behave differently). Sorry for being vague, but you have not provided any information what versions you are actually running, on what versions of OS, how you acquired them, etc. All of which has quite significant impact on FIPS-worthiness of any particular module. Also, to make matters worse (more confusing), software package version is not the same thing as FIPS module version. -- 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 alessandro.gherardi at yahoo.com Fri Sep 7 18:18:38 2018 From: alessandro.gherardi at yahoo.com (Alessandro Gherardi) Date: Fri, 7 Sep 2018 18:18:38 +0000 (UTC) Subject: [openssl-users] FIPS mode on Windows In-Reply-To: <4772032.K47y1oBqfg@pintsize.usersys.redhat.com> References: <905508722.260236.1536200318972.ref@mail.yahoo.com> <26054975.tAFZWagaeR@pintsize.usersys.redhat.com> <871352764.1102405.1536329928228@mail.yahoo.com> <4772032.K47y1oBqfg@pintsize.usersys.redhat.com> Message-ID: <414803129.265803.1536344318254@mail.yahoo.com> I'm running Windows 10. I downloaded the FIPS module sources from?https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz?and the OpenSSL sources from?https://www.openssl.org/source/openssl-1.0.2p.tar.gz?. I built both FIPS module and OpenSSL (following the instructions at?https://www.openssl.org/docs/fips/UserGuide-2.0.pdf?to make sure OpenSSL uses the FIPS module)?using Visual Studio. >?But please note that's not the only openssl FIPS module in existence I wasn't aware that other OpenSSL FIPS modules exist. Are those modules also opensource? Are they all FIPS-certified? Do you have a recommendation for which one is the "best" to use? Thanks again,Alessandro -------------- next part -------------- An HTML attachment was scrubbed... URL: From d3ck0r at gmail.com Sat Sep 8 07:29:46 2018 From: d3ck0r at gmail.com (J Decker) Date: Sat, 8 Sep 2018 00:29:46 -0700 Subject: [openssl-users] Using Windows system certficate store for server authentication In-Reply-To: References: Message-ID: On Fri, Sep 7, 2018 at 11:55 PM Juan Isoza wrote: > > It's a good idea using openssl under windows (with new openssl 1.1.1, we > will be able to use TLS 1.3 under Windows, from 7/2008 to 10/2016) instead > internal windows crypto.. > > But, by example, curl build for windows with openssl need a --insecure > parameters or a custom root certificate file. > > What about using the Windows certificate store ? > Loading the windows cert store isn't very hard.... https://github.com/d3x0r/SACK/blob/master/src/netlib/ssl_layer.c#L1037 But checking; I Guess that's just the code from that stack overflow. basically verbatim. > > I found info at > > https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store/15451831 > https://stackoverflow.com/questions/9507184/can-openssl-on-windows-use-the-system-certificate-store/15451831 > > > There is some code in openssl (in engines\e_capi.c) which deal with > Windows certificate store, but this seem not solve the problem > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Sat Sep 8 13:44:50 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 8 Sep 2018 13:44:50 +0000 Subject: [openssl-users] Using Windows system certficate store for server authentication In-Reply-To: References: Message-ID: <7BF6A766-686A-4902-BEA1-635C2E76BC07@akamai.com> OpenSSL does not use *any* certificate store, on any platform, it is up to the applications to do what they need. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sat Sep 8 18:00:24 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sat, 8 Sep 2018 14:00:24 -0400 Subject: [openssl-users] Using Windows system certficate store for server authentication In-Reply-To: <7BF6A766-686A-4902-BEA1-635C2E76BC07@akamai.com> References: <7BF6A766-686A-4902-BEA1-635C2E76BC07@akamai.com> Message-ID: <20180908180024.GB97812@straasha.imrryr.org> On Sat, Sep 08, 2018 at 01:44:50PM +0000, Salz, Rich via openssl-users wrote: > OpenSSL does not use *any* certificate store, on any platform, it is up to the applications to do what they need. More precisely, OpenSSL does not bundle any trusted certificates with the upstream source. OpenSSL does use $OPENSSLDIR/cert.pem and $OPENSSL/certs/ as the default CAfile and CApath respectively via the: SSL_CTX_set_default_verify_paths() function. These can also be specified via the SSL_CERT_FILE and SSL_CERT_DIR environment variables. Applications can specify additional or alternative CAfile or CApath locations. IIRC the upstream OpenSSL code does not include an interface to the Windows Active Directory certificate store. This may be available from third parties. -- Viktor. From gerhard.jahn at atos.net Mon Sep 10 08:05:24 2018 From: gerhard.jahn at atos.net (Jahn, Gerhard) Date: Mon, 10 Sep 2018 08:05:24 +0000 Subject: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK In-Reply-To: <2b2ef05f-1ffd-ba64-0ac8-d3a9d3ab0ecd@openssl.org> References: <2b2ef05f-1ffd-ba64-0ac8-d3a9d3ab0ecd@openssl.org> Message-ID: Ad: The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. This somehow contradicts the description of returncode <0 on SSL_connect which says that <0 The TLS/SSL handshake was not successful, because a fatal error occurred either at the protocol level or a connection failure occurred. The shutdown was not clean. It can also occur of action is need to continue the operation for non-blocking BIOs. Call SSL_get_error() with the return value ret to find out the reason. If SSL_ERROR_SYSCAL would always mean connection failure, why then any action to continue the operation..... So we're getting SSL_connect() = -1 and we call SSL_get_error() returning 5 as advised Then as SSL_get_error() says SSL_ERROR_SYSCALL Some non-recoverable I/O error occurred. The OpenSSL error queue may contain more information on the error. For socket I/O on Unix systems, consult errno for details We call ERR_print_errors_fp(stderr) which gives no output. We inspect errno which indicates EWOULDBLOCK or EAGAIN This seems to happen rarely (once per hundreds of SSL_Connect) and as we're currently treating any SSL_ERROR_SYSCALL as bogus and terminate the connection (SSL_shutdown+Socketclose) As our server runs "forever" and has high load we see a lot of such "SSL_Connect errors in our Logs" Additionally it seems to happen more frequently when connecting to a remote host rather than when connecting to a server co-located.... I have experienced the same behavior with SSL_read/SSL_write where we also get SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK But in these cases we "know" what to do (wait for readable when it appears in SSL_read and wait for writeable when in SSL_write) Therefore we have the feeling that same blocking happens during SSL_connect........? GJ -----Original Message----- From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Matt Caswell Sent: Friday, September 07, 2018 11:24 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK On 07/09/18 09:16, Jahn, Gerhard wrote: > Hi, > > We are using OpenSSl 1.0.2n in our server running on LINUX. > We call SSL_connect() on async socket (after TCP connect completion) > to establish a secure connection. > According to DOC SSL_get_error(() has to be called if SSL_connect() > returns <=0 > > We do not understand what to do if SSL_get_error(() returns > SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns > SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to > do... (we set the socket descriptor either in the readfds or writefds > and call select to wait until the socket becomes readable or writeable > (or times-out) But when EWOULDBLOCK is indicated, we do not know > whether to wait for readable/writeable...... (setting both might be an > idea but could easily lead to a live-loop as we suppose that the > handshake either waits for a read or for a write but not both... That's quite a surprising result. Possibly intervening code somewhere between the sys call and where you check errno has changed its value? The "correct" answer is that if you get SSL_ERROR_SYSCALL then the connection has failed and you shouldn't use that connection any more. Have you checked the openssl error stack for any reported issues? Matt > > Any ideas? > Thanks > > Mit freundlichen Gr??en/Best regards, > *____________ > **Gerhard Jahn* > > Identity and Access Management > > Phone: +49 (211) 399-33276 > Phone: +49 (211) 399-22891 > Email: _gerhard.jahn at atos.net_ > Otto-Hahn-Ring 6 > 81739 M?nchen, Germany > de.atos.net > > Atos Information Technology GmbH; Gesch?ftsf?hrung: Winfried Holz, Udo > Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: > M?nchen; Registergericht: M?nchen, HRB 235509. > > Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche > Informationen, die ausschlie?lich f?r den Empf?nger bestimmt sind. > Sollten Sie diese E-Mail irrt?mlich erhalten haben, benachrichtigen > Sie bitte unverz?glich den Absender per Antwort-Mail und l?schen Sie > diese E-Mail nebst Anlagen von Ihrem System. Da die Integrit?t > innerhalb des Internets nicht zu gew?hrleisten ist, kann die Atos > Gruppe f?r die Inhalteder Nachricht kein Haftung ?bernehmen. Obwohl > der Absender anstrebt ein virusfreies Computernetzwerk > sicherzustellen, kann der Absender nicht gew?hrleisten, dass diese > E-Mail virusfrei ist und wird damit keine Haftung bei Sch?den auf > Grund einer Virus?bermittlung ?bernehmen. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive > this e-mail in error, please notify the sender immediately and destroy > it. As its integrity cannot be secured on the Internet, the Atos group > liability cannot be triggered for the message content. Although the > sender endeavors to maintain a computer virus-free network, the sender > does not warrant that this transmission is virus-free and will not be > liable for any damages resulting from any virus transmitted. > > > > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 10 08:43:50 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 10 Sep 2018 09:43:50 +0100 Subject: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and errno == EWOULDBLOCK In-Reply-To: References: <2b2ef05f-1ffd-ba64-0ac8-d3a9d3ab0ecd@openssl.org> Message-ID: <944ea005-0682-dcf9-2b2f-71cec88f31e8@openssl.org> On 10/09/18 09:05, Jahn, Gerhard wrote: > Ad:? The "correct" answer is that if you get SSL_ERROR_SYSCALL then the > connection has failed and you shouldn't use that connection any more. > ? > This somehow contradicts the description of returncode <0 on SSL_connect > which says that > ? > <0 > ? > ??? The TLS/SSL handshake was not successful, because a fatal error > occurred either at the protocol level or a connection failure occurred. > The shutdown was not clean. It can also occur of *_action is need to > continue the operation for non-blocking BIOs_*. > Call SSL_get_error() with the return value ret to find out the reason. I don't see any contradiction in the OpenSSL docs. All this says is that if you get <=0 return code then you need to call SSL_get_error() to find out what to do. If you get SSL_ERROR_SYSCALL then a *non-recoverable* I/O error has occurred. So, in my mind, the OpenSSL documentation is clear - you've got a non-recoverable error and therefore you shouldn't continue. If there is a contradiction it is between the OpenSSL docs which tell you you have a non-recoverable error and the value of errno - which suggests a recoverable error. This is probably down to one of two things: 1) Something has caused the value of errno to change between when the non-recoverable error occurred and when you're checking it or 2) A bug in OpenSSL is incorrectly interpreting a recoverable error as a non-recoverable one. Matt > ? > If SSL_ERROR_SYSCAL would always mean connection failure, why then any > action to continue the operation?.. > So we?re getting SSL_connect() = -1 and we call SSL_get_error() > returning 5? as advised > Then as SSL_get_error() says > ? > SSL_ERROR_SYSCALL > Some non-recoverable I/O error occurred. The OpenSSL error queue may > contain more information on the error. > For socket I/O on Unix systems, consult *errno* for details > We call? ERR_print_errors_fp(stderr)which gives no output. > We inspect errno which indicates EWOULDBLOCK or EAGAIN > This seems to happen rarely (once per hundreds of SSL_Connect) and as > we?re currently treating any SSL_ERROR_SYSCALL > as bogus and terminate the connection (SSL_shutdown+Socketclose) > As our server runs ?forever? and has high load we see a lot of such > ?SSL_Connect errors in our Logs? > Additionally it seems to happen more frequently when connecting to a > remote host rather than when connecting to a server co-located?. > I have experienced the same behavior with SSL_read/SSL_write where we > also get SSL_ERROR_SYSCALL and find that errno is EWOULDBLOCK > But in these cases we ?know? what to do (wait for readable when it > appears in SSL_read and wait for writeable when in SSL_write) > Therefore we have the feeling that same blocking happens during > SSL_connect??..? > GJ > ? > -----Original Message----- > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Friday, September 07, 2018 11:24 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] SSL_connect returns SSL_ERROR_SYSCALL and > errno == EWOULDBLOCK > ? > ? > ? > On 07/09/18 09:16, Jahn, Gerhard wrote: >> Hi, >> ? >> We are using OpenSSl 1.0.2n in our server running on LINUX. >> We call SSL_connect() on async socket (after TCP connect completion) >> to establish a secure connection. >> According to DOC SSL_get_error(() has to be called if SSL_connect() >> returns <=0 >> ? >> We do not understand what to do if SSL_get_error(() returns >> SSL_ERROR_SYSCALLand errno is EWOULDBLOCK If SSL_get_error returns >> SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE it pretty clear what to >> do? (we set the socket descriptor either in the readfds or writefds >> and call select to wait until the socket becomes readable or writeable >> (or times-out) But when EWOULDBLOCK is indicated, we do not know >> whether to wait for readable/writeable?? (setting both might be an >> idea but could easily lead to a live-loop as we suppose that the >> handshake either waits for a read or for a write but not both? > ? > That's quite a surprising result. Possibly intervening code somewhere > between the sys call and where you check errno has changed its value? > ? > The "correct" answer is that if you get SSL_ERROR_SYSCALL then the > connection has failed and you shouldn't use that connection any more. > Have you checked the openssl error stack for any reported issues? > ? > Matt > ? > ? > ? >> ? >> Any ideas? >> Thanks >> ? >> Mit freundlichen Gr??en/Best regards, >> *____________ >> **Gerhard Jahn* >> >> Identity and Access Management >> ? >> Phone:? +49 (211) 399-33276 >> Phone:? +49 (211) 399-22891 >> Email: _gerhard.jahn at atos.net_ >> Otto-Hahn-Ring 6 >> 81739 M?nchen, Germany >> de.atos.net >> >> Atos Information Technology GmbH; Gesch?ftsf?hrung: Winfried Holz, Udo >> Littke; Vorsitzender des Aufsichtsrats: N.N.; Sitz der Gesellschaft: >> M?nchen; Registergericht: M?nchen, HRB 235509. >> >> Diese E-Mail und etwaige Anlagen enthalten firmenvertrauliche >> Informationen, die ausschlie?lich f?r den Empf?nger bestimmt sind. >> Sollten Sie diese E-Mail irrt?mlich erhalten haben, benachrichtigen >> Sie bitte unverz?glich den Absender per Antwort-Mail und l?schen Sie >> diese E-Mail nebst Anlagen von Ihrem System. Da die Integrit?t >> innerhalb des Internets nicht zu gew?hrleisten ist, kann die Atos >> Gruppe f?r die Inhalteder Nachricht kein Haftung ?bernehmen. Obwohl >> der Absender anstrebt ein virusfreies Computernetzwerk >> sicherzustellen, kann der Absender nicht gew?hrleisten, dass diese >> E-Mail virusfrei ist und wird damit keine Haftung bei Sch?den auf >> Grund einer Virus?bermittlung ?bernehmen. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive >> this e-mail in error, please notify the sender immediately and destroy >> it. As its integrity cannot be secured on the Internet, the Atos group >> liability cannot be triggered for the message content. Although the >> sender endeavors to maintain a computer virus-free network, the sender >> does not warrant that this transmission is virus-free and will not be >> liable for any damages resulting from any virus transmitted. >> ? >> ? >> ? >> ? >> >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > ? > > From hkario at redhat.com Mon Sep 10 11:26:25 2018 From: hkario at redhat.com (Hubert Kario) Date: Mon, 10 Sep 2018 13:26:25 +0200 Subject: [openssl-users] FIPS mode on Windows In-Reply-To: <414803129.265803.1536344318254@mail.yahoo.com> References: <905508722.260236.1536200318972.ref@mail.yahoo.com> <4772032.K47y1oBqfg@pintsize.usersys.redhat.com> <414803129.265803.1536344318254@mail.yahoo.com> Message-ID: <3985062.WvmH9SnDyy@pintsize.usersys.redhat.com> On Friday, 7 September 2018 20:18:38 CEST Alessandro Gherardi wrote: > I'm running Windows 10. > I downloaded the FIPS module sources > from https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz and the > OpenSSL sources from https://www.openssl.org/source/openssl-1.0.2p.tar.gz . > I built both FIPS module and OpenSSL (following the instructions > at https://www.openssl.org/docs/fips/UserGuide-2.0.pdf to make sure OpenSSL > uses the FIPS module) using Visual Studio. then that does sound like it does match the policy > > But please note that's not the only openssl FIPS module in existence > > I wasn't aware that other OpenSSL FIPS modules exist. Are those modules also > opensource? Are they all FIPS-certified? Do you have a recommendation for > which one is the "best" to use? the one we use in RHEL packages is different, and it is, of course, open source I wouldn't say that there is a "best" one, if it does match your requirements, it should be good enough. -- 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 jb-openssl at wisemo.com Mon Sep 10 11:41:41 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Mon, 10 Sep 2018 13:41:41 +0200 Subject: [openssl-users] Using Windows system certficate store for server authentication In-Reply-To: <20180908180024.GB97812@straasha.imrryr.org> References: <7BF6A766-686A-4902-BEA1-635C2E76BC07@akamai.com> <20180908180024.GB97812@straasha.imrryr.org> Message-ID: On 08/09/2018 20:00, Viktor Dukhovni wrote: > On Sat, Sep 08, 2018 at 01:44:50PM +0000, Salz, Rich via openssl-users wrote: > >> OpenSSL does not use *any* certificate store, on any platform, it is up to the applications to do what they need. > More precisely, OpenSSL does not bundle any trusted certificates > with the upstream source. OpenSSL does use $OPENSSLDIR/cert.pem > and $OPENSSL/certs/ as the default CAfile and CApath respectively > via the: > > SSL_CTX_set_default_verify_paths() > > function. These can also be specified via the SSL_CERT_FILE and > SSL_CERT_DIR environment variables. Applications can specify > additional or alternative CAfile or CApath locations. > > IIRC the upstream OpenSSL code does not include an interface to the > Windows Active Directory certificate store. This may be available > from third parties. Please note there is no "Active Directory certificate store" for trusted CAs. There are however at least 3 similarly named things: - A per user/machine local CryptoAPI Certificate Store for trusted CAs, ?known intermediary CAs and known extra-bad certs (CA or EE).? This may ?or may not be accessible via the "capi" engine. Alternatively, a script could be written in a Microsoft language (such as VBScript or ?PowerShell)to automatically keep an /etc/ssl/certs format copy of that ?data. - An Active Directory certificate store describing mappings between ?trusted end entity certificates and kerberos accounts (such as ?"foo at bar.example.com == specific cert, HTTP/baz.examplecom==some other ?cert).? This can be accessed via LDAP but would be wholy in the ?application domain from an OpenSSL perspective (e.g. an Apache mod_ssl ?config mapping client certs to accounts via LDAP). - An Active Directory certificate store for Microsoft's Enterprise CA ?software.? This is wholy internal to that non-OpenSSL CA software, ?although some of that data (such as revocation checking) may be ?available via LDAP. Rule of thumb: Active Directory ~ Microsoft LDAP Directory 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 kurt at roeckx.be Mon Sep 10 20:42:09 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Mon, 10 Sep 2018 22:42:09 +0200 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> Message-ID: <20180910204208.GA21946@roeckx.be> On Fri, Aug 31, 2018 at 06:14:25PM -0700, Jordan Brown wrote: > We're trying to nail down error reporting for TLS version mismatches, > and we're seeing a couple of puzzling behaviors. > > First, and most puzzling... assume these two command lines: > > $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1 > > $ openssl s_client -connect zel.us.oracle.com:4433 -tls1 > > That is, I have a server that won't accept TLSv1.0, and a client that > will only accept TLSv1.0. > > On the server side I see > > 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported > protocol:s23_srvr.c:605: > > which makes perfect sense.? On the client side I see > > 4294956672:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl > handshake failure:s3_pkt.c:659: > > which isn't as good, but is still sort of sensible.? But when I look at > the packets exchanged, I see that the client sends a Client Hello, and > the server responds with an ACK and then a FIN-ACK, with no data.? It > just hangs up the phone.? This seems to violate RFC 5246 section E.1:? > "If server supports (or is willing to use) only versions greater than > client_version, it MUST send a "protocol_version" alert message and > close the connection.".? Where's my protocol version alert? > > Of course my real case does not involve the sample client and server - > it involves my own clients and servers - but I seem to see the same > behavior with several servers (notably including the Apache httpd). > > This looks like it's the same as > https://rt.openssl.org/Ticket/Display.html?id=2777 .? I'm using 1.0.2o.? > (But I don't see anything relevant-looking in the 1.0.2p changes.)? I've > seen similar behavior from 1.0.2o-fips. I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I believe this was fixed in all branches. I've tried 1.0.2o too, and I still get the alert back. > And then, on the client side... > > SSL_connect returns zero.? Exactly how that failure differs from a > less-than-zero error is not clear, but OK.? The docs say to call > SSL_get_error().? SSL_get_error() returns 5, SSL_ERROR_SYSCALL.? (That > seems a little strange, since I don't think there's any system call > errors here.)? The docs say to consult the error queue and errno.? > ERR_peek_last_error( ) returns zero.? Errno is zero.? It failed, but > nobody will tell me why. I assume that it returns SSL_ERROR_SYSCALL because something is not properly setting an error, and SSL_get_error() returns SSL_ERROR_SYSCALL when it doesn't know what else to return. If the peer just closes the connection, you should have gotten SSL_ERROR_SSL. I assume read() returned 0 because of EOF, which is not an error for read() so it does not set errno, but OpenSSL should have set an error instead. Kurt From openssl at jordan.maileater.net Tue Sep 11 00:27:36 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 11 Sep 2018 00:27:36 +0000 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <20180910204208.GA21946@roeckx.be> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <20180910204208.GA21946@roeckx.be> Message-ID: <01010165c606c159-04dda6b0-bb36-40d7-ab93-fddfe7668c3a-000000@us-west-2.amazonses.com> On 9/10/2018 1:42 PM, Kurt Roeckx wrote: > I can not reproduce this in 1.0.1, 1.0.2, 1.1.0 or 1.1.1. I believe > this was fixed in all branches. I've tried 1.0.2o too, and I still get > the alert back. Interesting.? My attempts were on Solaris x86[*].? I'll have to try other platforms. [...later...] With the Cygwin server (1.0.2n), I get different behavior. The server says: 4294956672:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1500:SSL alert number 40 where you might recall the Solaris server said: 1:error:14076102:SSL routines:SSL23_GET_CLIENT_HELLO:unsupported protocol:s23_srvr.c:605: The client (either Solaris or Cygwin) says: 1:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: which is perfect. Time to go figure out why our OpenSSL server is misbehaving. [*] As you might infer from my signature below, I work for Oracle in the Solaris group.? My immediate organization is primarily concerned with our Solaris-based storage products.? (That's not quite accurate, but you don't want to know about our org chart.) -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl at jordan.maileater.net Tue Sep 11 00:28:20 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 11 Sep 2018 00:28:20 +0000 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <20180910204208.GA21946@roeckx.be> Message-ID: <01010165c6076ed8-404f5502-1f4f-4cc3-87b7-92e22f2ec8e3-000000@us-west-2.amazonses.com> And of course I remember just after hitting Send:? Thanks! -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 11 01:13:38 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 10 Sep 2018 21:13:38 -0400 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> Message-ID: > On Aug 31, 2018, at 9:14 PM, Jordan Brown wrote: > > We're trying to nail down error reporting for TLS version mismatches, and we're seeing a couple of puzzling behaviors. > > First, and most puzzling... assume these two command lines: > > $ openssl s_server -cert 2018.08.31.a.pem -key 2018.08.31.a.key -no_tls1 This disables TLS 1.0 on the server, and if SSL 3.0 is supported at compile time, leaves the server willing to do SSL 3.0 or TLS 1.1 and up. > $ openssl s_client -connect zel.us.oracle.com:4433 -tls1 This configures the client to do TLS 1.0 only via the version-specific TLS1_client_method(), which DOES NOT support version negotiation. It is NOT equivalent in some subtle ways to: $ openssl s_client -connect zel.us.oracle.com:4433 -no_ssl3 -no_tls1_1 -no_tls1_2 That said, in either case the client sends "TLS 1.0" is its "maximum" protocol version in its TLS client HELLO (the TLS 1.0 protocol does not support sending a supported version list). > That is, I have a server that won't accept TLSv1.0, and a client that will only accept TLSv1.0. No, more precisely, you have a version-flexible server, that does not accept 1.0 and a *fixed-version* client that only supports 1.0. What happens at that point depends on whether SSL 3.0 has been disabled on the server, or not. If SSL 3.0 is not disabled on the server (at compile time or by other means), then seeing TLS 1.0 as the client's max version, the server will respond with SSL 3.0. The client however, is not in a negotiating mood, and it will send a handshake failure alert: SSL_connect:SSLv3 write client hello A SSL3 alert write:fatal:handshake failure SSL_connect:error in SSLv3 read server hello A 140735512441800:error:1408F10B:SSL routines:SSL3_GET_RECORD:wrong version number:s3_pkt.c:365: and on the server side you'll see: SSL_accept:before/accept initialization SSL_accept:SSLv3 read client hello A SSL_accept:SSLv3 write server hello A SSL_accept:SSLv3 write key exchange A SSL_accept:SSLv3 write server done A SSL_accept:SSLv3 flush data SSL_accept:SSLv3 read client certificate A SSL3 alert read:fatal:handshake failure SSL_accept:failed in SSLv3 read client key exchange A ERROR 140735512441800:error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure:s3_pkt.c:1498:SSL alert number 40 If, on the other hand, you *also* disable SSL 3.0 on the server, then seeing a maxim version or TLS 1.0 from the client, but with TLS 1.0 disabled the server wants SSL 3.0, but that's also unavailable. For better or worse, OpenSSL is unable with respond with a TLS 1.0 alert (TLS 1.0 is off), nor SSL 3.0, so it simply fails: SSL_accept:before/accept initialization SSL_accept:error in SSLv2/v3 read client hello A ERROR 140735512441800:error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol:s23_srvr.c:643: shutting down SSL The client's view of this is: SSL_connect:before/connect initialization SSL_connect:SSLv3 write client hello A SSL_connect:failed in SSLv3 read server hello A 140735512441800:error:1409E0E5:SSL routines:ssl3_write_bytes:ssl handshake failure:s3_pkt.c:659: You might argue that would should be able to send a TLS 1.0 fatal alert even with TLS 1.0 disabled, but that's not how the OpenSSL 1.0.x code works. It does not select explicitly disabled protocols for sending alerts, nor does it select protocol versions higher than the client's limit. In OpenSSL 1.1.x, with its more modern rewritten state machine, the behaviour is closer to what you expected. Server reports: SSL_accept:before SSL initialization SSL_accept:before SSL initialization SSL3 alert write:fatal:protocol version SSL_accept:error in error ERROR 140735512441728:error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:../openssl/ssl/statem/statem_srvr.c:1655: and client sees: SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL3 alert read:fatal:protocol version SSL_connect:error in error 140735512441728:error:1409442E:SSL routines:ssl3_read_bytes:tlsv1 alert protocol version:../openssl/ssl/record/rec_layer_s3.c:1528:SSL alert number 70 -- Viktor. From armen.babikyan at gmail.com Tue Sep 11 06:09:49 2018 From: armen.babikyan at gmail.com (Armen Babikyan) Date: Mon, 10 Sep 2018 23:09:49 -0700 Subject: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates Message-ID: Hello, I have a question regarding openssl and verification of client certificates. Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application? It appears that what I want is not possible from the SSL_VERIFY_* options presented here: https://www.openssl.org/docs/man1.1.1/man3/SSL_CTX_set_ verify_depth.html#NOTES My use case is to opportunistically allow connections from VoIP devices, whether or not the clients have certificates I can verify. Suppose I use the term "blue check" as an internal measure of client trustworthiness/provenance. 1) If the client presents a certificate that I can verify, I want to build some context that gives this client a "blue check". 2) If the client presents a certificate that I can't verify, I want to still allow it to connect, but not have a "blue check" associated with that client. 3) If the client doesn't present a certificate, I want to still allow it to connect, but, as in (2), not have a "blue check" It seems that the openssl library and documented behavior is artificially limiting me to only allow (1) and (3). I would like to support scenario (2) as well. Is the existing behavior intentional, or am I out in left-field with this request? If the latter, would you consider a patch to implement the behavior in (2), perhaps as an additional param, e.g. SSL_VERIFY_DONTFAIL? Additionally, it would be great if I could still get some information about the cert presented by the unverifiable client from within my application as well. Thanks! Armen -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 11 06:19:42 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 02:19:42 -0400 Subject: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates In-Reply-To: References: Message-ID: > On Sep 11, 2018, at 2:09 AM, Armen Babikyan wrote: > > I have a question regarding openssl and verification of client certificates. Is there a way to have an openssl-enabled server ask for a client certificate, and when it receives one it can't verify, rather than immediately terminating the handshake, it would allow the connection, but pass some context about the failed verification to the calling application? Yes. > It appears that what I want is not possible from the SSL_VERIFY_* options presented here: Actually, SSL_VERIFY_PEER is the right choice, but you also need a non-null verification callback that continues (by returning 1) despite failures to verify the client certificate. You can check the verification status at the completion of the handshake via SSL_get_verify_result(3). -- Viktor. From armen.babikyan at gmail.com Tue Sep 11 06:25:27 2018 From: armen.babikyan at gmail.com (Armen Babikyan) Date: Mon, 10 Sep 2018 23:25:27 -0700 Subject: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates In-Reply-To: References: Message-ID: Hi Viktor, I realized that something like this could be an option a few minutes after I hit "send". Thanks for the confirmation - I'll give this a shot! Many thanks! Armen On Mon, Sep 10, 2018 at 11:19 PM, Viktor Dukhovni < openssl-users at dukhovni.org> wrote: > > > > On Sep 11, 2018, at 2:09 AM, Armen Babikyan > wrote: > > > > I have a question regarding openssl and verification of client > certificates. Is there a way to have an openssl-enabled server ask for a > client certificate, and when it receives one it can't verify, rather than > immediately terminating the handshake, it would allow the connection, but > pass some context about the failed verification to the calling application? > > Yes. > > > It appears that what I want is not possible from the SSL_VERIFY_* > options presented here: > > Actually, SSL_VERIFY_PEER is the right choice, but you also need a > non-null verification callback that continues (by returning 1) > despite failures to verify the client certificate. > > You can check the verification status at the completion of the > handshake via SSL_get_verify_result(3). > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Tue Sep 11 06:49:03 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 00:49:03 -0600 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 Message-ID: <20180911064903.GA47547@doctor.nl2k.ab.ca> Will that combination occur? -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From openssl-users at dukhovni.org Tue Sep 11 07:27:17 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 03:27:17 -0400 Subject: [openssl-users] Preventing Handshake Termination Because of Unverifiable Client Certificates In-Reply-To: References: Message-ID: > On Sep 11, 2018, at 2:25 AM, Armen Babikyan wrote: > > I realized that something like this could be an option a few minutes after I hit "send". Thanks for the confirmation - I'll give this a shot! You should also consider what if anything you want to pass to SSL_CTX_set_client_CA_list(3) See the docs. Some clients (IIRC Java's TLS stack) don't send any client certificates unless the server solicits a certificate from a matching CA, and leaving the list empty may not work for such clients. -- Viktor. From Matthias.St.Pierre at ncp-e.com Tue Sep 11 08:05:37 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Tue, 11 Sep 2018 08:05:37 +0000 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <20180911064903.GA47547@doctor.nl2k.ab.ca> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> Message-ID: > Von: openssl-users Im Auftrag von The Doctor > Gesendet: Dienstag, 11. September 2018 08:49 > An: openssl-users at openssl.org; openssl-dev at openssl.org > Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > > Will that combination occur? Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new features. HTH, Matthias See also https://wiki.openssl.org/index.php/TLS1.3 https://www.openssl.org/policies/releasestrat.html From matt at openssl.org Tue Sep 11 08:31:23 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 11 Sep 2018 09:31:23 +0100 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: References: <20180911064903.GA47547@doctor.nl2k.ab.ca> Message-ID: <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >> Von: openssl-users Im Auftrag von The Doctor >> Gesendet: Dienstag, 11. September 2018 08:49 >> An: openssl-users at openssl.org; openssl-dev at openssl.org >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >> >> Will that combination occur? > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. > OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new > features. Strictly speaking 1.0.2 will receive bug fixes and security fixes until the end of this year. From the end of this year until the end of 2019 it will receive security fixes only. In any case it will receive no new features (including TLSv1.3). >From the release of 1.1.1 (today), 1.1.0 will receive security fixes only for one year. Matt > > HTH, > Matthias > > See also > https://wiki.openssl.org/index.php/TLS1.3 > https://www.openssl.org/policies/releasestrat.html > > > From openssl at openssl.org Tue Sep 11 13:42:31 2018 From: openssl at openssl.org (OpenSSL) Date: Tue, 11 Sep 2018 13:42:31 +0000 Subject: [openssl-users] OpenSSL version 1.1.1 published Message-ID: <20180911134231.GA11632@openssl.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 OpenSSL version 1.1.1 released =============================== OpenSSL - The Open Source toolkit for SSL/TLS https://www.openssl.org/ The OpenSSL project team is pleased to announce the release of version 1.1.1 of our open source toolkit for SSL/TLS. For details of changes and known issues see the release notes at: https://www.openssl.org/news/openssl-1.1.1-notes.html OpenSSL 1.1.1 is available for download via HTTP and FTP from the following master locations (you can find the various FTP mirrors under https://www.openssl.org/source/mirror.html): * https://www.openssl.org/source/ * ftp://ftp.openssl.org/source/ The distribution file name is: o openssl-1.1.1.tar.gz Size: 8337920 SHA1 checksum: e4559f31dca37ce815e0c7135488b747745a056d SHA256 checksum: 2836875a0f89c03d0fdf483941512613a50cfb421d6fd94b9f41d7279d586a3d The checksums were calculated using the following commands: openssl sha1 openssl-1.1.1.tar.gz openssl sha256 openssl-1.1.1.tar.gz Yours, The OpenSSL Project Team. -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEhlersmDwVrHlGQg52cTSbQ5gRJEFAluXuZ8ACgkQ2cTSbQ5g RJFPFQf9G1LopuN1P3tIUTgps9Z1SS+TuC7OeRPu9TCEqOR0yO8WGyTCfLZnoXZ7 0BqFASYW4VbPCy8LH3glHLBe64NApdoA1HoMmHCvd+TxPQHEvhc0OejSaOGZKY/r 2LGUvEguiyYpjQS4bQmsl8wNl3CrYRGSMqBcbFj+qF/Rrlpa1hpKGnH4ooMxe7Nx /Ro4AjMe46vQL/RU980yFl+JTkhAvSOxw0cltbILPO2MP6Fo4QZqMO8mYRjEnqUZ E/Ixl/dIkSWjPC8pkkRS9FmMQHHYe66S20OK7V2Zl3Zd88FrNI+qeKgEF3ABGknR 6vR0kPkddRl43JktQ4B1QKS+GcwzHw== =fvfm -----END PGP SIGNATURE----- From matt at openssl.org Tue Sep 11 13:56:19 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 11 Sep 2018 14:56:19 +0100 Subject: [openssl-users] OpenSSL 1.1.1 Blog Message-ID: Our new Long Term Support release, OpenSSL 1.1.1, including TLSv1.3, has been released today. Please download and upgrade! There is a blog post about the new release and the status of the older releases here: https://www.openssl.org/blog/blog/2018/09/11/release111/ Matt From doctor at doctor.nl2k.ab.ca Tue Sep 11 13:58:11 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 07:58:11 -0600 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> Message-ID: <20180911135811.GA38827@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: > > > On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: > >> Von: openssl-users Im Auftrag von The Doctor > >> Gesendet: Dienstag, 11. September 2018 08:49 > >> An: openssl-users at openssl.org; openssl-dev at openssl.org > >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > >> > >> Will that combination occur? > > > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. > > OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new > > features. > > Strictly speaking 1.0.2 will receive bug fixes and security fixes until > the end of this year. From the end of this year until the end of 2019 it > will receive security fixes only. In any case it will receive no new > features (including TLSv1.3). > > >From the release of 1.1.1 (today), 1.1.0 will receive security fixes > only for one year. > > Matt > > Got you. So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API in order to use TLS 1.3 . > > > > > HTH, > > Matthias > > > > See also > > https://wiki.openssl.org/index.php/TLS1.3 > > https://www.openssl.org/policies/releasestrat.html > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From matt at openssl.org Tue Sep 11 14:01:38 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 11 Sep 2018 15:01:38 +0100 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <20180911135811.GA38827@doctor.nl2k.ab.ca> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> <20180911135811.GA38827@doctor.nl2k.ab.ca> Message-ID: <103a920a-5d4f-29ea-f964-e45a3d0487df@openssl.org> On 11/09/18 14:58, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: >> >> >> On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >>>> Von: openssl-users Im Auftrag von The Doctor >>>> Gesendet: Dienstag, 11. September 2018 08:49 >>>> An: openssl-users at openssl.org; openssl-dev at openssl.org >>>> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >>>> >>>> Will that combination occur? >>> >>> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. >>> OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new >>> features. >> >> Strictly speaking 1.0.2 will receive bug fixes and security fixes until >> the end of this year. From the end of this year until the end of 2019 it >> will receive security fixes only. In any case it will receive no new >> features (including TLSv1.3). >> >> >From the release of 1.1.1 (today), 1.1.0 will receive security fixes >> only for one year. >> >> Matt >> >> > > Got you. > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > in order to use TLS 1.3 . Yes. I would encourage *all* applications still on the 1.0.x API to move to 1.1.1 asap. By the end of next year there will be no supported OpenSSL version that has the old API. Matt > >> >>> >>> HTH, >>> Matthias >>> >>> See also >>> https://wiki.openssl.org/index.php/TLS1.3 >>> https://www.openssl.org/policies/releasestrat.html >>> >>> >>> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > From rsalz at akamai.com Tue Sep 11 14:02:51 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 11 Sep 2018 14:02:51 +0000 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <20180911135811.GA38827@doctor.nl2k.ab.ca> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> <20180911135811.GA38827@doctor.nl2k.ab.ca> Message-ID: <17C60704-DECE-467D-89AB-4225DBDB8B3C@akamai.com> > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API in order to use TLS 1.3 . Yes. From doctor at doctor.nl2k.ab.ca Tue Sep 11 14:04:25 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 08:04:25 -0600 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <103a920a-5d4f-29ea-f964-e45a3d0487df@openssl.org> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> <20180911135811.GA38827@doctor.nl2k.ab.ca> <103a920a-5d4f-29ea-f964-e45a3d0487df@openssl.org> Message-ID: <20180911140425.GG38827@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 03:01:38PM +0100, Matt Caswell wrote: > > > On 11/09/18 14:58, The Doctor wrote: > > On Tue, Sep 11, 2018 at 09:31:23AM +0100, Matt Caswell wrote: > >> > >> > >> On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: > >>>> Von: openssl-users Im Auftrag von The Doctor > >>>> Gesendet: Dienstag, 11. September 2018 08:49 > >>>> An: openssl-users at openssl.org; openssl-dev at openssl.org > >>>> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 > >>>> > >>>> Will that combination occur? > >>> > >>> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. > >>> OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new > >>> features. > >> > >> Strictly speaking 1.0.2 will receive bug fixes and security fixes until > >> the end of this year. From the end of this year until the end of 2019 it > >> will receive security fixes only. In any case it will receive no new > >> features (including TLSv1.3). > >> > >> >From the release of 1.1.1 (today), 1.1.0 will receive security fixes > >> only for one year. > >> > >> Matt > >> > >> > > > > Got you. > > > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > > in order to use TLS 1.3 . > > Yes. I would encourage *all* applications still on the 1.0.x API to move > to 1.1.1 asap. By the end of next year there will be no supported > OpenSSL version that has the old API. > > > Matt > > I will forward this to the many mailing lists I belong to. > > >> > >>> > >>> HTH, > >>> Matthias > >>> > >>> See also > >>> https://wiki.openssl.org/index.php/TLS1.3 > >>> https://www.openssl.org/policies/releasestrat.html > >>> > >>> > >>> > >> -- > >> openssl-users mailing list > >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From graeme.perrow at sap.com Tue Sep 11 14:12:15 2018 From: graeme.perrow at sap.com (Perrow, Graeme) Date: Tue, 11 Sep 2018 14:12:15 +0000 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> Message-ID: AFAIK 1.1.1 does not support the FIPS module, which means that those of us who require FIPS must stay on 1.0.2. Any ETA on when FIPS support might be added? Graeme -----Original Message----- From: openssl-users On Behalf Of Matt Caswell Sent: September 11, 2018 4:31 AM To: openssl-users at openssl.org Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >> Von: openssl-users Im Auftrag von The Doctor >> Gesendet: Dienstag, 11. September 2018 08:49 >> An: openssl-users at openssl.org; openssl-dev at openssl.org >> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >> >> Will that combination occur? > > Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. > OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new > features. Strictly speaking 1.0.2 will receive bug fixes and security fixes until the end of this year. From the end of this year until the end of 2019 it will receive security fixes only. In any case it will receive no new features (including TLSv1.3). >From the release of 1.1.1 (today), 1.1.0 will receive security fixes only for one year. Matt > > HTH, > Matthias > > See also > https://wiki.openssl.org/index.php/TLS1.3 > https://www.openssl.org/policies/releasestrat.html > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From matt at openssl.org Tue Sep 11 14:35:25 2018 From: matt at openssl.org (Matt Caswell) Date: Tue, 11 Sep 2018 15:35:25 +0100 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> Message-ID: On 11/09/18 15:12, Perrow, Graeme wrote: > AFAIK 1.1.1 does not support the FIPS module, which means that those of us who require FIPS must stay on 1.0.2. Any ETA on when FIPS support might be added? TBD. Likely to be next year (before the EOL of 1.0.2) IMO. Our development focus is now shifting from implementing TLSv1.3 to implementing the new FIPS module. Matt > > Graeme > > -----Original Message----- > From: openssl-users On Behalf Of Matt Caswell > Sent: September 11, 2018 4:31 AM > To: openssl-users at openssl.org > Subject: Re: [openssl-users] openssl 1.0.2 and TLS 1.3 > > > > On 11/09/18 09:05, Dr. Matthias St. Pierre wrote: >>> Von: openssl-users Im Auftrag von The Doctor >>> Gesendet: Dienstag, 11. September 2018 08:49 >>> An: openssl-users at openssl.org; openssl-dev at openssl.org >>> Betreff: [openssl-users] openssl 1.0.2 and TLS 1.3 >>> >>> Will that combination occur? >> >> Support for TLS 1.3 is a new feature in OpenSSL 1.1.1 which will be released today. >> OpenSSL 1.0.2 is an LTS release which will only receive security updates and no new >> features. > > Strictly speaking 1.0.2 will receive bug fixes and security fixes until > the end of this year. From the end of this year until the end of 2019 it > will receive security fixes only. In any case it will receive no new > features (including TLSv1.3). > > From the release of 1.1.1 (today), 1.1.0 will receive security fixes > only for one year. > > Matt > > > >> >> HTH, >> Matthias >> >> See also >> https://wiki.openssl.org/index.php/TLS1.3 >> https://www.openssl.org/policies/releasestrat.html >> >> >> From jisoza at gmail.com Tue Sep 11 14:59:45 2018 From: jisoza at gmail.com (Juan Isoza) Date: Tue, 11 Sep 2018 16:59:45 +0200 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server Message-ID: Hello, What is the better way, for anyone running, by example, Apache or nginx on a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ? Waiting package update to have openssl 1.1.1 ? probably a lot of time Recompile openssl dynamic library and replace system library ? We must be sure we don't broke the system Recompile Apache or NGinx with openssl statically linked ? probably complex -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 11 15:15:23 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 11:15:23 -0400 Subject: [openssl-users] openssl 1.0.2 and TLS 1.3 In-Reply-To: <20180911135811.GA38827@doctor.nl2k.ab.ca> References: <20180911064903.GA47547@doctor.nl2k.ab.ca> <115c476a-96c1-477e-06e2-1d82e4c2f42a@openssl.org> <20180911135811.GA38827@doctor.nl2k.ab.ca> Message-ID: > On Sep 11, 2018, at 9:58 AM, The Doctor wrote: > > So Openssh, NTPd, MOd_pagespeed have to adopt OPEnssl 1.1X API > in order to use TLS 1.3 . OpenSSH does not use TLS or libssl, so does not need that OpenSSL 1.1.x feature. It could still benefit from libcrypto algorithm improvements that result in more constant behaviour and/or other improvements. While OpenBSD may be slow to port to OpenSSL 1.1.x, porting OpenSSH to 1.1.x is not difficult. Christos Zoulas has done that for NetBSD, the latest HPN patches port OpenSSH to OpenSSL 1.1.0 [ I used the HPN patches for OpenSSH 7.7p1 as a starting point, and have a clean build of OpenSSH 7.8p1 with OpenSSL 1.1.x after some minor improvements. ] -- Viktor. From doctor at doctor.nl2k.ab.ca Tue Sep 11 15:33:36 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 09:33:36 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 Message-ID: <20180911153336.GA64283@doctor.nl2k.ab.ca> Looks likes I found a first bug ../test/recipes/70-test_comp.t ..................... Proxy started on port [::1]:10789 Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 engine "ossltest" set. Using default temp DH parameters ACCEPT [::1]:39577 Server responds on [::1]:39577 panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 My configuration is #!/usr/local/bin/bash CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From openssl-users at dukhovni.org Tue Sep 11 16:23:08 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 12:23:08 -0400 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911153336.GA64283@doctor.nl2k.ab.ca> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> Message-ID: <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> > On Sep 11, 2018, at 11:33 AM, The Doctor wrote: > > Looks likes I found a first bug > > ../test/recipes/70-test_comp.t ..................... > Proxy started on port [::1]:10789 > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > engine "ossltest" set. > Using default temp DH parameters > ACCEPT [::1]:39577 > Server responds on [::1]:39577 > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 This did not happen on my machine, the build succeeded, and all tests passed: $ uname -srp FreeBSD 11.1-RELEASE-p10 amd64 ## ## Makefile for OpenSSL ## ## WARNING: do not edit! ## Generated by Configure from ../Configurations/unix-Makefile.tmpl, ../Configurations/common.tmpl PLATFORM=BSD-x86_64 OPTIONS=enable-shared no-asan no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-md2 no-msan no-rc5 no-sctp no-ssl-trace no-ssl3 no-ssl3-method no-ubsan no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic CONFIGURE_ARGS=("BSD-x86_64", "shared") Ditto with a configuration similar to yours, but built with "CC=clang50": ## ## Makefile for OpenSSL ## ## WARNING: do not edit! ## Generated by Configure from ../Configurations/unix-Makefile.tmpl, ../Configurations/common.tmpl PLATFORM=BSD-x86_64 OPTIONS=--prefix=/usr/local enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared enable-zlib-dynamic enable-sctp enable-rc4 enable-ssl-trace enable-unit-test no-asan no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-idea no-md2 no-msan no-rc5 no-ssl3 no-ssl3-method no-ubsan no-weak-ssl-ciphers CONFIGURE_ARGS=("--prefix=/usr/local", "BSD-x86_64", "enable-crypto-mdebug", "enable-crypto-mdebug-backtrace", "enable-rfc3779", "enable-shared", "zlib-dynamic", "enable-sctp", "enable-rc4", "disable-weak-ssl-ciphers", "no-idea", "enable-ssl-trace", "enable-unit-test") > My configuration is > > #!/usr/local/bin/bash > CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend You don't need to, and should not run "make depend" for OpenSSL 1.1.x. I'd recommend building an empty sub-directory or "out of tree": mkdir build; cd build; $path_to_source/Configure ...; make; make test Why are you building with "enable-crypto-mdebug" and "enable-crypto-mdebug-backtrace"? These are developer-team options, not expected to used by others, or necessarily work reliably on all systems... They also incur a substantial performance penalty. -- Viktor. From openssl at jordan.maileater.net Tue Sep 11 16:33:18 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 11 Sep 2018 16:33:18 +0000 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> Message-ID: <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> Thanks! Now I need to wrap my head around what that all means. It sounds like the protocol doesn't really have a version-independent way for the version negotiation to cleanly fail.? That's unfortunate. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 11 16:46:58 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 12:46:58 -0400 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> Message-ID: <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> > On Sep 11, 2018, at 12:33 PM, Jordan Brown wrote: > > Thanks! > > Now I need to wrap my head around what that all means. > > It sounds like the protocol doesn't really have a version-independent way for the version negotiation to cleanly fail. That's unfortunate. Well, once SSL3 is out of the picture (as in OpenSSL 1.1.x), TLS 1.0 and up do all support the requisite alert, and the 1.1.x state machine seems to handle this more along the lines that you expect. The issue is that 1.0.2 is older and tries to stick to SSL 3.0 capabilities when talking to SSL 3.0 clients, ... so things get a bit messier. Part of the confusion is also using a version inflexible method on the client, that's rarely done. Instead of "s_client -tls1" it is wiser to test with "s_client -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That is subtract the versions you don't want. IIRC that still leaves you "version flexible" even if only with a single version. In OpenSSL 1.1.x all the "-no_some_version" options are superseded by the min/max version options, which should be used instead. -- Viktor. From doctor at doctor.nl2k.ab.ca Tue Sep 11 16:48:40 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 10:48:40 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911153336.GA64283@doctor.nl2k.ab.ca> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> Message-ID: <20180911164840.GA87295@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > Looks likes I found a first bug > > ../test/recipes/70-test_comp.t ..................... > Proxy started on port [::1]:10789 > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > engine "ossltest" set. > Using default temp DH parameters > ACCEPT [::1]:39577 > Server responds on [::1]:39577 > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > My configuration is > > #!/usr/local/bin/bash > CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend > -- > 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 > NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users Using perl 5.28.1 -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From dclarke at blastwave.org Tue Sep 11 16:48:53 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 11 Sep 2018 12:48:53 -0400 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> Message-ID: <07d870a4-39e8-dd6c-8283-dd699d43b80d@blastwave.org> On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: > > >> On Sep 11, 2018, at 11:33 AM, The Doctor wrote: >> >> Looks likes I found a first bug >> > > This did not happen on my machine, the build succeeded, and all tests > passed: > > $ uname -srp > FreeBSD 11.1-RELEASE-p10 amd64 > You have 11.1 there whereas the initial report is in regards to 11.2. I think 12.0 is right around the corner. I'll have a look at both. >> My configuration is >> >> #!/usr/local/bin/bash >> CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend > > You don't need to, and should not run "make depend" for OpenSSL 1.1.x. > I'd recommend building an empty sub-directory or "out of tree": > > mkdir build; cd build; $path_to_source/Configure ...; make; make test > > Why are you building with "enable-crypto-mdebug" and "enable-crypto-mdebug-backtrace"? > These are developer-team options, not expected to used by others, or necessarily work > reliably on all systems... They also incur a substantial performance penalty. > Hrmmm ... I'll give it a whirl out of the box but generally I find that the Configurations/10-main.conf needs to be edited as well as the resultant Makefile but after that everything goes smoothly. Dennis From doctor at doctor.nl2k.ab.ca Tue Sep 11 16:54:19 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 10:54:19 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> Message-ID: <20180911165419.GB87295@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 12:23:08PM -0400, Viktor Dukhovni wrote: > > > > On Sep 11, 2018, at 11:33 AM, The Doctor wrote: > > > > Looks likes I found a first bug > > > > ../test/recipes/70-test_comp.t ..................... > > Proxy started on port [::1]:10789 > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > engine "ossltest" set. > > Using default temp DH parameters > > ACCEPT [::1]:39577 > > Server responds on [::1]:39577 > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > This did not happen on my machine, the build succeeded, and all tests > passed: > > $ uname -srp > FreeBSD 11.1-RELEASE-p10 amd64 > Using 11.2 myself. 11.1 is now unsupported. > ## > ## Makefile for OpenSSL > ## > ## WARNING: do not edit! > ## Generated by Configure from ../Configurations/unix-Makefile.tmpl, ../Configurations/common.tmpl > > PLATFORM=BSD-x86_64 > OPTIONS=enable-shared no-asan no-crypto-mdebug no-crypto-mdebug-backtrace no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-md2 no-msan no-rc5 no-sctp no-ssl-trace no-ssl3 no-ssl3-method no-ubsan no-unit-test no-weak-ssl-ciphers no-zlib no-zlib-dynamic > CONFIGURE_ARGS=("BSD-x86_64", "shared") > > Ditto with a configuration similar to yours, but built with "CC=clang50": > > ## > ## Makefile for OpenSSL > ## > ## WARNING: do not edit! > ## Generated by Configure from ../Configurations/unix-Makefile.tmpl, ../Configurations/common.tmpl > > PLATFORM=BSD-x86_64 > OPTIONS=--prefix=/usr/local enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared enable-zlib-dynamic enable-sctp enable-rc4 enable-ssl-trace enable-unit-test no-asan no-ec_nistp_64_gcc_128 no-egd no-fuzz-afl no-fuzz-libfuzzer no-heartbeats no-idea no-md2 no-msan no-rc5 no-ssl3 no-ssl3-method no-ubsan no-weak-ssl-ciphers > CONFIGURE_ARGS=("--prefix=/usr/local", "BSD-x86_64", "enable-crypto-mdebug", "enable-crypto-mdebug-backtrace", "enable-rfc3779", "enable-shared", "zlib-dynamic", "enable-sctp", "enable-rc4", "disable-weak-ssl-ciphers", "no-idea", "enable-ssl-trace", "enable-unit-test") > > > My configuration is > > > > #!/usr/local/bin/bash > > CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend > > You don't need to, and should not run "make depend" for OpenSSL 1.1.x. > I'd recommend building an empty sub-directory or "out of tree": > > mkdir build; cd build; $path_to_source/Configure ...; make; make test > > Why are you building with "enable-crypto-mdebug" and "enable-crypto-mdebug-backtrace"? > These are developer-team options, not expected to used by others, or necessarily work > reliably on all systems... They also incur a substantial performance penalty. > clang 6.0 is the default and there is clang 6.0.1 and clang 7.0 FYI Let me try without mdebug > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From openssl-users at dukhovni.org Tue Sep 11 17:09:36 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 13:09:36 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: References: Message-ID: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> > On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote: > > What is the better way, for anyone running, by example, Apache or nginx on a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ? > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > Recompile openssl dynamic library and replace system library ? We must be sure we don't broke the system > > Recompile Apache or NGinx with openssl statically linked ? probably complex You can install OpenSSL 1.1.1 in a non-default location, say: ./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64": --- Configurations/10-main.conf +++ Configurations/10-main.conf + "BSD-x86_64-opt" => { + inherit_from => [ "BSD-x86_64" ], + shlib_variant => "-opt", + }, + but also specifying 'shlib_variant => "-opt"', see Configurations/README: shlib_variant => A "variant" identifier inserted between the base shared library name and the extension. On "unixy" platforms (BSD, Linux, Solaris, MacOS/X, ...) this supports installation of custom OpenSSL libraries that don't conflict with other builds of OpenSSL installed on the system. The variant identifier becomes part of the SONAME of the library and also any symbol versions (symbol versions are not used or needed with MacOS/X). For example, on a system where a default build would normally create the SSL shared library as 'libssl.so -> libssl.so.1.1' with the value of the symlink as the SONAME, a target definition that sets 'shlib_variant => "-abc"' will create 'libssl.so -> libssl-abc.so.1.1', again with an SONAME equal to the value of the symlink. The symbol versions associated with the variant library would then be 'OPENSSL_ABC_' rather than the default 'OPENSSL_'. The string inserted into symbol versions is obtained by mapping all letters in the "variant" identifier to upper case and all non-alphanumeric characters to '_'. The resulting libraries have a non-default SONAME: $ readelf -d *.so | grep SONAME 0x000000000000000e SONAME Library soname: [libcrypto-opt.so.1.1] 0x000000000000000e SONAME Library soname: [libssl-opt.so.1.1] And non-default symbol versions: $ objdump -T libssl.so | grep SSL_CTX_new 00000000000338c0 g DF .text 00000000000003b3 OPENSSL_OPT_1_1_0 SSL_CTX_new $ objdump -T libcrypto.so | grep X509_new 00000000001d7be0 g DF .text 0000000000000011 OPENSSL_OPT_1_1_0 X509_new All that remains is to link Apache, Nginx, ... with these libraries instead: CFLAGS+="-I/usr/local/opt/openssl/1.1.1/include" LDFLAGS+="-L/usr/local/opt/openssl/1.1.1/lib -Wl,-rpath,/usr/local/opt/openssl/1.1.1/lib" Integrating this into "ports" is an exercise for the reader... -- -- Viktor. From openssl at jordan.maileater.net Tue Sep 11 17:17:30 2018 From: openssl at jordan.maileater.net (Jordan Brown) Date: Tue, 11 Sep 2018 17:17:30 +0000 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> Message-ID: <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> On 9/11/2018 9:46 AM, Viktor Dukhovni wrote: > Part of the confusion is also using a version inflexible method on the > client, that's rarely done. My test engineers like trying all the variations, including the ones nobody will ever use :-) > Instead of "s_client -tls1" it is wiser to test with "s_client > -no_ssl2 -no_ssl3 -no_tls1_1 -no_tls1_2". That is subtract the > versions you don't want. IIRC that still leaves you "version flexible" > even if only with a single version. In the application that's causing me trouble now, we start with SSLv23_method and then add SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, and in this particular test case SSL_OP_NO_TLSv1_1 and SSL_OP_NO_TLSv1_2. But how we construct the client configuration won't matter.? The client says "the highest I support is 1.0" and the server says (to itself) "the lowest I support is 1.1; I don't even know how to say 'no' so I'm just giving up". The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail.? If the server supports only versions larger than the client supports, it has no way to say "no".? If the positions are reversed, the server counter-offers a version that the client then rejects as too old. Thanks again. -- Jordan Brown, Oracle Solaris -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Tue Sep 11 17:30:32 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 11:30:32 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <07d870a4-39e8-dd6c-8283-dd699d43b80d@blastwave.org> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> <07d870a4-39e8-dd6c-8283-dd699d43b80d@blastwave.org> Message-ID: <20180911173032.GA96700@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 12:48:53PM -0400, Dennis Clarke wrote: > On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: > > > > > >> On Sep 11, 2018, at 11:33 AM, The Doctor wrote: > >> > >> Looks likes I found a first bug > >> > > > > This did not happen on my machine, the build succeeded, and all tests > > passed: > > > > $ uname -srp > > FreeBSD 11.1-RELEASE-p10 amd64 > > > > You have 11.1 there whereas the initial report is in regards to 11.2. > I think 12.0 is right around the corner. I'll have a look at both. > > >> My configuration is > >> > >> #!/usr/local/bin/bash > >> CC=/usr/local/bin/clang60 ./Configure --prefix=/usr/local BSD-x86_64 enable-crypto-mdebug enable-crypto-mdebug-backtrace enable-rfc3779 enable-shared zlib-dynamic enable-sctp enable-rc4 disable-weak-ssl-ciphers no-idea enable-ssl-trace enable-unit-test; make depend > > > > You don't need to, and should not run "make depend" for OpenSSL 1.1.x. > > I'd recommend building an empty sub-directory or "out of tree": > > > > mkdir build; cd build; $path_to_source/Configure ...; make; make test > > > > Why are you building with "enable-crypto-mdebug" and "enable-crypto-mdebug-backtrace"? > > These are developer-team options, not expected to used by others, or necessarily work > > reliably on all systems... They also incur a substantial performance penalty. > > > > Hrmmm ... I'll give it a whirl out of the box but generally I find that > the Configurations/10-main.conf needs to be edited as well as the > resultant Makefile but after that everything goes smoothly. > > Dennis > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users LEt's get this tweaked accordingly for current BSD standards. -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From openssl-users at dukhovni.org Tue Sep 11 17:34:54 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 13:34:54 -0400 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> Message-ID: > On Sep 11, 2018, at 1:17 PM, Jordan Brown wrote: > > The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail. If the server supports only versions larger than the client supports, it has no way to say "no". If the positions are reversed, the server counter-offers a version that the client then rejects as too old. In OpenSSL 1.1.x, though the server might not support continuing with the client's maximum version, it is willing to do so just long enough to send a fatal protocol version mismatch alert. It helps that SSL2/SSL3 are not supported, and TLS 1.0 and up support the alert. Time to move to OpenSSL 1.1.x, it has many improvements, ... -- Viktor. From dclarke at blastwave.org Tue Sep 11 17:39:52 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 11 Sep 2018 13:39:52 -0400 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911173032.GA96700@doctor.nl2k.ab.ca> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <1767A126-C0B8-42B1-B502-2483528D54DD@dukhovni.org> <07d870a4-39e8-dd6c-8283-dd699d43b80d@blastwave.org> <20180911173032.GA96700@doctor.nl2k.ab.ca> Message-ID: <5300a6f9-3705-8b97-1e74-0cdf70deaae8@blastwave.org> On 09/11/2018 01:30 PM, The Doctor wrote: > On Tue, Sep 11, 2018 at 12:48:53PM -0400, Dennis Clarke wrote: >> On 09/11/2018 12:23 PM, Viktor Dukhovni wrote: >>>> On Sep 11, 2018, at 11:33 AM, The Doctor wrote: >>>> >>>> Looks likes I found a first bug >>>> Let's just slow down here a sec. > > LEt's get this tweaked accordingly for current BSD standards. > Well I have been building and testing all the beta releases on a mixture of platforms for a while. All year? A while now and have not seen any show stoppers anywhere other than a bit of config tweaks and Makefile edits. I have been running a TLS v1.3 website for months and it never skips a beat. So this is most likely just a FreeBSD "feature" and a non-issue. The maintainer(s) in the FreeBSD project are the folks to speak with here and not the OpenSSL folks. Regardless I will give the release a whirl on OpenBSD 11.2 and 12.0 and possibly on PPC64 also. If there is anything to report you will see it in the FreeBSD bugzilla. Dennis Clarke ye ol greybeard UNIX silverback From dclarke at blastwave.org Tue Sep 11 17:47:18 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 11 Sep 2018 13:47:18 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> References: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> Message-ID: On 09/11/2018 01:09 PM, Viktor Dukhovni wrote: > > >> On Sep 11, 2018, at 10:59 AM, Juan Isoza wrote: >> >> What is the better way, for anyone running, by example, Apache or nginx on a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS 1.3 ? >> >> Waiting package update to have openssl 1.1.1 ? probably a lot of time >> Roll you own. It works. Really really well in fact. >> Recompile openssl dynamic library and replace system library ? We must be sure we don't broke the system Don't do that. That path leads to madness. >> >> Recompile Apache or NGinx with openssl statically linked ? probably complex > > You can install OpenSSL 1.1.1 in a non-default location, say: > > ./Configure --prefix=/usr/local/opt/openssl/1.1.1 BSD-x86_64-opt shared > > with the "BSD-x86_64-opt" target inheriting from "BSD-x86_64": > > --- Configurations/10-main.conf > +++ Configurations/10-main.conf > > + "BSD-x86_64-opt" => { > + inherit_from => [ "BSD-x86_64" ], > + shlib_variant => "-opt", > + }, > + > > Integrating this into "ports" is an exercise for the reader... > It sounds like a downstream ELF header nightmare. Most likely better to just isolate systems entirely and build the software stack dependencies using standard locations and standard SONAME/RPATH/RUNPATH data. However if someone wants to spin in tight circles battling lib resolution, well gee, sounds like endless fun. Not for me .. thanks. Dennis From openssl-users at dukhovni.org Tue Sep 11 17:57:48 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 13:57:48 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: References: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> Message-ID: <20180911175748.GC3589@straasha.imrryr.org> On Tue, Sep 11, 2018 at 01:47:18PM -0400, Dennis Clarke wrote: > > --- Configurations/10-main.conf > > +++ Configurations/10-main.conf > > > > + "BSD-x86_64-opt" => { > > + inherit_from => [ "BSD-x86_64" ], > > + shlib_variant => "-opt", > > + }, > > + I guess this is a thread about Linux, and I gave a BSD example, but there are no substative differences. > It sounds like a downstream ELF header nightmare. Actually, it works just fine. You link with the variant library, and it happily coexists with any dependencies you may have that in turn depend on the system TLS library. The variant SONAME and symbol versions provide all the requisite isolation. You only pay the cost of customization for the handful of packages you want to have running against the non-default libraries. This has been running in production on thousands of servers for multiple years on Ubuntu (karmic, since retired), Debian wheezy, jessie and stretch. Otherwise, you have to be sure to recompile the world, to avoid dependency conflicts where some system library use TLS, say for LDAP lookups via an nsswitch module, and crashes because it wants a differen OpenSSL version. -- Viktor. From kurt at roeckx.be Tue Sep 11 18:10:01 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 11 Sep 2018 20:10:01 +0200 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: References: Message-ID: <20180911181000.GA2375@roeckx.be> On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > Hello, > > What is the better way, for anyone running, by example, Apache or nginx on > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > 1.3 ? > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > Recompile openssl dynamic library and replace system library ? We must be > sure we don't broke the system > > Recompile Apache or NGinx with openssl statically linked ? probably complex Note that you most likely need an update of both nginx/apache and openssl. I will very likely make 1.1.1 available in Debian backports. I hope that the nginx maintainer will also make a version that works with 1.1.1. But this is most likely going to take a while. We first want to make things work properly in testing. In the mean time buillding things yourself seems like the easiest solution. If using Debian you can just take the versions of the packages currently in unstable and build them on stable. Kurt From kurt at roeckx.be Tue Sep 11 18:14:00 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 11 Sep 2018 20:14:00 +0200 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <20180911181000.GA2375@roeckx.be> References: <20180911181000.GA2375@roeckx.be> Message-ID: <20180911181359.GB2375@roeckx.be> On Tue, Sep 11, 2018 at 08:10:01PM +0200, Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably complex > > Note that you most likely need an update of both nginx/apache and > openssl. > > I will very likely make 1.1.1 available in Debian backports. I hope that > the nginx maintainer will also make a version that works with 1.1.1. Looking at stretch-backports, it already has an nginx version that is recent enough, so you would just need a new openssl. I can only do an openssl upload to backports after it has reached testing. Kurt From dclarke at blastwave.org Tue Sep 11 18:28:12 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 11 Sep 2018 14:28:12 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <20180911175748.GC3589@straasha.imrryr.org> References: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> <20180911175748.GC3589@straasha.imrryr.org> Message-ID: <761ada47-608b-02ef-e251-a028d6e679a9@blastwave.org> > >> It sounds like a downstream ELF header nightmare. > > Actually, it works just fine. You link with the variant library, > and it happily coexists with any dependencies you may have that in > turn depend on the system TLS library. The variant SONAME and > symbol versions provide all the requisite isolation. You only > pay the cost of customization for the handful of packages you > want to have running against the non-default libraries. > Mildly interesting in giving it a try. However I have 1.1.1 running and tested fine on Solaris 10 sparc without any interferance from the system provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set to /usr/local/lib for everything I have built. > Otherwise, you have to be sure to recompile the world ... Right. Recompile the "world" isn't what it once was and a decently fast system gets that done overnight. In any case https://www.tls13.net/ is running just fine and a whole slew of browsers ( and curl ) have hit it. Nothing from the Opera folks however. Makes me wonder about lynx/links text browsers too. Dennis From openssl-users at dukhovni.org Tue Sep 11 18:35:54 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 14:35:54 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <761ada47-608b-02ef-e251-a028d6e679a9@blastwave.org> References: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> <20180911175748.GC3589@straasha.imrryr.org> <761ada47-608b-02ef-e251-a028d6e679a9@blastwave.org> Message-ID: <20180911183554.GD3589@straasha.imrryr.org> On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote: > >> It sounds like a downstream ELF header nightmare. > > > > Actually, it works just fine. You link with the variant library, > > and it happily coexists with any dependencies you may have that in > > turn depend on the system TLS library. The variant SONAME and > > symbol versions provide all the requisite isolation. You only > > pay the cost of customization for the handful of packages you > > want to have running against the non-default libraries. > > Mildly interesting in giving it a try. However I have 1.1.1 running and > tested fine on Solaris 10 sparc without any interferance from the system > provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set > to /usr/local/lib for everything I have built. One thing I've not tested, is isolation from system SSL libraries that don't employ symbol versions. Debian has been doing symbol versions for a long time, so I never needed to worry about that. And OpenSSL 1.1.0 has symbol versions on most platforms. I would assume that Solaris also has symbol versions for OpenSSL 1.0.x, but if it does not and that's the system's SSL library, then the variant build might not happily coexist with indirect dependencies in other shared libraries, haven't tried that. Regardless, you're no worse off than with the default SONAME and symbol versions. -- Viktor. From dclarke at blastwave.org Tue Sep 11 19:12:03 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Tue, 11 Sep 2018 15:12:03 -0400 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <20180911183554.GD3589@straasha.imrryr.org> References: <8C8B16AD-CF41-44E9-9CCE-78357C848095@dukhovni.org> <20180911175748.GC3589@straasha.imrryr.org> <761ada47-608b-02ef-e251-a028d6e679a9@blastwave.org> <20180911183554.GD3589@straasha.imrryr.org> Message-ID: On 09/11/2018 02:35 PM, Viktor Dukhovni wrote: > On Tue, Sep 11, 2018 at 02:28:12PM -0400, Dennis Clarke wrote: > >>>> It sounds like a downstream ELF header nightmare. >>> >>> Actually, it works just fine. You link with the variant library, >>> and it happily coexists with any dependencies you may have that in >>> turn depend on the system TLS library. The variant SONAME and >>> symbol versions provide all the requisite isolation. You only >>> pay the cost of customization for the handful of packages you >>> want to have running against the non-default libraries. >> >> Mildly interesting in giving it a try. However I have 1.1.1 running and >> tested fine on Solaris 10 sparc without any interferance from the system >> provided ( ORacle? ) ssl bits. However I do have RUNPATH and RPATH set >> to /usr/local/lib for everything I have built. > > One thing I've not tested, is isolation from system SSL libraries > that don't employ symbol versions. Debian has been doing symbol > versions for a long time, so I never needed to worry about that. > And OpenSSL 1.1.0 has symbol versions on most platforms. > > I would assume that Solaris also has symbol versions for OpenSSL > 1.0.x, but if it does not and that's the system's SSL library, then > the variant build might not happily coexist with indirect dependencies > in other shared libraries, haven't tried that. Regardless, you're > no worse off than with the default SONAME and symbol versions. > The GNU ld manual makes direct reference to ye old Solaris 2.5 as a sort of template for the format used. https://sourceware.org/binutils/docs/ld/VERSION.html but you won't find the section headers ( SHT_GNU_versym, SHT_GNU_verdef, and SHT_GNU_verneed ) in an ELF file on Solaris but SUNW_version has been around forever ( I think I saw it in 1994 ? ) : # elfdump -devl /usr/local/bin/openssl ELF Header ei_magic: { 0x7f, E, L, F } ei_class: ELFCLASS64 ei_data: ELFDATA2MSB ei_osabi: ELFOSABI_SOLARIS ei_abiversion: EAV_SUNW_CURRENT e_machine: EM_SPARCV9 e_version: EV_CURRENT e_type: ET_EXEC e_flags: [ EF_SPARCV9_TSO ] e_entry: 0x100020200 e_ehsize: 64 e_shstrndx: 29 e_shoff: 0x194bd78 e_shentsize: 64 e_shnum: 31 e_phoff: 0x40 e_phentsize: 56 e_phnum: 5 Version Needed Section: .SUNW_version index file version [2] libssl.so.1.1 OPENSSL_1_1_0 [ INFO ] [3] OPENSSL_1_1_1 [4] libcrypto.so.1.1 OPENSSL_1_1_0 [ INFO ] [5] OPENSSL_1_1_1 [6] libsocket.so.1 SUNW_0.7 [7] librt.so.1 SUNW_1.2 [8] SUNW_1.1 [ INFO ] [9] libpthread.so.1 SUNW_1.2 [10] SUNW_0.9 [ INFO ] [11] libc.so.1 SUNW_1.21.2 [12] SUNW_1.1 [ INFO ] [13] SUNW_0.7 [ INFO ] Dynamic Section: .dynamic index tag value [0] NEEDED 0x86d5 libssl.so.1.1 [1] NEEDED 0x86ff libcrypto.so.1.1 [2] NEEDED 0x8710 libsocket.so.1 [3] NEEDED 0x8774 libnsl.so.1 [4] NEEDED 0x8780 libdl.so.1 [5] NEEDED 0x8728 librt.so.1 [6] NEEDED 0x8745 libpthread.so.1 [7] NEEDED 0x875e libc.so.1 [8] INIT 0x100904ff8 [9] FINI 0x100905008 [10] RUNPATH 0x878b /usr/local/lib [11] RPATH 0x878b /usr/local/lib [12] HASH 0x100000178 [13] STRTAB 0x10000e710 [14] STRSZ 0x899a [15] SYMTAB 0x100003b08 [16] SYMENT 0x18 [17] CHECKSUM 0x9857 [18] VERNEED 0x1000170b0 [19] VERNEEDNUM 0x6 [20] PLTRELSZ 0x7e48 [21] PLTREL 0x7 [22] JMPREL 0x1000183b8 [23] RELA 0x100018028 [24] RELASZ 0x81d8 [25] RELAENT 0x18 [26] DEBUG 0 [27] FLAGS 0 0 [28] FLAGS_1 0 0 [29] SUNW_STRPAD 0x200 [30] SUNW_LDMACH 0x2b EM_SPARCV9 [31] PLTGOT 0x100a26700 [32-42] NULL 0 jupiter # Anyways .. the whole mess started with Sun's versioning concepts and it was Ulrich Drepper that did the first implementation in glibc 2.1 with Eric Youngdale who also bolted in "symbol-level versioning with multiple definitions of a symbol." : https://www.akkadia.org/drepper/symbol-versioning As for the sections that GNU ld type tools are looking for .. nope .. no such things in ye Solaris implementation. I'll take a gander at FreeBSD which does use the GNU tools. Dennis From ian.f.kelly at gmail.com Tue Sep 11 19:27:25 2018 From: ian.f.kelly at gmail.com (Strife1817) Date: Tue, 11 Sep 2018 12:27:25 -0700 (MST) Subject: [openssl-users] OpenSSL 1.0.2p w/ FIPS 2.0.16 - Apache 2.4.29 Message-ID: <1536694045663-0.post@n7.nabble.com> Noticing that my earlier attempts to compile Apache were not FIPS compliant, I set off to correct my error. I found the wiki, that provides the steps for building Apache with FIPS. Every time that it attempts to compile the SSL module, it dies. "mod_ssl.c", line 41: warning: syntax error: empty declaration "mod_ssl.c", line 398: warning: implicit function declaration: OPENSSL_malloc_init cc: acomp failed for mod_ssl.c *** Error code 1 make: Fatal error: Command failed for target `mod_ssl.lo' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules/ssl *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' '; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z 'libmod_ssl.la'; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules/ssl *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' aaa cache core database debugging filters http loggers metadata session slotmem ssl arch/unix dav/main generators dav/fs mappers'; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z ''; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' Current working directory /export/home/kellyi/Apache-2.4-Test/httpd-2.4.29/modules *** Error code 1 The following command caused the error: otarget=`echo all-recursive|sed s/-recursive//`; \ list=' srclib os server modules support'; \ for i in $list; do \ if test -d "$i"; then \ target="$otarget"; \ echo "Making $target in $i"; \ if test "$i" = "."; then \ made_local=yes; \ target="local-$target"; \ fi; \ (cd $i && make $target) || exit 1; \ fi; \ done; \ if test "$otarget" = "all" && test -z 'httpd shared-build '; then \ made_local=yes; \ fi; \ if test "$made_local" != "yes"; then \ make "local-$otarget" || exit 1; \ fi make: Fatal error: Command failed for target `all-recursive' However, now that I go back and look at openssl again, I see that there issues with it, as well. Here is the result from attempting to rebuild openssl. making all in crypto... /usr/bin/perl ../util/mkbuildinf.pl "/opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM" "solaris-sparcv9-cc" >buildinf.h /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c cryptlib.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c mem.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c mem_dbg.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c cversion.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c ex_data.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c cpt_err.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c ebcdic.c "ebcdic.c", line 9: warning: empty translation unit /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c uid.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c o_time.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c o_str.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c o_dir.c /opt/developerstudio12.6/bin/cc -I. -I.. -I../include -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c o_fips.c "o_fips.c", line 61: cannot find include file: "o_fips.c", line 62: cannot find include file: "o_fips.c", line 70: warning: implicit function declaration: FIPS_module_mode "o_fips.c", line 83: warning: implicit function declaration: FIPS_module_mode_set "o_fips.c", line 86: warning: implicit function declaration: FIPS_rand_get_method "o_fips.c", line 86: warning: improper pointer/integer combination: arg #1 cc: acomp failed for o_fips.c *** Error code 2 make: Fatal error: Command failed for target `o_fips.o' Current working directory /export/home/kellyi/openssl/openssl-1.0.2p/crypto *** Error code 1 The following command caused the error: dir=crypto; target=all; if expr " crypto ssl engines apps test tools " : ".* $dir " >/dev/null 2>&1; then if [ -d "$dir" ]; then ( cd $dir && echo "making $target in $dir..." && TOP= && unset TOP ${LIB+LIB} ${LIBS+LIBS} ${INCLUDE+INCLUDE} ${INCLUDES+INCLUDES} ${DIR+DIR} ${DIRS+DIRS} ${SRC+SRC} ${LIBSRC+LIBSRC} ${LIBOBJ+LIBOBJ} ${ALL+ALL} ${EXHEADER+EXHEADER} ${HEADER+HEADER} ${GENERAL+GENERAL} ${CFLAGS+CFLAGS} ${ASFLAGS+ASFLAGS} ${AFLAGS+AFLAGS} ${LDCMD+LDCMD} ${LDFLAGS+LDFLAGS} ${SCRIPTS+SCRIPTS} ${SHAREDCMD+SHAREDCMD} ${SHAREDFLAGS+SHAREDFLAGS} ${SHARED_LIB+SHARED_LIB} ${LIBEXTRAS+LIBEXTRAS} ${APPS+APPS} && make -e LC_ALL=C PLATFORM='solaris-sparcv9-cc' PROCESSOR='' CC='/opt/developerstudio12.6/bin/cc' CFLAG='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM' AS='/opt/developerstudio12.6/bin/cc' ASFLAG='-DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -m32 -xarch=sparc -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -I/usr/local/ssl/fips-2.0/include -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DGHASH_ASM -c' AR='ar r' NM='nm' RANLIB='/usr/ccs/bin/ranlib' RC='windres' CROSS_COMPILE='' PERL='/usr/bin/perl' ENGDIRS='ccgost' SDIRS='objects md4 md5 sha mdc2 hmac ripemd whrlpool des aes rc2 rc4 idea bf cast camellia seed modes bn ec rsa dsa ecdsa dh ecdh dso engine buffer bio stack lhash rand err evp asn1 pem x509 x509v3 conf txt_db pkcs7 pkcs12 comp ocsp ui krb5 cms pqueue ts srp cmac' LIBRPATH='/usr/local/ssl/lib' INSTALL_PREFIX='' INSTALLTOP='/usr/local/ssl' OPENSSLDIR='/usr/local/ssl/ssl' LIBDIR='lib' MAKEDEPEND='$${TOP}/util/domd $${TOP} -MD makedepend' DEPFLAG='-DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_RSAX -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS' MAKEDEPPROG='makedepend' SHARED_LDFLAGS='-G -dy -z text' KRB5_INCLUDES='' LIBKRB5='' ZLIB_INCLUDE='' LIBZLIB='' EXE_EXT='' SHARED_LIBS='' SHLIB_EXT='.so.1.0.0' SHLIB_TARGET='solaris-shared' PEX_LIBS='' EX_LIBS='-lsocket -lnsl -ldl' CPUID_OBJ='sparcv9cap.o sparccpuid.o' BN_ASM='bn-sparcv9.o sparcv9-mont.o sparcv9a-mont.o vis3-mont.o sparct4-mont.o sparcv9-gf2m.o' EC_ASM='' DES_ENC='des_enc-sparc.o fcrypt_b.o dest4-sparcv9.o' AES_ENC='aes_core.o aes_cbc.o aes-sparcv9.o aest4-sparcv9.o' CMLL_ENC='camellia.o cmll_misc.o cmll_cbc.o cmllt4-sparcv9.o' BF_ENC='bf_enc.o' CAST_ENC='c_enc.o' RC4_ENC='rc4_enc.o rc4_skey.o' RC5_ENC='rc5_enc.o' SHA1_ASM_OBJ='sha1-sparcv9.o sha256-sparcv9.o sha512-sparcv9.o' MD5_ASM_OBJ='md5-sparcv9.o' RMD160_ASM_OBJ='' WP_ASM_OBJ='wp_block.o' MODES_ASM_OBJ='ghash-sparcv9.o' ENGINES_ASM_OBJ='' PERLASM_SCHEME='void' FIPSLIBDIR='/usr/local/ssl/fips-2.0/lib/' FIPSDIR='/usr/local/ssl/fips-2.0' FIPSCANLIB="${FIPSCANLIB:-libcrypto}" THIS=${THIS:-build_crypto} MAKEFILE=Makefile MAKEOVERRIDES= TOP=.. DIR=$dir $target ) || exit 1; fi; fi make: Fatal error: Command failed for target `build_crypto' Please respond as soon as you are able, if you are able to assist. I need to try to get this upgrade completed this week, because I am moving to a different job; next week. It will be difficult for me to be able to get back to assist with this. Thanks for your time, and attention to this. Ian -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From bkaduk at akamai.com Tue Sep 11 19:57:09 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 11 Sep 2018 14:57:09 -0500 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911164840.GA87295@doctor.nl2k.ab.ca> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <20180911164840.GA87295@doctor.nl2k.ab.ca> Message-ID: <20180911195709.GG5819@akamai.com> On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > Looks likes I found a first bug > > > > ../test/recipes/70-test_comp.t ..................... > > Proxy started on port [::1]:10789 > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > engine "ossltest" set. > > Using default temp DH parameters > > ACCEPT [::1]:39577 > > Server responds on [::1]:39577 > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > Using perl 5.28.1 The test suite needs some modules not included in the core perl port/package. You should probably list out what p5-* you have installed. Also, do you have any IPv6 addresses configured? -Ben From openssl-users at dukhovni.org Tue Sep 11 20:08:40 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 16:08:40 -0400 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911195709.GG5819@akamai.com> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <20180911164840.GA87295@doctor.nl2k.ab.ca> <20180911195709.GG5819@akamai.com> Message-ID: <4D55AA48-3F6C-44BC-B4FD-A7BC646A3497@dukhovni.org> > On Sep 11, 2018, at 3:57 PM, Benjamin Kaduk via openssl-users wrote: > >>> panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 >>> >> >> Using perl 5.28.1 Thanks for the hint, I was looking too close at the panic... This is a Perl issue, with an XSUB routine pushing more arguments onto the stack than the stack can hold. Sure does not look like an OpenSSL issue... Perhaps similar to: http://code.activestate.com/lists/perl5-porters/240289/ https://rt.perl.org/Public/Bug/Display.html?id=133327 I have Perl 5.26 and all is well... -- Viktor. From doctor at doctor.nl2k.ab.ca Tue Sep 11 21:04:06 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 15:04:06 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911195709.GG5819@akamai.com> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <20180911164840.GA87295@doctor.nl2k.ab.ca> <20180911195709.GG5819@akamai.com> Message-ID: <20180911210406.GA43209@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users wrote: > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > Looks likes I found a first bug > > > > > > ../test/recipes/70-test_comp.t ..................... > > > Proxy started on port [::1]:10789 > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > engine "ossltest" set. > > > Using default temp DH parameters > > > ACCEPT [::1]:39577 > > > Server responds on [::1]:39577 > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > Using perl 5.28.1 > > The test suite needs some modules not included in the core perl port/package. > You should probably list out what p5-* you have installed. p5-Archive-Zip-1.63 Create, manipulate, read, and write Zip archive files p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module p5-Authen-PAM-0.16_2 Perl interface to the PAM library p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication p5-Business-ISBN-3.004 Work with International Standard Book Numbers p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN p5-CGI-4.40 Handle Common Gateway Interface requests and responses p5-Class-Inspector-1.32 Provides information about classes p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data structures p5-Convert-BinHex-1.125 Perl module to extract data from Macintosh BinHex files p5-Convert-TNEF-0.18_1 Perl module to read TNEF files p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic p5-Crypt-OpenSSL-Guess-0.11 Guess OpenSSL include path p5-Crypt-OpenSSL-RSA-0.30_1 Perl5 module to RSA encode and decode strings using OpenSSL p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random number generator p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make https connections p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through the DBI p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface (DBI) p5-DBI-1.641 Perl5 Database Interface, required for DBD::* modules p5-Data-Dump-1.23_1 Pretty printing of data structures p5-Date-EzDate-1.16 Date and time manipulation made easy p5-Devel-CheckLib-1.13 Check that a library is available p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble babble" format p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest Algorithms p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm p5-Encode-Detect-1.01_1 Encode::Encoding subclass that detects the encoding of data p5-Encode-Locale-1.05 Determine the locale encoding p5-Error-0.17026 Error/exception handling in object-oriented programming style p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS extensions p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config p5-File-Listing-6.04_1 Parse directory listings p5-File-ShareDir-1.116 Locate per-dist and per-module shared files p5-File-ShareDir-Install-0.13 Install read-only data files from a distribution p5-Filesys-Df-0.92_1 Perl extension for filesystem space p5-Filter-1.59 Number of source filters for perl5 programs p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD p5-GSSAPI-0.28_1 Perl extension providing access to the GSSAPIv2 library p5-Geo-IP-1.51 Gets country name by IP or hostname p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes p5-Glib2-1.327 This module provides access to Glib and GObject libraries p5-HTML-Parser-3.72 Perl5 module for parsing HTML documents p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML p5-HTTP-Cookies-6.04 HTTP Cookie jars p5-HTTP-Daemon-6.01_1 Simple HTTP server class p5-HTTP-Date-6.02_1 Conversion routines for the HTTP protocol date formats p5-HTTP-Message-6.18 Representation of HTTP style messages p5-HTTP-Negotiate-6.01_1 Implementation of the HTTP content negotiation algorithm p5-IO-HTML-1.001_1 Open an HTML file with automatic charset detection p5-IO-Socket-INET6-2.72_1 Perl module with object interface to AF_INET6 domain sockets p5-IO-Socket-SSL-2.059 Perl5 interface to SSL sockets p5-IO-String-1.08_1 Simplified Perl5 module to handle I/O on in-core strings p5-IO-Tty-1.12_2 Flexible I/O Perl5 module that allows manipulation of pseudo-TTYs p5-IO-stringy-2.111 Use IO handles with non-file objects p5-IP-Country-2.28_1 Fast lookup of country codes from IP addresses p5-Inline-0.80 Write Perl subroutines in other programming languages p5-Inline-C-0.78 Write Perl Subroutines in C p5-JSON-2.97.001 Perl extension to convert to JSON (JavaScript Object Notation) p5-JSON-XS-3.04 JSON serialising/deserialising, done correctly and fast p5-LWP-MediaTypes-6.02_1 Guess media type for a file or a URL p5-LWP-Protocol-https-6.07_1 Provide https support for LWP::UserAgent p5-Locale-gettext-1.07 Message handling functions p5-MIME-Tools-5.509,2 Set of perl5 modules for MIME p5-Mail-ClamAV-0.29_4 Perl extension for the clamav virus scanner p5-Mail-DKIM-0.53 Perl5 module to process and/or create DKIM email p5-Mail-IMAPClient-3.39 Perl5 module to talk to a IMAP4rev1 (RFC2060) server p5-Mail-SPF-2.9.0_4 Object-oriented implementation of Sender Policy Framework p5-Mail-Tools-2.19 Perl5 modules for dealing with Internet e-mail messages p5-Module-Build-0.4224 Build and install Perl modules p5-Mozilla-CA-20180117 Perl extension for Mozilla CA cert bundle in PEM format p5-Net-CIDR-0.19 Perl module to manipulate IPv4/IPv6 netblocks in CIDR notation p5-Net-CIDR-Lite-0.21_1 Perl extension for merging IPv4 or IPv6 CIDR addresses p5-Net-DNS-1.17,1 Perl5 interface to the DNS resolver, and dynamic updates p5-Net-DNS-Resolver-Mock-1.20171219 Mock a DNS Resolver object for testing p5-Net-DNS-Resolver-Programmable-0.009 Programmable DNS resolver for off-line testing p5-Net-Daemon-0.48_1 Perl5 extension for portable daemons p5-Net-HTTP-6.18 Low-level HTTP client p5-Net-IDN-Encode-2.400 Internationalizing Domain Names in Applications (RFC 3490) p5-Net-IP-1.26_1 Perl extension for manipulating IPv4/IPv6 addresses p5-Net-Ident-1.23_1 Lookup the username on the remote end of a TCP/IP connection p5-Net-LDAP-Server-0.43_1 Perl module for LDAP server side protocol handling p5-Net-LibIDN-0.12_4 This module provides access to the libidn library p5-Net-LibIDN2-1.00 Perl bindings for GNU Libidn2 p5-Net-SSLeay-1.85 Perl5 interface to SSL p5-NetAddr-IP-4.079 Work with IPv4 and IPv6 addresses and subnets p5-Number-Format-1.75 Perl extension for formatting numbers p5-OLE-Storage_Lite-0.19_1 Perl module for OLE document interface p5-Parse-RecDescent-1.967.009_2 Recursive descent parsing framework for Perl p5-Parse-Yapp-1.05_2 Perl extension for generating and using LALR parsers p5-Path-Class-0.37 Cross-platform path specification manipulation p5-Pegex-0.66 Acmeist PEG Parser Framework p5-PlRPC-0.2020_2 Perl module for writing RPC servers and clients p5-Socket6-0.28 IPv6 related part of the C socket.h defines and structure manipulators p5-Switch-2.17_1 Switch - A switch statement for Perl p5-Sys-Hostname-Long-1.5_1 Try every conceivable way to get full hostname p5-Sys-SigAction-0.23 Perl extension for Consistent Signal Handling p5-Term-ReadKey-2.37 Perl5 module for simple terminal control p5-Test-Manifest-2.021 Perl module to interact with a t/test_manifest file p5-Test-NoWarnings-1.04_2 Hide and store warnings while running test scripts p5-Text-Soundex-3.05 Implementation of the soundex algorithm p5-Time-Local-1.28 Efficiently compute time from local and GMT time p5-TimeDate-2.30_2,1 Perl5 module containing a better/faster date parser for absolute dates p5-Try-Tiny-0.28 Minimal try/catch with proper localization of $@ p5-Types-Serialiser-1.0_1 Simple data types for common serialisation formats p5-URI-1.74 Perl5 interface to Uniform Resource Identifier (URI) references p5-WWW-RobotRules-6.02_1 Database of robots.txt-derived permissions p5-XML-Filter-BufferText-1.01_1 Filter to put all characters() in one event p5-XML-LibXML-2.0132,1 Interface to Gnome libxml2 library p5-XML-NamespaceSupport-1.12 Simple generic namespace support class p5-XML-Parser-2.44 Perl extension interface to James Clark's XML parser, expat p5-XML-SAX-1.00 Simple API for XML p5-XML-SAX-Base-1.09 Base class SAX Drivers and Filters p5-XML-SAX-Expat-0.51_1 Simple API for XML p5-XML-SAX-Writer-0.57 SAX2 XML Writer p5-XML-Simple-2.25 Trivial API for reading and writing XML (esp config files) p5-YAML-LibYAML-0.72 Perl YAML Serialization using XS and libyaml p5-common-sense-3.74 Perl common defaults with lower memory usage p5-libwww-6.35 Perl5 library for WWW access p5-perl-ldap-0.6500 Client interface to LDAP (includes Net::LDAP) p5-subversion-1.10.2_1 Perl bindings for Version control system > Also, do you have any IPv6 addresses configured? > No. But the test was localhost based. > -Ben > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From bkaduk at akamai.com Tue Sep 11 21:09:48 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Tue, 11 Sep 2018 16:09:48 -0500 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911210406.GA43209@doctor.nl2k.ab.ca> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <20180911164840.GA87295@doctor.nl2k.ab.ca> <20180911195709.GG5819@akamai.com> <20180911210406.GA43209@doctor.nl2k.ab.ca> Message-ID: <20180911210948.GH5819@akamai.com> On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users wrote: > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > > Looks likes I found a first bug > > > > > > > > ../test/recipes/70-test_comp.t ..................... > > > > Proxy started on port [::1]:10789 > > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > > engine "ossltest" set. > > > > Using default temp DH parameters > > > > ACCEPT [::1]:39577 > > > > Server responds on [::1]:39577 > > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > > > > Using perl 5.28.1 > > > > The test suite needs some modules not included in the core perl port/package. > > You should probably list out what p5-* you have installed. > > > p5-Archive-Zip-1.63 Create, manipulate, read, and write Zip archive files > p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module > p5-Authen-PAM-0.16_2 Perl interface to the PAM library > p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication > p5-Business-ISBN-3.004 Work with International Standard Book Numbers > p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN > p5-CGI-4.40 Handle Common Gateway Interface requests and responses > p5-Class-Inspector-1.32 Provides information about classes > p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data structures > p5-Convert-BinHex-1.125 Perl module to extract data from Macintosh BinHex files > p5-Convert-TNEF-0.18_1 Perl module to read TNEF files > p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic > p5-Crypt-OpenSSL-Guess-0.11 Guess OpenSSL include path > p5-Crypt-OpenSSL-RSA-0.30_1 Perl5 module to RSA encode and decode strings using OpenSSL > p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random number generator > p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make https connections > p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through the DBI > p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface (DBI) > p5-DBI-1.641 Perl5 Database Interface, required for DBD::* modules > p5-Data-Dump-1.23_1 Pretty printing of data structures > p5-Date-EzDate-1.16 Date and time manipulation made easy > p5-Devel-CheckLib-1.13 Check that a library is available > p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble babble" format > p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest Algorithms > p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm > p5-Encode-Detect-1.01_1 Encode::Encoding subclass that detects the encoding of data > p5-Encode-Locale-1.05 Determine the locale encoding > p5-Error-0.17026 Error/exception handling in object-oriented programming style > p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS extensions > p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config > p5-File-Listing-6.04_1 Parse directory listings > p5-File-ShareDir-1.116 Locate per-dist and per-module shared files > p5-File-ShareDir-Install-0.13 Install read-only data files from a distribution > p5-Filesys-Df-0.92_1 Perl extension for filesystem space > p5-Filter-1.59 Number of source filters for perl5 programs > p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 > p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD > p5-GSSAPI-0.28_1 Perl extension providing access to the GSSAPIv2 library > p5-Geo-IP-1.51 Gets country name by IP or hostname > p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes > p5-Glib2-1.327 This module provides access to Glib and GObject libraries > p5-HTML-Parser-3.72 Perl5 module for parsing HTML documents > p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML > p5-HTTP-Cookies-6.04 HTTP Cookie jars > p5-HTTP-Daemon-6.01_1 Simple HTTP server class > p5-HTTP-Date-6.02_1 Conversion routines for the HTTP protocol date formats > p5-HTTP-Message-6.18 Representation of HTTP style messages > p5-HTTP-Negotiate-6.01_1 Implementation of the HTTP content negotiation algorithm > p5-IO-HTML-1.001_1 Open an HTML file with automatic charset detection > p5-IO-Socket-INET6-2.72_1 Perl module with object interface to AF_INET6 domain sockets > p5-IO-Socket-SSL-2.059 Perl5 interface to SSL sockets > p5-IO-String-1.08_1 Simplified Perl5 module to handle I/O on in-core strings > p5-IO-Tty-1.12_2 Flexible I/O Perl5 module that allows manipulation of pseudo-TTYs > p5-IO-stringy-2.111 Use IO handles with non-file objects > p5-IP-Country-2.28_1 Fast lookup of country codes from IP addresses > p5-Inline-0.80 Write Perl subroutines in other programming languages > p5-Inline-C-0.78 Write Perl Subroutines in C > p5-JSON-2.97.001 Perl extension to convert to JSON (JavaScript Object Notation) > p5-JSON-XS-3.04 JSON serialising/deserialising, done correctly and fast > p5-LWP-MediaTypes-6.02_1 Guess media type for a file or a URL > p5-LWP-Protocol-https-6.07_1 Provide https support for LWP::UserAgent > p5-Locale-gettext-1.07 Message handling functions > p5-MIME-Tools-5.509,2 Set of perl5 modules for MIME > p5-Mail-ClamAV-0.29_4 Perl extension for the clamav virus scanner > p5-Mail-DKIM-0.53 Perl5 module to process and/or create DKIM email > p5-Mail-IMAPClient-3.39 Perl5 module to talk to a IMAP4rev1 (RFC2060) server > p5-Mail-SPF-2.9.0_4 Object-oriented implementation of Sender Policy Framework > p5-Mail-Tools-2.19 Perl5 modules for dealing with Internet e-mail messages > p5-Module-Build-0.4224 Build and install Perl modules > p5-Mozilla-CA-20180117 Perl extension for Mozilla CA cert bundle in PEM format > p5-Net-CIDR-0.19 Perl module to manipulate IPv4/IPv6 netblocks in CIDR notation > p5-Net-CIDR-Lite-0.21_1 Perl extension for merging IPv4 or IPv6 CIDR addresses > p5-Net-DNS-1.17,1 Perl5 interface to the DNS resolver, and dynamic updates > p5-Net-DNS-Resolver-Mock-1.20171219 Mock a DNS Resolver object for testing > p5-Net-DNS-Resolver-Programmable-0.009 Programmable DNS resolver for off-line testing > p5-Net-Daemon-0.48_1 Perl5 extension for portable daemons > p5-Net-HTTP-6.18 Low-level HTTP client > p5-Net-IDN-Encode-2.400 Internationalizing Domain Names in Applications (RFC 3490) > p5-Net-IP-1.26_1 Perl extension for manipulating IPv4/IPv6 addresses > p5-Net-Ident-1.23_1 Lookup the username on the remote end of a TCP/IP connection > p5-Net-LDAP-Server-0.43_1 Perl module for LDAP server side protocol handling > p5-Net-LibIDN-0.12_4 This module provides access to the libidn library > p5-Net-LibIDN2-1.00 Perl bindings for GNU Libidn2 > p5-Net-SSLeay-1.85 Perl5 interface to SSL > p5-NetAddr-IP-4.079 Work with IPv4 and IPv6 addresses and subnets > p5-Number-Format-1.75 Perl extension for formatting numbers > p5-OLE-Storage_Lite-0.19_1 Perl module for OLE document interface > p5-Parse-RecDescent-1.967.009_2 Recursive descent parsing framework for Perl > p5-Parse-Yapp-1.05_2 Perl extension for generating and using LALR parsers > p5-Path-Class-0.37 Cross-platform path specification manipulation > p5-Pegex-0.66 Acmeist PEG Parser Framework > p5-PlRPC-0.2020_2 Perl module for writing RPC servers and clients > p5-Socket6-0.28 IPv6 related part of the C socket.h defines and structure manipulators > p5-Switch-2.17_1 Switch - A switch statement for Perl > p5-Sys-Hostname-Long-1.5_1 Try every conceivable way to get full hostname > p5-Sys-SigAction-0.23 Perl extension for Consistent Signal Handling > p5-Term-ReadKey-2.37 Perl5 module for simple terminal control > p5-Test-Manifest-2.021 Perl module to interact with a t/test_manifest file > p5-Test-NoWarnings-1.04_2 Hide and store warnings while running test scripts > p5-Text-Soundex-3.05 Implementation of the soundex algorithm > p5-Time-Local-1.28 Efficiently compute time from local and GMT time > p5-TimeDate-2.30_2,1 Perl5 module containing a better/faster date parser for absolute dates > p5-Try-Tiny-0.28 Minimal try/catch with proper localization of $@ > p5-Types-Serialiser-1.0_1 Simple data types for common serialisation formats > p5-URI-1.74 Perl5 interface to Uniform Resource Identifier (URI) references > p5-WWW-RobotRules-6.02_1 Database of robots.txt-derived permissions > p5-XML-Filter-BufferText-1.01_1 Filter to put all characters() in one event > p5-XML-LibXML-2.0132,1 Interface to Gnome libxml2 library > p5-XML-NamespaceSupport-1.12 Simple generic namespace support class > p5-XML-Parser-2.44 Perl extension interface to James Clark's XML parser, expat > p5-XML-SAX-1.00 Simple API for XML > p5-XML-SAX-Base-1.09 Base class SAX Drivers and Filters > p5-XML-SAX-Expat-0.51_1 Simple API for XML > p5-XML-SAX-Writer-0.57 SAX2 XML Writer > p5-XML-Simple-2.25 Trivial API for reading and writing XML (esp config files) > p5-YAML-LibYAML-0.72 Perl YAML Serialization using XS and libyaml > p5-common-sense-3.74 Perl common defaults with lower memory usage > p5-libwww-6.35 Perl5 library for WWW access > p5-perl-ldap-0.6500 Client interface to LDAP (includes Net::LDAP) > p5-subversion-1.10.2_1 Perl bindings for Version control system Thanks. My memory of what I did for my machine's setup is a bit hazy, but could you try installing p5-Socket and repeating the tests? > > Also, do you have any IPv6 addresses configured? > > > > No. > > But the test was localhost based. Okay. Thanks! -Ben From jcsible at cert.org Tue Sep 11 20:55:36 2018 From: jcsible at cert.org (Joseph Christopher Sible) Date: Tue, 11 Sep 2018 20:55:36 +0000 Subject: [openssl-users] Curves and ECDHParameters Message-ID: <1536699336.24353.3.camel@cert.org> What exactly are each of "Curves" and "ECDHParameters" used for, as documented by https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html? My understanding of elliptic curves in TLS is that they're used in two places: as ECDSA key pairs used in certificates, and in ECDHE for key exchange. (Are there more uses I'm not aware of?) I know the curve used for ECDSA is a property of the key pair associated with the certificate, so it doesn't make sense to be a setting controlled at runtime. My best guess is that the curve for ECDHE is controlled by ECDHParameters. Given all of this, I can't figure out what's left for the "Curves" parameter to control. Are my above assumptions right? If so, what does "Curves" control? Joseph C. Sible From doctor at doctor.nl2k.ab.ca Tue Sep 11 21:42:22 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Tue, 11 Sep 2018 15:42:22 -0600 Subject: [openssl-users] openssl 1.1.1 and FreeBSD 11.2 In-Reply-To: <20180911210948.GH5819@akamai.com> References: <20180911153336.GA64283@doctor.nl2k.ab.ca> <20180911164840.GA87295@doctor.nl2k.ab.ca> <20180911195709.GG5819@akamai.com> <20180911210406.GA43209@doctor.nl2k.ab.ca> <20180911210948.GH5819@akamai.com> Message-ID: <20180911214222.GA52466@doctor.nl2k.ab.ca> On Tue, Sep 11, 2018 at 04:09:48PM -0500, Benjamin Kaduk wrote: > On Tue, Sep 11, 2018 at 03:04:06PM -0600, The Doctor wrote: > > On Tue, Sep 11, 2018 at 02:57:09PM -0500, Benjamin Kaduk via openssl-users wrote: > > > On Tue, Sep 11, 2018 at 10:48:40AM -0600, The Doctor wrote: > > > > On Tue, Sep 11, 2018 at 09:33:36AM -0600, The Doctor wrote: > > > > > Looks likes I found a first bug > > > > > > > > > > ../test/recipes/70-test_comp.t ..................... > > > > > Proxy started on port [::1]:10789 > > > > > Server command: ../../util/shlib_wrap.sh ../../apps/openssl s_server -max_protocol TLSv1.3 -no_comp -rev -engine ossltest -ext_cache -accept [::1]:0 -cert ../../apps/server.pem -cert2 ../../apps/server.pem -naccept 1 -cipher AES128-SHA -ciphersuites TLS_AES_128_GCM_SHA256 > > > > > engine "ossltest" set. > > > > > Using default temp DH parameters > > > > > ACCEPT [::1]:39577 > > > > > Server responds on [::1]:39577 > > > > > panic: XSUB Socket6::getaddrinfo (Socket6.c) failed to extend arg stack: base=805d16098, sp=805d160e8, hwm=805d160d0 > > > > > > > > > > > > > Using perl 5.28.1 > > > > > > The test suite needs some modules not included in the core perl port/package. > > > You should probably list out what p5-* you have installed. > > > > > > p5-Archive-Zip-1.63 Create, manipulate, read, and write Zip archive files > > p5-Authen-NTLM-1.09_1 Perl5 NTLM authentication module > > p5-Authen-PAM-0.16_2 Perl interface to the PAM library > > p5-Authen-SASL-2.16_1 Perl5 module for SASL authentication > > p5-Business-ISBN-3.004 Work with International Standard Book Numbers > > p5-Business-ISBN-Data-20140910.003 Data pack for Business::ISBN > > p5-CGI-4.40 Handle Common Gateway Interface requests and responses > > p5-Class-Inspector-1.32 Provides information about classes > > p5-Convert-ASN1-0.27_2 Perl5 module to encode and decode ASN.1 data structures > > p5-Convert-BinHex-1.125 Perl module to extract data from Macintosh BinHex files > > p5-Convert-TNEF-0.18_1 Perl module to read TNEF files > > p5-Crypt-OpenSSL-Bignum-0.09 OpenSSL's multiprecision integer arithmetic > > p5-Crypt-OpenSSL-Guess-0.11 Guess OpenSSL include path > > p5-Crypt-OpenSSL-RSA-0.30_1 Perl5 module to RSA encode and decode strings using OpenSSL > > p5-Crypt-OpenSSL-Random-0.15 Perl5 interface to the OpenSSL pseudo-random number generator > > p5-Crypt-SSLeay-0.72_3 Perl5 interface to allow p5-libwww LWP to make https connections > > p5-DBD-SQLite-1.58 Provides access to SQLite3 databases through the DBI > > p5-DBD-mysql-4.046 MySQL driver for the Perl5 Database Interface (DBI) > > p5-DBI-1.641 Perl5 Database Interface, required for DBD::* modules > > p5-Data-Dump-1.23_1 Pretty printing of data structures > > p5-Date-EzDate-1.16 Date and time manipulation made easy > > p5-Devel-CheckLib-1.13 Check that a library is available > > p5-Digest-BubbleBabble-0.02_1 Perl5 interface to a fingerprint in "bubble babble" format > > p5-Digest-HMAC-1.03_1 Perl5 interface to HMAC Message-Digest Algorithms > > p5-Digest-SHA1-2.13_1 Perl interface to the SHA-1 Algorithm > > p5-Encode-Detect-1.01_1 Encode::Encoding subclass that detects the encoding of data > > p5-Encode-Locale-1.05 Determine the locale encoding > > p5-Error-0.17026 Error/exception handling in object-oriented programming style > > p5-ExtUtils-Depends-0.405 Easily build XS extensions that depend on XS extensions > > p5-ExtUtils-PkgConfig-1.16 Simplistic interface to pkg-config > > p5-File-Listing-6.04_1 Parse directory listings > > p5-File-ShareDir-1.116 Locate per-dist and per-module shared files > > p5-File-ShareDir-Install-0.13 Install read-only data files from a distribution > > p5-Filesys-Df-0.92_1 Perl extension for filesystem space > > p5-Filter-1.59 Number of source filters for perl5 programs > > p5-GD-2.68 Perl5 interface to Gd Graphics Library version2 > > p5-GD-Barcode-1.15_6 GD::Barcode - Create barcode image with GD > > p5-GSSAPI-0.28_1 Perl extension providing access to the GSSAPIv2 library > > p5-Geo-IP-1.51 Gets country name by IP or hostname > > p5-Geography-Countries-2009041301_1 Handle ISO-3166 country codes > > p5-Glib2-1.327 This module provides access to Glib and GObject libraries > > p5-HTML-Parser-3.72 Perl5 module for parsing HTML documents > > p5-HTML-Tagset-3.20_1 Some useful data table in parsing HTML > > p5-HTTP-Cookies-6.04 HTTP Cookie jars > > p5-HTTP-Daemon-6.01_1 Simple HTTP server class > > p5-HTTP-Date-6.02_1 Conversion routines for the HTTP protocol date formats > > p5-HTTP-Message-6.18 Representation of HTTP style messages > > p5-HTTP-Negotiate-6.01_1 Implementation of the HTTP content negotiation algorithm > > p5-IO-HTML-1.001_1 Open an HTML file with automatic charset detection > > p5-IO-Socket-INET6-2.72_1 Perl module with object interface to AF_INET6 domain sockets > > p5-IO-Socket-SSL-2.059 Perl5 interface to SSL sockets > > p5-IO-String-1.08_1 Simplified Perl5 module to handle I/O on in-core strings > > p5-IO-Tty-1.12_2 Flexible I/O Perl5 module that allows manipulation of pseudo-TTYs > > p5-IO-stringy-2.111 Use IO handles with non-file objects > > p5-IP-Country-2.28_1 Fast lookup of country codes from IP addresses > > p5-Inline-0.80 Write Perl subroutines in other programming languages > > p5-Inline-C-0.78 Write Perl Subroutines in C > > p5-JSON-2.97.001 Perl extension to convert to JSON (JavaScript Object Notation) > > p5-JSON-XS-3.04 JSON serialising/deserialising, done correctly and fast > > p5-LWP-MediaTypes-6.02_1 Guess media type for a file or a URL > > p5-LWP-Protocol-https-6.07_1 Provide https support for LWP::UserAgent > > p5-Locale-gettext-1.07 Message handling functions > > p5-MIME-Tools-5.509,2 Set of perl5 modules for MIME > > p5-Mail-ClamAV-0.29_4 Perl extension for the clamav virus scanner > > p5-Mail-DKIM-0.53 Perl5 module to process and/or create DKIM email > > p5-Mail-IMAPClient-3.39 Perl5 module to talk to a IMAP4rev1 (RFC2060) server > > p5-Mail-SPF-2.9.0_4 Object-oriented implementation of Sender Policy Framework > > p5-Mail-Tools-2.19 Perl5 modules for dealing with Internet e-mail messages > > p5-Module-Build-0.4224 Build and install Perl modules > > p5-Mozilla-CA-20180117 Perl extension for Mozilla CA cert bundle in PEM format > > p5-Net-CIDR-0.19 Perl module to manipulate IPv4/IPv6 netblocks in CIDR notation > > p5-Net-CIDR-Lite-0.21_1 Perl extension for merging IPv4 or IPv6 CIDR addresses > > p5-Net-DNS-1.17,1 Perl5 interface to the DNS resolver, and dynamic updates > > p5-Net-DNS-Resolver-Mock-1.20171219 Mock a DNS Resolver object for testing > > p5-Net-DNS-Resolver-Programmable-0.009 Programmable DNS resolver for off-line testing > > p5-Net-Daemon-0.48_1 Perl5 extension for portable daemons > > p5-Net-HTTP-6.18 Low-level HTTP client > > p5-Net-IDN-Encode-2.400 Internationalizing Domain Names in Applications (RFC 3490) > > p5-Net-IP-1.26_1 Perl extension for manipulating IPv4/IPv6 addresses > > p5-Net-Ident-1.23_1 Lookup the username on the remote end of a TCP/IP connection > > p5-Net-LDAP-Server-0.43_1 Perl module for LDAP server side protocol handling > > p5-Net-LibIDN-0.12_4 This module provides access to the libidn library > > p5-Net-LibIDN2-1.00 Perl bindings for GNU Libidn2 > > p5-Net-SSLeay-1.85 Perl5 interface to SSL > > p5-NetAddr-IP-4.079 Work with IPv4 and IPv6 addresses and subnets > > p5-Number-Format-1.75 Perl extension for formatting numbers > > p5-OLE-Storage_Lite-0.19_1 Perl module for OLE document interface > > p5-Parse-RecDescent-1.967.009_2 Recursive descent parsing framework for Perl > > p5-Parse-Yapp-1.05_2 Perl extension for generating and using LALR parsers > > p5-Path-Class-0.37 Cross-platform path specification manipulation > > p5-Pegex-0.66 Acmeist PEG Parser Framework > > p5-PlRPC-0.2020_2 Perl module for writing RPC servers and clients > > p5-Socket6-0.28 IPv6 related part of the C socket.h defines and structure manipulators > > p5-Switch-2.17_1 Switch - A switch statement for Perl > > p5-Sys-Hostname-Long-1.5_1 Try every conceivable way to get full hostname > > p5-Sys-SigAction-0.23 Perl extension for Consistent Signal Handling > > p5-Term-ReadKey-2.37 Perl5 module for simple terminal control > > p5-Test-Manifest-2.021 Perl module to interact with a t/test_manifest file > > p5-Test-NoWarnings-1.04_2 Hide and store warnings while running test scripts > > p5-Text-Soundex-3.05 Implementation of the soundex algorithm > > p5-Time-Local-1.28 Efficiently compute time from local and GMT time > > p5-TimeDate-2.30_2,1 Perl5 module containing a better/faster date parser for absolute dates > > p5-Try-Tiny-0.28 Minimal try/catch with proper localization of $@ > > p5-Types-Serialiser-1.0_1 Simple data types for common serialisation formats > > p5-URI-1.74 Perl5 interface to Uniform Resource Identifier (URI) references > > p5-WWW-RobotRules-6.02_1 Database of robots.txt-derived permissions > > p5-XML-Filter-BufferText-1.01_1 Filter to put all characters() in one event > > p5-XML-LibXML-2.0132,1 Interface to Gnome libxml2 library > > p5-XML-NamespaceSupport-1.12 Simple generic namespace support class > > p5-XML-Parser-2.44 Perl extension interface to James Clark's XML parser, expat > > p5-XML-SAX-1.00 Simple API for XML > > p5-XML-SAX-Base-1.09 Base class SAX Drivers and Filters > > p5-XML-SAX-Expat-0.51_1 Simple API for XML > > p5-XML-SAX-Writer-0.57 SAX2 XML Writer > > p5-XML-Simple-2.25 Trivial API for reading and writing XML (esp config files) > > p5-YAML-LibYAML-0.72 Perl YAML Serialization using XS and libyaml > > p5-common-sense-3.74 Perl common defaults with lower memory usage > > p5-libwww-6.35 Perl5 library for WWW access > > p5-perl-ldap-0.6500 Client interface to LDAP (includes Net::LDAP) > > p5-subversion-1.10.2_1 Perl bindings for Version control system > > Thanks. My memory of what I did for my machine's setup is a bit hazy, but could > you try installing p5-Socket and repeating the tests? > Same issue. > > > Also, do you have any IPv6 addresses configured? > > > > > > > No. > > > > But the test was localhost based. > > Okay. > > Thanks! > > -Ben -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From openssl-users at dukhovni.org Tue Sep 11 22:20:03 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 18:20:03 -0400 Subject: [openssl-users] Curves and ECDHParameters In-Reply-To: <1536699336.24353.3.camel@cert.org> References: <1536699336.24353.3.camel@cert.org> Message-ID: > On Sep 11, 2018, at 4:55 PM, Joseph Christopher Sible wrote: > > What exactly are each of "Curves" and "ECDHParameters" used for, as > documented by https://www.openssl.org/docs/man1.0.2/ssl/SSL_CONF_cmd.html? The documentation of OpenSSL 1.1.x does not mention "ECDHParameters", only "Curves" is documented as a synonym of "Groups". The 1.0.2 documentation for "ECDHParameters" explains that this is server-side setting to select a particular *fixed* ECDHE curve. This is a legacy feature that predates negotiation of the curve used based on the client's extension. -- Viktor. From openssl-users at dukhovni.org Tue Sep 11 22:41:36 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 18:41:36 -0400 Subject: [openssl-users] Curves and ECDHParameters In-Reply-To: References: <1536699336.24353.3.camel@cert.org> Message-ID: <3AFFAFEC-D8FD-45F8-8462-999E08D74AB4@dukhovni.org> > On Sep 11, 2018, at 6:20 PM, Viktor Dukhovni wrote: > > > The 1.0.2 documentation for "ECDHParameters" explains that this is > server-side setting to select a particular *fixed* ECDHE curve. > This is a legacy feature that predates negotiation of the curve > used based on the client's extension. That said, in 1.0.2, it may be necessary to set "ECDHParameters" to "Automatic" in order to enable ECDHE with Curve negotiation based on the (separately specified) Curves. I am not sure whether automatic ECDHE is on by default in 1.0.2, IIRC it may not be. -- Viktor. From jb-openssl at wisemo.com Wed Sep 12 01:57:37 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 12 Sep 2018 03:57:37 +0200 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> Message-ID: <7b50dafd-6e8c-b5fd-5ce6-e39a0dd15ac2@wisemo.com> On 11/09/2018 19:34, Viktor Dukhovni wrote: > >> On Sep 11, 2018, at 1:17 PM, Jordan Brown wrote: >> >> The key piece that I was missing - I hadn't looked at and thought about the protocol enough - was that there's no version-independent way for the server to fail. If the server supports only versions larger than the client supports, it has no way to say "no". If the positions are reversed, the server counter-offers a version that the client then rejects as too old. > In OpenSSL 1.1.x, though the server might not support continuing with the client's > maximum version, it is willing to do so just long enough to send a fatal protocol > version mismatch alert. It helps that SSL2/SSL3 are not supported, and TLS 1.0 > and up support the alert. > > Time to move to OpenSSL 1.1.x, it has many improvements, ... > Clarification question, as I cannot match what you wrote above with the changelog (NEWS) in the OpenSSL 1.1.1 tarball: - Does OpenSSL 1.1.1 include SSL3.0 support or not? Note that some real world clients are permanently stuck at SSL 3.0 due to the vendor refusing to release updates. 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 wrowe at rowe-clan.net Wed Sep 12 02:15:03 2018 From: wrowe at rowe-clan.net (William A Rowe Jr) Date: Tue, 11 Sep 2018 21:15:03 -0500 Subject: [openssl-users] Migrating to openssl 1.1.1 in real life linux server In-Reply-To: <20180911181000.GA2375@roeckx.be> References: <20180911181000.GA2375@roeckx.be> Message-ID: On Tue, Sep 11, 2018, 13:10 Kurt Roeckx wrote: > On Tue, Sep 11, 2018 at 04:59:45PM +0200, Juan Isoza wrote: > > Hello, > > > > What is the better way, for anyone running, by example, Apache or nginx > on > > a popular Linux districution (Ubuntu, Debian, Suse) and want support TLS > > 1.3 ? > > > > Waiting package update to have openssl 1.1.1 ? probably a lot of time > > > > Recompile openssl dynamic library and replace system library ? We must be > > sure we don't broke the system > > > > Recompile Apache or NGinx with openssl statically linked ? probably > complex > > Note that you most likely need an update of both nginx/apache and > openssl. > Note that httpd 2.4 released does not yet support TLS 1.3, although it compiles against the new OpenSSL, YMMV. Within the next two httpd releases, we would expect OpenSSL 1.1.1 TLS 1.3 support to be GA. In the interim there is a working branch for 1.1.1 compatibility merges, and svn trunk already supports it, if you want to live on the bleeding edge. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Wed Sep 12 02:38:21 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 11 Sep 2018 22:38:21 -0400 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <7b50dafd-6e8c-b5fd-5ce6-e39a0dd15ac2@wisemo.com> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> <7b50dafd-6e8c-b5fd-5ce6-e39a0dd15ac2@wisemo.com> Message-ID: <083E8CF2-6672-42E4-9F41-0C35B02E127C@dukhovni.org> > On Sep 11, 2018, at 9:57 PM, Jakob Bohm wrote: > > Clarification question, as I cannot match what you wrote above with > the changelog (NEWS) in the OpenSSL 1.1.1 tarball: > > - Does OpenSSL 1.1.1 include SSL3.0 support or not? The code is there, but it is disabled in default builds. You need to run: ./Configure enable-ssl3 ... to get SSL 3.0 support. -- Viktor. From openssl-users at dukhovni.org Wed Sep 12 05:21:18 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Sep 2018 01:21:18 -0400 Subject: [openssl-users] Version negotiation failure failure? In-Reply-To: <01010165cc372c56-698a75a1-b6d1-40d4-88ba-91fd3da39a3c-000000@us-west-2.amazonses.com> References: <93cf76d8-88d5-6c44-2790-630a870482ef@jordan.maileater.net> <01010165c97ae3c9-a6266961-a929-461f-ad2e-fbf89a3e6ce5-000000@us-west-2.amazonses.com> <17855879-73EA-451A-ADE0-8C4313B8FB82@dukhovni.org> <01010165c9a35b49-2ed6e7ae-ff2e-4d0f-8c99-55693ba59d45-000000@us-west-2.amazonses.com> <01010165cc372c56-698a75a1-b6d1-40d4-88ba-91fd3da39a3c-000000@us-west-2.amazonses.com> Message-ID: <0FA782C5-75D7-4E5F-9D2E-C56A9E1952DC@dukhovni.org> Ah, yes. Well that's why FIPS for OpenSSL is the main focus of the next release, and presumably why Oracle is one of the sponsors... :-) In the mean-time, yeah, you may have to support 1.0.2 for ~1 more year. > On Sep 12, 2018, at 1:18 AM, Jordan Brown wrote: > > My understanding is that lack of FIPS-140 certification is a problem for us. -- Viktor. From john.sha.jiang at gmail.com Wed Sep 12 07:07:25 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 12 Sep 2018 15:07:25 +0800 Subject: [openssl-users] Why was early data rejected? Message-ID: I just build OpenSSL 1.1.1 on MacOSX. Tried 0-RTT, and the commands like the followings, openssl s_server -cert server.cer -key server.key -tls1_3 -early_data -accept 9443 ... openssl s_client -CAfile ca.cer -tls1_3 -sess_in openssl.sess -early_data data -connect localhost:9443 s_client reported New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 ... Early data was rejected Verify return code: 0 (ok) What's wrong with my testing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 12 08:16:10 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 09:16:10 +0100 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: Message-ID: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> On 12/09/18 08:07, John Jiang wrote: > I just build OpenSSL 1.1.1 on MacOSX. > Tried 0-RTT, and the commands like the followings, > openssl s_server -cert server.cer -key server.key -tls1_3 -early_data > -accept 9443 > ... > openssl s_client -CAfile ca.cer -tls1_3 -sess_in openssl.sess > -early_data data -connect localhost:9443 > > s_client reported > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 The "New" here means that the resumption attempt failed. Successful resumption is a pre-requisite for early data. How did you create "openssl.sess"? Matt > ... > Early data was rejected > Verify return code: 0 (ok) > > What's wrong with my testing? > > From john.sha.jiang at gmail.com Wed Sep 12 08:34:36 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 12 Sep 2018 16:34:36 +0800 Subject: [openssl-users] Why was early data rejected? In-Reply-To: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: Matt Caswell ?2018?9?12??? ??4:16??? > > > On 12/09/18 08:07, John Jiang wrote: > > I just build OpenSSL 1.1.1 on MacOSX. > > Tried 0-RTT, and the commands like the followings, > > openssl s_server -cert server.cer -key server.key -tls1_3 -early_data > > -accept 9443 > > ... > > openssl s_client -CAfile ca.cer -tls1_3 -sess_in openssl.sess > > -early_data data -connect localhost:9443 > > > > s_client reported > > New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 > > The "New" here means that the resumption attempt failed. Successful > resumption is a pre-requisite for early data. How did you create > "openssl.sess"? > openssl s_client -CAfile ca.cer -tls1_3 -sess_out openssl.sess -connect localhost:9443 I just re-tried my test case. Re-started s_server and did two connection. The second connection reported: Reused, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 256 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was rejected Verify return code: 0 (ok) It looks the session was resumed, but early data still was rejected. > Matt > > > > ... > > Early data was rejected > > Verify return code: 0 (ok) > > > > What's wrong with my testing? > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 12 08:47:58 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 09:47:58 +0100 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: On 12/09/18 09:34, John Jiang wrote: > > It looks the session was resumed, but early data still was rejected. Hmm. Strange. I just tried the exact same sequence of commands and it was accepted. One thing to try is to recompile OpenSSL with the "enable-ssl-trace" config option. Then you can add the "-trace" option to s_client and/or s_server which might give a better clue as to why it is rejected. Matt From beldmit at gmail.com Wed Sep 12 09:02:09 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Wed, 12 Sep 2018 12:02:09 +0300 Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS Message-ID: Hello, The issue https://github.com/openssl/openssl/pull/7129 has introduced a possibility to limit the amount of TLS records processed without key changing as required by FIPS. We in Russia have limitations with the same semantics applicable to Russian GOST TLS ciphersuites ( https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so I think that this mechanism is very useful. The current implementation is done at EVP level, and it seems suboptimal because of the following reasons: - If the AES implementation is provided via engine, not by OpenSSL itself, the limitation can be avoided - the limitation has been made too generic - the implementation seems to be AEAD-specific. So does not it make sense to provide this limitation at least at the ciphersuite level? It can provide more straightforward way to manage such limitations. Thank you! -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From dhanukumar1990 at gmail.com Wed Sep 12 09:23:45 2018 From: dhanukumar1990 at gmail.com (Cipher) Date: Wed, 12 Sep 2018 02:23:45 -0700 (MST) Subject: [openssl-users] /dev/random in FIPS mode Error: PRNG not seeded Message-ID: <1536744225004-0.post@n7.nabble.com> Hello, We have a custom hardware system running Linux Debian OS having openssl 1.0.2l compiled with FIPS module 2.0. We are trying for FIPS 140-2 certification. By default it looks like openssl RAND_poll() uses /dev/urandom for entropy. We are told this may not be acceptable for FIPS 140-2 Level 1 certification and we should be using /dev/random. So we patched e_os.h to change order to use "/dev/random" than /dev/urandom. i.e before define DEVRANDOM "/dev/urandom","/dev/random" after define DEVRANDOM "/dev/random","/dev/urandom" Now we see that openssl is using /dev/random, but the problem is openssl operations randomly fail when run multiple times with "PRNG not seeded" error. This is in-spite of having rngd installed to boost entropy. [root at debian ~]# OPENSSL_FIPS=1 openssl version FIPS mode ON. OpenSSL 1.0.2l-fips 25 May 2017 [root at debian ~]# OPENSSL_FIPS=1 openssl version FIPS mode ON. OpenSSL 1.0.2l-fips 25 May 2017 [root at debian ~]# [root at debian ~]# OPENSSL_FIPS=1 openssl version 139889362065040:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:549:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 139889362065040:error:2D07406D:FIPS routines:FIPS_drbg_instantiate:error retrieving entropy:fips_drbg_lib.c:284: 139889362065040:error:24066067:random number generator:RAND_init_fips:error instantiating drbg:rand_lib.c:293: 139889362065040:error:04088003:rsa routines:RSA_setup_blinding:BN lib:rsa_crpt.c:212: 139889362065040:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:rsa_eay.c:443: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=RSA SHA256 PSS 139889362065040:error:2A067068:lib(42):ECDSA_sign_setup:random number generation failed:ecs_ossl.c:149: 139889362065040:error:2A06502A:lib(42):ECDSA_do_sign:reason(42):ecs_ossl.c:308: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=ECDSA P-224 139889362065040:error:0A06B003:dsa routines:DSA_sign_setup:BN lib:dsa_ossl.c:318: 139889362065040:error:0A070003:dsa routines:DSA_do_sign:BN lib:dsa_ossl.c:225: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=DSA SHA384 [root at debian ~]# cat /proc/sys/kernel/random/entropy_avail 3090 [root at debian ~]# Few Questions: 1)Would anyone know if usage of /dev/random as openssl entropy source is mandatory for FIPS 140-2 certification? 2) entropy_avail shows 3090, yet we hit 'PRNG not seeded' error. Is this because every FIPS_mode_set(1) call utilizes lot of entropy for selfTests etc? Is there any entropy estimate for each FIPS_mode_set() call? 3) Is there a way to avoid this issue with openssl code changes? i.e by doing some sort of auto-fallback to /dev/urandom if /dev/random pool is drained. 4) Since /dev/random is blocking, shouldn't openssl commands get stuck than error out if enough entropy is not available? Is there a way to do such a thing(by waiting for pool to get replenished). If yes what part of code needs to be changed? Thanks in Advance, D -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html From john.sha.jiang at gmail.com Wed Sep 12 10:50:54 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 12 Sep 2018 18:50:54 +0800 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: Could you please take a look at the attached s_client.log? It was outputted by s_client with options -trace and -state in the second connection. Matt Caswell ?2018?9?12??? ??4:48??? > > > On 12/09/18 09:34, John Jiang wrote: > > > > It looks the session was resumed, but early data still was rejected. > > Hmm. Strange. I just tried the exact same sequence of commands and it > was accepted. > > One thing to try is to recompile OpenSSL with the "enable-ssl-trace" > config option. Then you can add the "-trace" option to s_client and/or > s_server which might give a better clue as to why it is rejected. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s_client.log Type: application/octet-stream Size: 6652 bytes Desc: not available URL: From matt at openssl.org Wed Sep 12 11:08:56 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 12:08:56 +0100 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: Nothing particularly unexpected in there. Could you send me the s_server log including *both* connections, i.e. the original connection attempt to create the session, followed by the subsequent resume. Thanks Matt On 12/09/18 11:50, John Jiang wrote: > Could you please take a look at the attached s_client.log? > It was outputted by s_client with options -trace and -state in the > second connection. > > Matt Caswell > ?2018?9?12 > ??? ??4:48??? > > > > On 12/09/18 09:34, John Jiang wrote: > > > > It looks the session was resumed, but early data still was rejected. > > Hmm. Strange. I just tried the exact same sequence of commands and it > was accepted. > > One thing to try is to recompile OpenSSL with the "enable-ssl-trace" > config option. Then you can add the "-trace" option to s_client and/or > s_server which might give a better clue as to why it is rejected. > > Matt > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > From john.sha.jiang at gmail.com Wed Sep 12 11:25:33 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 12 Sep 2018 19:25:33 +0800 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: Very strange. I re-tried the same case, but the resumption failed. The attached logs contain the full outputs in the both connections on server and client sides. On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell wrote: > Nothing particularly unexpected in there. Could you send me the s_server > log including *both* connections, i.e. the original connection attempt > to create the session, followed by the subsequent resume. > > Thanks > > Matt > > > On 12/09/18 11:50, John Jiang wrote: > > Could you please take a look at the attached s_client.log? > > It was outputted by s_client with options -trace and -state in the > > second connection. > > > > Matt Caswell > ?2018?9?12 > > ??? ??4:48??? > > > > > > > > On 12/09/18 09:34, John Jiang wrote: > > > > > > It looks the session was resumed, but early data still was > rejected. > > > > Hmm. Strange. I just tried the exact same sequence of commands and it > > was accepted. > > > > One thing to try is to recompile OpenSSL with the "enable-ssl-trace" > > config option. Then you can add the "-trace" option to s_client > and/or > > s_server which might give a better clue as to why it is rejected. > > > > Matt > > > > -- > > openssl-users mailing list > > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s_server.log Type: application/octet-stream Size: 17542 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: s_client.log Type: application/octet-stream Size: 17697 bytes Desc: not available URL: From matt at openssl.org Wed Sep 12 12:15:59 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 13:15:59 +0100 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> Message-ID: <0b9d06e6-8d3d-d21a-c3e6-8e4c0988dca6@openssl.org> Were you using the -www option to s_server before? You didn't mention it in your original email, but in this log it shows you using it. Try without that option. Matt On 12/09/18 12:25, John Jiang wrote: > Very strange. I re-tried the same case, but the resumption failed. > The attached logs contain the full outputs in the both connections on > server and client sides. > > On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell > wrote: > > Nothing particularly unexpected in there. Could you send me the s_server > log including *both* connections, i.e. the original connection attempt > to create the session, followed by the subsequent resume. > > Thanks > > Matt > > > On 12/09/18 11:50, John Jiang wrote: > > Could you please take a look at the attached s_client.log? > > It was outputted by s_client with options -trace and -state in the > > second connection. > > > > Matt Caswell > >> ?2018?9?12 > > ??? ??4:48??? > > > > > > > >? ? ?On 12/09/18 09:34, John Jiang wrote: > >? ? ?> > >? ? ?> It looks the session was resumed, but early data still was > rejected. > > > >? ? ?Hmm. Strange. I just tried the exact same sequence of commands > and it > >? ? ?was accepted. > > > >? ? ?One thing to try is to recompile OpenSSL with the > "enable-ssl-trace" > >? ? ?config option. Then you can add the "-trace" option to > s_client and/or > >? ? ?s_server which might give a better clue as to why it is rejected. > > > >? ? ?Matt > > > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > From john.sha.jiang at gmail.com Wed Sep 12 13:04:32 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Wed, 12 Sep 2018 21:04:32 +0800 Subject: [openssl-users] Why was early data rejected? In-Reply-To: <0b9d06e6-8d3d-d21a-c3e6-8e4c0988dca6@openssl.org> References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> <0b9d06e6-8d3d-d21a-c3e6-8e4c0988dca6@openssl.org> Message-ID: I got the points! 1. should not use -www option on server side 2. Possibly, no session ticket was saved in the first connection with the below command, echo "M" | openssl s_client -trace -state -CAfile ca.cer -tls1_3 -sess_out openssl.sess -connect localhost:9443 The client exited so quickly that didn't receive sever's session ticket. On Wed, Sep 12, 2018 at 8:16 PM Matt Caswell wrote: > Were you using the -www option to s_server before? You didn't mention it > in your original email, but in this log it shows you using it. > > Try without that option. > > Matt > > > On 12/09/18 12:25, John Jiang wrote: > > Very strange. I re-tried the same case, but the resumption failed. > > The attached logs contain the full outputs in the both connections on > > server and client sides. > > > > On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell > > wrote: > > > > Nothing particularly unexpected in there. Could you send me the > s_server > > log including *both* connections, i.e. the original connection > attempt > > to create the session, followed by the subsequent resume. > > > > Thanks > > > > Matt > > > > > > On 12/09/18 11:50, John Jiang wrote: > > > Could you please take a look at the attached s_client.log? > > > It was outputted by s_client with options -trace and -state in the > > > second connection. > > > > > > Matt Caswell > > >> ?2018?9?12 > > > ??? ??4:48??? > > > > > > > > > > > > On 12/09/18 09:34, John Jiang wrote: > > > > > > > > It looks the session was resumed, but early data still was > > rejected. > > > > > > Hmm. Strange. I just tried the exact same sequence of commands > > and it > > > was accepted. > > > > > > One thing to try is to recompile OpenSSL with the > > "enable-ssl-trace" > > > config option. Then you can add the "-trace" option to > > s_client and/or > > > s_server which might give a better clue as to why it is > rejected. > > > > > > Matt > > > > > > -- > > > openssl-users mailing list > > > To unsubscribe: > > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Wed Sep 12 13:07:23 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 14:07:23 +0100 Subject: [openssl-users] Why was early data rejected? In-Reply-To: References: <2f357ae4-9de7-e3d2-79c7-9de8e0aa3a6a@openssl.org> <0b9d06e6-8d3d-d21a-c3e6-8e4c0988dca6@openssl.org> Message-ID: <18f0e78b-353b-b484-eb95-4963124bdcf2@openssl.org> On 12/09/18 14:04, John Jiang wrote: > I got the points! > 1. should not use -www option on server side Right - we should probably error out if you attempt to use those two options in combination. > 2. Possibly, no session ticket was saved in the first connection with > the below command, > echo "M" | openssl s_client -trace -state -CAfile ca.cer -tls1_3 > -sess_out openssl.sess -connect localhost:9443 > The client exited so quickly that didn't receive sever's session ticket. Ahh! Makes sense! Matt > > On Wed, Sep 12, 2018 at 8:16 PM Matt Caswell > wrote: > > Were you using the -www option to s_server before? You didn't mention it > in your original email, but in this log it shows you using it. > > Try without that option. > > Matt > > > On 12/09/18 12:25, John Jiang wrote: > > Very strange. I re-tried the same case, but the resumption failed. > > The attached logs contain the full outputs in the both connections on > > server and client sides. > > > > On Wed, Sep 12, 2018 at 7:09 PM Matt Caswell > > >> wrote: > > > >? ? ?Nothing particularly unexpected in there. Could you send me > the s_server > >? ? ?log including *both* connections, i.e. the original connection > attempt > >? ? ?to create the session, followed by the subsequent resume. > > > >? ? ?Thanks > > > >? ? ?Matt > > > > > >? ? ?On 12/09/18 11:50, John Jiang wrote: > >? ? ?> Could you please take a look at the attached s_client.log? > >? ? ?> It was outputted by s_client with options -trace and -state > in the > >? ? ?> second connection. > >? ? ?> > >? ? ?> Matt Caswell > > > >? ? ? > >>> ?2018?9?12 > >? ? ?> ??? ??4:48??? > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?>? ? ?On 12/09/18 09:34, John Jiang wrote: > >? ? ?>? ? ?> > >? ? ?>? ? ?> It looks the session was resumed, but early data still was > >? ? ?rejected. > >? ? ?> > >? ? ?>? ? ?Hmm. Strange. I just tried the exact same sequence of > commands > >? ? ?and it > >? ? ?>? ? ?was accepted. > >? ? ?> > >? ? ?>? ? ?One thing to try is to recompile OpenSSL with the > >? ? ?"enable-ssl-trace" > >? ? ?>? ? ?config option. Then you can add the "-trace" option to > >? ? ?s_client and/or > >? ? ?>? ? ?s_server which might give a better clue as to why it is > rejected. > >? ? ?> > >? ? ?>? ? ?Matt > >? ? ?> > >? ? ?>? ? ?-- > >? ? ?>? ? ?openssl-users mailing list > >? ? ?>? ? ?To unsubscribe: > >? ? ?https://mta.openssl.org/mailman/listinfo/openssl-users > >? ? ?> > >? ? ?> > >? ? ?> > >? ? ?-- > >? ? ?openssl-users mailing list > >? ? ?To unsubscribe: > https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > From shinelight at shininglightpro.com Wed Sep 12 13:53:36 2018 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Wed, 12 Sep 2018 06:53:36 -0700 Subject: [openssl-users] NMAKE fatal error, 32-bit time_t Message-ID: cl /Z7 /Fdapp.pdb /Gs0 /GF /Gy /MD /W3 /wd4090 /nologo /O2 /WX /I "include" -D"OPENSSL_SYS_WIN32" -D"WIN32_LEAN_AND_MEAN" -D"UNICODE" -D"_UNICODE" -D"_CRT_SECURE_NO_DEPRECATE" -D"_WINSOCK_DEPRECATED_NO_WARNINGS" -D"OPENSSL_USE_APPLINK" -D"NDEBUG" -D_USE_32BIT_TIME_T -D_USING_V110_SDK71_ -D_WINSOCK_DEPRECATED_NO_WARNINGS /Zs /showIncludes "test\ct_test.c" 2>&1 > test\ct_test.d NMAKE : fatal error U1077: 'cl' : return code '0x2' Stop. NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\bin\HostX86\x86\nmake.exe"' : return code '0x2' Stop. test\ct_test.c(503): error C2220: warning treated as error - no 'object' file generated test\ct_test.c(503): warning C4244: 'initializing': conversion from 'uint64_t' to 'const time_t', possible loss of data Probably triggered by the usage of: -D_USE_32BIT_TIME_T I use that define for 32-bit builds on my 64-bit hardware as per this old post: https://groups.google.com/forum/#!topic/mailing.openssl.users/AGuOi4yEY9A Casting to time_t appears to correct the issue and the build completes successfully: const time_t default_time = (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / 1000; -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From openssl-users at dukhovni.org Wed Sep 12 14:03:44 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Sep 2018 10:03:44 -0400 Subject: [openssl-users] NMAKE fatal error, 32-bit time_t In-Reply-To: References: Message-ID: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> > On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska wrote: > > Casting to time_t appears to correct the issue and the build completes successfully: > > const time_t default_time = (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / > 1000; Since the CT time value is in "ms" since epoch, you really don't want to down-convert that to 32 bit *before* the division. You'll need some parentheses: https://en.cppreference.com/w/c/language/operator_precedence type cast has higher precedence than division, but you need to divide first, then cast. -- Viktor. From kk at keppler-it.de Wed Sep 12 13:50:17 2018 From: kk at keppler-it.de (Klaus Keppler) Date: Wed, 12 Sep 2018 15:50:17 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working Message-ID: Hi, when I create a TLS-1.3-only "web" server with s_server (from OpenSSL 1.1.1-release), Firefox/Chrome can't access it. According to all docs I've read so far, the TLS 1.3 implementations both from Firefox (62.x) and from Chrome (69.x) should be compatible so far. I created the web server with the following command: ./openssl s_server -accept 8444 -tls1_3 \ -cert sslcert.pem -key sslcert.key \ -www -state -debug -msg -security_debug_verbose sslcert.pem/sslcert.key is a self-signed 2048 bit RSA certificate. When starting without the "-tls1_3" option (or with "-tls1_2"), both browsers can access that service (an OpenSSL stats page is displayed then). With "-tls1_3", - Firefox issues a SSL_ERROR_PROTOCOL_VERSION_ALERT - Chrome issues a ERR_SSL_VERSION_OR_CIPHER_MISMATCH Server-side output is the same in both cases, see below for full message. Connecting to that service using "openssl s_client -connect localhost:8444" works fine. There's no proxy, firewall or web filter software involved. When I open e.g. www.cloudflare.com in a browser, connection is made using TLS 1.3. So, the browser-side obviously works, I expect the problem to be on the server-side. Am I missing something? I can't imagine these products to be incompatible... Thanks & best regards! -Klaus ---cut--- Security callback: Version=TLS 1.3: yes Security callback: Version=TLS 1.3: yes SSL_accept:before SSL initialization read from 0x2335fb0 [0x233c1b3] (5 bytes => 5 (0x5)) 0000 - 16 03 01 02 00 ..... <<< ??? [length 0005] 16 03 01 02 00 read from 0x2335fb0 [0x233c1b8] (512 bytes => 512 (0x200)) 0000 - 01 00 01 fc 03 03 bb 93-78 7e 86 eb 69 e5 b4 9f [...] 01f0 - 00 00 00 00 00 00 00 00-00 00 00 00 00 00 00 00 SSL_accept:before SSL initialization <<< TLS 1.3, Handshake [length 0200], ClientHello 01 00 01 fc 03 03 bb 93 78 7e 86 eb 69 e5 b4 9f c2 28 16 9f 25 27 37 f5 42 5b c9 10 36 09 11 30 11 7f a5 ec 39 b8 20 15 a8 20 9e 24 0f 78 5d 11 b0 72 9a b0 4f 74 9b d2 c7 09 64 2d 3d 73 7c 8d bd ce 4d f2 de 17 cf 00 1c 13 01 13 03 13 02 c0 2b c0 2f cc a9 cc a8 c0 2c c0 30 c0 13 c0 14 00 2f 00 35 00 0a 01 00 01 97 00 17 00 00 ff 01 00 01 00 00 0a 00 0e 00 0c 00 1d 00 17 00 18 00 19 01 00 01 01 00 0b 00 02 01 00 00 23 00 00 00 10 00 0e 00 0c 02 68 32 08 68 74 74 70 2f 31 2e 31 00 05 00 05 01 00 00 00 00 00 33 00 6b 00 69 00 1d 00 20 de 3f e9 13 12 8a 84 f4 5b 22 40 ae 3d e9 56 04 e8 b4 68 ef 0a 02 fe b7 42 90 ab 26 f1 95 ff 2d 00 17 00 41 04 41 fd 89 36 89 df 02 3c a3 cf 12 8a 27 6f d5 ba 17 29 49 b8 91 6b 6c 95 e2 7d a8 df fe a5 50 dc 35 0c 3d b5 2a b4 93 70 17 cd 62 a5 a1 03 7f 32 11 07 04 b3 b0 89 a4 8f 62 05 9f 69 74 1b c2 99 00 2b 00 09 08 7f 1c 03 03 03 02 03 01 00 0d 00 18 00 16 04 03 05 03 06 03 08 04 08 05 08 06 04 01 05 01 06 01 02 03 02 01 00 2d 00 02 01 01 00 1c 00 02 40 01 00 15 00 af 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>> ??? [length 0005] 15 03 03 00 02 write to 0x2335fb0 [0x234a930] (7 bytes => 7 (0x7)) 0000 - 15 03 03 00 02 02 46 ......F >>> TLS 1.2, Alert [length 0002], fatal protocol_version 02 46 SSL3 alert write:fatal:protocol version SSL_accept:error in error 140042894132992:error:14209102:SSL routines:tls_early_post_process_client_hello:unsupported protocol:ssl/statem/statem_srvr.c:1655: From bkaduk at akamai.com Wed Sep 12 14:20:38 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Wed, 12 Sep 2018 09:20:38 -0500 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: References: Message-ID: <20180912142038.GI5819@akamai.com> On Wed, Sep 12, 2018 at 03:50:17PM +0200, Klaus Keppler wrote: > Hi, > > when I create a TLS-1.3-only "web" server with s_server (from OpenSSL > 1.1.1-release), Firefox/Chrome can't access it. > According to all docs I've read so far, the TLS 1.3 implementations both > from Firefox (62.x) and from Chrome (69.x) should be compatible so far. You need to check that the browser is implementing the final RFC 8446 version and not an earlier draft version -- two are incompatible by design (and OpenSSL 1.1.1 implements the final RFC 8446 version). IIUC, only Firefox nightly as of approximately today will support the final RFC 8446 version; I haven't looked into Chrome yet. -Ben From openssl-users at dukhovni.org Wed Sep 12 14:41:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Sep 2018 10:41:01 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <20180912142038.GI5819@akamai.com> References: <20180912142038.GI5819@akamai.com> Message-ID: <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org> > On Sep 12, 2018, at 10:20 AM, Benjamin Kaduk via openssl-users wrote: > > IIUC, only Firefox nightly as of approximately today will support the final > RFC 8446 version; I haven't looked into Chrome yet. From the Firefox TLS 1.3 blog entry: https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/ What Now? TLS 1.3 is already widely deployed: both Firefox and Chrome have fielded ?draft? versions. Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). We expect to ship the final version in Firefox 63, scheduled for October 2018. Cloudflare, Google, and Facebook are running it on their servers today. Our telemetry shows that around 5% of Firefox connections are TLS 1.3. Cloudflare reports similar numbers, and Facebook reports that an astounding 50+% of their traffic is already TLS 1.3! -- Viktor. From openssl-users at dukhovni.org Wed Sep 12 14:44:35 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Sep 2018 10:44:35 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org> References: <20180912142038.GI5819@akamai.com> <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org> Message-ID: > On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni wrote: > >> IIUC, only Firefox nightly as of approximately today will support the final >> RFC 8446 version; I haven't looked into Chrome yet. > > From the Firefox TLS 1.3 blog entry: > > https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/ Similarly, for Chrome the final TLS 1.3 is not out quite yet: https://www.chromium.org/Home/tls13 Chrome has been shipping a draft version of TLS 1.3 since Chrome 65. In Chrome 70, the final version of TLS 1.3 will be enabled for outgoing connections. (A small percentage may be held back to provide comparison metrics.) -- Viktor. From dclarke at blastwave.org Wed Sep 12 15:15:33 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 12 Sep 2018 11:15:33 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: References: <20180912142038.GI5819@akamai.com> <40A86C9B-BEB7-48BD-B426-17F7CF026595@dukhovni.org> Message-ID: <6cce24de-a351-89aa-3164-1a2b34ca8973@blastwave.org> On 09/12/2018 10:44 AM, Viktor Dukhovni wrote: > > >> On Sep 12, 2018, at 10:41 AM, Viktor Dukhovni wrote: >> >>> IIUC, only Firefox nightly as of approximately today will support the final >>> RFC 8446 version; I haven't looked into Chrome yet. >> >> From the Firefox TLS 1.3 blog entry: >> >> https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/ > > Similarly, for Chrome the final TLS 1.3 is not out quite yet: > > https://www.chromium.org/Home/tls13 > > Chrome has been shipping a draft version of TLS 1.3 since Chrome 65. >In Chrome 70, the final version of TLS 1.3 will be enabled ... Some Chrome browsers seem to be hitting https://www.tls13.net/ with versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0. The Firefox nightly versions have been fine for a while now. Weeks. There is no sign of life at all from the Opera people sadly. Dennis From dclarke at blastwave.org Wed Sep 12 15:22:17 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 12 Sep 2018 11:22:17 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: References: Message-ID: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> On 09/12/2018 09:50 AM, Klaus Keppler wrote: > Hi, > > when I create a TLS-1.3-only "web" server with s_server (from OpenSSL > 1.1.1-release), Firefox/Chrome can't access it. Be sure to use Firefox nightly version 64.0a1 and upwards. Anything less and you may be getting draft 28 support and NOT actual RFC release protocol support. Mozilla/5.0 (X11; Linux x86_64; rv:64.0) Gecko/20100101 Firefox/64.0 That works. Dennis From shinelight at shininglightpro.com Wed Sep 12 15:23:24 2018 From: shinelight at shininglightpro.com (Thomas J. Hruska) Date: Wed, 12 Sep 2018 08:23:24 -0700 Subject: [openssl-users] NMAKE fatal error, 32-bit time_t In-Reply-To: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> References: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> Message-ID: On 9/12/2018 7:03 AM, Viktor Dukhovni wrote: > > >> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska wrote: >> >> Casting to time_t appears to correct the issue and the build completes successfully: >> >> const time_t default_time = (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / >> 1000; > > Since the CT time value is in "ms" since epoch, you really don't want > to down-convert that to 32 bit *before* the division. You'll need > some parentheses: > > https://en.cppreference.com/w/c/language/operator_precedence > > type cast has higher precedence than division, but you need to > divide first, then cast. Whoops. Well, being pointed at the "intro to C" documentation is what I get for rushing that. It's a bit ironic since I'm notorious for wrapping everything in extra parenthesis just to avoid memorizing operator precedence. Thanks for pointing that out though. -- Thomas Hruska Shining Light Productions Home of BMP2AVI and Win32 OpenSSL. http://www.slproweb.com/ From matt at openssl.org Wed Sep 12 15:24:03 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 16:24:03 +0100 Subject: [openssl-users] NMAKE fatal error, 32-bit time_t In-Reply-To: References: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> Message-ID: On 12/09/18 16:23, Thomas J. Hruska wrote: > On 9/12/2018 7:03 AM, Viktor Dukhovni wrote: >> >> >>> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska >>> wrote: >>> >>> Casting to time_t appears to correct the issue and the build >>> completes successfully: >>> >>> ??? const time_t default_time = >>> (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / >>> ??????????????????????????????? 1000; >> >> Since the CT time value is in "ms" since epoch, you really don't want >> to down-convert that to 32 bit *before* the division.? You'll need >> some parentheses: >> >> ?? https://en.cppreference.com/w/c/language/operator_precedence >> >> type cast has higher precedence than division, but you need to >> divide first, then cast. > > Whoops.? Well, being pointed at the "intro to C" documentation is what I > get for rushing that.? It's a bit ironic since I'm notorious for > wrapping everything in extra parenthesis just to avoid memorizing > operator precedence. > > Thanks for pointing that out though. > Is this new to 1.1.1? Or does it also impact 1.1.0? Matt From levitte at openssl.org Wed Sep 12 15:33:19 2018 From: levitte at openssl.org (Richard Levitte) Date: Wed, 12 Sep 2018 17:33:19 +0200 (CEST) Subject: [openssl-users] NMAKE fatal error, 32-bit time_t In-Reply-To: References: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> Message-ID: <20180912.173319.796947843524979822.levitte@openssl.org> In message on Wed, 12 Sep 2018 16:24:03 +0100, Matt Caswell said: > > > On 12/09/18 16:23, Thomas J. Hruska wrote: > > On 9/12/2018 7:03 AM, Viktor Dukhovni wrote: > >> > >> > >>> On Sep 12, 2018, at 9:53 AM, Thomas J. Hruska > >>> wrote: > >>> > >>> Casting to time_t appears to correct the issue and the build > >>> completes successfully: > >>> > >>> ??? const time_t default_time = > >>> (time_t)CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / > >>> ??????????????????????????????? 1000; > >> > >> Since the CT time value is in "ms" since epoch, you really don't want > >> to down-convert that to 32 bit *before* the division.? You'll need > >> some parentheses: > >> > >> ?? https://en.cppreference.com/w/c/language/operator_precedence > >> > >> type cast has higher precedence than division, but you need to > >> divide first, then cast. > > > > Whoops.? Well, being pointed at the "intro to C" documentation is what I > > get for rushing that.? It's a bit ironic since I'm notorious for > > wrapping everything in extra parenthesis just to avoid memorizing > > operator precedence. > > > > Thanks for pointing that out though. > > > > Is this new to 1.1.1? Or does it also impact 1.1.0? The same problematic code line exists in 1.1.0 (line 545). I cannot say why we haven't been hit by this before... -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From openssl-users at dukhovni.org Wed Sep 12 15:34:01 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 12 Sep 2018 11:34:01 -0400 Subject: [openssl-users] NMAKE fatal error, 32-bit time_t In-Reply-To: References: <480A5385-5BB2-4A89-81F3-EAF42793741F@dukhovni.org> Message-ID: > On Sep 12, 2018, at 11:24 AM, Matt Caswell wrote: > > > Is this new to 1.1.1? Or does it also impact 1.1.0? Seems to affect 1.1.0 also: $ git grep -A1 CT_POLICY_EVAL_CTX_get_time OpenSSL_1_1_0-stable -- test OpenSSL_1_1_0-stable:test/ct_test.c: const time_t default_time = CT_POLICY_EVAL_CTX_get_time(ct_policy_ctx) / OpenSSL_1_1_0-stable:test/ct_test.c- 1000; -- Viktor. From angus at magsys.co.uk Wed Sep 12 16:06:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 12 Sep 2018 17:06 +0100 (BST) Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <20180912142038.GI5819@akamai.com> Message-ID: > IIUC, only Firefox nightly as of approximately today will support > the final RFC 8446 version; Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday. https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-U S > I haven't looked into Chrome yet. My versions don't work yet, but I might not be on the latest nightly stuff. Angus From angus at magsys.co.uk Wed Sep 12 16:40:00 2018 From: angus at magsys.co.uk (Angus Robertson - Magenta Systems Ltd) Date: Wed, 12 Sep 2018 17:40 +0100 (BST) Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <6cce24de-a351-89aa-3164-1a2b34ca8973@blastwave.org> Message-ID: > Some Chrome browsers seem to be hitting https://www.tls13.net/ > with versions from Chrome/70.0.3534.4 upwards to Chrome/71.0.3544.0 Some of my public web servers are now on yesterday's version, three TLSv1.3 users today, two with Firefox 63, one with Chrome/68.0.3440.106+Safari/537.36. I seem to be on Chromium Chrome/70.0.3538.9 and TLSv1.3 did not initially work, had to go to experimental flags to change from draft 28 and final and now it does work. Angus From dclarke at blastwave.org Wed Sep 12 16:45:13 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 12 Sep 2018 12:45:13 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: References: Message-ID: <9ec8cf88-452a-5e75-9658-917e4ad7f6c3@blastwave.org> On 09/12/2018 12:06 PM, Angus Robertson - Magenta Systems Ltd wrote: >> IIUC, only Firefox nightly as of approximately today will support >> the final RFC 8446 version; > > Firefox 63.0b5 works OK with OpenSSL 1.1.1, think it came Tuesday. > Even Firefox/60.0 works. > https://download.mozilla.org/?product=firefox-beta-stub&os=win&lang=en-U > S > >> I haven't looked into Chrome yet. Seen in the wild : Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.42 Safari/537.36 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/69.0.3497.57 Safari/537.36 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.9 Safari/537.36 Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3544.0 Safari/537.36 Dennis From coutwin at newstuff.com Wed Sep 12 18:24:15 2018 From: coutwin at newstuff.com (Chris Outwin) Date: Wed, 12 Sep 2018 13:24:15 -0500 Subject: [openssl-users] Checksum for openssl-1.0.2p download Message-ID: I?m an OpenSSL newbie and this is my first post. I?m using OpenSSL for receipt validation in an iOS application. Is there a list of checksums to verify openssl download versions? I believe I should be using openssl-1.0.2p. Can openssl-1.1.1 be used in a production application yet? Why doesn?t openssl-1.1.1 end with a letter of the alphabet? Thank you very much. From matt at openssl.org Wed Sep 12 18:28:52 2018 From: matt at openssl.org (Matt Caswell) Date: Wed, 12 Sep 2018 19:28:52 +0100 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: References: Message-ID: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> On 12/09/18 19:24, Chris Outwin wrote: > I?m an OpenSSL newbie and this is my first post. I?m using OpenSSL for receipt validation in an iOS application. > > Is there a list of checksums to verify openssl download versions? Next to each download on the website there are links for SHA256/PGP/SHA1 checksums. https://www.openssl.org/source/ > I believe I should be using openssl-1.0.2p. Can openssl-1.1.1 be used in a production application yet? Yes. The final version was released earlier this week. > Why doesn?t openssl-1.1.1 end with a letter of the alphabet? 1.1.1 is the first production release of the 1.1.1 series. The next time we issue a bug and/or security fix version it will be 1.1.1a. The one after that 1.1.1b, and so on. Matt From Michael.Wojcik at microfocus.com Wed Sep 12 18:42:18 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 12 Sep 2018 18:42:18 +0000 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> References: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Matt Caswell > Sent: Wednesday, September 12, 2018 14:29 > > On 12/09/18 19:24, Chris Outwin wrote: > > I?m an OpenSSL newbie and this is my first post. I?m using OpenSSL for > receipt validation in an iOS application. > > > > Is there a list of checksums to verify openssl download versions? > > Next to each download on the website there are links for SHA256/PGP/SHA1 > checksums. > > https://www.openssl.org/source/ I'd strongly recommend verifying the PGP (OpenPGP, gpg) signature on the tarball. The signature files are right there alongside the tarballs. If you're new to gpg (or whatever OpenPGP implementation of your choice), there's a bit of learning and setup to do: you'll need to fetch the appropriate key from a public keyserver or other trustworthy (-ish) source to fully verify the signature, and you'll probably want to mark the key as trusted so the output from gpg is clear. But once you've done that, it's very easy to verify the signature, and to automate the process if you prefer. And the signatures add a bit of defense-in-depth because publishing a tampered-with tarball would require subverting the private key as well as to the OpenSSL web server. (If you're just checking the SHA256 hash, an attacker could either get access to the OpenSSL web server, or force you to a counterfeit server, for example via DNS cache poisoning. And due to the systemic brokenness of the web PKI, it's pretty easy to fool a lot of people with a counterfeit server.) So do the work now to set yourself up for verifying the signature, and inculcate a good habit. -- Michael Wojcik Distinguished Engineer, Micro Focus From jisoza at gmail.com Wed Sep 12 20:46:18 2018 From: jisoza at gmail.com (Juan Isoza) Date: Wed, 12 Sep 2018 22:46:18 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <9ec8cf88-452a-5e75-9658-917e4ad7f6c3@blastwave.org> References: <9ec8cf88-452a-5e75-9658-917e4ad7f6c3@blastwave.org> Message-ID: As I understand and check: https://www.tls13.net accept connexion from final openssl-1.1.1 (RFC8446) but not from openssl-1.1.1 pre8 (draft 28) https://tls13.crypto.mozilla.org accept connexion from openssl-1.1.1 pre8 (draft 28) but not from final openssl-1.1.1 (RFC8446) https://www.facebook.com accept connexion from both openssl-1.1.1 pre8 (draft 28) and from final openssl-1.1.1 (RFC8446) Current public release of chrome and firefox uses draft 28 ------ I tested ios 12 GM (published today) on an iPhone and it seem not using TLS 1.3 :-( -------------- next part -------------- An HTML attachment was scrubbed... URL: From coutwin at newstuff.com Wed Sep 12 20:56:49 2018 From: coutwin at newstuff.com (Chris Outwin) Date: Wed, 12 Sep 2018 15:56:49 -0500 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: References: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> Message-ID: Thank you very much for your helpful reply. I?m a graphics programmer with no experience in PGP. The shell script I have calls: OPENSSL_ARCHIVE_URL="https://www.openssl.org/source/old/${BRANCH}/${OPENSSL_ARCHIVE_FILE_NAME}? in the process of downloading OpenSSL for use in building an iOS static implementation. Does https have a reasonable level of security? I believe I can include a block of code in the script to do a checksum. > On Sep 12, 2018, at 1:42 PM, Michael Wojcik wrote: > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Matt Caswell >> Sent: Wednesday, September 12, 2018 14:29 >> >> On 12/09/18 19:24, Chris Outwin wrote: >>> I?m an OpenSSL newbie and this is my first post. I?m using OpenSSL for >> receipt validation in an iOS application. >>> >>> Is there a list of checksums to verify openssl download versions? >> >> Next to each download on the website there are links for SHA256/PGP/SHA1 >> checksums. >> >> https://www.openssl.org/source/ > > I'd strongly recommend verifying the PGP (OpenPGP, gpg) signature on the tarball. The signature files are right there alongside the tarballs. > > If you're new to gpg (or whatever OpenPGP implementation of your choice), there's a bit of learning and setup to do: you'll need to fetch the appropriate key from a public keyserver or other trustworthy (-ish) source to fully verify the signature, and you'll probably want to mark the key as trusted so the output from gpg is clear. > > But once you've done that, it's very easy to verify the signature, and to automate the process if you prefer. And the signatures add a bit of defense-in-depth because publishing a tampered-with tarball would require subverting the private key as well as to the OpenSSL web server. (If you're just checking the SHA256 hash, an attacker could either get access to the OpenSSL web server, or force you to a counterfeit server, for example via DNS cache poisoning. And due to the systemic brokenness of the web PKI, it's pretty easy to fool a lot of people with a counterfeit server.) > > So do the work now to set yourself up for verifying the signature, and inculcate a good habit. > > -- > Michael Wojcik > Distinguished Engineer, Micro Focus > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From jb-openssl at wisemo.com Wed Sep 12 21:18:19 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 12 Sep 2018 23:18:19 +0200 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: References: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> Message-ID: (Top posting to avoid zig-zag) Testing your OpenSSL download with the HTTPS security bites its own tail, especially if your download tool uses an (older) version of OpenSSL to check the connection. But unless you have an established personal list of GPG/PGP keys you have checked against their holders in person yourself, checking the HTTPS certificate of the OpenSSL.org web server is pretty much all you can do to distinguish between a genuine and a fake first time OpenSSL download (signatures on later downloads can be compared to previous downloadsfor some degree of signature consistency). Of cause some real knowledge is needed to not use the OpenSSL source code incorrectly, unless you are merely compiling other peoples software exactly as instructed. Personally, I would prefer if there also was a detached CMS signature with an EV software signing certificate independently validated as belonging to the real OpenSSL foundation. On 12/09/2018 22:56, Chris Outwin wrote: > Thank you very much for your helpful reply. > > I?m a graphics programmer with no experience in PGP. The shell script I have calls: OPENSSL_ARCHIVE_URL="https://www.openssl.org/source/old/${BRANCH}/${OPENSSL_ARCHIVE_FILE_NAME}? in the process of downloading OpenSSL for use in building an iOS static implementation. Does https have a reasonable level of security? I believe I can include a block of code in the script to do a checksum. > >> On Sep 12, 2018, at 1:42 PM, Michael Wojcik wrote: >> >>> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >>> Of Matt Caswell >>> Sent: Wednesday, September 12, 2018 14:29 >>> >>> On 12/09/18 19:24, Chris Outwin wrote: >>>> I?m an OpenSSL newbie and this is my first post. I?m using OpenSSL for >>> receipt validation in an iOS application. >>>> Is there a list of checksums to verify openssl download versions? >>> Next to each download on the website there are links for SHA256/PGP/SHA1 >>> checksums. >>> >>> https://www.openssl.org/source/ >> I'd strongly recommend verifying the PGP (OpenPGP, gpg) signature on the tarball. The signature files are right there alongside the tarballs. >> >> If you're new to gpg (or whatever OpenPGP implementation of your choice), there's a bit of learning and setup to do: you'll need to fetch the appropriate key from a public keyserver or other trustworthy (-ish) source to fully verify the signature, and you'll probably want to mark the key as trusted so the output from gpg is clear. >> >> But once you've done that, it's very easy to verify the signature, and to automate the process if you prefer. And the signatures add a bit of defense-in-depth because publishing a tampered-with tarball would require subverting the private key as well as to the OpenSSL web server. (If you're just checking the SHA256 hash, an attacker could either get access to the OpenSSL web server, or force you to a counterfeit server, for example via DNS cache poisoning. And due to the systemic brokenness of the web PKI, it's pretty easy to fool a lot of people with a counterfeit server.) >> >> So do the work now to set yourself up for verifying the signature, and inculcate a good habit. >> 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 paul.dale at oracle.com Wed Sep 12 21:36:30 2018 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 12 Sep 2018 14:36:30 -0700 (PDT) Subject: [openssl-users] /dev/random in FIPS mode Error: PRNG not seeded In-Reply-To: <1536744225004-0.post@n7.nabble.com> References: <1536744225004-0.post@n7.nabble.com> Message-ID: <81957222-5069-49c8-a9ae-d9996f276c3b@default> In FIPS mode, the default entropy gathering is not performed. You, the user, must supply all entropy to the module. See section 6.1.1 of the OpenSSL FIPS User Guide (https://www.openssl.org/docs/fips/UserGuide-2.0.pdf). Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Cipher [mailto:dhanukumar1990 at gmail.com] Sent: Wednesday, 12 September 2018 7:24 PM To: openssl-users at openssl.org Subject: [openssl-users] /dev/random in FIPS mode Error: PRNG not seeded Hello, We have a custom hardware system running Linux Debian OS having openssl 1.0.2l compiled with FIPS module 2.0. We are trying for FIPS 140-2 certification. By default it looks like openssl RAND_poll() uses /dev/urandom for entropy. We are told this may not be acceptable for FIPS 140-2 Level 1 certification and we should be using /dev/random. So we patched e_os.h to change order to use "/dev/random" than /dev/urandom. i.e before define DEVRANDOM "/dev/urandom","/dev/random" after define DEVRANDOM "/dev/random","/dev/urandom" Now we see that openssl is using /dev/random, but the problem is openssl operations randomly fail when run multiple times with "PRNG not seeded" error. This is in-spite of having rngd installed to boost entropy. [root at debian ~]# OPENSSL_FIPS=1 openssl version FIPS mode ON. OpenSSL 1.0.2l-fips 25 May 2017 [root at debian ~]# OPENSSL_FIPS=1 openssl version FIPS mode ON. OpenSSL 1.0.2l-fips 25 May 2017 [root at debian ~]# [root at debian ~]# OPENSSL_FIPS=1 openssl version 139889362065040:error:24064064:random number generator:SSLEAY_RAND_BYTES:PRNG not seeded:md_rand.c:549:You need to read the OpenSSL FAQ, http://www.openssl.org/support/faq.html 139889362065040:error:2D07406D:FIPS routines:FIPS_drbg_instantiate:error retrieving entropy:fips_drbg_lib.c:284: 139889362065040:error:24066067:random number generator:RAND_init_fips:error instantiating drbg:rand_lib.c:293: 139889362065040:error:04088003:rsa routines:RSA_setup_blinding:BN lib:rsa_crpt.c:212: 139889362065040:error:04066044:rsa routines:RSA_EAY_PRIVATE_ENCRYPT:internal error:rsa_eay.c:443: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=RSA SHA256 PSS 139889362065040:error:2A067068:lib(42):ECDSA_sign_setup:random number generation failed:ecs_ossl.c:149: 139889362065040:error:2A06502A:lib(42):ECDSA_do_sign:reason(42):ecs_ossl.c:308: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=ECDSA P-224 139889362065040:error:0A06B003:dsa routines:DSA_sign_setup:BN lib:dsa_ossl.c:318: 139889362065040:error:0A070003:dsa routines:DSA_do_sign:BN lib:dsa_ossl.c:225: 139889362065040:error:2D079089:FIPS routines:fips_pkey_signature_test:test failure:fips_post.c:334:Type=DSA SHA384 [root at debian ~]# cat /proc/sys/kernel/random/entropy_avail 3090 [root at debian ~]# Few Questions: 1)Would anyone know if usage of /dev/random as openssl entropy source is mandatory for FIPS 140-2 certification? 2) entropy_avail shows 3090, yet we hit 'PRNG not seeded' error. Is this because every FIPS_mode_set(1) call utilizes lot of entropy for selfTests etc? Is there any entropy estimate for each FIPS_mode_set() call? 3) Is there a way to avoid this issue with openssl code changes? i.e by doing some sort of auto-fallback to /dev/urandom if /dev/random pool is drained. 4) Since /dev/random is blocking, shouldn't openssl commands get stuck than error out if enough entropy is not available? Is there a way to do such a thing(by waiting for pool to get replenished). If yes what part of code needs to be changed? Thanks in Advance, D -- Sent from: http://openssl.6102.n7.nabble.com/OpenSSL-User-f3.html -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From dclarke at blastwave.org Wed Sep 12 21:57:08 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Wed, 12 Sep 2018 17:57:08 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: References: <9ec8cf88-452a-5e75-9658-917e4ad7f6c3@blastwave.org> Message-ID: <31f31958-fa78-217d-c1c1-5adf114b3d9b@blastwave.org> On 09/12/2018 04:46 PM, Juan Isoza wrote: > As I understand and check: > > > https://www.tls13.net accept connexion from final openssl-1.1.1 > (RFC8446) but not from openssl-1.1.1 pre8 (draft 28) > At this point the protocol is published and the OpenSSL 1.1.1 release is done. You should not be looking for *draft* anything. Dennis From paul.dale at oracle.com Wed Sep 12 22:54:38 2018 From: paul.dale at oracle.com (Paul Dale) Date: Wed, 12 Sep 2018 15:54:38 -0700 (PDT) Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: References: Message-ID: <484c33c9-c843-4aa4-b5c9-79148d835248@default> I wasn?t aware of other national standards requiring a similar check. ? I made the change in the AES-GCM code because FIPS demands the check be inside the FIPS boundary.? I?d have preferred to make it in the TLS layer, but that mustn?t be inside the FIPS boundary.? My understanding is that TLS catches this case earlier and thus the test can never pass. ? I don?t think dropping the check down into the algorithm implementations makes sense.? A more generic mechanism at the EVP would. ? ? ? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia ? From: Dmitry Belyavsky [mailto:beldmit at gmail.com] Sent: Wednesday, 12 September 2018 7:02 PM To: openssl-users at openssl.org Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS ? Hello, ? The issue https://github.com/openssl/openssl/pull/7129 has introduced a possibility to limit the amount of TLS records processed without key changing as required by FIPS. ? We in Russia have limitations with the same semantics applicable to Russian GOST TLS ciphersuites (https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so I think that this mechanism is very useful.? ? The current implementation is done at EVP level, and it seems suboptimal because of the following reasons: - If the AES implementation is provided via engine, not by OpenSSL itself, the limitation can be avoided - the limitation has been made too generic - the implementation seems to be AEAD-specific.? ? So does not it make sense to provide this limitation at least at the ciphersuite level? It can provide more straightforward way to manage such limitations. Thank you! ? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Wojcik at microfocus.com Thu Sep 13 01:24:46 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Thu, 13 Sep 2018 01:24:46 +0000 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: References: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf > Of Jakob Bohm > Sent: Wednesday, September 12, 2018 17:18 > > Testing your OpenSSL download with the HTTPS security bites its > own tail, especially if your download tool uses an (older) version > of OpenSSL to check the connection. And as I noted in my previous email, the HTTPS PKI is rubbish. Historically there have been numerous successful attacks on it, even in modes that do not involve user intervention. It's better than nothing, but checking the PGP signature is defense in depth that does not rely solely on the integrity of the HTTPS PKI. > But unless you have an established personal list of GPG/PGP keys > you have checked against their holders in person yourself, checking > the HTTPS certificate of the OpenSSL.org web server is pretty much > all you can do to distinguish between a genuine and a fake first time > OpenSSL download (signatures on later downloads can be compared to > previous downloadsfor some degree of signature consistency). There are plenty of other channels that can be used to validate the PGP public key used to confirm the signature of the OpenSSL tarball. None of them are secure in themselves, but by using multiple channels, the defender greatly increases the attacker's work factor and risk of discovery. That's the whole point of defense in depth. It's not hard to learn how to install an OpenPGP implementation (most likely gpg) and use it to verify a detached signature. There are many tutorials available online. I don't think a lack of experience with PGP or gpg is a valid excuse for not validating the signature. > Of cause some real knowledge is needed to not use the OpenSSL source > code incorrectly, unless you are merely compiling other peoples > software exactly as instructed. Yes. And this is a much more likely source of problems than a counterfeit OpenSSL distribution. -- Michael Wojcik Distinguished Engineer, Micro Focus From kk at keppler-it.de Thu Sep 13 07:57:15 2018 From: kk at keppler-it.de (Klaus Keppler) Date: Thu, 13 Sep 2018 09:57:15 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> Message-ID: <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> Hi, thank you for all your responses. I've just tested with Firefox Nightly 64.0a1, and both s_server and our own app (using OpenSSL 1.1.1-release) are working fine. The Firefox website is quite confusing: > Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) This is quite confusing, as it sounds better than it actually is. (so I've just learned that draft-28 is obviously incompatible with RFC8446) So thank you for your input, will now continue with OpenSSL 1.1.1. The rest will be only a matter of time. :D Best regards -Klaus From naliaka at protonmail.com Thu Sep 13 10:23:47 2018 From: naliaka at protonmail.com (Cyrus Naliaka) Date: Thu, 13 Sep 2018 10:23:47 +0000 Subject: [openssl-users] License change still scheduled for 1.1.1 ? In-Reply-To: <45129FC9-48AC-4A50-A2D4-1C7FFEA7743F@akamai.com> References: <45129FC9-48AC-4A50-A2D4-1C7FFEA7743F@akamai.com> Message-ID: 1.1.1 release still has the legacy license. Should we still expect a license change? Thank you. ??????? Original Message ??????? On Monday, June 25, 2018 5:20 PM, Salz, Rich wrote: > - Do you still plan to switch to Apache license for the final 1.1.1 release? > > That is still our goal, as stated. -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Thu Sep 13 10:41:40 2018 From: matt at openssl.org (Matt Caswell) Date: Thu, 13 Sep 2018 11:41:40 +0100 Subject: [openssl-users] License change still scheduled for 1.1.1 ? In-Reply-To: References: <45129FC9-48AC-4A50-A2D4-1C7FFEA7743F@akamai.com> Message-ID: <84a97005-183c-43a3-c446-1b8341d415c2@openssl.org> On 13/09/18 11:23, Cyrus Naliaka via openssl-users wrote: > 1.1.1 release still has the legacy license. > > Should we still expect a license change? > It is still our intention to change the license at some point however issues remain. It is likely to be some while before we are able to do so. Matt From aleksandr.derevianko at btsignal.ru Thu Sep 13 13:43:17 2018 From: aleksandr.derevianko at btsignal.ru (aleksandr.derevianko at btsignal.ru) Date: Thu, 13 Sep 2018 16:43:17 +0300 Subject: [openssl-users] DTLS-over-UDP client example In-Reply-To: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> References: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> Message-ID: <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> Hello ! I'm completely new to openssl, but really need to implement simple application which will use DTLS over UDP. Unfortunelly, it seems that all examples which I can find, correctly implement DTLS server, but not implement DTLS client side. For example, this one: https://github.com/nplab/DTLS-Examples/blob/master/src/dtls_udp_echo.c implement both client and server, but all connection from client to server have no encoding: SSL_CIPHER_get_name(SSL_get_current_cipher(ssl)) returns "NULL-SHA256"; It's because client side sets SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5"); If I try to connect to the dtls_udp_echo application in server mode using openssl s_client, it connects successfully and with encoding enabled ("AES256-SHA"). If I change client side SSL_CTX_set_cipher_list to "ALL", or "AES256:SHA" - SSL_connect() on client hangs forever. I think, the reason is that server side require cookie exchange, and clients side doesn't implement it. At least, if I connect using openssl s_client, on server side both verify_cookie and generate_cookie was called. If I use example client, only generate_cookie was called. Client just hangs forever, sending packets to server every few seconds until timeout expired (~8 minutes) and return SSL_connect: Resource temporarily unavailable error:1413C138:SSL routines:dtls1_check_timeout_num:read timeout expired It seems for me that for DTLS connection, SSL_connect() doesn't implement cookies exchange. I tryed to dig inside openssl s_client source code, but it's really too complex for me, it seems like s_client doesn't use SSL_connect, instead, using more low-level functions. So, does anybody have any simple client-side implementation of DTLS over UDP connection? --? ????????? ?????????/Aleksander Derevianko ???. ?????? ????? ?????????-??????????? ??????? ????????? ????????????? (??????)/Bombardier Transportation (Signal) Ltd. T: ? +74959255370 ???. 265 M: +79859229755 From jb-openssl at wisemo.com Thu Sep 13 17:55:54 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 13 Sep 2018 19:55:54 +0200 Subject: [openssl-users] Checksum for openssl-1.0.2p download In-Reply-To: References: <163ce955-d7ee-2dbe-06fd-99407321f4e4@openssl.org> Message-ID: <2bd9663a-e803-31a3-cc69-59b9779713e7@wisemo.com> On 13/09/2018 03:24, Michael Wojcik wrote: >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf >> Of Jakob Bohm >> Sent: Wednesday, September 12, 2018 17:18 >> >> Testing your OpenSSL download with the HTTPS security bites its >> own tail, especially if your download tool uses an (older) version >> of OpenSSL to check the connection. > And as I noted in my previous email, the HTTPS PKI is rubbish. Historically there have been numerous successful attacks on it, even in modes that do not involve user intervention. > > It's better than nothing, but checking the PGP signature is defense in depth that does not rely solely on the integrity of the HTTPS PKI. > >> But unless you have an established personal list of GPG/PGP keys >> you have checked against their holders in person yourself, checking >> the HTTPS certificate of the OpenSSL.org web server is pretty much >> all you can do to distinguish between a genuine and a fake first time >> OpenSSL download (signatures on later downloads can be compared to >> previous downloadsfor some degree of signature consistency). > There are plenty of other channels that can be used to validate the PGP public key used to confirm the signature of the OpenSSL tarball. None of them are secure in themselves, but by using multiple channels, the defender greatly increases the attacker's work factor and risk of discovery. That's the whole point of defense in depth. > > It's not hard to learn how to install an OpenPGP implementation (most likely gpg) and use it to verify a detached signature. There are many tutorials available online. I don't think a lack of experience with PGP or gpg is a valid excuse for not validating the signature. > >> Of cause some real knowledge is needed to not use the OpenSSL source >> code incorrectly, unless you are merely compiling other peoples >> software exactly as instructed. > Yes. And this is a much more likely source of problems than a counterfeit OpenSSL distribution. > To make it clear, I am very experienced and do in fact check the gpg signature if possible.? I was trying to give good advice to the OP based on my experience checking the only ways that the OpenSSL foundation provides. The OpenPGP/GPG key servers that you suggested, by design, accept any made up key identity and thus provide no indication of validity, so just downloading the key from there is a non-solution to the problem of bootstrapping trust in someones first OpenSSL download. To my knowledge the only ways to check that the .asc file was signed with an authorized release key are: A) Trusting that the HTTPS connection to the download server is uncompromised, ? essentially treating at least the first such signature as a glorified ? .sha256 file. B) Checking doc/fingerprints.txt in the previous tarball and hoping the OpenSSL ? foundation double checks the correctness of that file before signing a new ? tarball. C) Using the text (BUT NOT THE INSECURE LINKS) on ? https://www.openssl.org/community/omc.html ?? But this lists some unauthorized keys, and also relies on that same HTTPS ? certificate. Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com Transformervej 29, 2860 S?borg, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded From jb-openssl at wisemo.com Thu Sep 13 18:13:41 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Thu, 13 Sep 2018 20:13:41 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> Message-ID: <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> On 13/09/2018 09:57, Klaus Keppler wrote: > Hi, > > thank you for all your responses. > > I've just tested with Firefox Nightly 64.0a1, and both s_server and our > own app (using OpenSSL 1.1.1-release) are working fine. > > The Firefox website is quite confusing: > >> Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). > (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) > > This is quite confusing, as it sounds better than it actually is. > (so I've just learned that draft-28 is obviously incompatible with RFC8446) > > So thank you for your input, will now continue with OpenSSL 1.1.1. > The rest will be only a matter of time. :D > > Best regards > > -Klaus Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be removed again in a few years) to accept the draft version number of final TLS 1.3, if the protocols are otherwise identical? This would be similar to the (now historic) bits for known bugs in other popular clients.? It also seems to be what Facebook has done for their own servers (according to other posts in this discussion). Or would it be unproblematic from a real world perspective to just keep TLS 1.3 non-functional for draft-28 browsers? 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 dclarke at blastwave.org Thu Sep 13 18:55:16 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 13 Sep 2018 14:55:16 -0400 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> Message-ID: On 09/13/2018 02:13 PM, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: >> Hi, >> >> thank you for all your responses. >> >> I've just tested with Firefox Nightly 64.0a1, and both s_server and our >> own app (using OpenSSL 1.1.1-release) are working fine. >> >> The Firefox website is quite confusing: >> >>> Firefox 61 is already shipping draft-28, which is essentially the >>> same as the final published version (just with a different version >>> number). >> (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) >> >> >> This is quite confusing, as it sounds better than it actually is. >> (so I've just learned that draft-28 is obviously incompatible with >> RFC8446) >> >> So thank you for your input, will now continue with OpenSSL 1.1.1. >> The rest will be only a matter of time. :D >> >> Best regards >> >> ??? -Klaus > Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be > removed again in a few years) to accept the draft version number of final > TLS 1.3, if the protocols are otherwise identical? > What would the benefit be? Allow support for older browsers? I think that TLSv1.3 support exists fine in Firefox now and ver 61 is not an ESR release at all. I am not sure what the benefit would be. Draft 28 is much like Draft X for any X less than 28. > This would be similar to the (now historic) bits for known bugs in other > popular clients.? It also seems to be what Facebook has done for their > own servers (according to other posts in this discussion). > > Or would it be unproblematic from a real world perspective to just keep > TLS 1.3 non-functional for draft-28 browsers? Given that the protocol is published and the browser support exists for the real protocol then there can not be a raeason to support Draft X. Dennis From bkaduk at akamai.com Thu Sep 13 19:10:50 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Thu, 13 Sep 2018 14:10:50 -0500 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> Message-ID: <20180913191050.GN5819@akamai.com> On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: > >Hi, > > > >thank you for all your responses. > > > >I've just tested with Firefox Nightly 64.0a1, and both s_server and our > >own app (using OpenSSL 1.1.1-release) are working fine. > > > >The Firefox website is quite confusing: > > > >>Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). > >(https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) > > > >This is quite confusing, as it sounds better than it actually is. > >(so I've just learned that draft-28 is obviously incompatible with RFC8446) > > > >So thank you for your input, will now continue with OpenSSL 1.1.1. > >The rest will be only a matter of time. :D > > > >Best regards > > > > -Klaus > Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be > removed again in a few years) to accept the draft version number of final > TLS 1.3, if the protocols are otherwise identical? > > This would be similar to the (now historic) bits for known bugs in other > popular clients.? It also seems to be what Facebook has done for their > own servers (according to other posts in this discussion). > > Or would it be unproblematic from a real world perspective to just keep > TLS 1.3 non-functional for draft-28 browsers? It would be unproblematic. Such browsers will use TLS 1.2 just fine, and are going to be auto-updating to a version capable of official TLS 1.3 very soon anyway. -Ben From rsalz at akamai.com Thu Sep 13 19:47:34 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 13 Sep 2018 19:47:34 +0000 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <20180913191050.GN5819@akamai.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180913191050.GN5819@akamai.com> Message-ID: <7A7020A9-4C2A-4DA4-AC3C-2A7755FA785A@akamai.com> Much work for little gain and purpose. You can mix drafts, but mixing the draft and the official version is hard, there's too many semantic changes (e.g., around fallback vs no-fallback-protection). From jb-openssl at wisemo.com Fri Sep 14 05:34:45 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Fri, 14 Sep 2018 07:34:45 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <7A7020A9-4C2A-4DA4-AC3C-2A7755FA785A@akamai.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180913191050.GN5819@akamai.com> <7A7020A9-4C2A-4DA4-AC3C-2A7755FA785A@akamai.com> Message-ID: <54240f97-cc54-a911-4c56-06519e6be137@wisemo.com> On 13/09/2018 21:47, Salz, Rich via openssl-users wrote: > Much work for little gain and purpose. > > You can mix drafts, but mixing the draft and the official version is hard, there's too many semantic changes (e.g., around fallback vs no-fallback-protection). Ok, from what others had said, the only change between draft-28 and final was supposedly the version number.? Given all the talk of testing of the protocol design, it would seem out of character for the WG to have mechanisms that were disabled in all the drafts and thus untested. 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 beldmit at gmail.com Fri Sep 14 10:30:00 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Sep 2018 13:30:00 +0300 Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: <484c33c9-c843-4aa4-b5c9-79148d835248@default> References: <484c33c9-c843-4aa4-b5c9-79148d835248@default> Message-ID: Dear Paul, Could you please clarify? The code seems to be related to s390 platform. Do I miss something? On Thu, Sep 13, 2018 at 1:55 AM Paul Dale wrote: > I wasn?t aware of other national standards requiring a similar check. > > > > I made the change in the AES-GCM code because FIPS demands the check be > inside the FIPS boundary. I?d have preferred to make it in the TLS layer, > but that mustn?t be inside the FIPS boundary. My understanding is that TLS > catches this case earlier and thus the test can never pass. > > > > I don?t think dropping the check down into the algorithm implementations > makes sense. A more generic mechanism at the EVP would. > > > > > > > > Pauli > > -- > > Oracle > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] > *Sent:* Wednesday, 12 September 2018 7:02 PM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Limit the number of AES-GCM keys allowed in TLS > > > > Hello, > > > > The issue https://github.com/openssl/openssl/pull/7129 has introduced a > possibility to limit the amount of TLS records processed without key > changing as required by FIPS. > > > > We in Russia have limitations with the same semantics applicable to > Russian GOST TLS ciphersuites ( > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so > I think that this mechanism is very useful. > > > > The current implementation is done at EVP level, and it seems suboptimal > because of the following reasons: > > - If the AES implementation is provided via engine, not by OpenSSL itself, > the limitation can be avoided > > - the limitation has been made too generic > > - the implementation seems to be AEAD-specific. > > > > So does not it make sense to provide this limitation at least at the > ciphersuite level? It can provide more straightforward way to manage such > limitations. > > > Thank you! > > > > -- > > SY, Dmitry Belyavsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From beldmit at gmail.com Fri Sep 14 10:41:21 2018 From: beldmit at gmail.com (Dmitry Belyavsky) Date: Fri, 14 Sep 2018 13:41:21 +0300 Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: References: <484c33c9-c843-4aa4-b5c9-79148d835248@default> Message-ID: Hello, Sorry, I've just found similar checks in all _CGM functions. On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky wrote: > Dear Paul, > > Could you please clarify? > The code seems to be related to s390 platform. Do I miss something? > > On Thu, Sep 13, 2018 at 1:55 AM Paul Dale wrote: > >> I wasn?t aware of other national standards requiring a similar check. >> >> >> >> I made the change in the AES-GCM code because FIPS demands the check be >> inside the FIPS boundary. I?d have preferred to make it in the TLS layer, >> but that mustn?t be inside the FIPS boundary. My understanding is that TLS >> catches this case earlier and thus the test can never pass. >> >> >> >> I don?t think dropping the check down into the algorithm implementations >> makes sense. A more generic mechanism at the EVP would. >> >> >> >> >> >> >> >> Pauli >> >> -- >> >> Oracle >> >> Dr Paul Dale | Cryptographer | Network Security & Encryption >> >> Phone +61 7 3031 7217 >> >> Oracle Australia >> >> >> >> *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] >> *Sent:* Wednesday, 12 September 2018 7:02 PM >> *To:* openssl-users at openssl.org >> *Subject:* [openssl-users] Limit the number of AES-GCM keys allowed in >> TLS >> >> >> >> Hello, >> >> >> >> The issue https://github.com/openssl/openssl/pull/7129 has introduced a >> possibility to limit the amount of TLS records processed without key >> changing as required by FIPS. >> >> >> >> We in Russia have limitations with the same semantics applicable to >> Russian GOST TLS ciphersuites ( >> https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so >> I think that this mechanism is very useful. >> >> >> >> The current implementation is done at EVP level, and it seems suboptimal >> because of the following reasons: >> >> - If the AES implementation is provided via engine, not by OpenSSL >> itself, the limitation can be avoided >> >> - the limitation has been made too generic >> >> - the implementation seems to be AEAD-specific. >> >> >> >> So does not it make sense to provide this limitation at least at the >> ciphersuite level? It can provide more straightforward way to manage such >> limitations. >> >> >> Thank you! >> >> >> >> -- >> >> SY, Dmitry Belyavsky >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > > > -- > SY, Dmitry Belyavsky > -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From doctor at doctor.nl2k.ab.ca Fri Sep 14 14:08:48 2018 From: doctor at doctor.nl2k.ab.ca (The Doctor) Date: Fri, 14 Sep 2018 08:08:48 -0600 Subject: [openssl-users] openssl 1.1.1 daily snapshots Message-ID: <20180914140848.GG23810@doctor.nl2k.ab.ca> When will those be ready to go? -- 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 NB 24 Sept vote Liberal! Quebec votez contre le PQ et le QS des 1 October 2018! From gmm at csdoc.com Fri Sep 14 14:30:34 2018 From: gmm at csdoc.com (Gena Makhomed) Date: Fri, 14 Sep 2018 17:30:34 +0300 Subject: [openssl-users] OpenSSL OCSP and RFC 6960 Message-ID: Hello, All! For certificates generated by "Let's Encrypt Authority X3" for getting ocsp response from letsencrypt I need to use such command: # openssl ocsp -verify_other chain.pem \ -issuer chain.pem \ -cert cert.pem \ -text \ -url http://ocsp.int-x3.letsencrypt.org \ -header "Host" "ocsp.int-x3.letsencrypt.org" =========================== If I remove '-header "Host" "ocsp.int-x3.letsencrypt.org"' from command line I got error: Error querying OCSP responder 140274026829712:error:27076072:OCSP routines:PARSE_HTTP_LINE1:server response error:ocsp_ht.c:314:Code=400,Reason=Bad Request openssl ocsp utility does not send 'Host' header by default? But why? Looks like this is bug. =========================== If I remove '-verify_other chain.pem' from command line I got error: Response Verify Failure 140272439146384:error:27069076:OCSP routines:OCSP_basic_verify:signer certificate not found:ocsp_vfy.c:92: 'man ocsp' tell what -verify_other file file containing additional certificates to search when attempting to locate the OCSP response signing certificate. Some responders omit the actual signer's certificate from the response: this option can be used to supply the necessary certificate in such cases. But why I need to provide '-verify_other chain.pem' with issuer certificate? As I understand, RFC 6960 tell what only issuer certificate is required for OCSP response verification. Looks like this is bug in OpenSSL library / openssl ocsp utility. -- Best regards, Gena From jay-jordan82 at outlook.com Sat Sep 15 02:43:32 2018 From: jay-jordan82 at outlook.com (Jason Jordan) Date: Sat, 15 Sep 2018 02:43:32 +0000 Subject: [openssl-users] (no subject) Message-ID: Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From jay-jordan82 at outlook.com Sat Sep 15 02:44:50 2018 From: jay-jordan82 at outlook.com (Jason Jordan) Date: Sat, 15 Sep 2018 02:44:50 +0000 Subject: [openssl-users] Contents of openssl-users digest..." Message-ID: Get Outlook for Android -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Sep 15 04:45:31 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 15 Sep 2018 06:45:31 +0200 (CEST) Subject: [openssl-users] openssl 1.1.1 daily snapshots In-Reply-To: <20180914140848.GG23810@doctor.nl2k.ab.ca> References: <20180914140848.GG23810@doctor.nl2k.ab.ca> Message-ID: <20180915.064531.1482681054365529357.levitte@openssl.org> In message <20180914140848.GG23810 at doctor.nl2k.ab.ca> on Fri, 14 Sep 2018 08:08:48 -0600, The Doctor said: > When will those be ready to go? At 06:22 UTC today. That's just over 1? hours from now. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From kurt at roeckx.be Sat Sep 15 08:46:01 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Sat, 15 Sep 2018 10:46:01 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> Message-ID: <20180915084601.GA6822@roeckx.be> On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: > On 13/09/2018 09:57, Klaus Keppler wrote: > > Hi, > > > > thank you for all your responses. > > > > I've just tested with Firefox Nightly 64.0a1, and both s_server and our > > own app (using OpenSSL 1.1.1-release) are working fine. > > > > The Firefox website is quite confusing: > > > > > Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). > > (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) > > > > This is quite confusing, as it sounds better than it actually is. > > (so I've just learned that draft-28 is obviously incompatible with RFC8446) > > > > So thank you for your input, will now continue with OpenSSL 1.1.1. > > The rest will be only a matter of time. :D > > > > Best regards > > > > -Klaus > Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be > removed again in a few years) to accept the draft version number of final > TLS 1.3, if the protocols are otherwise identical? Draft versions really should die as soon as possible. If we ever put it in a released version, it will still be in use in 10 years, which really isn't something we want. On the other hand, in a few weeks browsers will stop using those draft versions, so I really don't see the point. Kurt From murugaiyan.perumal at yahoo.co.in Sun Sep 16 15:44:00 2018 From: murugaiyan.perumal at yahoo.co.in (Murugaiyan Perumal) Date: Sun, 16 Sep 2018 15:44:00 +0000 (UTC) Subject: [openssl-users] QNX 6.5 OpenSSL Build References: <1856433470.4937525.1537112640324.ref@mail.yahoo.com> Message-ID: <1856433470.4937525.1537112640324@mail.yahoo.com> Hi,Am trying to build the openssl source for QNX 6.5/6.6 OS. I have tried to build after the instructions given in internet.? 1. QNX 6.6 build environment variable is set.?2. Executed below command.?sh-3.1$? ./Configure QNX6 shared --prefix=./qnx660/release --openssldir=./qnx660/release 3. make depend exectuted. Got compilation error.? ../../util/domd ../.. -MD gcc -- -fPIC -DOPENSSL_PIC -DOPENSSL_THREADS? -DDSO_DLFCN -DHAVE_DLFCN_H? -I.. -I../.. -I../modes -I../asn1 -I../evp -I../../include? -DOPENSSL_NO_DEPRECATED -DOPENSSL_NO_EC_NISTP_64_GCC_128 -DOPENSSL_NO_GMP -DOPENSSL_NO_JPAKE -DOPENSSL_NO_LIBUNBOUND -DOPENSSL_NO_MD2 -DOPENSSL_NO_RC5 -DOPENSSL_NO_RFC3779 -DOPENSSL_NO_SCTP -DOPENSSL_NO_SSL_TRACE -DOPENSSL_NO_SSL2 -DOPENSSL_NO_STORE -DOPENSSL_NO_UNIT_TEST -DOPENSSL_NO_WEAK_SSL_CIPHERS --? dso_dl.c dso_dlfcn.c dso_err.c dso_lib.c dso_null.c dso_openssl.c dso_win32.c dso_vms.c dso_beos.cdso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory?#? include Also when I executed make all from command line. Seems like nothing has been built.?????sh-3.1$ makesh-3.1$ make allsh-3.1$ Could anyone help me out to build openssl for qnx 6.5 os.? Thanks,Murugaiyan -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Sep 16 17:04:10 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 16 Sep 2018 13:04:10 -0400 Subject: [openssl-users] QNX 6.5 OpenSSL Build In-Reply-To: <1856433470.4937525.1537112640324@mail.yahoo.com> References: <1856433470.4937525.1537112640324.ref@mail.yahoo.com> <1856433470.4937525.1537112640324@mail.yahoo.com> Message-ID: <7E017E71-1E57-4AC4-B8BE-92AA997935D4@dukhovni.org> > On Sep 16, 2018, at 11:44 AM, Murugaiyan Perumal via openssl-users wrote: > > dso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory > # include http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/d/dlopen.html This header is expected to be present, perhaps your system is missing the requisite software development package, or GCC-specific headers. -- Viktor. From paul.dale at oracle.com Sun Sep 16 21:23:21 2018 From: paul.dale at oracle.com (Paul Dale) Date: Sun, 16 Sep 2018 14:23:21 -0700 (PDT) Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: References: <484c33c9-c843-4aa4-b5c9-79148d835248@default> Message-ID: <2a7535a2-01bc-4733-a67a-755ddaf32348@default> There is nothing S390 specific in this, it is a requirement to use GCM based ciphers for TLS when running in a FIPS validated environment.? The check will be cheaper than trying to avoid it by conditioning on FIPS mode -- hence it?s unconditional. ? ? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia ? From: Dmitry Belyavsky [mailto:beldmit at gmail.com] Sent: Friday, 14 September 2018 8:41 PM To: openssl-users at openssl.org Subject: Re: [openssl-users] Limit the number of AES-GCM keys allowed in TLS ? Hello, ? Sorry, I've just found similar checks in all _CGM functions.? ? On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky wrote: Dear Paul, ? Could you please clarify?? The code seems to be related to s390 platform. Do I miss something? ? On Thu, Sep 13, 2018 at 1:55 AM Paul Dale wrote: I wasn?t aware of other national standards requiring a similar check. ? I made the change in the AES-GCM code because FIPS demands the check be inside the FIPS boundary.? I?d have preferred to make it in the TLS layer, but that mustn?t be inside the FIPS boundary.? My understanding is that TLS catches this case earlier and thus the test can never pass. ? I don?t think dropping the check down into the algorithm implementations makes sense.? A more generic mechanism at the EVP would. ? ? ? Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia ? From: Dmitry Belyavsky [mailto:HYPERLINK "mailto:beldmit at gmail.com"beldmit at gmail.com] Sent: Wednesday, 12 September 2018 7:02 PM To: HYPERLINK "mailto:openssl-users at openssl.org"openssl-users at openssl.org Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS ? Hello, ? The issue https://github.com/openssl/openssl/pull/7129 has introduced a possibility to limit the amount of TLS records processed without key changing as required by FIPS. ? We in Russia have limitations with the same semantics applicable to Russian GOST TLS ciphersuites (https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so I think that this mechanism is very useful.? ? The current implementation is done at EVP level, and it seems suboptimal because of the following reasons: - If the AES implementation is provided via engine, not by OpenSSL itself, the limitation can be avoided - the limitation has been made too generic - the implementation seems to be AEAD-specific.? ? So does not it make sense to provide this limitation at least at the ciphersuite level? It can provide more straightforward way to manage such limitations. Thank you! ? -- SY, Dmitry Belyavsky -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ? -- SY, Dmitry Belyavsky ? -- SY, Dmitry Belyavsky -------------- next part -------------- An HTML attachment was scrubbed... URL: From katzenjaeger at yandex.com Mon Sep 17 00:36:34 2018 From: katzenjaeger at yandex.com (Nafanja) Date: Mon, 17 Sep 2018 02:36:34 +0200 Subject: [openssl-users] Building openssl-1.1.1 Message-ID: <5ba40780-063a-0d19-1233-b5fbcbf72d2b@yandex.com> Hello, I tried to compile openssl-1.1.1 and the process runs without errors but wenn I try to verify the version by oppenssl version I got this message: Kompilierung und Installation von openssl-1.1.1 verliefen ohne Probleme aber bei der Versionsabfrage erhalte ich: openssl version openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version `OPENSSL_1_1_1' not found (required by openssl) I run Linux Mint 19 with Kernel 4.18.8 I followed this tutorial: -------> hxxps://mdxdave.de/technik/linux/openssl-debian wget ftp://ftp.openssl.org/source/openssl-1.1.1.tar.gz tar xfz openssl-1.1.1.tar.gz cd openssl-1.1.1 sudo ./config --prefix=/usr zlib-dynamic --openssldir=/etc/ssl shared sudo make sudo make test sudo make install Any ideas about this problem and how to solve it? Thank you an good night :) -------------- next part -------------- A non-text attachment was scrubbed... Name: 0xD1E6AD6A1149BC42.asc Type: application/pgp-keys Size: 3914 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From bbrumley at gmail.com Mon Sep 17 05:30:11 2018 From: bbrumley at gmail.com (Billy Brumley) Date: Mon, 17 Sep 2018 08:30:11 +0300 Subject: [openssl-users] Building openssl-1.1.1 In-Reply-To: <5ba40780-063a-0d19-1233-b5fbcbf72d2b@yandex.com> References: <5ba40780-063a-0d19-1233-b5fbcbf72d2b@yandex.com> Message-ID: > openssl version > openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version > `OPENSSL_1_1_1' not found (required by openssl) > openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version > `OPENSSL_1_1_1' not found (required by openssl) Sounds like a loader issue. Try "which openssl" then "ldd /path/to/openssl" I dunno what current recommendation is, but I normally use RPATH: https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs Hope it helps, BBB From gaofanv at 126.com Mon Sep 17 09:40:34 2018 From: gaofanv at 126.com (Gaofan) Date: Mon, 17 Sep 2018 17:40:34 +0800 (CST) Subject: [openssl-users] Why default FIPS DBRG only call the RAND_poll() once? Message-ID: <3a7041d7.aa22.165e6e72c67.Coremail.gaofanv@126.com> hi all, I set the fips mode and call the RAND_pseudo_bytes for more than 1<<24 times to trigger the reseed process, but I found RAND_Poll() still cannot be called in the reseed process. if (!initialized) { RAND_poll(); initialized = 1; } the initialized cannot be changed during the reseed process, can anyone help, why it will not call the RAND_poll() to get the data from the /dev/urandom? Thanks a lot. Best regard Gaofan -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 17 12:21:29 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 17 Sep 2018 08:21:29 -0400 Subject: [openssl-users] Building openssl-1.1.1 In-Reply-To: References: <5ba40780-063a-0d19-1233-b5fbcbf72d2b@yandex.com> Message-ID: > On Sep 17, 2018, at 1:30 AM, Billy Brumley wrote: > >> openssl version >> openssl: /usr/lib/x86_64-linux-gnu/libssl.so.1.1: version >> `OPENSSL_1_1_1' not found (required by openssl) >> openssl: /usr/lib/x86_64-linux-gnu/libcrypto.so.1.1: version >> `OPENSSL_1_1_1' not found (required by openssl) > > Sounds like a loader issue. No, rather this user built the library with "--prefix /usr", but /usr/lib already contains an OpenSSL 1.1.0 library. Which does not have the 1.1.1 symbol versions. > Try "which openssl" then "ldd /path/to/openssl" > > I dunno what current recommendation is, but I normally use RPATH: > > https://wiki.openssl.org/index.php/Compilation_and_Installation#Using_RPATHs To deploy a second library, it needs to go somewhere else (/usr/local, /opt/openssl, ...), and then indeed one also needs RPATH so that the executable and libssl know where to find their dependencies. -- Viktor. From rgm at htt-consult.com Mon Sep 17 13:15:36 2018 From: rgm at htt-consult.com (Robert Moskowitz) Date: Mon, 17 Sep 2018 09:15:36 -0400 Subject: [openssl-users] Successful testing of 1.1.1 Message-ID: Fedora 29 beta just provided (in testing-update repo): openssl-1.1.1-2.fc29.armv7hl.rpm Against this version, I successfully produced by ED25519 pki per: https://github.com/rgmhtt/draft-moskowitz-eddsa-pki I have some minor textual edits to make in the draft and then submit it.? Then I can also go to IEEE 802.1 and raise up adding EDDSA support to IEEE 802.1AR. Thank you for providing the code base! And all your help along the way. From richard.weinberger at gmail.com Mon Sep 17 13:25:27 2018 From: richard.weinberger at gmail.com (Richard Weinberger) Date: Mon, 17 Sep 2018 15:25:27 +0200 Subject: [openssl-users] DTLS-over-UDP client example In-Reply-To: <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> References: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> Message-ID: On Thu, Sep 13, 2018 at 3:51 PM wrote: > I tryed to dig inside openssl s_client source code, but it's really too complex for me, it seems like s_client doesn't use > SSL_connect, instead, using more low-level functions. > > > So, does anybody have any simple client-side implementation of DTLS over UDP connection? https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c ... is a good example. In case you are on 1.1.x, please also see: https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html OpenSSL badly regressed in 1.1.x wrt. DTLS. -- Thanks, //richard From Neil.Craig at bbc.co.uk Mon Sep 17 15:29:29 2018 From: Neil.Craig at bbc.co.uk (Neil Craig) Date: Mon, 17 Sep 2018 15:29:29 +0000 Subject: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1 Message-ID: Hi all I'm trying to re-add 3DES support (a temporary move, due to business requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. Whilst I do see some older ciphersuites being offered by NGINX after doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but that didn?t work. I have also tried adding @seclevel=0 to the ciphersuite string in NGINX but again, that didn?t work, I don?t see any 3DES ciphersuites available in NGINX. I'm wondering whether something changed between the above article and the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was completely removed in OpenSSL 1.1.1). Any pointers would be very much appreciated, I can?t find anything very useful on the web. Cheers Neil Craig Lead Technical Architect | Online Technology Group [cid:FDC52DA5-F1EC-4ED7-A69C-CACB83B41880] Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: 60158DAA-E151-40BD-A3FB-C615340C7061[19].png Type: image/png Size: 1914 bytes Desc: 60158DAA-E151-40BD-A3FB-C615340C7061[19].png URL: From matt at openssl.org Mon Sep 17 16:41:40 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 17 Sep 2018 17:41:40 +0100 Subject: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1 In-Reply-To: References: Message-ID: <5e005ca5-d135-c28e-f9bb-f4b0fe4704e6@openssl.org> On 17/09/18 16:29, Neil Craig wrote: > Hi all > > I'm trying to re-add 3DES support (a temporary move, due to business > requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX > build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt > from https://www.openssl.org/blog/blog/2016/08/24/sweet32/.? > > Whilst I do see some older ciphersuites being offered by NGINX after > doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was > expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but > that didn?t work. I have also tried adding @seclevel=0 to the > ciphersuite string in NGINX but again, that didn?t work, I don?t see any > 3DES ciphersuites available in NGINX. > > I'm wondering whether something changed between the above article and > the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was > completely removed in OpenSSL 1.1.1). > > Any pointers would be very much appreciated, I can?t find anything very > useful on the web. 3DES is still available in 1.1.1 but is no longer in the DEFAULT ciphersuite list, so unless you explicitly configure them to be available you won't see them (even if you configure with enable-weak-ssl-ciphers). E.g. (assuming you compiled with enable-weak-ssl-ciphers): $ openssl ciphers -v | grep 3DES Will give you 0 ciphers, but $ openssl ciphers -v 3DES | grep 3DES Should list 14 different 3DES ciphersuites that are available. I don't know about nginx config though so maybe someone else can help there. Matt From jayf0ster at roadrunner.com Mon Sep 17 18:12:39 2018 From: jayf0ster at roadrunner.com (Jay Foster) Date: Mon, 17 Sep 2018 11:12:39 -0700 Subject: [openssl-users] OpenSSL 1.1.1 Compiler Warnings Message-ID: <85336f2c-9671-c91d-2b92-6403884eaf2f@roadrunner.com> With the recent release of OpenSSL 1.1.1, I tried to cross compile it for a 32-bit ARM architecture.? I observe many compiler warnings similar to the following: crypto/ec/curve448/curve448.c:30: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448.c:30: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448.c:30: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448.c:30: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/curve448_tables.c:19: warning: integer constant is too large for 'long' type crypto/ec/curve448/f_generic.c:15: warning: integer constant is too large for 'long' type crypto/ec/curve448/f_generic.c:15: warning: integer constant is too large for 'long' type crypto/ec/curve448/f_generic.c:15: warning: integer constant is too large for 'long' type crypto/ec/curve448/f_generic.c:15: warning: integer constant is too large for 'long' type crypto/ec/curve448/f_generic.c:15: warning: integer constant is too large for 'long' type crypto/ec/curve448/scalar.c:17: warning: integer constant is too large for 'long' type crypto/ec/curve448/scalar.c:21: warning: integer constant is too large for 'long' type crypto/ec/curve448/scalar.c:21: warning: integer constant is too large for 'long' type crypto/ec/curve448/scalar.c:21: warning: integer constant is too large for 'long' type There were many many more of these, which I omitted for brevity.? I looked at the source and it does look like the code is trying to stuff a 64-bit constant into a 32-bit variable.? Does OpenSSL-1.1.1 work on 32-bit architectures? Jay From matt at openssl.org Mon Sep 17 18:22:55 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 17 Sep 2018 19:22:55 +0100 Subject: [openssl-users] OpenSSL 1.1.1 Compiler Warnings In-Reply-To: <85336f2c-9671-c91d-2b92-6403884eaf2f@roadrunner.com> References: <85336f2c-9671-c91d-2b92-6403884eaf2f@roadrunner.com> Message-ID: <83b171c0-06cb-4c73-41b5-164b5abb0ea1@openssl.org> On 17/09/18 19:12, Jay Foster wrote: > There were many many more of these, which I omitted for brevity.? I > looked at the source and it does look like the code is trying to stuff a > 64-bit constant into a 32-bit variable.? Does OpenSSL-1.1.1 work on > 32-bit architectures? Yes. It should work just fine on 32-bit. Matt From Neil.Craig at bbc.co.uk Mon Sep 17 20:20:04 2018 From: Neil.Craig at bbc.co.uk (Neil Craig) Date: Mon, 17 Sep 2018 20:20:04 +0000 Subject: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1 In-Reply-To: <5e005ca5-d135-c28e-f9bb-f4b0fe4704e6@openssl.org> References: <5e005ca5-d135-c28e-f9bb-f4b0fe4704e6@openssl.org> Message-ID: Thanks very much Matt. I have indeed built with NGINX configure opt --with-openssl-opt=enable-weak-ssl-cipher and whilst I don?t see an error when running NGINX with a/some 3DES cipher(s) in the ciphers list, I don?t see any 3DES ciphers in the output of e.g. Testssl and I can?t make a connection to the server using openssl CLI with -cipher <3DES cipher>. I wonder if the problem might be either NGINX not respecting/processing the configure opt (above) or possibly removing 3DES ciphers for some reason with openssl 1.1.1. I?ll keep digging, thanks again for your help and for confirming that?s the right thing to do. Cheers Neil Craig Lead Technical Architect | Online Technology Group Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org On 17/09/2018, 17:41, "openssl-users on behalf of Matt Caswell" wrote: > > >On 17/09/18 16:29, Neil Craig wrote: >> Hi all >> >> I'm trying to re-add 3DES support (a temporary move, due to business >> requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX >> build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt >> from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. >> >> Whilst I do see some older ciphersuites being offered by NGINX after >> doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was >> expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but >> that didn?t work. I have also tried adding @seclevel=0 to the >> ciphersuite string in NGINX but again, that didn?t work, I don?t see any >> 3DES ciphersuites available in NGINX. >> >> I'm wondering whether something changed between the above article and >> the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was >> completely removed in OpenSSL 1.1.1). >> >> Any pointers would be very much appreciated, I can?t find anything very >> useful on the web. > >3DES is still available in 1.1.1 but is no longer in the DEFAULT >ciphersuite list, so unless you explicitly configure them to be >available you won't see them (even if you configure with >enable-weak-ssl-ciphers). > >E.g. (assuming you compiled with enable-weak-ssl-ciphers): > > >$ openssl ciphers -v | grep 3DES > >Will give you 0 ciphers, but > >$ openssl ciphers -v 3DES | grep 3DES > >Should list 14 different 3DES ciphersuites that are available. > >I don't know about nginx config though so maybe someone else can help >there. > >Matt > >-- >openssl-users mailing list >To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- From parashah at cisco.com Mon Sep 17 20:59:59 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Mon, 17 Sep 2018 20:59:59 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Message-ID: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> I have softhsm-v2.5.0-rc1 which has ec keys imported in it. Now, when I try to use these keys from openssl CLI using the pkcs11 engine, it fails. 1. SoftHSM version []:~$ softhsm2-util --version 2.5.0rc1 2. SoftHSM token init []:~$ softhsm2-util --init-token --slot 0 --label "token 2.5.0-rc1" === SO PIN (4-255 characters) === Please enter SO PIN: **** Please reenter SO PIN: **** === User PIN (4-255 characters) === Please enter user PIN: **** Please reenter user PIN: **** The token has been initialized and is reassigned to slot 928024111 3. ECC key in pkcs8 format []:~$ openssl pkey -in ~/tmp/secp256k1-key.pem.pkcs8 -text -----BEGIN PRIVATE KEY----- MIGEAgEAMBAGByqGSM49AgEGBSuBBAAKBG0wawIBAQQgYCXpIJyEAexhkvrCMGlF A4sQItcIp6wm83WVoeOFzEyhRANCAATMfAkLtsynHRmRyYLn+uRpJUm6bOZJBQhK N81nJv06fN6MY0nEzWG9jJsvSNlf5jW7yecbje2wWQL/JYqviFwr -----END PRIVATE KEY----- Private-Key: (256 bit) priv: 60:25:e9:20:9c:84:01:ec:61:92:fa:c2:30:69:45: 03:8b:10:22:d7:08:a7:ac:26:f3:75:95:a1:e3:85: cc:4c pub: 04:cc:7c:09:0b:b6:cc:a7:1d:19:91:c9:82:e7:fa: e4:69:25:49:ba:6c:e6:49:05:08:4a:37:cd:67:26: fd:3a:7c:de:8c:63:49:c4:cd:61:bd:8c:9b:2f:48: d9:5f:e6:35:bb:c9:e7:1b:8d:ed:b0:59:02:ff:25: 8a:af:88:5c:2b ASN1 OID: secp256k1 4. Import the key into softhsm []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token "token 2.5.0-rc1" Found slot 928024111 with matching token label. === User PIN (4-255 characters) === Please enter user PIN: **** Please reenter user PIN: **** The key pair has been imported. 5. Get the pkcs11 url for the private key []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all Object 0: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private Type: Private key Label: ec key Flags: CKA_PRIVATE; CKA_SENSITIVE; ID: 11:11 Object 1: URL: pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=public Type: Public key Label: ec key ID: 11:11 6. Try to access key with openssl engine. []:~$ openssl version OpenSSL 1.1.1 11 Sep 2018 []:~$ more ~/tmp/openssl.cnf openssl_conf = openssl_init [openssl_init] engines=engine_section [engine_section] pkcs11 = pkcs11_section [pkcs11_section] engine_id = pkcs11 dynamic_path = /Users/parashah/Downloads/libp11-0.4.9/src/.libs/pkcs11.dylib MODULE_PATH = /usr/local/lib/softhsm/libsofthsm2.so init = 0 []:~$ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private" -inform ENGINE -engine pkcs11 -text engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: 140736065815424:error:100C0010:elliptic curve routines:i2d_ECPrivateKey:EC lib:crypto/ec/ec_asn1.c:995: 140736065815424:error:100D6010:elliptic curve routines:eckey_priv_encode:EC lib:crypto/ec/ec_ameth.c:242: 140736065815424:error:06071092:digital envelope routines:EVP_PKEY2PKCS8:private key encode error:crypto/evp/evp_pkey.c:72: 140736065815424:error:0907E073:PEM routines:do_pk8pkey:error converting private key:crypto/pem/pem_pk8.c:73: ==== Please let me know if I am missing anything. Note that the same operations work fine on a RSA key. -- Paras -------------- next part -------------- An HTML attachment was scrubbed... URL: From parashah at cisco.com Mon Sep 17 21:05:04 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Mon, 17 Sep 2018 21:05:04 +0000 Subject: [openssl-users] ED25519 key with openssl engine Message-ID: <831F2293-B318-407B-B399-8D127FBBCE6F@cisco.com> I get the following error when I try to access the ed25519 key stored in SoftHSM via the openssl engine interface using engine_pkcs11. []:~$ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%22%22;object=ed25519%20leaf%20key;type=private" -inform ENGINE -engine pkcs11 -text engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: Key not found. PKCS11_get_private_key returned NULL cannot load key from engine 140736065815424:error:80067065:pkcs11 engine:ctx_load_privkey:object not found:eng_back.c:862: 140736065815424:error:26096080:engine routines:ENGINE_load_private_key:failed loading private key:crypto/engine/eng_pkey.c:78: unable to load key The openssl version used above is 1.1.1. which supports the ed25519 keys. The softhsm is v2.5.0-rc1 which also support the ed25519 keys. -- Paras -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Mon Sep 17 21:22:22 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 17 Sep 2018 23:22:22 +0200 (CEST) Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> Message-ID: <20180917.232222.1527258087716065205.levitte@openssl.org> In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" said: > 4. Import the key into softhsm > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > "token 2.5.0-rc1" Ok, so here, the ID is "1111" > 5. Get the pkcs11 url for the private key > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > Object 0: > > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private But here, the ID is "%11%11", and since those get percent decoded, that's actually two vertical tabs, or with C vector syntax, { 0x0b, 0x0b } I'm not sure what engine-pkcs11 asks of you otherwise, but one guess could be to change 'id=%11%11' to 'id=1111' in that URL and try again. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ From parashah at cisco.com Mon Sep 17 22:15:08 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Mon, 17 Sep 2018 22:15:08 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: <20180917.232222.1527258087716065205.levitte@openssl.org> References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> Message-ID: <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> That is not it. It results in the same error for the EC key. It is not the URL or the ID. Because for a RSA key in the softhsm with id = 3333, it works fine with url containing id=%33%33 $ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" -engine pkcs11 -inform ENGINE engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: -----BEGIN PRIVATE KEY----- MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+ 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN dGAUprcbAgMBAAE= -----END PRIVATE KEY----- Coming back to EC key, looking at the error logs emitted, it does seem to recognize it to be EC (the logs contain EC_routines) somehow but then fails. ?On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" wrote: In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" said: > 4. Import the key into softhsm > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > "token 2.5.0-rc1" Ok, so here, the ID is "1111" > 5. Get the pkcs11 url for the private key > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > Object 0: > > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private But here, the ID is "%11%11", and since those get percent decoded, that's actually two vertical tabs, or with C vector syntax, { 0x0b, 0x0b } I'm not sure what engine-pkcs11 asks of you otherwise, but one guess could be to change 'id=%11%11' to 'id=1111' in that URL and try again. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Mon Sep 17 22:37:30 2018 From: matt at openssl.org (Matt Caswell) Date: Mon, 17 Sep 2018 23:37:30 +0100 Subject: [openssl-users] ED25519 key with openssl engine In-Reply-To: <831F2293-B318-407B-B399-8D127FBBCE6F@cisco.com> References: <831F2293-B318-407B-B399-8D127FBBCE6F@cisco.com> Message-ID: <166191ce-95d1-4a3c-55b4-f4c96b63ae6b@openssl.org> Perhaps the pkcs11 engine does not support ed25519 keys? Matt On 17/09/18 22:05, Paras Shah (parashah) via openssl-users wrote: > I get the following error when I try to access the ed25519 key stored in > SoftHSM via the openssl engine interface using engine_pkcs11. > > ? > > []:~$ openssl pkey -in > "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%22%22;object=ed25519%20leaf%20key;type=private" > -inform ENGINE -engine pkcs11 -text > > engine "pkcs11" set. > > Enter PKCS#11 token PIN for token 2.5.0-rc1: > > Key not found. > > PKCS11_get_private_key returned NULL > > cannot load key from engine > > 140736065815424:error:80067065:pkcs11 engine:ctx_load_privkey:object not > found:eng_back.c:862: > > 140736065815424:error:26096080:engine > routines:ENGINE_load_private_key:failed loading private > key:crypto/engine/eng_pkey.c:78: > > unable to load key > > ? > > ? > > The openssl version used above is 1.1.1. which supports the ed25519 > keys. The softhsm is v2.5.0-rc1 which also support the ed25519 keys. > > ? > > ? > > --? > > Paras > > > From parashah at cisco.com Mon Sep 17 22:58:01 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Mon, 17 Sep 2018 22:58:01 +0000 Subject: [openssl-users] ED25519 key with openssl engine In-Reply-To: <166191ce-95d1-4a3c-55b4-f4c96b63ae6b@openssl.org> References: <831F2293-B318-407B-B399-8D127FBBCE6F@cisco.com> <166191ce-95d1-4a3c-55b4-f4c96b63ae6b@openssl.org> Message-ID: <9189214A-1DB3-40B0-94D4-12C6B637ACE9@cisco.com> I had the same doubt. I have x-posed this question on the opensc mailing list as well. ?On 9/17/18, 3:37 PM, "openssl-users on behalf of Matt Caswell" wrote: Perhaps the pkcs11 engine does not support ed25519 keys? Matt On 17/09/18 22:05, Paras Shah (parashah) via openssl-users wrote: > I get the following error when I try to access the ed25519 key stored in > SoftHSM via the openssl engine interface using engine_pkcs11. > > > > []:~$ openssl pkey -in > "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%22%22;object=ed25519%20leaf%20key;type=private" > -inform ENGINE -engine pkcs11 -text > > engine "pkcs11" set. > > Enter PKCS#11 token PIN for token 2.5.0-rc1: > > Key not found. > > PKCS11_get_private_key returned NULL > > cannot load key from engine > > 140736065815424:error:80067065:pkcs11 engine:ctx_load_privkey:object not > found:eng_back.c:862: > > 140736065815424:error:26096080:engine > routines:ENGINE_load_private_key:failed loading private > key:crypto/engine/eng_pkey.c:78: > > unable to load key > > > > > > The openssl version used above is 1.1.1. which supports the ed25519 > keys. The softhsm is v2.5.0-rc1 which also support the ed25519 keys. > > > > > > -- > > Paras > > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From aerowolf at gmail.com Tue Sep 18 04:51:58 2018 From: aerowolf at gmail.com (Kyle Hamilton) Date: Mon, 17 Sep 2018 21:51:58 -0700 Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: <2a7535a2-01bc-4733-a67a-755ddaf32348@default> References: <484c33c9-c843-4aa4-b5c9-79148d835248@default> <2a7535a2-01bc-4733-a67a-755ddaf32348@default> Message-ID: ...and once again FIPS screws those who don't want to adhere to its mandates (which everyone in the know has always stated simply reduces security by requiring the use of less-secure ciphers and implementations, without allowing patches or modifications to deal with newly-discovered classes of attacks without requiring a complete new validation procedure). Also, I fear that I am likely to be viewed as "overly paranoid" here, by reminding everyone that Oracle exists because CIA wanted a way to avoid paying IBM more money. They have maintained their national-security roots ("Trusted Oracle", anyone?), and both US and Australia are members of the Five Eyes coalition; there's no reason that governments wouldn't lean on their assets which hire contributors to OpenSSL to reduce the putative security level that OpenSSL could provide, via platitudes of the form "the check will be cheaper". (It was in the Snowden docs, after all, that the US government has wealened encryption by sabotaging standardization efforts and open-source particopation. I have no doubt that governments within Five Eyes want to decrease the number of keys they have to crack in traffic that they don't already know the profile of.) I really think that the checks should be conditional on FIPS mode or setting an option flag (for those national standards that don't have a validation effort associated with them). -Kyle H On Sun, Sep 16, 2018, 14:23 Paul Dale wrote: > There is nothing S390 specific in this, it is a requirement to use GCM > based ciphers for TLS when running in a FIPS validated environment. The > check will be cheaper than trying to avoid it by conditioning on FIPS mode > -- hence it?s unconditional. > > > > > > Pauli > > -- > > Oracle > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] > *Sent:* Friday, 14 September 2018 8:41 PM > *To:* openssl-users at openssl.org > *Subject:* Re: [openssl-users] Limit the number of AES-GCM keys allowed > in TLS > > > > Hello, > > > > Sorry, I've just found similar checks in all _CGM functions. > > > > On Fri, Sep 14, 2018 at 1:30 PM Dmitry Belyavsky > wrote: > > Dear Paul, > > > > Could you please clarify? > > The code seems to be related to s390 platform. Do I miss something? > > > > On Thu, Sep 13, 2018 at 1:55 AM Paul Dale wrote: > > I wasn?t aware of other national standards requiring a similar check. > > > > I made the change in the AES-GCM code because FIPS demands the check be > inside the FIPS boundary. I?d have preferred to make it in the TLS layer, > but that mustn?t be inside the FIPS boundary. My understanding is that TLS > catches this case earlier and thus the test can never pass. > > > > I don?t think dropping the check down into the algorithm implementations > makes sense. A more generic mechanism at the EVP would. > > > > > > > > Pauli > > -- > > Oracle > > Dr Paul Dale | Cryptographer | Network Security & Encryption > > Phone +61 7 3031 7217 > > Oracle Australia > > > > *From:* Dmitry Belyavsky [mailto:beldmit at gmail.com] > *Sent:* Wednesday, 12 September 2018 7:02 PM > *To:* openssl-users at openssl.org > *Subject:* [openssl-users] Limit the number of AES-GCM keys allowed in TLS > > > > Hello, > > > > The issue https://github.com/openssl/openssl/pull/7129 has introduced a > possibility to limit the amount of TLS records processed without key > changing as required by FIPS. > > > > We in Russia have limitations with the same semantics applicable to > Russian GOST TLS ciphersuites ( > https://datatracker.ietf.org/doc/draft-smyshlyaev-tls12-gost-suites/) so > I think that this mechanism is very useful. > > > > The current implementation is done at EVP level, and it seems suboptimal > because of the following reasons: > > - If the AES implementation is provided via engine, not by OpenSSL itself, > the limitation can be avoided > > - the limitation has been made too generic > > - the implementation seems to be AEAD-specific. > > > > So does not it make sense to provide this limitation at least at the > ciphersuite level? It can provide more straightforward way to manage such > limitations. > > > Thank you! > > > > -- > > SY, Dmitry Belyavsky > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > -- > > SY, Dmitry Belyavsky > > > > > -- > > SY, Dmitry Belyavsky > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nic.tuv at gmail.com Tue Sep 18 05:04:59 2018 From: nic.tuv at gmail.com (Nicola) Date: Tue, 18 Sep 2018 08:04:59 +0300 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> Message-ID: Would it be possible for you to open this as an issue on Github and include there your first email and the full logs? Thanks, Nicola Tuveri On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users < openssl-users at openssl.org> wrote: > That is not it. It results in the same error for the EC key. > > > > It is not the URL or the ID. Because for a RSA key in the softhsm with id > = 3333, it works fine with url containing id=%33%33 > > > > *$ openssl pkey -in > "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" > -engine pkcs11 -inform ENGINE* > > *engine "pkcs11" set.* > > *Enter PKCS#11 token PIN for token 2.5.0-rc1:* > > *-----BEGIN PRIVATE KEY-----* > > *MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP* > > *WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi* > > *oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp* > > *t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq* > > *4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+* > > *9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN* > > *dGAUprcbAgMBAAE=* > > *-----END PRIVATE KEY-----* > > > > Coming back to EC key, looking at the error logs emitted, it does seem to > recognize it to be EC (the logs contain EC_routines) somehow but then > fails. > > > > ?On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" < > openssl-users-bounces at openssl.org on behalf of levitte at openssl.org> wrote: > > > > In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, > 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" > said: > > > > > 4. Import the key into softhsm > > > > > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label > "ec key" --id 1111 --token > > > "token 2.5.0-rc1" > > > > Ok, so here, the ID is "1111" > > > > > 5. Get the pkcs11 url for the private key > > > > > > []:~$ p11tool --login > --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > > > > > Object 0: > > > > > > URL: > > > > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private > > > > But here, the ID is "%11%11", and since those get percent decoded, > > that's actually two vertical tabs, or with C vector syntax, > > { 0x0b, 0x0b } > > > > I'm not sure what engine-pkcs11 asks of you otherwise, but one guess > > could be to change 'id=%11%11' to 'id=1111' in that URL and try again. > > > > Cheers, > > Richard > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Tue Sep 18 07:16:11 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Tue, 18 Sep 2018 09:16:11 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <20180915084601.GA6822@roeckx.be> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180915084601.GA6822@roeckx.be> Message-ID: <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> On 15/09/2018 10:46, Kurt Roeckx wrote: > On Thu, Sep 13, 2018 at 08:13:41PM +0200, Jakob Bohm wrote: >> On 13/09/2018 09:57, Klaus Keppler wrote: >>> Hi, >>> >>> thank you for all your responses. >>> >>> I've just tested with Firefox Nightly 64.0a1, and both s_server and our >>> own app (using OpenSSL 1.1.1-release) are working fine. >>> >>> The Firefox website is quite confusing: >>> >>>> Firefox 61 is already shipping draft-28, which is essentially the same as the final published version (just with a different version number). >>> (https://blog.mozilla.org/security/2018/08/13/tls-1-3-published-in-firefox-today/) >>> >>> This is quite confusing, as it sounds better than it actually is. >>> (so I've just learned that draft-28 is obviously incompatible with RFC8446) >>> >>> So thank you for your input, will now continue with OpenSSL 1.1.1. >>> The rest will be only a matter of time. :D >>> >>> Best regards >>> >>> -Klaus >> Would it be reasonable for 1.1.1a to add a transitional "bugs" bit (to be >> removed again in a few years) to accept the draft version number of final >> TLS 1.3, if the protocols are otherwise identical? > Draft versions really should die as soon as possible. If we ever put > it in a released version, it will still be in use in 10 years, > which really isn't something we want. > > On the other hand, in a few weeks browsers will stop using those > draft versions, so I really don't see the point. My point was about the likelihood of last-draft browsers lingering on in the real world for some time (like 1 to 3 years) after the TLS1.3-final browser versions ship.? The inspiration was the report that facebook had done this on their own servers, presumably based on their massive metrics of real world browsers. 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 aleksandr.derevianko at btsignal.ru Tue Sep 18 07:11:11 2018 From: aleksandr.derevianko at btsignal.ru (aleksandr.derevianko at btsignal.ru) Date: Tue, 18 Sep 2018 10:11:11 +0300 Subject: [openssl-users] DTLS-over-UDP client example In-Reply-To: References: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> Message-ID: <22239891537254671@myt4-c0b480c282c8.qloud-c.yandex.net> Hello ! 17.09.2018, 16:26, "Richard Weinberger" : > On Thu, Sep 13, 2018 at 3:51 PM wrote: >> ?I tryed to dig inside openssl s_client source code, but it's really too complex for me, it seems like s_client doesn't use >> ?SSL_connect, instead, using more low-level functions. >> >> ?So, does anybody have any simple client-side implementation of DTLS over UDP connection? > > https://web.archive.org/web/20150806185102/http://sctp.fh-muenster.de:80/dtls/dtls_udp_echo.c > ... is a good example. Unfortunelly, it's exactly this example which I use. You have pointed on slightly different version, but all difference is: SSL_CTX_set_cookie_verify_cb(ctx, &verify_cookie); instead of SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie); ctx = SSL_CTX_new(DTLS_client_method()); instead of ctx = SSL_CTX_new(DTLSv1_client_method()); I have tryed it, works exactly the same. In both versions, on client side cipher_list is: SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5"); With such list it works, but without encoding (data send in cleartext, connection established as Cipher: NULL-SHA) and if I remove eNULL on client side, it doesn't connect - server wait repeat of client cookue forever. At the same time, "openssl s_client -dtls1 ..." connects fine, with Cipher: AES256-SHA > > In case you are on 1.1.x, please also see: > https://mta.openssl.org/pipermail/openssl-users/2018-August/008498.html > > OpenSSL badly regressed in 1.1.x wrt. DTLS. > Actually, I use openssl-1.0.2o_2,1 Also, this "regression" is for multy-threaded server, not for single-threaded client. --? ????????? ?????????/Aleksander Derevianko ???. ?????? ????? ?????????-??????????? ??????? ????????? ????????????? (??????)/Bombardier Transportation (Signal) Ltd. T: ? +74959255370 ???. 265 M: +79859229755 From richard.weinberger at gmail.com Tue Sep 18 10:35:38 2018 From: richard.weinberger at gmail.com (Richard Weinberger) Date: Tue, 18 Sep 2018 12:35:38 +0200 Subject: [openssl-users] DTLS-over-UDP client example In-Reply-To: <22239891537254671@myt4-c0b480c282c8.qloud-c.yandex.net> References: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> <22239891537254671@myt4-c0b480c282c8.qloud-c.yandex.net> Message-ID: On Tue, Sep 18, 2018 at 9:18 AM wrote:> Unfortunelly, it's exactly this example which I use. You have pointed on slightly different version, > but all difference is: > > SSL_CTX_set_cookie_verify_cb(ctx, &verify_cookie); > instead of > SSL_CTX_set_cookie_verify_cb(ctx, verify_cookie); > > ctx = SSL_CTX_new(DTLS_client_method()); > instead of > ctx = SSL_CTX_new(DTLSv1_client_method()); > > > I have tryed it, works exactly the same. > > In both versions, on client side cipher_list is: > SSL_CTX_set_cipher_list(ctx, "eNULL:!MD5"); > > With such list it works, but without encoding (data send in cleartext, connection established as Cipher: NULL-SHA) > > and if I remove eNULL on client side, it doesn't connect - server wait repeat of client cookue forever. > > At the same time, "openssl s_client -dtls1 ..." connects fine, with Cipher: AES256-SHA Then debug why the server is ignoring the client request. OpenSSL has good debug output, in worst case add new prints... -- Thanks, //richard From aleksandr.derevianko at btsignal.ru Tue Sep 18 10:43:15 2018 From: aleksandr.derevianko at btsignal.ru (aleksandr.derevianko at btsignal.ru) Date: Tue, 18 Sep 2018 13:43:15 +0300 Subject: [openssl-users] DTLS-over-UDP client example In-Reply-To: References: <2186921536844924@myt2-dc4bba9bb23c.qloud-c.yandex.net> <1906661536846197@sas2-2074c606c35d.qloud-c.yandex.net> <22239891537254671@myt4-c0b480c282c8.qloud-c.yandex.net> Message-ID: <1397431537267395@myt4-415a3339794b.qloud-c.yandex.net> Hello ! >> >> ?With such list it works, but without encoding (data send in cleartext, connection established as Cipher: NULL-SHA) >> >> ?and if I remove eNULL on client side, it doesn't connect - server wait repeat of client cookue forever. >> >> ?At the same time, "openssl s_client -dtls1 ..." connects fine, with Cipher: AES256-SHA > > Then debug why the server is ignoring the client request. > OpenSSL has good debug output, in worst case add new prints... > Actually, I have traced it to ClientHello cookie exchange: test client connects to server, server calls generate_cookie() and never calls verify_cookie(). If I connect to test server using openssl s_client - server calls both generate_cookie() and verify_cookie(), and connection establishes. If I return eNULL back in client ciphers list, server do not call generate_cookie(), and connection went OK. If I comment out SSL_CTX_set_cookie_generate_cb() on server side, it still doesn't connect using test client but still connectes using openssl s_client. --? ????????? ?????????/Aleksander Derevianko ???. ?????? ????? ?????????-??????????? ??????? ????????? ????????????? (??????)/Bombardier Transportation (Signal) Ltd. T: ? +74959255370 ???. 265 M: +79859229755 From admin at mdtech.us Tue Sep 18 16:12:49 2018 From: admin at mdtech.us (admin at mdtech.us) Date: Tue, 18 Sep 2018 12:12:49 -0400 Subject: [openssl-users] OpenSSL 1.1 X509_STORE sharing Message-ID: <6ab50576f04ed6cb8297d65e9008db7c@mdtech.us> Hello, I have some legacy code that I am updating for 1.1 and there they set SSL_CTX::cert_store to NULL before `SSL_CTX_free`. Is this neccessary for the X509_STORE to be shared between contexts? Note that this still has to be buildable on 1.0 with the same result. In the docs it says "X509_STORE_free() frees up a single X509_STORE object." Does it just decrease the reference count or does it really delete the whole thing and break other contexts? Thanks, Maxwell. From openssl-users at dukhovni.org Tue Sep 18 16:28:16 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 18 Sep 2018 12:28:16 -0400 Subject: [openssl-users] OpenSSL 1.1 X509_STORE sharing In-Reply-To: <6ab50576f04ed6cb8297d65e9008db7c@mdtech.us> References: <6ab50576f04ed6cb8297d65e9008db7c@mdtech.us> Message-ID: <0A1952B9-789B-4EC6-A843-C2CC99F0C448@dukhovni.org> > On Sep 18, 2018, at 12:12 PM, admin at mdtech.us wrote: > > I have some legacy code that I am updating for 1.1 and there they set SSL_CTX::cert_store to NULL before `SSL_CTX_free`. Is this neccessary for the X509_STORE to be shared between contexts? > Note that this still has to be buildable on 1.0 with the same result. > In the docs it says "X509_STORE_free() frees up a single X509_STORE object." Does it just decrease the reference count or does it really delete the whole thing and break other contexts? X509_STORE_free() decrements a reference count, and frees the object only when the count reaches zero. -- Viktor. From rsalz at akamai.com Tue Sep 18 17:00:14 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 18 Sep 2018 17:00:14 +0000 Subject: [openssl-users] Limit the number of AES-GCM keys allowed in TLS In-Reply-To: References: <484c33c9-c843-4aa4-b5c9-79148d835248@default> <2a7535a2-01bc-4733-a67a-755ddaf32348@default> Message-ID: <9942938D-736B-4469-80AB-72FEF6CC1CD6@akamai.com> This is factually incorrect; the TLS values are lower than the FIPS values, for example. And also, what ?everyone in the know? has always stated isn?t really true any more. It would be nice to keep politics out of this list. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 18 17:04:55 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 18 Sep 2018 13:04:55 -0400 Subject: [openssl-users] OpenSSL 1.1 X509_STORE sharing In-Reply-To: <5a995d76-2a7d-8fdb-d1b5-26c48db390ff@mdtech.us> References: <6ab50576f04ed6cb8297d65e9008db7c@mdtech.us> <0A1952B9-789B-4EC6-A843-C2CC99F0C448@dukhovni.org> <5a995d76-2a7d-8fdb-d1b5-26c48db390ff@mdtech.us> Message-ID: > On Sep 18, 2018, at 12:30 PM, Maxwell Dreytser wrote: > >> X509_STORE_free() decrements a reference count, and frees the object only >> when the count reaches zero. >> > Was this behavior the same in older versions? Yes. > If so, then there is no reason to clear cert_store even in older version, right? That depends on whether setting the cert_store element was done properly (in a way that incremented the reference count) or not. See the documentation of: SSL_CTX_set1_cert_store(3) SSL_CTX_set_cert_store(3) the latter does not facilitate sharing the store across multiple SSL_CTX instances. -- Viktor. From parashah at cisco.com Tue Sep 18 17:06:10 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Tue, 18 Sep 2018 17:06:10 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> Message-ID: <582ED379-8BAE-4124-A438-AED7F511862C@cisco.com> Sure. I will open the issue. From: Nicola Date: Monday, September 17, 2018 at 10:05 PM To: "Paras Shah (parashah)" , "openssl-users at openssl.org" Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Would it be possible for you to open this as an issue on Github and include there your first email and the full logs? Thanks, Nicola Tuveri On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users > wrote: That is not it. It results in the same error for the EC key. It is not the URL or the ID. Because for a RSA key in the softhsm with id = 3333, it works fine with url containing id=%33%33 $ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" -engine pkcs11 -inform ENGINE engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: -----BEGIN PRIVATE KEY----- MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+ 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN dGAUprcbAgMBAAE= -----END PRIVATE KEY----- Coming back to EC key, looking at the error logs emitted, it does seem to recognize it to be EC (the logs contain EC_routines) somehow but then fails. On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" on behalf of levitte at openssl.org> wrote: In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" > said: > 4. Import the key into softhsm > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > "token 2.5.0-rc1" Ok, so here, the ID is "1111" > 5. Get the pkcs11 url for the private key > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > Object 0: > > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private But here, the ID is "%11%11", and since those get percent decoded, that's actually two vertical tabs, or with C vector syntax, { 0x0b, 0x0b } I'm not sure what engine-pkcs11 asks of you otherwise, but one guess could be to change 'id=%11%11' to 'id=1111' in that URL and try again. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rsalz at akamai.com Tue Sep 18 17:11:42 2018 From: rsalz at akamai.com (Salz, Rich) Date: Tue, 18 Sep 2018 17:11:42 +0000 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180915084601.GA6822@roeckx.be> <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> Message-ID: <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> > My point was about the likelihood of last-draft browsers lingering on in the real world for some time (like 1 to 3 years) after the TLS1.3-final browser versions ship. I do not think this is a concern. Chrome and FF auto-update and get almost full coverage within a month or two, for example. Edge hasn't shipped TLS 1.3 yet. Safari encourages auto-update. That's most of the browser market. From openssl-users at dukhovni.org Tue Sep 18 17:21:25 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 18 Sep 2018 13:21:25 -0400 Subject: [openssl-users] OpenSSL 1.1 X509_STORE sharing In-Reply-To: References: <6ab50576f04ed6cb8297d65e9008db7c@mdtech.us> <0A1952B9-789B-4EC6-A843-C2CC99F0C448@dukhovni.org> <5a995d76-2a7d-8fdb-d1b5-26c48db390ff@mdtech.us> Message-ID: <574878DE-E424-4FA3-AE02-85813C521091@dukhovni.org> > On Sep 18, 2018, at 1:04 PM, Viktor Dukhovni wrote: > > That depends on whether setting the cert_store element was done properly (in a way > that incremented the reference count) or not. See the documentation of: > > SSL_CTX_set1_cert_store(3) > SSL_CTX_set_cert_store(3) > > the latter does not facilitate sharing the store across multiple SSL_CTX instances. Note that SSL_CTX_set1_cert_store(3) is new with OpenSSL 1.1.x. In OpenSSL 1.0.2, the caller would have to increment the reference count prior to calling SSL_CTX_cert_store(). The caller typically owns a primary copy of the store to use when configuring various SSL_CTX objects. In that case the primary copy can be freed once the application no longer intends to use the store to configuring any more SSL_CTX objects. In OpenSSL 1.1.x there is an X509_STORE_up_ref() function. In OpenSSL 1.0.2, you can do that directly via: CRYPTO_add(&store->references, 1, CRYPTO_LOCK_X509_STORE); Bottom line, you need to figure out the life-cycle of the object, and ensure that reference counts are properly maintained. -- Viktor. From kurt at roeckx.be Tue Sep 18 19:16:20 2018 From: kurt at roeckx.be (Kurt Roeckx) Date: Tue, 18 Sep 2018 21:16:20 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180915084601.GA6822@roeckx.be> <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> Message-ID: <20180918191620.GA8784@roeckx.be> On Tue, Sep 18, 2018 at 05:11:42PM +0000, Salz, Rich via openssl-users wrote: > > My point was about the likelihood of last-draft browsers lingering > on in the real world for some time (like 1 to 3 years) after the > TLS1.3-final browser versions ship. > > I do not think this is a concern. Chrome and FF auto-update and get almost full coverage within a month or two, for example. Edge hasn't shipped TLS 1.3 yet. Safari encourages auto-update. That's most of the browser market. I think chrome and firefox cover all browsers that ever enabled a draft version. Kurt From moyaldror at gmail.com Tue Sep 18 21:27:20 2018 From: moyaldror at gmail.com (=?UTF-8?B?15PXqNeV16gg157XldeZ15w=?=) Date: Wed, 19 Sep 2018 00:27:20 +0300 Subject: [openssl-users] Unexpected behavior in certificate hostname check Message-ID: Hi, I'm experiencing some unexpected (in my opinion - and I might be in the wrong here) behavior in hostname checking the OpenSSL CLI utils. I'm trying to verify the hostname of a certificate which has CN=mysite.com and altSubj=localhost (was generated by pyca/cryptography example - https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate) and the check always fails on hostname mismatch. I tried the following: 1. openssl x509 -in certificate.pem -checkhost mysite.com 2. openssl verify -verify_hostname mysite.com certificate.pem I could see in the code that they both use X509_check_host and they both call it with flags=0. The thing is, that when the flags=0, X509_check_host will call do_X509_check that will verify only the altSubjNames and not the CN in the Subj. I tried to find a way to set the flags to X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT using a CLI flag or config but there is no such option. Was it meant to work like this? am I missing something? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Tue Sep 18 21:49:41 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 18 Sep 2018 17:49:41 -0400 Subject: [openssl-users] Unexpected behavior in certificate hostname check In-Reply-To: References: Message-ID: <36A8A0B1-4D99-401F-86E5-51F63BB1766E@dukhovni.org> > On Sep 18, 2018, at 5:27 PM, ????? ????? wrote: > > I'm experiencing some unexpected (in my opinion - and I might be in the wrong here) behavior in hostname checking the OpenSSL CLI utils. The default behaviour follows: https://tools.ietf.org/html/rfc6125#section-6.4.4 which says: As noted, a client MUST NOT seek a match for a reference identifier of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, URI-ID, or any application-specific identifier types supported by the client. > I'm trying to verify the hostname of a certificate which has CN=mysite.com and altSubj=localhost (was generated by pyca/cryptography example - https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate) and the check always fails on hostname mismatch. Your certificate is poorly crafted it must list all the desired domains in the subjectAltName extension, and then may repeat one of them in the Subject CN as a fallback for legacy software. > The thing is, that when the flags=0, X509_check_host will call do_X509_check > that will verify only the altSubjNames and not the CN in the Subj. As expected. > I tried to find a way to set the flags to X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT > using a CLI flag or config but there is no such option. > > Was it meant to work like this? am I missing something? Obtain a properly crafted certificate and all will be well. The host flags, are not IIRC exposed via the CLI. Good luck. -- Viktor. From moyaldror at gmail.com Tue Sep 18 22:19:22 2018 From: moyaldror at gmail.com (=?UTF-8?B?15PXqNeV16gg157XldeZ15w=?=) Date: Wed, 19 Sep 2018 01:19:22 +0300 Subject: [openssl-users] Unexpected behavior in certificate hostname check In-Reply-To: <36A8A0B1-4D99-401F-86E5-51F63BB1766E@dukhovni.org> References: <36A8A0B1-4D99-401F-86E5-51F63BB1766E@dukhovni.org> Message-ID: Thanks! On Wed, 19 Sep 2018 at 00:50, Viktor Dukhovni wrote: > > On Sep 18, 2018, at 5:27 PM, ????? ????? wrote: > > > > I'm experiencing some unexpected (in my opinion - and I might be in the > wrong here) behavior in hostname checking the OpenSSL CLI utils. > > The default behaviour follows: > > https://tools.ietf.org/html/rfc6125#section-6.4.4 > > which says: > > As noted, a client MUST NOT seek a match for a reference identifier > of CN-ID if the presented identifiers include a DNS-ID, SRV-ID, > URI-ID, or any application-specific identifier types supported by the > client. > > > I'm trying to verify the hostname of a certificate which has CN= > mysite.com and altSubj=localhost (was generated by pyca/cryptography > example - > https://cryptography.io/en/latest/x509/tutorial/#creating-a-self-signed-certificate) > and the check always fails on hostname mismatch. > > Your certificate is poorly crafted it must list all the desired domains in > the > subjectAltName extension, and then may repeat one of them in the Subject > CN as > a fallback for legacy software. > > > The thing is, that when the flags=0, X509_check_host will call > do_X509_check > > that will verify only the altSubjNames and not the CN in the Subj. > > As expected. > > > I tried to find a way to set the flags to > X509_CHECK_FLAG_ALWAYS_CHECK_SUBJECT > > using a CLI flag or config but there is no such option. > > > > Was it meant to work like this? am I missing something? > > Obtain a properly crafted certificate and all will be well. > The host flags, are not IIRC exposed via the CLI. Good luck. > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jb-openssl at wisemo.com Wed Sep 19 19:33:29 2018 From: jb-openssl at wisemo.com (Jakob Bohm) Date: Wed, 19 Sep 2018 21:33:29 +0200 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180915084601.GA6822@roeckx.be> <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> Message-ID: <184c41d8-c6fe-725e-f1ed-717f6168030e@wisemo.com> On 18/09/2018 19:11, Salz, Rich via openssl-users wrote: >> My point was about the likelihood of last-draft browsers lingering > on in the real world for some time (like 1 to 3 years) after the > TLS1.3-final browser versions ship. > > I do not think this is a concern. Chrome and FF auto-update and get almost full coverage within a month or two, for example. Edge hasn't shipped TLS 1.3 yet. Safari encourages auto-update. That's most of the browser market. While I have already accepted the infeasibility of adding this to OpenSSL, I will have to emphasize that your argument has a serious flaw: The users who delay or block automatic updates tend to greatly overlap with the users who actively block remote telemetry of their update habits, thus skewing such statistics of "get almost full coverage within a month or two". 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 Sep 19 19:53:20 2018 From: rsalz at akamai.com (Salz, Rich) Date: Wed, 19 Sep 2018 19:53:20 +0000 Subject: [openssl-users] s_server -www -tls1_3: Firefox/Chrome not working In-Reply-To: <184c41d8-c6fe-725e-f1ed-717f6168030e@wisemo.com> References: <12f50ddd-a008-371d-d783-d130992c0d06@blastwave.org> <0cd3f781-9608-6aff-67c6-73fdb4778775@keppler-it.de> <5d0b657e-8a97-ab69-ea6a-756b5546035f@wisemo.com> <20180915084601.GA6822@roeckx.be> <158a5e02-de79-c10f-1f95-5de106bacf0d@wisemo.com> <3C2E739E-640A-4CEE-856A-CD9E3E1BB086@akamai.com> <184c41d8-c6fe-725e-f1ed-717f6168030e@wisemo.com> Message-ID: > The users who delay or block automatic updates tend to greatly overlap with the users who actively block remote telemetry of their update habits, thus skewing such statistics of "get almost full coverage within a month or two". But not downloads. :) Shrug. From tshort at akamai.com Wed Sep 19 20:37:35 2018 From: tshort at akamai.com (Short, Todd) Date: Wed, 19 Sep 2018 20:37:35 +0000 Subject: [openssl-users] QNX 6.5 OpenSSL Build In-Reply-To: <7E017E71-1E57-4AC4-B8BE-92AA997935D4@dukhovni.org> References: <1856433470.4937525.1537112640324.ref@mail.yahoo.com> <1856433470.4937525.1537112640324@mail.yahoo.com> <7E017E71-1E57-4AC4-B8BE-92AA997935D4@dukhovni.org> Message-ID: You can add the "no-dso" option to the command line to avoid this feature, but you lose access to loading engines. -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 16, 2018, at 1:04 PM, Viktor Dukhovni > wrote: On Sep 16, 2018, at 11:44 AM, Murugaiyan Perumal via openssl-users > wrote: dso_dlfcn.c:84:12: fatal error: dlfcn.h: No such file or directory # include http://www.qnx.com/developers/docs/6.5.0/topic/com.qnx.doc.neutrino_lib_ref/d/dlopen.html This header is expected to be present, perhaps your system is missing the requisite software development package, or GCC-specific headers. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From tshort at akamai.com Wed Sep 19 20:48:18 2018 From: tshort at akamai.com (Short, Todd) Date: Wed, 19 Sep 2018 20:48:18 +0000 Subject: [openssl-users] Re-enable 3DES on NGINX + OpenSSL 1.1.1 In-Reply-To: References: <5e005ca5-d135-c28e-f9bb-f4b0fe4704e6@openssl.org> Message-ID: <316461BA-6917-4037-ABF8-BF14F9EA2AA6@akamai.com> 3DES is considered to only be 112 bits in strength. The default security level is 1 (which allows most things), perhaps nginx resets the security level to 3 or greater (which means a minimum of 128-bit ciphers). -- -Todd Short // tshort at akamai.com // "One if by land, two if by sea, three if by the Internet." On Sep 17, 2018, at 4:20 PM, Neil Craig > wrote: Thanks very much Matt. I have indeed built with NGINX configure opt --with-openssl-opt=enable-weak-ssl-cipher and whilst I don?t see an error when running NGINX with a/some 3DES cipher(s) in the ciphers list, I don?t see any 3DES ciphers in the output of e.g. Testssl and I can?t make a connection to the server using openssl CLI with -cipher <3DES cipher>. I wonder if the problem might be either NGINX not respecting/processing the configure opt (above) or possibly removing 3DES ciphers for some reason with openssl 1.1.1. I?ll keep digging, thanks again for your help and for confirming that?s the right thing to do. Cheers Neil Craig Lead Technical Architect | Online Technology Group Broadcast Centre, London W12 7TQ | BC4 A3 Twitter: https://twitter.com/tdp_org On 17/09/2018, 17:41, "openssl-users on behalf of Matt Caswell" on behalf of matt at openssl.org> wrote: On 17/09/18 16:29, Neil Craig wrote: Hi all I'm trying to re-add 3DES support (a temporary move, due to business requirements) to an NGINX (1.15.3) + OpenSSL (1.1.1) build via the NGINX build flag --with-openssl-opt=enable-weak-ssl-ciphers which i learnt from https://www.openssl.org/blog/blog/2016/08/24/sweet32/. Whilst I do see some older ciphersuites being offered by NGINX after doing this, e.g. Camelia, Seed and so on, i don't see 3DES. I was expecting to be able to specifically list 3DES e.g. via DES-CBC3-SHA but that didn?t work. I have also tried adding @seclevel=0 to the ciphersuite string in NGINX but again, that didn?t work, I don?t see any 3DES ciphersuites available in NGINX. I'm wondering whether something changed between the above article and the final version of OpenSSL 1.1.1? (I.e. Whether 3DES support was completely removed in OpenSSL 1.1.1). Any pointers would be very much appreciated, I can?t find anything very useful on the web. 3DES is still available in 1.1.1 but is no longer in the DEFAULT ciphersuite list, so unless you explicitly configure them to be available you won't see them (even if you configure with enable-weak-ssl-ciphers). E.g. (assuming you compiled with enable-weak-ssl-ciphers): $ openssl ciphers -v | grep 3DES Will give you 0 ciphers, but $ openssl ciphers -v 3DES | grep 3DES Should list 14 different 3DES ciphersuites that are available. I don't know about nginx config though so maybe someone else can help there. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users ----------------------------- http://www.bbc.co.uk This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated. If you have received it in error, please delete it from your system. Do not use, copy or disclose the information in any way nor act in reliance on it and notify the sender immediately. Please note that the BBC monitors e-mails sent or received. Further communication will signify your consent to this. ----------------------------- -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From dclarke at blastwave.org Thu Sep 20 14:48:52 2018 From: dclarke at blastwave.org (Dennis Clarke) Date: Thu, 20 Sep 2018 10:48:52 -0400 Subject: [openssl-users] Manpages still say "pre-release" Message-ID: <241819d6-d121-9d58-88da-70b61ecc1efb@blastwave.org> Pretty sure this could be cleaned up : https://www.openssl.org/docs/manpages.html Then again the tar balls create all the manpages locally but the install process wants some perl pod2html thing laying about and some systems don't have that. Dennis From mcr at sandelman.ca Thu Sep 20 19:43:25 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 20 Sep 2018 15:43:25 -0400 Subject: [openssl-users] updating openssl on MacOS Message-ID: <28786.1537472605@localhost> (I'm a Linux desktop guy) Sitting with a colleague, he's trying to get some code working that requires ECDSA support, so openssl 1.1.0 or newer, and his Mac is infested with 0.98letter. There are a a whole bunch of pages with a variety of recommendations. None of them are on openssl.org... I wonder if openssl.org shouldn't include at least a page of advice that is know to work? My colleague eventually did something like: brew update brew uninstall --force openssl (unclear if this worked..) brew uninstall --ignore-dependancies openssl brew upgrade brew install openssl and the libraries wound up in /usr/local/opt/{include,lib}. From rsalz at akamai.com Thu Sep 20 19:53:07 2018 From: rsalz at akamai.com (Salz, Rich) Date: Thu, 20 Sep 2018 19:53:07 +0000 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <28786.1537472605@localhost> References: <28786.1537472605@localhost> Message-ID: <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> It's hard enough for the openssl team to document the basic config/build things, let alone all the operating systems and vendor-supplied stuff. Perhaps a wiki page, that the community could help maintain? From dominyktiller at gmail.com Thu Sep 20 20:03:48 2018 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Thu, 20 Sep 2018 21:03:48 +0100 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> References: <28786.1537472605@localhost> <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> Message-ID: <99fa5e60-7921-9b0e-4335-f05a27f42cb0@gmail.com> FWIW on macOS: If you use Homebrew and want/need OpenSSL 1.1.1 then `brew install openssl at 1.1`. If you want the 1.0.2x series `brew install openssl` currently is & will likely remain attached to 1.0.2x for the foreseeable. If you use MacPorts and want OpenSSL 1.0.2x then `sudo port install openssl`. As far as I'm aware MacPorts does not currently offer a port for either 1.1.0x or 1.1.1x. If you use Nix and want OpenSSL 1.1.1 then `nix-env -i openssl-1.1.1` (I'm unsure if this has made it into a stable release of Nix yet) and if you want OpenSSL 1.0.2x then `nix-env -i openssl-1.0.2p`. You can get nix to spit out a list of OpenSSL versions available via `nix-env -qa openssl`. Hope this helps some. I'm not sure what the situation is with fink or pkgsrc, or any newer package managers for the platform I'm unaware of. Dom === Sent from macOS. On 20/09/2018 20:53, Salz, Rich via openssl-users wrote: > It's hard enough for the openssl team to document the basic config/build things, let alone all the operating systems and vendor-supplied stuff. > > Perhaps a wiki page, that the community could help maintain? > > From uri at ll.mit.edu Thu Sep 20 20:36:34 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 20 Sep 2018 20:36:34 +0000 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <99fa5e60-7921-9b0e-4335-f05a27f42cb0@gmail.com> References: <28786.1537472605@localhost> <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> <99fa5e60-7921-9b0e-4335-f05a27f42cb0@gmail.com> Message-ID: Macports team is working on upgrading OpenSSL to 1.1.1. It takes time because they plan to move all the ports that depend on OpenSSL to that level. I assume that once that is done, 1.0.2 won't be supported/available on Macports anymore. Installation - as Dominyk said: "sudo port install openssl" (possibly with parameters, check for them via "port info openssl"), and Macports would do the right thing. ;-) I'm not aware of any efforts by Macports to support 1.1.0. Thanks! ? Regards, Uri ?On 9/20/18, 4:04 PM, "openssl-users on behalf of Dominyk Tiller" wrote: FWIW on macOS: If you use Homebrew and want/need OpenSSL 1.1.1 then `brew install openssl at 1.1`. If you want the 1.0.2x series `brew install openssl` currently is & will likely remain attached to 1.0.2x for the foreseeable. If you use MacPorts and want OpenSSL 1.0.2x then `sudo port install openssl`. As far as I'm aware MacPorts does not currently offer a port for either 1.1.0x or 1.1.1x. If you use Nix and want OpenSSL 1.1.1 then `nix-env -i openssl-1.1.1` (I'm unsure if this has made it into a stable release of Nix yet) and if you want OpenSSL 1.0.2x then `nix-env -i openssl-1.0.2p`. You can get nix to spit out a list of OpenSSL versions available via `nix-env -qa openssl`. Hope this helps some. I'm not sure what the situation is with fink or pkgsrc, or any newer package managers for the platform I'm unaware of. Dom === Sent from macOS. On 20/09/2018 20:53, Salz, Rich via openssl-users wrote: > It's hard enough for the openssl team to document the basic config/build things, let alone all the operating systems and vendor-supplied stuff. > > Perhaps a wiki page, that the community could help maintain? > > -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- 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 Sep 20 20:38:44 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Thu, 20 Sep 2018 16:38:44 -0400 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <28786.1537472605@localhost> References: <28786.1537472605@localhost> Message-ID: <19BB8510-B657-42A2-9626-DE77E760B7EC@dukhovni.org> > On Sep 20, 2018, at 3:43 PM, Michael Richardson wrote: > > Sitting with a colleague, he's trying to get some code working that requires > ECDSA support, ECDSA support is also present in OpenSSL 1.0.2. With recent versions of MacOS you actually get LibreSSL with the base system: $ /usr/bin/openssl version LibreSSL 2.2.7 Despite (IMHO) its increasing obsolescence and irrelevance, the LibreSSL fork of OpenSSL 1.0.2 also supports ECDSA. $ /usr/bin/openssl ciphers -v aECDSA ECDHE-ECDSA-CHACHA20-POLY1305 TLSv1.2 Kx=ECDH Au=ECDSA Enc=ChaCha20-Poly1305 Mac=AEAD ECDHE-ECDSA-AES256-GCM-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(256) Mac=AEAD ECDHE-ECDSA-AES256-SHA384 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA384 ECDHE-ECDSA-AES256-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(256) Mac=SHA1 ECDHE-ECDSA-AES128-GCM-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AESGCM(128) Mac=AEAD ECDHE-ECDSA-AES128-SHA256 TLSv1.2 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA256 ECDHE-ECDSA-AES128-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=AES(128) Mac=SHA1 ECDHE-ECDSA-RC4-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=RC4(128) Mac=SHA1 ECDHE-ECDSA-DES-CBC3-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=3DES(168) Mac=SHA1 ECDHE-ECDSA-NULL-SHA SSLv3 Kx=ECDH Au=ECDSA Enc=None Mac=SHA1 > so openssl 1.1.0 or newer, and his Mac is infested with > 0.98letter. That sounds like a Mac that's running a dated copy of the OS. -- Viktor. From uri at ll.mit.edu Thu Sep 20 20:43:09 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Thu, 20 Sep 2018 20:43:09 +0000 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <19BB8510-B657-42A2-9626-DE77E760B7EC@dukhovni.org> References: <28786.1537472605@localhost> <19BB8510-B657-42A2-9626-DE77E760B7EC@dukhovni.org> Message-ID: On 9/20/18, 4:39 PM, "openssl-users on behalf of Viktor Dukhovni" wrote: Despite (IMHO) its increasing obsolescence and irrelevance, the LibreSSL fork of OpenSSL 1.0.2 also supports ECDSA. Yep. > so openssl 1.1.0 or newer, and his Mac is infested with > 0.98letter. That sounds like a Mac that's running a dated copy of the OS. The latest released (High Sierra) MacOS has LibreSSL 2.2.7 - pretty dated (but no worries - it doesn't include .h files or linkable libraries for LibreSSL, as far as I could tell ;). The previous versions included 0.98letter. Anybody who needs a "real" OpenSSL on MacOS either builds it himself (like what I'm doing with the master ;), or installs stable via Macports (ends up in /opt/local) or Brew (AFAIK, ends up in /usr/local/ssl). -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5249 bytes Desc: not available URL: From dominyktiller at gmail.com Thu Sep 20 20:57:09 2018 From: dominyktiller at gmail.com (Dominyk Tiller) Date: Thu, 20 Sep 2018 21:57:09 +0100 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: References: <28786.1537472605@localhost> <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> <99fa5e60-7921-9b0e-4335-f05a27f42cb0@gmail.com> Message-ID: Thanks Uri. On the Homebrew side the same sort of loose plan is being followed. I recently departed the project for unrelated reasons but before I left I was pushing a timetable of no later than Summer 2019 to have migrated everything over to OpenSSL 1.1.1, likely with some package-availability casualties, and the 1.0.2x series to be removed entirely by the end of 2019 when it hits EOL. I was essentially the one pushing the timeline/roadmap on that so I can't speak for what will happen now, but I would expect `brew install openssl` to eventually equal installing OpenSSL 1.1.1x (Assuming there isn't a broadly-compatible 1.1.2x or such by then, etc). 1.1.0x is no longer available through Homebrew as of the 1.1.1 release, and again whilst not an official comment any more, isn't likely to make a return. Dom === Sent from macOS. On 20/09/2018 21:36, Blumenthal, Uri - 0553 - MITLL wrote: > Macports team is working on upgrading OpenSSL to 1.1.1. It takes time because they plan to move all the ports that depend on OpenSSL to that level. I assume that once that is done, 1.0.2 won't be supported/available on Macports anymore. > > Installation - as Dominyk said: "sudo port install openssl" (possibly with parameters, check for them via "port info openssl"), and Macports would do the right thing. ;-) > > I'm not aware of any efforts by Macports to support 1.1.0. > > Thanks! > ? > Regards, > Uri > > ?On 9/20/18, 4:04 PM, "openssl-users on behalf of Dominyk Tiller" wrote: > > FWIW on macOS: > > If you use Homebrew and want/need OpenSSL 1.1.1 then `brew install > openssl at 1.1`. If you want the 1.0.2x series `brew install openssl` > currently is & will likely remain attached to 1.0.2x for the foreseeable. > > If you use MacPorts and want OpenSSL 1.0.2x then `sudo port install > openssl`. As far as I'm aware MacPorts does not currently offer a port > for either 1.1.0x or 1.1.1x. > > If you use Nix and want OpenSSL 1.1.1 then `nix-env -i openssl-1.1.1` > (I'm unsure if this has made it into a stable release of Nix yet) and if > you want OpenSSL 1.0.2x then `nix-env -i openssl-1.0.2p`. You can get > nix to spit out a list of OpenSSL versions available via `nix-env -qa > openssl`. > > Hope this helps some. I'm not sure what the situation is with fink or > pkgsrc, or any newer package managers for the platform I'm unaware of. > > Dom > === > Sent from macOS. > > On 20/09/2018 20:53, Salz, Rich via openssl-users wrote: > > It's hard enough for the openssl team to document the basic config/build things, let alone all the operating systems and vendor-supplied stuff. > > > > Perhaps a wiki page, that the community could help maintain? > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > From mcr at sandelman.ca Fri Sep 21 01:17:47 2018 From: mcr at sandelman.ca (Michael Richardson) Date: Thu, 20 Sep 2018 21:17:47 -0400 Subject: [openssl-users] updating openssl on MacOS In-Reply-To: <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> References: <28786.1537472605@localhost> <75D3A589-FA25-4AD0-83E5-D3BF298B1E40@akamai.com> Message-ID: <7663.1537492667@localhost> Salz, Rich via openssl-users wrote: > It's hard enough for the openssl team to document the basic > config/build things, let alone all the operating systems and > vendor-supplied stuff. > Perhaps a wiki page, that the community could help maintain? that's what I had in mind. From parashah at cisco.com Fri Sep 21 06:08:20 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Fri, 21 Sep 2018 06:08:20 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: <582ED379-8BAE-4124-A438-AED7F511862C@cisco.com> References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> <582ED379-8BAE-4124-A438-AED7F511862C@cisco.com> Message-ID: I opened the issue https://github.com/openssl/openssl/issues/7258 Also, opened issue https://github.com/OpenSC/libp11/issues/249 and https://github.com/opendnssec/SoftHSMv2/issues/417 Found the root cause to be the openssl version 1.1.1 that was used to compile the engine_pkcs11 and SoftHSM. When I recompiled with openssl-1.0.2p, it worked fine. See https://github.com/OpenSC/libp11/issues/249 for details. From: "Paras Shah (parashah)" Date: Tuesday, September 18, 2018 at 10:06 AM To: Nicola , "openssl-users at openssl.org" Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Sure. I will open the issue. From: Nicola Date: Monday, September 17, 2018 at 10:05 PM To: "Paras Shah (parashah)" , "openssl-users at openssl.org" Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Would it be possible for you to open this as an issue on Github and include there your first email and the full logs? Thanks, Nicola Tuveri On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users > wrote: That is not it. It results in the same error for the EC key. It is not the URL or the ID. Because for a RSA key in the softhsm with id = 3333, it works fine with url containing id=%33%33 $ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" -engine pkcs11 -inform ENGINE engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: -----BEGIN PRIVATE KEY----- MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+ 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN dGAUprcbAgMBAAE= -----END PRIVATE KEY----- Coming back to EC key, looking at the error logs emitted, it does seem to recognize it to be EC (the logs contain EC_routines) somehow but then fails. On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" on behalf of levitte at openssl.org> wrote: In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" > said: > 4. Import the key into softhsm > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > "token 2.5.0-rc1" Ok, so here, the ID is "1111" > 5. Get the pkcs11 url for the private key > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > Object 0: > > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private But here, the ID is "%11%11", and since those get percent decoded, that's actually two vertical tabs, or with C vector syntax, { 0x0b, 0x0b } I'm not sure what engine-pkcs11 asks of you otherwise, but one guess could be to change 'id=%11%11' to 'id=1111' in that URL and try again. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From uri at ll.mit.edu Fri Sep 21 12:07:03 2018 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Fri, 21 Sep 2018 12:07:03 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> <582ED379-8BAE-4124-A438-AED7F511862C@cisco.com> Message-ID: <6979011E-FFA2-49D6-AD5A-6706BBF42D50@ll.mit.edu> Note that the key to reproducing this issue is compiling SoftHSMv2 with 1.1.1. When compiled with 1.0.2p, everything else can be compiled against 1.1.1 and it works ok. Regards, Uri Sent from my iPhone > On Sep 21, 2018, at 02:09, Paras Shah (parashah) via openssl-users wrote: > > I opened the issue https://github.com/openssl/openssl/issues/7258 > Also, opened issue https://github.com/OpenSC/libp11/issues/249 > and https://github.com/opendnssec/SoftHSMv2/issues/417 > > Found the root cause to be the openssl version 1.1.1 that was used to compile the engine_pkcs11 and SoftHSM. > When I recompiled with openssl-1.0.2p, it worked fine. See https://github.com/OpenSC/libp11/issues/249 for details. > > From: "Paras Shah (parashah)" > Date: Tuesday, September 18, 2018 at 10:06 AM > To: Nicola , "openssl-users at openssl.org" > Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. > > Sure. I will open the issue. > > From: Nicola > Date: Monday, September 17, 2018 at 10:05 PM > To: "Paras Shah (parashah)" , "openssl-users at openssl.org" > Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. > > Would it be possible for you to open this as an issue on Github and include there your first email and the full logs? > > Thanks, > > Nicola Tuveri > > On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users wrote: > That is not it. It results in the same error for the EC key. > > > > It is not the URL or the ID. Because for a RSA key in the softhsm with id = 3333, it works fine with url containing id=%33%33 > > > > $ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" -engine pkcs11 -inform ENGINE > > engine "pkcs11" set. > > Enter PKCS#11 token PIN for token 2.5.0-rc1: > > -----BEGIN PRIVATE KEY----- > > MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP > > WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi > > oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp > > t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq > > 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+ > > 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN > > dGAUprcbAgMBAAE= > > -----END PRIVATE KEY----- > > > > Coming back to EC key, looking at the error logs emitted, it does seem to recognize it to be EC (the logs contain EC_routines) somehow but then fails. > > > > On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" wrote: > > > > In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" said: > > > > > 4. Import the key into softhsm > > > > > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > > > "token 2.5.0-rc1" > > > > Ok, so here, the ID is "1111" > > > > > 5. Get the pkcs11 url for the private key > > > > > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > > > > > Object 0: > > > > > > URL: > > > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private > > > > But here, the ID is "%11%11", and since those get percent decoded, > > that's actually two vertical tabs, or with C vector syntax, > > { 0x0b, 0x0b } > > > > I'm not sure what engine-pkcs11 asks of you otherwise, but one guess > > could be to change 'id=%11%11' to 'id=1111' in that URL and try again. > > > > Cheers, > > Richard > > > > -- > > Richard Levitte levitte at openssl.org > > OpenSSL Project http://www.openssl.org/~levitte/ > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5801 bytes Desc: not available URL: From ece8537 at upnet.gr Fri Sep 21 15:55:48 2018 From: ece8537 at upnet.gr (Konstantinos Schoinas) Date: Fri, 21 Sep 2018 18:55:48 +0300 Subject: [openssl-users] SSL-Connection Message-ID: Hello, I ?? encountering a problem in ending a SSL-Connection properly, and i wonder if there is a problem of my application or a problem of openSSL. My setup is: Host Computer: ovs-dpdk (virtual switch) vm1 : openssl vm2 : dpdk-application (role of a virtual switch that connect vm1 and vm3) vm3 : apache2 server Role of each component: vm1 : Just trying to connect to apache2 server through openssl vm2 : Dpdk-applcation that is a learning switch.Its purpose is to block the traffic if openssl (or some client) is trying to connect to a forbidden Server) vm3 : Just the Server So what I am actually doing is blocking the connection by responding with a TLS-alert (fatal , unrecognized name) When I do that it take some time for open ssl to end the connection .But after 2 or 3 seconds I see that open ssl in VM1 has read my response even in the actual Desktop.I see that it has read 7 bytes and the correct ssl-alert message that I send.(I check these on Wireshark as well). But that's a problem cause it take a lots of time.So the other thing I tried was to also send a TCP PACKET with a RST value in order to end the TCP session as well.That solved the problem from the perspective of speed because It now close the connection really fast but the problem is that now openssl don?t read my alert packet and the reason I closed the connection.I wanna mention also that when I receive the Client-Hello I response immediately with 2 packets .The one is the TLS-alert and the other one is TCP-RST packet. So my questions are these: 1)Is TCP reset the correct way to end the TLS-session(Handshake) after TLS alert message?If yes shall I send these 2 packets together as I do now?(forgive me, for my lack of knowledge on TCP) 2)Is there another way to end the connection except TCP(Reset)? 3)Is there a possibility that openssl read only TCP reset and not my alert packet, so for that reason the I only see connection closed but not the actual reason? 4)Is there a better way to do this? My end goal is to end the connection properly and openssl reads my SSl-alert message, so I will get in Vm1( with openssl) connection closed with unrecognized name as the actual reason. Thanks for your time, Konstantinos Schoinas From ncaro at compunetix.com Fri Sep 21 16:23:46 2018 From: ncaro at compunetix.com (Nelson Caro) Date: Fri, 21 Sep 2018 16:23:46 +0000 Subject: [openssl-users] FIPS mode on Windows Message-ID: On Mon Sep 10 11:26:25 UTC 2018, Hubert Kario wrote: > On Friday, 7 September 2018 20:18:38 CEST Alessandro Gherardi wrote: >> I'm running Windows 10. >> I downloaded the FIPS module sources >> from https://www.openssl.org/source/openssl-fips-2.0.16.tar.gz and the >> OpenSSL sources from https://www.openssl.org/source/openssl-1.0.2p.tar.gz . >> I built both FIPS module and OpenSSL (following the instructions >> at https://www.openssl.org/docs/fips/UserGuide-2.0.pdf to make sure OpenSSL >> uses the FIPS module) using Visual Studio. > > then that does sound like it does match the policy It does not: Security Policy 2.0.16 does not have any Microsoft Windows platforms in the "Tested Configurations" section. 2.0.10 was the last one that had, and it was Windows 7, not 10. Nelson D. Caro Embedded Software Engineer | Compunetix, Inc. 2420 Mosside Blvd | Monroeville, PA 15146 | www.compunetix.com nelson.caro at compunetix.com From ncaro at compunetix.com Fri Sep 21 17:05:57 2018 From: ncaro at compunetix.com (Nelson Caro) Date: Fri, 21 Sep 2018 17:05:57 +0000 Subject: [openssl-users] Could we have more details on the FIPS 3.0 plans? Message-ID: Dear Reader: I know that it may be early in the FIPS process, so the answer may not be ready. Could you provide us with more details as to the objectives for the FIPS Object Module 3.0? In particular, my company would like to know the estimated timetable for it to get certified, and whether Microsoft Windows 10 Professional and Microsoft Windows Server 2016 are included. (I had looked at the "FIPS module 3.0" wiki page, https://wiki.openssl.org/index.php/FIPS_module_3.0 , but it has not been updated since Mar 14.) Nelson D. Caro Embedded Software Engineer | Compunetix, Inc. 2420 Mosside Blvd | Monroeville, PA 15146 | www.compunetix.com nelson.caro at compunetix.com From openssl-mailman at familie-lahme.de Sat Sep 22 12:28:31 2018 From: openssl-mailman at familie-lahme.de (Carsten) Date: Sat, 22 Sep 2018 14:28:31 +0200 Subject: [openssl-users] [openssl]: Subject alternative names not recognized when signing certificates Message-ID: <9269f609-06c3-bb11-634c-cc33d19edf63@familie-lahme.de> Hi list, this is about setting up a certificate authority to sign incoming (forgeign) certificate requests. I have installed #################################### /var/caintermed # openssl version -a OpenSSL 1.1.2-dev xx XXX xxxx built on: Fri Sep 21 10:19:51 2018 UTC platform: linux-armv4 options: bn(64,32) rc4(char) des(long) idea(int) blowfish(ptr) compiler: gcc -fPIC -pthread -march=armv7-a -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPOLY1305_ASM -DNDEBUG OPENSSLDIR: "/usr/local/ssl" ENGINESDIR: "/usr/local/lib/engines-1.1" Seeding source: os-specific ############################################################ My setup is based on this: https://jamielinux.com/docs/openssl-certificate-authority/create-the-root-pair.html I can sign certificate requests successfully, BUT.... if the request contains SAN attributs (subjectalternatenames) they are ignored -not visible in the signed certificate. I found many exambles how to create a SAN-Certificate using the selfsigned mechanism, but that is not what I want. Is there any how-to in the wild, how to set up a fully working CA including SAN (v3) attributs? br Carsten From Matthias.St.Pierre at ncp-e.com Sat Sep 22 14:55:13 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Sat, 22 Sep 2018 14:55:13 +0000 Subject: [openssl-users] Manpages still say "pre-release" In-Reply-To: <241819d6-d121-9d58-88da-70b61ecc1efb@blastwave.org> References: <241819d6-d121-9d58-88da-70b61ecc1efb@blastwave.org> Message-ID: <7e7a92b993d544d19b9d6ab7726144df@Ex13.ncp.local> Thanks for the reminder, see https://github.com/openssl/web/pull/83. Matthias From parashah at cisco.com Sat Sep 22 23:42:08 2018 From: parashah at cisco.com (Paras Shah (parashah)) Date: Sat, 22 Sep 2018 23:42:08 +0000 Subject: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. In-Reply-To: <6979011E-FFA2-49D6-AD5A-6706BBF42D50@ll.mit.edu> References: <4AC69FC3-BEC7-46F6-882A-671196FC0156@contoso.com> <20180917.232222.1527258087716065205.levitte@openssl.org> <42B238D2-BB20-498A-B311-F4CE8C0FD030@cisco.com> <582ED379-8BAE-4124-A438-AED7F511862C@cisco.com> <6979011E-FFA2-49D6-AD5A-6706BBF42D50@ll.mit.edu> Message-ID: To update this thread. Please follow the commentary on the https://github.com/OpenSC/libp11/issues/249 From: "Blumenthal, Uri - 0553 - MITLL" Date: Friday, September 21, 2018 at 5:07 AM To: "Paras Shah (parashah)" , "openssl-users at openssl.org" Cc: Nicola Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Note that the key to reproducing this issue is compiling SoftHSMv2 with 1.1.1. When compiled with 1.0.2p, everything else can be compiled against 1.1.1 and it works ok. Regards, Uri Sent from my iPhone On Sep 21, 2018, at 02:09, Paras Shah (parashah) via openssl-users > wrote: I opened the issue https://github.com/openssl/openssl/issues/7258 Also, opened issue https://github.com/OpenSC/libp11/issues/249 and https://github.com/opendnssec/SoftHSMv2/issues/417 Found the root cause to be the openssl version 1.1.1 that was used to compile the engine_pkcs11 and SoftHSM. When I recompiled with openssl-1.0.2p, it worked fine. See https://github.com/OpenSC/libp11/issues/249 for details. From: "Paras Shah (parashah)" > Date: Tuesday, September 18, 2018 at 10:06 AM To: Nicola >, "openssl-users at openssl.org" > Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Sure. I will open the issue. From: Nicola > Date: Monday, September 17, 2018 at 10:05 PM To: "Paras Shah (parashah)" >, "openssl-users at openssl.org" > Subject: Re: [openssl-users] Softhsm + engine_pkcs11 + openssl with EC keys fail. Would it be possible for you to open this as an issue on Github and include there your first email and the full logs? Thanks, Nicola Tuveri On Tue, 18 Sep 2018 at 01:15, Paras Shah (parashah) via openssl-users > wrote: That is not it. It results in the same error for the EC key. It is not the URL or the ID. Because for a RSA key in the softhsm with id = 3333, it works fine with url containing id=%33%33 $ openssl pkey -in "pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%33%33;object=rsa%20key;type=private" -engine pkcs11 -inform ENGINE engine "pkcs11" set. Enter PKCS#11 token PIN for token 2.5.0-rc1: -----BEGIN PRIVATE KEY----- MIIBJwIBADANBgkqhkiG9w0BAQEFAASCAREwggENAgEAAoIBAQDD3378F1XbXJvP WP2GtZry0u6sL3eNYktQwJfhDMz5evDG+PahVjCMszV5CZvG+Kvap40xPBJoonqi oMAQsoLu7/fTx82aEL3TbdjXNLFnQ2KKYmfG9ymx80sLHMmdmDXpNNE+bEKJz1dp t1Q0cVduwmqSfB8JyIE6Udz7JX7HCXaVmxoK7z4Njh3dyHsqhdqKIx0dBuK0hCaq 4zPzGP/sORA3G9ZPxxpEvF3gvE/zsXj7ifihqbqr2eIFOpB/lQqAehsgQT5/6Iq+ 9pAX2LCxNkaUHYYZpMkM8Oi37jzg8PX/FnHdm9HQU2IBqYhoqo7/VsNdUDln2QHN dGAUprcbAgMBAAE= -----END PRIVATE KEY----- Coming back to EC key, looking at the error logs emitted, it does seem to recognize it to be EC (the logs contain EC_routines) somehow but then fails. On 9/17/18, 2:22 PM, "openssl-users on behalf of Richard Levitte" on behalf of levitte at openssl.org> wrote: In message <4AC69FC3-BEC7-46F6-882A-671196FC0156 at contoso.com> on Mon, 17 Sep 2018 20:59:59 +0000, "Paras Shah (parashah)" > said: > 4. Import the key into softhsm > > []:~$ softhsm2-util --import ~/tmp/secp256k1-key.pem.pkcs8 --label "ec key" --id 1111 --token > "token 2.5.0-rc1" Ok, so here, the ID is "1111" > 5. Get the pkcs11 url for the private key > > []:~$ p11tool --login --provider=/usr/local/lib/softhsm/libsofthsm2.so --set-pin=1111 --list-all > > Object 0: > > URL: > pkcs11:model=SoftHSM%20v2;manufacturer=SoftHSM%20project;serial=6a160d52b750862f;token=token%202.5.0-rc1;id=%11%11;object=ec%20key;type=private But here, the ID is "%11%11", and since those get percent decoded, that's actually two vertical tabs, or with C vector syntax, { 0x0b, 0x0b } I'm not sure what engine-pkcs11 asks of you otherwise, but one guess could be to change 'id=%11%11' to 'id=1111' in that URL and try again. Cheers, Richard -- Richard Levitte levitte at openssl.org OpenSSL Project http://www.openssl.org/~levitte/ -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Sun Sep 23 20:18:18 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Sun, 23 Sep 2018 16:18:18 -0400 Subject: [openssl-users] [openssl]: Subject alternative names not recognized when signing certificates In-Reply-To: <9269f609-06c3-bb11-634c-cc33d19edf63@familie-lahme.de> References: <9269f609-06c3-bb11-634c-cc33d19edf63@familie-lahme.de> Message-ID: <9E440C72-FE11-4430-9B70-DEC826DB6691@dukhovni.org> > On Sep 22, 2018, at 8:28 AM, Carsten wrote: > > I can sign certificate requests successfully, BUT.... > if the request contains SAN attributs (subjectalternatenames) they are ignored -not visible in the signed certificate. > > I found many exambles how to create a SAN-Certificate using the selfsigned mechanism, but that is not what I want. > > Is there any how-to in the wild, how to set up a fully working CA including SAN (v3) attributs? My approach is generally to dynamically generate a config file with the requisite extensions, and use that to build the certificate. It is possible to copy extensions from the request (CSR) to the certificate, but not always wise if you've not carefully checked that all the extensions in the CSR are appropriate. https://www.openssl.org/docs/man1.1.0/apps/ca.html copy_extensions determines how extensions in certificate requests should be handled. If set to none or this option is not present then extensions are ignored and not copied to the certificate. If set to copy then any extensions present in the request that are not already present are copied to the certificate. If set to copyall then all extensions in the request are copied to the certificate: if the extension is already present in the certificate it is deleted first. See the WARNINGS section before using this option. ... The copy_extensions option should be used with caution. If care is not taken then it can be a security risk. For example if a certificate request contains a basicConstraints extension with CA:TRUE and the copy_extensions value is set to copyall and the user does not spot this when the certificate is displayed then this will hand the requester a valid CA certificate. This situation can be avoided by setting copy_extensions to copy and including basicConstraints with CA:FALSE in the configuration file. Then if the request contains a basicConstraints extension it will be ignored. It is advisable to also include values for other extensions such as keyUsage to prevent a request supplying its own values. Additional restrictions can be placed on the CA certificate itself. For example if the CA certificate has: basicConstraints = CA:TRUE, pathlen:0 then even if a certificate is issued with CA:TRUE it will not be valid. -- Viktor. From paul.dale at oracle.com Sun Sep 23 21:37:36 2018 From: paul.dale at oracle.com (Paul Dale) Date: Sun, 23 Sep 2018 14:37:36 -0700 (PDT) Subject: [openssl-users] Could we have more details on the FIPS 3.0 plans? In-Reply-To: References: Message-ID: It is early in the FIPS process. Design and planning stages. At this point, we do not know for certain: 1. which algorithms will be validated; 2. what platforms they will be validated on or 3. when the formal validation will begin. The decision making processes take time and while I'm confident some aspects of the first two points are known, they've not been formally codified. Pauli -- Oracle Dr Paul Dale | Cryptographer | Network Security & Encryption Phone +61 7 3031 7217 Oracle Australia -----Original Message----- From: Nelson Caro [mailto:ncaro at compunetix.com] Sent: Saturday, 22 September 2018 3:06 AM To: openssl-users at openssl.org Cc: Nelson Caro Subject: [openssl-users] Could we have more details on the FIPS 3.0 plans? Dear Reader: I know that it may be early in the FIPS process, so the answer may not be ready. Could you provide us with more details as to the objectives for the FIPS Object Module 3.0? In particular, my company would like to know the estimated timetable for it to get certified, and whether Microsoft Windows 10 Professional and Microsoft Windows Server 2016 are included. (I had looked at the "FIPS module 3.0" wiki page, https://wiki.openssl.org/index.php/FIPS_module_3.0 , but it has not been updated since Mar 14.) Nelson D. Caro Embedded Software Engineer | Compunetix, Inc. 2420 Mosside Blvd | Monroeville, PA 15146 | www.compunetix.com nelson.caro at compunetix.com -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From peter.petrik at lutraconsulting.co.uk Mon Sep 24 09:03:15 2018 From: peter.petrik at lutraconsulting.co.uk (Peter Petrik) Date: Mon, 24 Sep 2018 11:03:15 +0200 Subject: [openssl-users] building openssl 1.1.1 using CrystaX NDK 10.3.2 (Android) Message-ID: Hi, I want to add openssl to OSGeo4A , which is built with CrystaX NDK. I have run into issues building openssl, missing random functions: arm-linux-androideabi-gcc -I. -Icrypto/include -Iinclude -I../openssl-1.1.1 -I../openssl-1.1.1/crypto/include -I../op enssl-1.1.1/include -fPIC -pthread -mandroid --sysroot=/opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm -march= armv7-a -Wa,--noexecstack -Wall -O3 -DOPENSSL_USE_NODELETE -DOPENSSL_PIC -DOPENSSL_CPUID_OBJ -DOPENSSL_BN_ASM_MONT -DO PENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DKECCAK1600_ASM -DAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ 256_ASM -DPOLY1305_ASM -DOPENSSLDIR="\"/usr/local/ssl/16/\"" -DENGINESDIR="\"/usr/local/lib/engines-1.1\"" -DNDEBUG -D __ANDROID_API__=16 -MMD -MF crypto/rand/rand_unix.d.tmp -MT crypto/rand/rand_unix.o -c -o crypto/rand/rand_unix.o ../o penssl-1.1.1/crypto/rand/rand_unix.c In file included from /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include/sys/glibc-syscalls.h:43:0, from /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include/crystax/bionic/libc/include/sy s/mangled-syscall.h:34, from /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include/sys/syscall.h:43, from ../openssl-1.1.1/crypto/rand/rand_unix.c:22: ../openssl-1.1.1/crypto/rand/rand_unix.c: In function 'syscall_random': ../openssl-1.1.1/crypto/rand/rand_unix.c:297:20: error: '__NR_getrandom' undeclared (first use in this function) return syscall(SYS_getrandom, buf, buflen, 0); (see attached configure.txt) What is strange is that when I try with --with-rand-seed=none, I have the same error message. With other rand-seed options, different methods are missing. Do you have any idea how to proceed here? Thanks a lot. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- Command line (with current working directory = .): /usr/bin/perl ../openssl-1.1.1/Configure android-arm shared no-comp no-hw no-engine --openssldir=/usr/local/ssl/16/ -D__ANDROID_API__=16 Perl information: /usr/bin/perl 5.26.0 for x86_64-linux-gnu-thread-multi Enabled features: aria asm async autoalginit autoerrinit autoload-config bf blake2 camellia capieng cast chacha cmac cms ct deprecated des dgram dh dsa dso dtls dynamic-engine ec ec2m ecdh ecdsa err filenames gost hw(-.+)? idea makedepend md4 mdc2 multiblock nextprotoneg ocb ocsp pic poly1305 posix-io psk rc2 rc4 rdrand rfc3779 rmd160 scrypt seed shared siphash sm2 sm3 sm4 sock srp srtp sse2 ssl static-engine stdio tests threads tls ts ui-console whirlpool tls1 tls1-method tls1_1 tls1_1-method tls1_2 tls1_2-method tls1_3 dtls1 dtls1-method dtls1_2 dtls1_2-method Disabled features: afalgeng [forced] OPENSSL_NO_AFALGENG asan [default] OPENSSL_NO_ASAN comp [option] OPENSSL_NO_COMP (skip crypto/comp) crypto-mdebug [default] OPENSSL_NO_CRYPTO_MDEBUG crypto-mdebug-backtrace [default] OPENSSL_NO_CRYPTO_MDEBUG_BACKTRACE devcryptoeng [default] OPENSSL_NO_DEVCRYPTOENG ec_nistp_64_gcc_128 [default] OPENSSL_NO_EC_NISTP_64_GCC_128 egd [default] OPENSSL_NO_EGD engine [option] OPENSSL_NO_ENGINE (skip crypto/engine, engines) external-tests [default] OPENSSL_NO_EXTERNAL_TESTS fuzz-libfuzzer [default] OPENSSL_NO_FUZZ_LIBFUZZER fuzz-afl [default] OPENSSL_NO_FUZZ_AFL heartbeats [default] OPENSSL_NO_HEARTBEATS md2 [default] OPENSSL_NO_MD2 (skip crypto/md2) msan [default] OPENSSL_NO_MSAN rc5 [default] OPENSSL_NO_RC5 (skip crypto/rc5) sctp [default] OPENSSL_NO_SCTP ssl-trace [default] OPENSSL_NO_SSL_TRACE ubsan [default] OPENSSL_NO_UBSAN unit-test [default] OPENSSL_NO_UNIT_TEST weak-ssl-ciphers [default] OPENSSL_NO_WEAK_SSL_CIPHERS zlib [default] zlib-dynamic [default] ssl3 [default] OPENSSL_NO_SSL3 ssl3-method [default] OPENSSL_NO_SSL3_METHOD Config target attributes: AR => "ar", ARFLAGS => "r", CC => "gcc", CFLAGS => "-Wall -O3", CXX => "g++", CXXFLAGS => "-Wall -O3", HASHBANGPERL => "/usr/bin/env perl", RANLIB => "ranlib", RC => "windres", aes_asm_src => "aes_cbc.c aes-armv4.S bsaes-armv7.S aesv8-armx.S", aes_obj => "aes_cbc.o aes-armv4.o bsaes-armv7.o aesv8-armx.o", apps_aux_src => "", apps_init_src => "", apps_obj => "", bf_asm_src => "bf_enc.c", bf_obj => "bf_enc.o", bin_cflags => "-pie", bn_asm_src => "bn_asm.c armv4-mont.S armv4-gf2m.S", bn_obj => "bn_asm.o armv4-mont.o armv4-gf2m.o", bn_ops => "BN_LLONG RC4_CHAR", build_file => "Makefile", build_scheme => [ "unified", "unix" ], cast_asm_src => "c_enc.c", cast_obj => "c_enc.o", cflags => "-pthread -mandroid --sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm", chacha_asm_src => "chacha-armv4.S", chacha_obj => "chacha-armv4.o", cmll_asm_src => "camellia.c cmll_misc.c cmll_cbc.c", cmll_obj => "camellia.o cmll_misc.o cmll_cbc.o", cppflags => "", cpuid_asm_src => "armcap.c armv4cpuid.S", cpuid_obj => "armcap.o armv4cpuid.o", cxxflags => "-std=c++11 -pthread -mandroid --sysroot=\$(ANDROID_NDK)/platforms/android-16/arch-arm", defines => [ ], des_asm_src => "des_enc.c fcrypt_b.c", des_obj => "des_enc.o fcrypt_b.o", disable => [ ], dso_extension => ".so", dso_scheme => "dlfcn", ec_asm_src => "ecp_nistz256.c ecp_nistz256-armv4.S", ec_obj => "ecp_nistz256.o ecp_nistz256-armv4.o", enable => [ ], ex_libs => "-ldl -pthread", exe_extension => "", includes => [ ], keccak1600_asm_src => "keccak1600-armv4.S", keccak1600_obj => "keccak1600-armv4.o", lflags => "", lib_cflags => "", lib_cppflags => "-DOPENSSL_USE_NODELETE", lib_defines => [ ], md5_asm_src => "", md5_obj => "", modes_asm_src => "ghash-armv4.S ghashv8-armx.S", modes_obj => "ghash-armv4.o ghashv8-armx.o", module_cflags => "-fPIC", module_cxxflags => "", module_ldflags => "-Wl,-znodelete -shared -Wl,-Bsymbolic", padlock_asm_src => "", padlock_obj => "", perlasm_scheme => "void", poly1305_asm_src => "poly1305-armv4.S", poly1305_obj => "poly1305-armv4.o", rc4_asm_src => "rc4_enc.c rc4_skey.c", rc4_obj => "rc4_enc.o rc4_skey.o", rc5_asm_src => "rc5_enc.c", rc5_obj => "rc5_enc.o", rmd160_asm_src => "", rmd160_obj => "", sha1_asm_src => "sha1-armv4-large.S sha256-armv4.S sha512-armv4.S", sha1_obj => "sha1-armv4-large.o sha256-armv4.o sha512-armv4.o", shared_cflag => "-fPIC", shared_defflag => "-Wl,--version-script=", shared_defines => [ ], shared_extension => ".so.\$(SHLIB_VERSION_NUMBER)", shared_extension_simple => ".so", shared_ldflag => "-Wl,-znodelete -shared -Wl,-Bsymbolic", shared_rcflag => "", shared_sonameflag => "-Wl,-soname=", shared_target => "linux-shared", thread_defines => [ ], thread_scheme => "pthreads", unistd => "", uplink_aux_src => "", uplink_obj => "", wp_asm_src => "wp_block.c", wp_obj => "wp_block.o", Recorded environment: AR = BUILDFILE = CC = CROSS_COMPILE = - CXX = ccache arm-linux-androideabi-g++ -DANDROID -mandroid -fomit-frame-pointer --sysroot /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm -I/home/peter/quick/OSGeo4A/stage/armeabi-v7a/include -L/opt/crystax-ndk-10.3.2/sources/crystax/libs/armeabi-v7a -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include HASHBANGPERL = OPENSSL_LOCAL_CONFIG_DIR = PERL = RANLIB = arm-linux-androideabi-ranlib RC = WINDRES = __CNF_CFLAGS = -march=armv7-a __CNF_CPPDEFINES = __CNF_CPPFLAGS = __CNF_CPPINCLUDES = __CNF_CXXFLAGS = -march=armv7-a __CNF_LDFLAGS = __CNF_LDLIBS = Makevars: AR = arm-linux-androideabi-ar ARFLAGS = r CC = arm-linux-androideabi-gcc CFLAGS = -Wall -O3 CPPDEFINES = __ANDROID_API__=16 CPPFLAGS = CPPINCLUDES = CROSS_COMPILE = arm-linux-androideabi- CXX = arm-linux-androideabi-ccache arm-linux-androideabi-g++ -DANDROID -mandroid -fomit-frame-pointer --sysroot /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm -I/home/peter/quick/OSGeo4A/stage/armeabi-v7a/include -L/opt/crystax-ndk-10.3.2/sources/crystax/libs/armeabi-v7a -march=armv7-a -mfloat-abi=softfp -mfpu=vfp -mthumb -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/include -isystem /opt/crystax-ndk-10.3.2/sources/cxx-stl/gnu-libstdc++/4.9/libs/armeabi-v7a/include -isystem /opt/crystax-ndk-10.3.2/platforms/android-16/arch-arm/usr/include CXXFLAGS = -Wall -O3 HASHBANGPERL = /usr/bin/env perl LDFLAGS = LDLIBS = PERL = /usr/bin/perl RANLIB = arm-linux-androideabi-arm-linux-androideabi-ranlib RC = arm-linux-androideabi-windres NOTE: These variables only represent the configuration view. The build file template may have processed these variables further, please have a look at the build file for more exact data: Makefile build file: Makefile build file templates: ../openssl-1.1.1/Configurations/common0.tmpl ../openssl-1.1.1/Configurations/unix-Makefile.tmpl ../openssl-1.1.1/Configurations/common.tmpl Operating system: armv7-whatever-android Configuring OpenSSL version 1.1.1 (0x1010100fL) for android-arm Using os-specific seed configuration Creating configdata.pm Creating Makefile From vinay.mummadi at digicert.com Mon Sep 24 13:12:51 2018 From: vinay.mummadi at digicert.com (Vinay Mummadi) Date: Mon, 24 Sep 2018 13:12:51 +0000 Subject: [openssl-users] Build issues with openssl-1.1.1 In-Reply-To: <7AA8B273-06BD-43CC-AC1F-26383822F509@digicert.com> References: <7AA8B273-06BD-43CC-AC1F-26383822F509@digicert.com> Message-ID: <4B3E5BE8-18C9-4847-A71F-10EE9B410D8A@digicert.com> Hi team, I have downloaded openssl-1.1.1.tar.gz and executed the build it fails during make with this error. Following are the steps. 1. "./config --prefix=/u/build/build2/openssl/openssl.SYMC-1.1.1.shared/root/app/symc/packages/openssl.SYMC-1.1.1.shared shared zlib -L$baseLinkDir/lib -lz enable-ec_nistp_64_gcc_128" 2. "make depend" 1. "make" I see this error crypto/ec/ecp_nistp224.c:48:4: error: #error "Your compiler doesn't appear to support 128-bit integer types" crypto/ec/ecp_nistp224.c:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widelimb' crypto/ec/ecp_nistp224.c:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widefelem' crypto/ec/ecp_nistp224.c:426: error: expected ')' before 'out' crypto/ec/ecp_nistp224.c:454: error: expected ')' before 'out' crypto/ec/ecp_nistp224.c:491: error: expected ')' before 'out' crypto/ec/ecp_nistp224.c:503: error: expected ')' before 'out' crypto/ec/ecp_nistp224.c:519: error: expected ')' before 'out' crypto/ec/ecp_nistp224.c:537: warning: type defaults to 'int' in declaration of 'widefelem' crypto/ec/ecp_nistp224.c:537: error: expected ';', ',' or ')' before 'in' crypto/ec/ecp_nistp224.c: In function 'felem_square_reduce': crypto/ec/ecp_nistp224.c:603: error: 'widefelem' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:603: error: (Each undeclared identifier is reported only once crypto/ec/ecp_nistp224.c:603: error: for each function it appears in.) crypto/ec/ecp_nistp224.c:603: error: expected ';' before 'tmp' crypto/ec/ecp_nistp224.c:604: warning: implicit declaration of function 'felem_square' crypto/ec/ecp_nistp224.c:604: error: 'tmp' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:605: warning: implicit declaration of function 'felem_reduce' crypto/ec/ecp_nistp224.c: In function 'felem_mul_reduce': crypto/ec/ecp_nistp224.c:610: error: 'widefelem' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:610: error: expected ';' before 'tmp' crypto/ec/ecp_nistp224.c:611: warning: implicit declaration of function 'felem_mul' crypto/ec/ecp_nistp224.c:611: error: 'tmp' undeclared (first use in this function) crypto/ec/ecp_nistp224.c: In function 'felem_neg': crypto/ec/ecp_nistp224.c:678: error: 'widefelem' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:678: error: expected ';' before 'tmp' crypto/ec/ecp_nistp224.c:679: warning: implicit declaration of function 'felem_diff_128_64' crypto/ec/ecp_nistp224.c:679: error: 'tmp' undeclared (first use in this function) crypto/ec/ecp_nistp224.c: In function 'felem_inv': crypto/ec/ecp_nistp224.c:713: error: 'widefelem' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:713: error: expected ';' before 'tmp' crypto/ec/ecp_nistp224.c:716: error: 'tmp' undeclared (first use in this function) crypto/ec/ecp_nistp224.c: In function 'point_double': crypto/ec/ecp_nistp224.c:830: error: 'widefelem' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:830: error: expected ';' before 'tmp' crypto/ec/ecp_nistp224.c:837: error: 'tmp' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:888: error: 'tmp2' undeclared (first use in this function) crypto/ec/ecp_nistp224.c:890: warning: implicit declaration of function 'widefelem_scalar' earlier for openssl-1.1.0i, I used the same steps. I have attached the build.log and the dump as requested. Please suggest the resolution for this issue. Thanks, Vinay ------ Vinay 9008855944 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: perl-configdata-dump Type: application/octet-stream Size: 7837 bytes Desc: perl-configdata-dump URL: From levitte at openssl.org Mon Sep 24 13:42:48 2018 From: levitte at openssl.org (Richard Levitte) Date: Mon, 24 Sep 2018 15:42:48 +0200 (CEST) Subject: [openssl-users] Build issues with openssl-1.1.1 In-Reply-To: <4B3E5BE8-18C9-4847-A71F-10EE9B410D8A@digicert.com> References: <7AA8B273-06BD-43CC-AC1F-26383822F509@digicert.com> <4B3E5BE8-18C9-4847-A71F-10EE9B410D8A@digicert.com> Message-ID: <20180924.154248.2078713038705571598.levitte@openssl.org> I'm noticing these from the dump: Recorded environment: ... CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ Could it be that those compilers don't have support for 128 bit integers on your platform? In that case, you should remove 'enable-ec_nistp_64_gcc_128' from your configuration command. Cheers, Richard In message <4B3E5BE8-18C9-4847-A71F-10EE9B410D8A at digicert.com> on Mon, 24 Sep 2018 13:12:51 +0000, Vinay Mummadi said: > Hi team, > > I have downloaded openssl-1.1.1.tar.gz and executed the build it fails during make with this error. > > Following are the steps. > > 1 "./config > --prefix=/u/build/build2/openssl/openssl.SYMC-1.1.1.shared/root/app/symc/packages/openssl.SYMC-1.1.1.shared > shared zlib -L$baseLinkDir/lib -lz enable-ec_nistp_64_gcc_128" > > 2 "make depend" > > 1 "make" > > I see this error > > crypto/ec/ecp_nistp224.c:48:4: error: #error "Your compiler doesn't appear to support 128-bit > integer types" > > crypto/ec/ecp_nistp224.c:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widelimb' > > crypto/ec/ecp_nistp224.c:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widefelem' > > crypto/ec/ecp_nistp224.c:426: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:454: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:491: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:503: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:519: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:537: warning: type defaults to 'int' in declaration of 'widefelem' > > crypto/ec/ecp_nistp224.c:537: error: expected ';', ',' or ')' before 'in' > > crypto/ec/ecp_nistp224.c: In function 'felem_square_reduce': > > crypto/ec/ecp_nistp224.c:603: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:603: error: (Each undeclared identifier is reported only once > > crypto/ec/ecp_nistp224.c:603: error: for each function it appears in.) > > crypto/ec/ecp_nistp224.c:603: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:604: warning: implicit declaration of function 'felem_square' > > crypto/ec/ecp_nistp224.c:604: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:605: warning: implicit declaration of function 'felem_reduce' > > crypto/ec/ecp_nistp224.c: In function 'felem_mul_reduce': > > crypto/ec/ecp_nistp224.c:610: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:610: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:611: warning: implicit declaration of function 'felem_mul' > > crypto/ec/ecp_nistp224.c:611: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'felem_neg': > > crypto/ec/ecp_nistp224.c:678: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:678: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:679: warning: implicit declaration of function 'felem_diff_128_64' > > crypto/ec/ecp_nistp224.c:679: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'felem_inv': > > crypto/ec/ecp_nistp224.c:713: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:713: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:716: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'point_double': > > crypto/ec/ecp_nistp224.c:830: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:830: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:837: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:888: error: 'tmp2' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:890: warning: implicit declaration of function 'widefelem_scalar' > > earlier for openssl-1.1.0i, I used the same steps. > > I have attached the build.log and the dump as requested. Please suggest the resolution for this > issue. > > Thanks, > > Vinay > > ------ > > Vinay > > 9008855944 > From scott_n at xypro.com Mon Sep 24 22:25:06 2018 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 24 Sep 2018 22:25:06 +0000 Subject: [openssl-users] Certificate format question? Message-ID: I tried googling, but couldn't find an answer to this... I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Mon Sep 24 22:55:16 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Mon, 24 Sep 2018 18:55:16 -0400 Subject: [openssl-users] Certificate format question? In-Reply-To: References: Message-ID: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> > On Sep 24, 2018, at 6:25 PM, Scott Neugroschl wrote: > > I tried googling, but couldn?t find an answer to this? > > I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. > > I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications? https://tools.ietf.org/html/rfc7468#section-2 -- Viktor. From scott_n at xypro.com Tue Sep 25 15:26:03 2018 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 25 Sep 2018 15:26:03 +0000 Subject: [openssl-users] Certificate format question? In-Reply-To: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> Message-ID: >On Sept 24, 2018, at 3:55 PM, Viktor Dukhovni wrote: >> On Sep 24, 2018, at 6:25 PM, Scott Neugroschl > wrote: >> >> I tried googling, but couldn?t find an answer to this? >> >> I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. >> >> I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN >>delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it >>explicitly permitted by the standards/specifications? >https://tools.ietf.org/html/rfc7468#section-2 Thanks, Viktor, appreciated. From hkario at redhat.com Tue Sep 25 17:15:47 2018 From: hkario at redhat.com (Hubert Kario) Date: Tue, 25 Sep 2018 19:15:47 +0200 Subject: [openssl-users] Certificate format question? In-Reply-To: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> Message-ID: <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> On Tuesday, 25 September 2018 00:55:16 CEST Viktor Dukhovni wrote: > > On Sep 24, 2018, at 6:25 PM, Scott Neugroschl wrote: > > > > I tried googling, but couldn?t find an answer to this? > > > > I came across a certificate that had some text garbage before the ---- > > BEGIN CERTIFICATE ---- line. > > > > I know that the cert is defined as the data between the delimiters. Do > > the specs say anything about data before the BEGIN delimiter? Would a > > certificate with such data be valid? I know OpenSSL accepts such a cert, > > but is this an extension, or is it explicitly permitted by the > > standards/specifications? > https://tools.ietf.org/html/rfc7468#section-2 then it looks like the parser used in asn1parse -inform pem is non- compliant... https://github.com/openssl/openssl/issues/7317 -- 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 openssl-users at dukhovni.org Tue Sep 25 17:35:31 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Tue, 25 Sep 2018 13:35:31 -0400 Subject: [openssl-users] Certificate format question? In-Reply-To: <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> Message-ID: <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> That particular parser tries to parse an arbitrary single PEM-encoded object, rather than a first object of a particular type (as with "pkey", "req", "x509", ...). The code for that is more specialized, and does support leading free-form text. While it could skip to the first boundary, and a well written pull request would be welcome, it is not critical for asn1parse to be able to ignore free-form text above the PEM object. In the meantime: $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem | openssl asn1parse > On Sep 25, 2018, at 1:15 PM, Hubert Kario wrote: > > then it looks like the parser used in asn1parse -inform pem is non- > compliant... > > https://github.com/openssl/openssl/issues/7317 -- Viktor. From steffen at sdaoden.eu Tue Sep 25 18:57:24 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Tue, 25 Sep 2018 20:57:24 +0200 Subject: [openssl-users] Certificate format question? In-Reply-To: <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> Message-ID: <20180925185724.bA-y8%steffen@sdaoden.eu> Viktor Dukhovni wrote in <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F at dukhovni.org>: |That particular parser tries to parse an arbitrary single |PEM-encoded object, rather than a first object of a particular |type (as with "pkey", "req", "x509", ...). The code for that |is more specialized, and does support leading free-form text. | |While it could skip to the first boundary, and a well written |pull request would be welcome, it is not critical for asn1parse |to be able to ignore free-form text above the PEM object. | |In the meantime: | | $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem | | openssl asn1parse The RFC 7468 term "parsers SHOULD ignore whitespace and other non- base64 characters" makes me wonder. I know (or used to know) that the OpenSSL base64 decoder is (or was) pretty bad in doing so. But this RFC is about PKIX specifics, of course, yet i (as a MUA maintainer) struggled with how to deal with embedded data in base64 encodings, and this RFC seems to explicitly allow them. And i struggled because i have seen mail messages with data embedded in base64; the rewrite of the MIME encoder (MUA commit [d91a4bd0]), necessary to deal with those sequences. says a. o.: In both cases: except that we, due to lack of a context, cannot give an error message, say, once per handled message. I.e., we cannot provide any error logging in order to avoid a possibly infinite amount of such messages. Regarding the garbage in base64 parts that we now simply skip. I mean, it is possible to embed abuse porn or similar shit in between the valid data, and now we _also_ simply skip over the "garbage", silently extraditing our users to automatic parsers which may gobble that s..t! Also because the mutt(1) MUA is pretty good in skipping over things. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From rkrehbiel at kastle.com Tue Sep 25 18:34:33 2018 From: rkrehbiel at kastle.com (Krehbiel, Richard) Date: Tue, 25 Sep 2018 18:34:33 +0000 Subject: [openssl-users] An example issuing an intermediate CA with policy mappings? Message-ID: For my testing I want to explore the behaviors of policies, policy constraints, and policy mappings. I have figured out how to request and issue certs with custom policy OIDs, but I haven't yet seen a method of granting an intermediate cert with policy mappings. Can openssl do this? How? Thanks. KASTLE SYSTEMS 855.527.8531 | KASTLE.COM Follow us on LinkedIn or Twitter for Security Tips! Click Here to see why the Washington Post is calling our Hands-Free Mobile Credential "the end of the badge." -------------- next part -------------- An HTML attachment was scrubbed... URL: From scott_n at xypro.com Tue Sep 25 21:25:00 2018 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 25 Sep 2018 21:25:00 +0000 Subject: [openssl-users] Certificate format question? In-Reply-To: <20180925185724.bA-y8%steffen@sdaoden.eu> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> <20180925185724.bA-y8%steffen@sdaoden.eu> Message-ID: Steffen Nurpmeso, Tuesday, September 25, 2018 11:57 AM > The RFC 7468 term "parsers SHOULD ignore whitespace and other non- >base64 characters" makes me wonder. The relevant clause is a few sentences up: "Data before the encapsulation boundaries are permitted, and parsers MUST NOT malfunction when processing such data. From vinay.mummadi at digicert.com Wed Sep 26 02:47:51 2018 From: vinay.mummadi at digicert.com (Vinay Mummadi) Date: Wed, 26 Sep 2018 02:47:51 +0000 Subject: [openssl-users] openssl-users Digest, Vol 46, Issue 46 In-Reply-To: References: Message-ID: Hi Richard, CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ I was using these for openssl 1.1.0h and it compiled with this option " enable-ec_nistp_64_gcc_128" Any other possibility, Please suggest. ------ Vinay 9008855944 ?On 9/25/18, 10:52 PM, "openssl-users on behalf of openssl-users-request at openssl.org" wrote: Send openssl-users mailing list submissions to openssl-users at openssl.org To subscribe or unsubscribe via the World Wide Web, visit https://clicktime.symantec.com/a/1/SXS5XgWCQv7_XKjynYvihvgWkHBXM75USaaY43D_lOU=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-users or, via email, send a message with subject or body 'help' to openssl-users-request at openssl.org You can reach the person managing the list at openssl-users-owner at openssl.org When replying, please edit your Subject line so it is more specific than "Re: Contents of openssl-users digest..." Today's Topics: 1. Re: Build issues with openssl-1.1.1 (Richard Levitte) 2. Certificate format question? (Scott Neugroschl) 3. Re: Certificate format question? (Viktor Dukhovni) 4. Re: Certificate format question? (Scott Neugroschl) 5. Re: Certificate format question? (Hubert Kario) ---------------------------------------------------------------------- Message: 1 Date: Mon, 24 Sep 2018 15:42:48 +0200 (CEST) From: Richard Levitte To: openssl-users at openssl.org Subject: Re: [openssl-users] Build issues with openssl-1.1.1 Message-ID: <20180924.154248.2078713038705571598.levitte at openssl.org> Content-Type: Text/Plain; charset=us-ascii I'm noticing these from the dump: Recorded environment: ... CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ Could it be that those compilers don't have support for 128 bit integers on your platform? In that case, you should remove 'enable-ec_nistp_64_gcc_128' from your configuration command. Cheers, Richard In message <4B3E5BE8-18C9-4847-A71F-10EE9B410D8A at digicert.com> on Mon, 24 Sep 2018 13:12:51 +0000, Vinay Mummadi said: > Hi team, > > I have downloaded openssl-1.1.1.tar.gz and executed the build it fails during make with this error. > > Following are the steps. > > 1 "./config > --prefix=/u/build/build2/openssl/openssl.SYMC-1.1.1.shared/root/app/symc/packages/openssl.SYMC-1.1.1.shared > shared zlib -L$baseLinkDir/lib -lz enable-ec_nistp_64_gcc_128" > > 2 "make depend" > > 1 "make" > > I see this error > > crypto/ec/ecp_nistp224.c:48:4: error: #error "Your compiler doesn't appear to support 128-bit > integer types" > > crypto/ec/ecp_nistp224.c:75: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widelimb' > > crypto/ec/ecp_nistp224.c:78: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'widefelem' > > crypto/ec/ecp_nistp224.c:426: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:454: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:491: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:503: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:519: error: expected ')' before 'out' > > crypto/ec/ecp_nistp224.c:537: warning: type defaults to 'int' in declaration of 'widefelem' > > crypto/ec/ecp_nistp224.c:537: error: expected ';', ',' or ')' before 'in' > > crypto/ec/ecp_nistp224.c: In function 'felem_square_reduce': > > crypto/ec/ecp_nistp224.c:603: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:603: error: (Each undeclared identifier is reported only once > > crypto/ec/ecp_nistp224.c:603: error: for each function it appears in.) > > crypto/ec/ecp_nistp224.c:603: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:604: warning: implicit declaration of function 'felem_square' > > crypto/ec/ecp_nistp224.c:604: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:605: warning: implicit declaration of function 'felem_reduce' > > crypto/ec/ecp_nistp224.c: In function 'felem_mul_reduce': > > crypto/ec/ecp_nistp224.c:610: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:610: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:611: warning: implicit declaration of function 'felem_mul' > > crypto/ec/ecp_nistp224.c:611: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'felem_neg': > > crypto/ec/ecp_nistp224.c:678: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:678: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:679: warning: implicit declaration of function 'felem_diff_128_64' > > crypto/ec/ecp_nistp224.c:679: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'felem_inv': > > crypto/ec/ecp_nistp224.c:713: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:713: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:716: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c: In function 'point_double': > > crypto/ec/ecp_nistp224.c:830: error: 'widefelem' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:830: error: expected ';' before 'tmp' > > crypto/ec/ecp_nistp224.c:837: error: 'tmp' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:888: error: 'tmp2' undeclared (first use in this function) > > crypto/ec/ecp_nistp224.c:890: warning: implicit declaration of function 'widefelem_scalar' > > earlier for openssl-1.1.0i, I used the same steps. > > I have attached the build.log and the dump as requested. Please suggest the resolution for this > issue. > > Thanks, > > Vinay > > ------ > > Vinay > > 9008855944 > ------------------------------ Message: 2 Date: Mon, 24 Sep 2018 22:25:06 +0000 From: Scott Neugroschl To: "openssl-users at openssl.org" Subject: [openssl-users] Certificate format question? Message-ID: Content-Type: text/plain; charset="us-ascii" I tried googling, but couldn't find an answer to this... I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications? Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: ------------------------------ Message: 3 Date: Mon, 24 Sep 2018 18:55:16 -0400 From: Viktor Dukhovni To: "openssl-users at openssl.org" Subject: Re: [openssl-users] Certificate format question? Message-ID: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44 at dukhovni.org> Content-Type: text/plain; charset=utf-8 > On Sep 24, 2018, at 6:25 PM, Scott Neugroschl wrote: > > I tried googling, but couldn?t find an answer to this? > > I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. > > I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it explicitly permitted by the standards/specifications? https://clicktime.symantec.com/a/1/wMs9_KBHcnDbewE3qEoDEEpmCpvHjBatvULuyuMRmfI=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7468%23section-2 -- Viktor. ------------------------------ Message: 4 Date: Tue, 25 Sep 2018 15:26:03 +0000 From: Scott Neugroschl To: "'openssl-users at openssl.org'" Subject: Re: [openssl-users] Certificate format question? Message-ID: Content-Type: text/plain; charset="utf-8" >On Sept 24, 2018, at 3:55 PM, Viktor Dukhovni wrote: >> On Sep 24, 2018, at 6:25 PM, Scott Neugroschl > wrote: >> >> I tried googling, but couldn?t find an answer to this? >> >> I came across a certificate that had some text garbage before the ---- BEGIN CERTIFICATE ---- line. >> >> I know that the cert is defined as the data between the delimiters. Do the specs say anything about data before the BEGIN >>delimiter? Would a certificate with such data be valid? I know OpenSSL accepts such a cert, but is this an extension, or is it >>explicitly permitted by the standards/specifications? >https://clicktime.symantec.com/a/1/wMs9_KBHcnDbewE3qEoDEEpmCpvHjBatvULuyuMRmfI=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7468%23section-2 Thanks, Viktor, appreciated. ------------------------------ Message: 5 Date: Tue, 25 Sep 2018 19:15:47 +0200 From: Hubert Kario To: openssl-users at openssl.org Subject: Re: [openssl-users] Certificate format question? Message-ID: <1823844.pAo1nv2Lg2 at pintsize.usersys.redhat.com> Content-Type: text/plain; charset="utf-8" On Tuesday, 25 September 2018 00:55:16 CEST Viktor Dukhovni wrote: > > On Sep 24, 2018, at 6:25 PM, Scott Neugroschl wrote: > > > > I tried googling, but couldn?t find an answer to this? > > > > I came across a certificate that had some text garbage before the ---- > > BEGIN CERTIFICATE ---- line. > > > > I know that the cert is defined as the data between the delimiters. Do > > the specs say anything about data before the BEGIN delimiter? Would a > > certificate with such data be valid? I know OpenSSL accepts such a cert, > > but is this an extension, or is it explicitly permitted by the > > standards/specifications? > https://clicktime.symantec.com/a/1/wMs9_KBHcnDbewE3qEoDEEpmCpvHjBatvULuyuMRmfI=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc7468%23section-2 then it looks like the parser used in asn1parse -inform pem is non- compliant... https://clicktime.symantec.com/a/1/SdiPoXfXm6gJ4b-GTsltca8zYpQxzBYDyF6WVJvkOOY=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fissues%2F7317 -- 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: ------------------------------ Subject: Digest Footer _______________________________________________ openssl-users mailing list openssl-users at openssl.org https://clicktime.symantec.com/a/1/SXS5XgWCQv7_XKjynYvihvgWkHBXM75USaaY43D_lOU=?d=7U6BPcrfpQINoyAkaWunm-Zlxgg6nczKEb9ZYXUfcNhzNfvR2d74CjA_35NwXwCg2RmGxDD2gqG7TcqIzSct_FMsWOb9VEMhQqKgoGJyVI_ItuSei6LGnLenR9YJi6TsTKsDHJo6bTNEgQNuVYFDBsNp1aCcfNYAiYfSl1J3xd_9ybL1pedLE7cfRJuAWroMNo3zsb40q9IP2dL2nqyGLQWlF5Oyy0_0IliS1xgXE6-mWi-BS2Eu0EhPWhSPbuHFpq3s7Spfo8D88OojTXiT8GAu0BoQ7E0tonETjZ3kpBq3CY74WaE6CtoirEO-zWarTsJDrJqrDExmOAWKaeSQNNw4Pvefo2hLZfYK-wfTeildTjU0j5dNkkbOtMSGOlg7sM10mgp1zuxpwiY0-I3PRPmMVPA%3D&u=https%3A%2F%2Fmta.openssl.org%2Fmailman%2Flistinfo%2Fopenssl-users ------------------------------ End of openssl-users Digest, Vol 46, Issue 46 ********************************************* From amit.prajapati at hpe.com Wed Sep 26 06:03:16 2018 From: amit.prajapati at hpe.com (Prajapati, Amit) Date: Wed, 26 Sep 2018 06:03:16 +0000 Subject: [openssl-users] Need help for porting RSA_verify Message-ID: Hi For one of my application I am trying to port "RSA_verify()"(crypto/rsa/rsa_sign.c) function from openssl for verification of the signature. While compilation I am not able to find the definition of "d2i_X509_SIG()" and "X509_SIG_free()" functions which is called from the "int_rsa_verify()". I tried to find it in google but I am getting only openssl man pages. Could someone please help me how to get the definition of these functions. Any other suggestions for porting RSA_verify will also be welcomed. Thanks & Regards, Amit -------------- next part -------------- An HTML attachment was scrubbed... URL: From Matthias.St.Pierre at ncp-e.com Wed Sep 26 07:55:43 2018 From: Matthias.St.Pierre at ncp-e.com (Dr. Matthias St. Pierre) Date: Wed, 26 Sep 2018 07:55:43 +0000 Subject: [openssl-users] Certificate format question? In-Reply-To: <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> Message-ID: > -----Urspr?ngliche Nachricht----- > In the meantime: > > $ perl -ne 'print if (/^-----BEGIN/../^-----END/);' foo.pem | > openssl asn1parse > > > On Sep 25, 2018, at 1:15 PM, Hubert Kario wrote: > > > > then it looks like the parser used in asn1parse -inform pem is non- > > compliant... > > > > https://github.com/openssl/openssl/issues/7317 Starting with version 1.1.0, the asn1parse has the -strictpem option to deal with exactly this case. I just submitted a pull request on GitHub which attempts to make RFC compliance the default behavior and introduces a new '-inform b64' option for raw base64 parsing. https://github.com/openssl/openssl/pull/7320 I would be interested in your (the users) opinion about whether this should become the new default in the future, or whether raw base64 parsing should remain the default. Matthias From dcoombs at carillon.ca Wed Sep 26 13:10:15 2018 From: dcoombs at carillon.ca (Dave Coombs) Date: Wed, 26 Sep 2018 09:10:15 -0400 Subject: [openssl-users] An example issuing an intermediate CA with policy mappings? In-Reply-To: References: Message-ID: <003C0CF9-CE20-4B1F-97AF-A21ACF23A4F7@carillon.ca> > On Sep 25, 2018, at 14:34, Krehbiel, Richard wrote: > > For my testing I want to explore the behaviors of policies, policy constraints, and policy mappings. I have figured out how to request and issue certs with custom policy OIDs, but I haven't yet seen a method of granting an intermediate cert with policy mappings. Can openssl do this? How? Thanks. Yes, I've used "openssl ca" to make certs with policy mappings in the past. Try something like this in your openssl.cnf, for use with "openssl ca -extensions test_ext" for example. (I haven't tested with these exact values, but it should be a starting point.) [openssl_init] oid_section = new_oids ... [new_oids] issuerOID = Issuer Domain Policy, 1.2.3.4.5 subjectOID = Subject Domain Policy, 1.3.5.7.9 ... [test_ext] policyMappings = @policy_mappings ... [policy_mappings] issuerOID = subjectOID And if you want to map more than one subject domain policy OID to the same issuer domain policy OID, you can use issuerOID.0, issuerOID.1, issuerOID.2, etc, to differentiate them in the policy_mappings section. Good luck, -Dave From Michael.Wojcik at microfocus.com Wed Sep 26 15:35:16 2018 From: Michael.Wojcik at microfocus.com (Michael Wojcik) Date: Wed, 26 Sep 2018 15:35:16 +0000 Subject: [openssl-users] Need help for porting RSA_verify In-Reply-To: References: Message-ID: > From: openssl-users [mailto:openssl-users-bounces at openssl.org] On Behalf Of Prajapati, Amit > Sent: Wednesday, September 26, 2018 02:03 > For one of my application I am trying to port ?RSA_verify()?(crypto/rsa/rsa_sign.c) function from > openssl for verification of the signature. What do you mean by "port"? Are you trying to extract the relevant code from the OpenSSL source and incorporate it into your application? If so, you're Doing It Wrong. Don't try to do that. Link with OpenSSL (or at least libcrypto) and call the public OpenSSL APIs you need. > While compilation I am not able to find the definition of ?d2i_X509_SIG()? and ?X509_SIG_free()? > functions which is called from the ?int_rsa_verify()?. Probably because they're defined using macros. You haven't told us what OpenSSL version you're looking at (next time, please think about what information might be needed by the people who could answer your question), but if it's the 1.0.2 series, d2i_X509_SIG is defined in crypto/asn1/asn1t.h, for example. It's defined using a token-pasting macro, so search for "d2i_##". But trying to lift this code out of the OpenSSL source will be an exercise in frustration, and if you ever got something to compile, likely a disaster. Do not attempt to create your own cryptography implementation, even using pieces of someone else's. > I tried to find it in google but I am getting only openssl man pages. Yes, because OpenSSL provides an API for applications. Use it. > Any other suggestions for porting RSA_verify will also be welcomed. Don't. Use OpenSSL properly instead. -- Michael Wojcik Distinguished Engineer, Micro Focus From shinejaekal at naver.com Thu Sep 27 01:19:19 2018 From: shinejaekal at naver.com (=?utf-8?B?7J207JiB7KO8?=) Date: Thu, 27 Sep 2018 10:19:19 +0900 Subject: [openssl-users] =?utf-8?q?May_I_ask_you_about_the_master-key_in_o?= =?utf-8?q?penssl_s=5Fclient_command_result=3F?= Message-ID: <9091fffb4859eab02e41248bf532b6@cweb02.nm.nhnsystem.com> Hello. I am a person working in Korea. I have a question. I wonder why master-key is revealed in plaintext in the results below. (used command : Openssl s_client -connect host:port) ------------------------------------------------------------------------------------ (skip) SSL-Session Protocol : TLSv1.2 Cipher : ECDHE-RSA-AES128-GCM-SHA256 Session-ID : C3921E69... Session-ID-ctx: Master-Key : 6244A1C4B9D48A6C2100198... (skip) ------------------------------------------------------------------------------------ Does it matter if the master key is exposed in plaintext? And I wonder what role this master key plays. Thank you for your detailed answer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From openssl-users at dukhovni.org Thu Sep 27 01:55:02 2018 From: openssl-users at dukhovni.org (Viktor Dukhovni) Date: Wed, 26 Sep 2018 21:55:02 -0400 Subject: [openssl-users] May I ask you about the master-key in openssl s_client command result? In-Reply-To: <9091fffb4859eab02e41248bf532b6@cweb02.nm.nhnsystem.com> References: <9091fffb4859eab02e41248bf532b6@cweb02.nm.nhnsystem.com> Message-ID: <3FD34AA5-7AD8-4C4A-88DC-50391AB7CB33@dukhovni.org> > On Sep 26, 2018, at 9:19 PM, ??? wrote: > > I wonder why master-key is revealed in plaintext in the results below. > (used command : Openssl s_client -connect host:port) Because s_client is a debugging tool, and a source of example code that demonstrates many elaborate features of the API from which you can pic and chose the functions that are useful to you. The s_client command is NOT designed to be used for any non-diagnostic purposes. > Does it matter if the master key is exposed in plaintext? That's a feature. You can check when using s_server that both computed the same key. > And I wonder what role this master key plays. https://tools.ietf.org/html/rfc5246#section-8.1 https://tools.ietf.org/html/rfc5246#appendix-A.6 https://tools.ietf.org/html/rfc5246#section-6.3 https://tools.ietf.org/html/rfc5246#section-7.4.9 https://tools.ietf.org/html/rfc5246#appendix-F.1.1 https://tools.ietf.org/html/rfc5246#appendix-F.1.4 https://tools.ietf.org/html/rfc5246#appendix-F.2 -- Viktor. From stiju.easo at gmail.com Thu Sep 27 05:01:39 2018 From: stiju.easo at gmail.com (Stiju Easo) Date: Thu, 27 Sep 2018 10:31:39 +0530 Subject: [openssl-users] May I ask you about the master-key in openssl s_client command result? In-Reply-To: <3FD34AA5-7AD8-4C4A-88DC-50391AB7CB33@dukhovni.org> References: <9091fffb4859eab02e41248bf532b6@cweb02.nm.nhnsystem.com> <3FD34AA5-7AD8-4C4A-88DC-50391AB7CB33@dukhovni.org> Message-ID: Hi, Just an Info, may not be relevant. If extended master secret is enabled,(by default on all browsers now a days) the computation of master secret is different. https://tools.ietf.org/html/rfc7627#section-4 On Thu, Sep 27, 2018 at 7:25 AM Viktor Dukhovni wrote: > > > > On Sep 26, 2018, at 9:19 PM, ??? wrote: > > > > I wonder why master-key is revealed in plaintext in the results below. > > (used command : Openssl s_client -connect host:port) > > Because s_client is a debugging tool, and a source of example code > that demonstrates many elaborate features of the API from which you > can pic and chose the functions that are useful to you. The s_client > command is NOT designed to be used for any non-diagnostic purposes. > > > Does it matter if the master key is exposed in plaintext? > > That's a feature. You can check when using s_server that both computed > the same key. > > > And I wonder what role this master key plays. > > https://tools.ietf.org/html/rfc5246#section-8.1 > https://tools.ietf.org/html/rfc5246#appendix-A.6 > https://tools.ietf.org/html/rfc5246#section-6.3 > https://tools.ietf.org/html/rfc5246#section-7.4.9 > https://tools.ietf.org/html/rfc5246#appendix-F.1.1 > https://tools.ietf.org/html/rfc5246#appendix-F.1.4 > https://tools.ietf.org/html/rfc5246#appendix-F.2 > > -- > Viktor. > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -- Stiju Easo The unexamined life is not worth living for man. Socrates, in Plato, Dialogues, Apology Greek philosopher in Athens (469 BC - 399 BC) -------------- next part -------------- An HTML attachment was scrubbed... URL: From steffen at sdaoden.eu Thu Sep 27 12:13:58 2018 From: steffen at sdaoden.eu (Steffen Nurpmeso) Date: Thu, 27 Sep 2018 14:13:58 +0200 Subject: [openssl-users] Certificate format question? In-Reply-To: References: <23D0E1E9-F56A-4CBE-92E9-FC0349CF3E44@dukhovni.org> <1823844.pAo1nv2Lg2@pintsize.usersys.redhat.com> <5D44B1E9-CDB3-49C1-A3E5-4AB0D889C40F@dukhovni.org> <20180925185724.bA-y8%steffen@sdaoden.eu> Message-ID: <20180927121358._dArC%steffen@sdaoden.eu> Scott Neugroschl wrote in : |Steffen Nurpmeso, Tuesday, September 25, 2018 11:57 AM |> The RFC 7468 term "parsers SHOULD ignore whitespace and other non- |>base64 characters" makes me wonder. | |The relevant clause is a few sentences up: "Data before the encapsulation \ |boundaries are |permitted, and parsers MUST NOT malfunction when processing such data. Ok i thought a day, but now i came to the conclusion that it would make sense to admit that i fail to see any interrelation between the two sentences, nor the problem (what methinks) as such. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt) From kgoldman at us.ibm.com Thu Sep 27 13:55:22 2018 From: kgoldman at us.ibm.com (Ken Goldman) Date: Thu, 27 Sep 2018 09:55:22 -0400 Subject: [openssl-users] HMAC key in PEM or other format Message-ID: Is there a standard format for passing around an HMAC key? Can openssl read and write it? I know that an HMAC key is just a random number, and I can probably pass it around in binary, hex ascii, or base64. But I'd rather use a standard format if there is one. From levitte at openssl.org Fri Sep 28 03:21:47 2018 From: levitte at openssl.org (Richard Levitte) Date: Fri, 28 Sep 2018 05:21:47 +0200 (CEST) Subject: [openssl-users] openssl-users Digest, Vol 46, Issue 46 In-Reply-To: References: Message-ID: <20180928.052147.25495493162839106.levitte@openssl.org> Ah, I forgot... we changed the requirements to compile that code, from this: # if defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) to this: # if defined(__SIZEOF_INT128__) && __SIZEOF_INT128__==16 the latter denotes official support while the former was more of a hack, and turned out to be unreliable... There's a bit of discussion on that here: https://github.com/openssl/openssl/issues/6327 So it turns out that your gcc may have the 128-bit extension, but doesn't declare official support for it. Cheers, Richard In message on Wed, 26 Sep 2018 02:47:51 +0000, Vinay Mummadi said: > Hi Richard, > > CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc > CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ > > I was using these for openssl 1.1.0h and it compiled with this option " enable-ec_nistp_64_gcc_128" > > Any other possibility, Please suggest. ... > Message: 1 > Date: Mon, 24 Sep 2018 15:42:48 +0200 (CEST) > From: Richard Levitte > To: openssl-users at openssl.org > Subject: Re: [openssl-users] Build issues with openssl-1.1.1 > Message-ID: <20180924.154248.2078713038705571598.levitte at openssl.org> > Content-Type: Text/Plain; charset=us-ascii > > I'm noticing these from the dump: > > Recorded environment: > > ... > CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc > CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ > > Could it be that those compilers don't have support for 128 bit > integers on your platform? In that case, you should remove > 'enable-ec_nistp_64_gcc_128' from your configuration command. > > Cheers, > Richard ... From benjamin.dupalut at esiee.fr Fri Sep 28 06:06:31 2018 From: benjamin.dupalut at esiee.fr (DUPALUT, Benjamin) Date: Fri, 28 Sep 2018 08:06:31 +0200 Subject: [openssl-users] SSL routines:ssl3_read_bytes:tlsv1 alert internal error Message-ID: Hello, First of all, sorry if my english isn't very good. I'm using freeradius server to authenticate users on Eduroam Wi-Fi. I set up a local certification authority et signed the freeradius server certificate using openssl. Users got the CA certfificate via the Configuration Assistant Tool for Eduroam but it fails at the TLS session : eap_peap: Peer indicated complete TLS record size will be 7 bytes eap_peap: Got complete TLS record (7 bytes) eap_peap: [eaptls verify] = length included eap_peap: <<< recv TLS 1.2 [length 0002] eap_peap: ERROR: TLS Alert read:fatal:internal error eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error eap_peap: ERROR: System call (I/O) error (-1) eap_peap: ERROR: TLS receive handshake failed during operation eap_peap: ERROR: [eaptls process] = fail eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module failed Does anyone knows where the problem come from ? Thanks in advance for your help. Benjamin Dupalut -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt at openssl.org Fri Sep 28 07:53:33 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 28 Sep 2018 08:53:33 +0100 Subject: [openssl-users] openssl-users Digest, Vol 46, Issue 46 In-Reply-To: <20180928.052147.25495493162839106.levitte@openssl.org> References: <20180928.052147.25495493162839106.levitte@openssl.org> Message-ID: <0d01f4fb-7179-39cd-f72a-e9b725c2bfe2@openssl.org> On 28/09/18 04:21, Richard Levitte wrote: > Ah, I forgot... we changed the requirements to compile that code, > from this: > > # if defined(__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 1)) > > to this: > > # if defined(__SIZEOF_INT128__) && __SIZEOF_INT128__==16 > > the latter denotes official support while the former was more of a > hack, and turned out to be unreliable... > > There's a bit of discussion on that here: > > https://github.com/openssl/openssl/issues/6327 > > So it turns out that your gcc may have the 128-bit extension, but > doesn't declare official support for it. As per the suggestion in that issue, if you have absolute faith that your compiler does support 128 bit ints then you can pass "-D__SIZEOF_INT128__=16" to config. Matt > > Cheers, > Richard > > In message on Wed, 26 Sep 2018 02:47:51 +0000, Vinay Mummadi said: > >> Hi Richard, >> >> CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc >> CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ >> >> I was using these for openssl 1.1.0h and it compiled with this option " enable-ec_nistp_64_gcc_128" >> >> Any other possibility, Please suggest. > ... >> Message: 1 >> Date: Mon, 24 Sep 2018 15:42:48 +0200 (CEST) >> From: Richard Levitte >> To: openssl-users at openssl.org >> Subject: Re: [openssl-users] Build issues with openssl-1.1.1 >> Message-ID: <20180924.154248.2078713038705571598.levitte at openssl.org> >> Content-Type: Text/Plain; charset=us-ascii >> >> I'm noticing these from the dump: >> >> Recorded environment: >> >> ... >> CC = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/gcc >> CXX = /u/build/build1/engtools/linux/2.6.18-8.el5/x86_64/gcc/versions/4.3.2/bin/g++ >> >> Could it be that those compilers don't have support for 128 bit >> integers on your platform? In that case, you should remove >> 'enable-ec_nistp_64_gcc_128' from your configuration command. >> >> Cheers, >> Richard > ... > From matt at openssl.org Fri Sep 28 10:31:22 2018 From: matt at openssl.org (Matt Caswell) Date: Fri, 28 Sep 2018 11:31:22 +0100 Subject: [openssl-users] SSL routines:ssl3_read_bytes:tlsv1 alert internal error In-Reply-To: References: Message-ID: On 28/09/18 07:06, DUPALUT, Benjamin wrote: > Hello, > > First of all, sorry if my english isn't very good. > > I'm using freeradius server to authenticate users on Eduroam Wi-Fi. I > set up a local certification authority et signed the freeradius server > certificate using openssl. > > Users? got the CA certfificate via the Configuration Assistant Tool for > Eduroam but it fails at the TLS session : > > eap_peap: Peer indicated complete TLS record size will be 7 bytes > eap_peap: Got complete TLS record (7 bytes) > eap_peap: [eaptls verify] = length included > eap_peap: <<< recv TLS 1.2? [length 0002]? > eap_peap: ERROR: TLS Alert read:fatal:internal error > eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done > eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL > routines:ssl3_read_bytes:tlsv1 alert internal error This error actually comes from the peer. The peer has sent an internal error alert to your server, which then causes your server to abort the connection. So the question is why does the peer send the internal error alert? Can any logging be obtained from that side of the connection? Matt > eap_peap: ERROR: System call (I/O) error (-1) > eap_peap: ERROR: TLS receive handshake failed during operation > eap_peap: ERROR: [eaptls process] = fail > eap: ERROR: Failed continuing EAP PEAP (25) session.? EAP sub-module failed > > Does anyone knows where the problem come from ? > > Thanks in advance for your help. > > Benjamin Dupalut > > From jan.burgmeier at unicon-software.com Fri Sep 28 11:11:25 2018 From: jan.burgmeier at unicon-software.com (Jan Burgmeier) Date: Fri, 28 Sep 2018 13:11:25 +0200 Subject: [openssl-users] Same dir with different type in X509_LOOKUP_hash_dir Message-ID: <2e5a9e53712a0e0138eee7d07d7145194286024a.camel@unicon-software.com> Hi, during setup of my X509_STORE I use X509_LOOKUP_hash_dir with same dir but different type X509_FILETYPE_PEM and X509_FILETYPE_ASN1. But only certificates of the first type are looked up. I dig into the code and made a little change to fix my problem, see attached patched. Is this behavior by design and I am doing anything wrong or is this a bug? Regards Jan Burgmeier --- a/crypto/x509/by_dir.c +++ b/crypto/x509/by_dir.c @@ -217,7 +217,8 @@ continue; for (j = 0; j < sk_BY_DIR_ENTRY_num(ctx->dirs); j++) { ent = sk_BY_DIR_ENTRY_value(ctx->dirs, j); - if (strlen(ent->dir) == (size_t)len && + if (type == ent->dir_type && + strlen(ent->dir) == (size_t)len && strncmp(ent->dir, ss, (unsigned int)len) == 0) break; } From benjamin.dupalut at esiee.fr Fri Sep 28 14:00:49 2018 From: benjamin.dupalut at esiee.fr (DUPALUT, Benjamin) Date: Fri, 28 Sep 2018 16:00:49 +0200 Subject: [openssl-users] SSL routines:ssl3_read_bytes:tlsv1 alert internal error In-Reply-To: References: Message-ID: Hi Matt, Thank you for your answer. I don't the Wi-Fi controler that initiate the connection but i can try to ask for logs. I will come back to you if i manage to get those logs. Cordialement, *Benjamin Dupalut* Ing?nieur syst?me et r?seau Service Informatique, T?l?communications, Audiovisuel et Reprographie (SITAR) ESIEE Paris 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex T : +33 1 45 92 66 17 benjamin.dupalut at esiee.fr www.esiee.fr / www.cci-paris-idf.fr Le ven. 28 sept. 2018 ? 12:31, Matt Caswell a ?crit : > > > On 28/09/18 07:06, DUPALUT, Benjamin wrote: > > Hello, > > > > First of all, sorry if my english isn't very good. > > > > I'm using freeradius server to authenticate users on Eduroam Wi-Fi. I > > set up a local certification authority et signed the freeradius server > > certificate using openssl. > > > > Users got the CA certfificate via the Configuration Assistant Tool for > > Eduroam but it fails at the TLS session : > > > > eap_peap: Peer indicated complete TLS record size will be 7 bytes > > eap_peap: Got complete TLS record (7 bytes) > > eap_peap: [eaptls verify] = length included > > eap_peap: <<< recv TLS 1.2 [length 0002] > > eap_peap: ERROR: TLS Alert read:fatal:internal error > > eap_peap: TLS_accept: Need to read more data: SSLv3/TLS write server done > > eap_peap: ERROR: Failed in __FUNCTION__ (SSL_read): error:14094438:SSL > > routines:ssl3_read_bytes:tlsv1 alert internal error > > This error actually comes from the peer. The peer has sent an internal > error alert to your server, which then causes your server to abort the > connection. So the question is why does the peer send the internal error > alert? Can any logging be obtained from that side of the connection? > > Matt > > > > eap_peap: ERROR: System call (I/O) error (-1) > > eap_peap: ERROR: TLS receive handshake failed during operation > > eap_peap: ERROR: [eaptls process] = fail > > eap: ERROR: Failed continuing EAP PEAP (25) session. EAP sub-module > failed > > > > Does anyone knows where the problem come from ? > > > > Thanks in advance for your help. > > > > Benjamin Dupalut > > > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjamin.dupalut at esiee.fr Fri Sep 28 16:00:08 2018 From: benjamin.dupalut at esiee.fr (DUPALUT, Benjamin) Date: Fri, 28 Sep 2018 18:00:08 +0200 Subject: [openssl-users] SubjectAltName syntax in openssl.cnf Message-ID: Hello, i Have to set a SubjectAltName for a server certificate but documentations on the web does not provide the same syntax. Is this syntax correct ? subjectAltName=DNS:test.example.com Also, does it belong in the [ usr_cert ] section ? Thank you for your help. Regards, *Benjamin Dupalut* Ing?nieur syst?me et r?seau Service Informatique, T?l?communications, Audiovisuel et Reprographie (SITAR) ESIEE Paris 2 bd Blaise Pascal - 93162 Noisy-le-Grand Cedex T : +33 1 45 92 66 17 benjamin.dupalut at esiee.fr www.esiee.fr / www.cci-paris-idf.fr -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Sat Sep 29 10:54:09 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Sat, 29 Sep 2018 18:54:09 +0800 Subject: [openssl-users] Two sessions in a single full handshake Message-ID: Using OpenSSL 1.1.1. The debug logs display two "SSL-Session" blocks in a full handshake. Only one "SSL-Session" block is displayed in a resumption. Why does full handshake has two sessions? -------------- next part -------------- An HTML attachment was scrubbed... URL: From levitte at openssl.org Sat Sep 29 12:13:52 2018 From: levitte at openssl.org (Richard Levitte) Date: Sat, 29 Sep 2018 14:13:52 +0200 (CEST) Subject: [openssl-users] Same dir with different type in X509_LOOKUP_hash_dir In-Reply-To: <2e5a9e53712a0e0138eee7d07d7145194286024a.camel@unicon-software.com> References: <2e5a9e53712a0e0138eee7d07d7145194286024a.camel@unicon-software.com> Message-ID: <20180929.141352.865554983569125909.levitte@openssl.org> Well, that will kinda sorta work, I think... what you're basically doing there, albeit not entirely clearly, is making the type a part of the directory index, not just its name. I haven't looked thoroughly enough to see if there are corner cases that will screw that up. That being said, you will see an increase in processing time. The type setting for a directory is applied to ALL hash-named files this code can find, so if you have two lookups, one with each file type setting, what will happen is that it will attempt through all the files, which will of course fail for those with the wrong format. You won't notice, because the loading errors are simply ignored and there will be success as soon as a file could be loaded and matches your lookup criteium. So in essence, that does look like a workable solution, but with bad optimization. Cheers, Richard In message <2e5a9e53712a0e0138eee7d07d7145194286024a.camel at unicon-software.com> on Fri, 28 Sep 2018 13:11:25 +0200, Jan Burgmeier said: > Hi, > > during setup of my X509_STORE I use X509_LOOKUP_hash_dir with same dir > but different type X509_FILETYPE_PEM and X509_FILETYPE_ASN1. But only > certificates of the first type are looked up. > I dig into the code and made a little change to fix my problem, see > attached patched. Is this behavior by design and I am doing anything > wrong or is this a bug? > > Regards > Jan Burgmeier > > --- a/crypto/x509/by_dir.c > +++ b/crypto/x509/by_dir.c > @@ -217,7 +217,8 @@ > continue; > for (j = 0; j < sk_BY_DIR_ENTRY_num(ctx->dirs); j++) { > ent = sk_BY_DIR_ENTRY_value(ctx->dirs, j); > - if (strlen(ent->dir) == (size_t)len && > + if (type == ent->dir_type && > + strlen(ent->dir) == (size_t)len && > strncmp(ent->dir, ss, (unsigned int)len) == 0) > break; > } > > From rsalz at akamai.com Sat Sep 29 19:18:50 2018 From: rsalz at akamai.com (Salz, Rich) Date: Sat, 29 Sep 2018 19:18:50 +0000 Subject: [openssl-users] Two sessions in a single full handshake In-Reply-To: References: Message-ID: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> * The debug logs display two "SSL-Session" blocks in a full handshake. Only one "SSL-Session" block is displayed in a resumption. Why does full handshake has two sessions? This is part of the TLS 1.3 standard. A server can send back multiple sessions, so that a client may resume with a different session, and therefore prevent an observer from ?linking? two different activities. -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.sha.jiang at gmail.com Sun Sep 30 03:06:14 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Sun, 30 Sep 2018 11:06:14 +0800 Subject: [openssl-users] Two sessions in a single full handshake In-Reply-To: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> References: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> Message-ID: Does s_client resume any session in the local session file? On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users < openssl-users at openssl.org> wrote: > > - The debug logs display two "SSL-Session" blocks in a full handshake. > > Only one "SSL-Session" block is displayed in a resumption. > > Why does full handshake has two sessions? > > > > This is part of the TLS 1.3 standard. A server can send back multiple > sessions, so that a client may resume with a different session, and > therefore prevent an observer from ?linking? two different activities. > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bkaduk at akamai.com Sun Sep 30 03:46:45 2018 From: bkaduk at akamai.com (Benjamin Kaduk) Date: Sat, 29 Sep 2018 22:46:45 -0500 Subject: [openssl-users] Two sessions in a single full handshake In-Reply-To: References: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> Message-ID: <20180930034645.GM19845@akamai.com> s_client has -sess_out and -sess_in options that can be used to save session information to a file and read it in for a subsequent connection. Neither is used by default. -Ben On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote: > Does s_client resume any session in the local session file? > > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users < > openssl-users at openssl.org> wrote: > > > > > - The debug logs display two "SSL-Session" blocks in a full handshake. > > > > Only one "SSL-Session" block is displayed in a resumption. > > > > Why does full handshake has two sessions? > > > > > > > > This is part of the TLS 1.3 standard. A server can send back multiple > > sessions, so that a client may resume with a different session, and > > therefore prevent an observer from ?linking? two different activities. > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users From john.sha.jiang at gmail.com Sun Sep 30 05:05:30 2018 From: john.sha.jiang at gmail.com (John Jiang) Date: Sun, 30 Sep 2018 13:05:30 +0800 Subject: [openssl-users] Two sessions in a single full handshake In-Reply-To: <20180930034645.GM19845@akamai.com> References: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> <20180930034645.GM19845@akamai.com> Message-ID: Now that full handshake sends two sessions, does that mean option -sess_out saves both of the sessions to a local file? If so, when resume session via option -sess_in, which session will be resumed? On Sun, Sep 30, 2018 at 11:47 AM Benjamin Kaduk via openssl-users < openssl-users at openssl.org> wrote: > s_client has -sess_out and -sess_in options that can be used > to save session information to a file and read it in for a subsequent > connection. Neither is used by default. > > -Ben > > On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote: > > Does s_client resume any session in the local session file? > > > > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users < > > openssl-users at openssl.org> wrote: > > > > > > > > - The debug logs display two "SSL-Session" blocks in a full > handshake. > > > > > > Only one "SSL-Session" block is displayed in a resumption. > > > > > > Why does full handshake has two sessions? > > > > > > > > > > > > This is part of the TLS 1.3 standard. A server can send back multiple > > > sessions, so that a client may resume with a different session, and > > > therefore prevent an observer from ?linking? two different activities. > > > -- > > > openssl-users mailing list > > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From richard at kccable.com Sun Sep 30 05:34:07 2018 From: richard at kccable.com (Richard) Date: Sat, 29 Sep 2018 22:34:07 -0700 Subject: [openssl-users] Two sessions in a single full handshake In-Reply-To: References: <8BD8B17B-B091-42D1-9AA4-FAEFE5C9AE5F@akamai.com> <20180930034645.GM19845@akamai.com> Message-ID: B I On Sat, Sep 29, 2018 at 10:06 PM John Jiang wrote: > Now that full handshake sends two sessions, does that mean option > -sess_out saves both of the sessions to a local file? > If so, when resume session via option -sess_in, which session will be > resumed? > > On Sun, Sep 30, 2018 at 11:47 AM Benjamin Kaduk via openssl-users < > openssl-users at openssl.org> wrote: > >> s_client has -sess_out and -sess_in options that can be used >> to save session information to a file and read it in for a subsequent >> connection. Neither is used by default. >> >> -Ben >> >> On Sun, Sep 30, 2018 at 11:06:14AM +0800, John Jiang wrote: >> > Does s_client resume any session in the local session file? >> > >> > On Sun, Sep 30, 2018 at 3:19 AM Salz, Rich via openssl-users < >> > openssl-users at openssl.org> wrote: >> > >> > > >> > > - The debug logs display two "SSL-Session" blocks in a full >> handshake. >> > > >> > > Only one "SSL-Session" block is displayed in a resumption. >> > > >> > > Why does full handshake has two sessions? >> > > >> > > >> > > >> > > This is part of the TLS 1.3 standard. A server can send back multiple >> > > sessions, so that a client may resume with a different session, and >> > > therefore prevent an observer from ?linking? two different activities. >> > > -- >> > > openssl-users mailing list >> > > To unsubscribe: >> https://mta.openssl.org/mailman/listinfo/openssl-users >> > > >> >> > -- >> > openssl-users mailing list >> > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> >> -- >> openssl-users mailing list >> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users >> > -- > openssl-users mailing list > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: