Re: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free
> On Nov 28, 2018, at 6:31 PM, Claus Assmann wrote: > > Thanks for the reply, it helped me adding some more debugging > statements to various places to track down the problem: > it is due to a change in TLS session handling in TLSv1.3. Thanks for following up, much appreciated. > It seems there are multiple SSL_SESSION structures for a single SSL > connection (SMTP session). The callback installed using > SSL_CTX_sess_set_new_cb() was called twice for the same SSL connection > and the code was written to handle only one callback per connection. Yes, by default the OpenSSL library now issues two session tickets for each full (non-resumed handshake), and a new session ticket after each resumption. Recent versions of the Postfix SMTP server, when linked against OpenSSL 1.1.1 ask the library to issue just one session ticket after a full handshake: https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521 and none on resumption if the current ticket is still valid (existing code from Postfix 2.11, which implements session ticket key sharing and rotation for a pool of Postfix SMTP servers on a single host): https://github.com/vdukhovni/postfix/blame/postfix-3.3/postfix/src/tls/tls_server.c#L507-L521 Linkability of sessions is not in my view a concern for SMTP, and SMTP clients either don't cache session tickets at all, or cache at most one, so issuing two initially and avoiding re-use is largely wasteful. > This resulted in a "use after free" situation. Sorry for the false > alarm. Makes sense. I did look briefly for potential issues in the library, that matched your stack trace (freeing the peer's DH public key), but did not find any smoking gun. I might however add belt-and-suspenders safety in one code path were I think that the current safe behaviour could prove fragile as the code evolves. So it has not been entirely unproductive. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] 1.1.1a: crash in CRYPTO_THREAD_lock_free
Thanks for the reply, it helped me adding some more debugging statements to various places to track down the problem: it is due to a change in TLS session handling in TLSv1.3. It seems there are multiple SSL_SESSION structures for a single SSL connection (SMTP session). The callback installed using SSL_CTX_sess_set_new_cb() was called twice for the same SSL connection and the code was written to handle only one callback per connection. This resulted in a "use after free" situation. Sorry for the false alarm. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
This was discussed around when OpenSSL first talked about the project. You might find it worth reading the various blog entries (and comment/responses) https://www.openssl.org/blog/blog/categories/license/ One thing to note is that cryptography can be a patent minefield, and the patent protections in the Apache license were important to the project at the time we decided which license to move to. Not everyone will be happy, and we knew that at the time. Overall, however, we felt that this was the best way to go. /r$, not a member of the project any more -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
On 28/11/18 21:41, Daniel Kahn Gillmor wrote: > On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote: >> On 28/11/18 17:02, Matt Caswell wrote: >>> Please see the following blog post about OpenSSL Versioning and License: >>> >>> https://www.openssl.org/blog/blog/2018/11/28/version/ >> >> :-( >> >> The Apache license is incompatible with GPLv2: >> >> https://www.apache.org/licenses/GPL-compatibility.html >> >> Those of us using GPLv2 code in products will no longer be able to use >> OpenSSL. For many of us, GPLv3 is not an option. > > The existing OpenSSL license is arguably incompatible with GPLv2 anyway, > in some analyses: > >https://people.gnome.org/~markmc/openssl-and-the-gpl.html Yes I believe any GPLv2 users have been relying on a license exception. I'm not sure the license exception in the GPL software I'm using would be sufficient if calls to OpenSSL are made from the GPL'd code: "As a special exception, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other works to produce a work based on this file, this file does not by itself cause the resulting work to be covered by the GNU General Public License.[...]" If my own (non-GPL) code calls OpenSSL, that seems fine. But what if I have modified the GPL'd (with exception) code to call OpenSSL? > That said, I also would have liked something that is GPLv2-compatible in > addition to GPLv3-compatible. Yes, that would have made things unambiguous. Jifl -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
On Wed 2018-11-28 19:54:34 +, Jonathan Larmour wrote: > On 28/11/18 17:02, Matt Caswell wrote: >> Please see the following blog post about OpenSSL Versioning and License: >> >> https://www.openssl.org/blog/blog/2018/11/28/version/ > > :-( > > The Apache license is incompatible with GPLv2: > > https://www.apache.org/licenses/GPL-compatibility.html > > Those of us using GPLv2 code in products will no longer be able to use > OpenSSL. For many of us, GPLv3 is not an option. The existing OpenSSL license is arguably incompatible with GPLv2 anyway, in some analyses: https://people.gnome.org/~markmc/openssl-and-the-gpl.html so the move to apache2 appears to be an overall loosening of restrictions, not making things worse (the older license was incompatible with even GPLv3 also, yuck). So it's an improvement over the current state of play, no? That said, I also would have liked something that is GPLv2-compatible in addition to GPLv3-compatible. --dkg -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SNI callback
> On Nov 28, 2018, at 3:48 PM, Jeremy Harris wrote: > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? For an SMTP server, SNI values that don't match are not unexpected, given that e.g. with DANE the DANE-aware clients will send the TLSA base domain, while non-DANE clients will send the original MX hostname, which may be different. So while it is interesting to test failing on SNI mismatch, please DO NOT fail handshakes on SNI mismatch in SMTP. -- Viktor. -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] Mail
Sent from my Samsung Galaxy smartphone.-- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SNI callback
On 28/11/2018 21:03, Benjamin Kaduk via openssl-users wrote: > On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: >> OpenSSL 1.1.1 FIPS 11 Sep 2018 >> RHEL 8.0 beta >> >> Using SSL_CTX_set_tlsext_servername_callback() >> when the called routine returns SSL_TLSEXT_ERR_NOACK >> I was expecting the handshake to fail. It carries >> on; am I doing something wrong? > > NOACK is basically "pretend that there wasn't a callback here"; > you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the > connection if you want the handshake to fail. Gotcha. - Thanks -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] SNI callback
On Wed, Nov 28, 2018 at 08:48:10PM +, Jeremy Harris wrote: > OpenSSL 1.1.1 FIPS 11 Sep 2018 > RHEL 8.0 beta > > Using SSL_CTX_set_tlsext_servername_callback() > when the called routine returns SSL_TLSEXT_ERR_NOACK > I was expecting the handshake to fail. It carries > on; am I doing something wrong? NOACK is basically "pretend that there wasn't a callback here"; you should probably use SSL_TLSEXT_ERR_ALERT_FATAL to abort the connection if you want the handshake to fail. -Ben -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] SNI callback
OpenSSL 1.1.1 FIPS 11 Sep 2018 RHEL 8.0 beta Using SSL_CTX_set_tlsext_servername_callback() when the called routine returns SSL_TLSEXT_ERR_NOACK I was expecting the handshake to fail. It carries on; am I doing something wrong? -- Thanks, Jeremy -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] [openssl-announce] OpenSSL Versioning and License
On 28/11/18 17:02, Matt Caswell wrote: > Please see the following blog post about OpenSSL Versioning and License: > > https://www.openssl.org/blog/blog/2018/11/28/version/ :-( The Apache license is incompatible with GPLv2: https://www.apache.org/licenses/GPL-compatibility.html Those of us using GPLv2 code in products will no longer be able to use OpenSSL. For many of us, GPLv3 is not an option. What about dual licensing? Jifl -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] OpenSSL Versioning and License
Please see the following blog post about OpenSSL Versioning and License: https://www.openssl.org/blog/blog/2018/11/28/version/ Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
If GSCheck is just a tool to check if you remembered to build code with the buffer overflow checks that Microsoft C can insert, then you should just treat this as a warning that the tool doesn't know how to check code from other compilers (in this case the manual work of the OpenSSL team). On 28/11/2018 10:06, Vinay Kumar via openssl-users wrote: Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope again: aes-586.obj aesni-x86.obj bf-586.obj bn-586.obj chacha-x86.obj cmll-x86.obj co-586.obj crypt586.obj des-586.obj ecp_nistz256-x86.obj ghash-x86.obj md5-586.obj poly1305-x86.obj rc4-586.obj rmd-586.obj sha1-586.obj sha256-586.obj sha512-586.obj vpaes-x86.obj wp-mmx.obj x86-gf2m.obj x86-mont.obj x86cpuid.obj Any idea on how to resolve this problem or is it expected behavior. NOTE: 1. Adding /GS flag and enabling debug mode did not resolve the problem. 2. The same works fine with 64bit Windows 'libeay32.dll' 3. For other OpenSSL library 'libssl32.dll', GSCheck passes for both 32bit and 64bit. 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
Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
> The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for > binscope GSCheck on Windows. This must be a customised non-standard library, since 1.1.0 does not build with that name, but as libcrypto-1_1.dll. Angus -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Re: [openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
I thibk those are all the .asm modules. If they are, you'll probably want to Configure with no-asm and rebuild in order to get the C implementations. -Kyle H On Wed, Nov 28, 2018, 01:07 Vinay Kumar via openssl-users < openssl-users@openssl.org wrote: > Hi All, > > The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope > GSCheck on Windows. > > E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the > following modules for which a language could not be identified. Ensure > these were compiled with debug information and run BinScope again: > aes-586.obj > aesni-x86.obj > bf-586.obj > bn-586.obj > chacha-x86.obj > cmll-x86.obj > co-586.obj > crypt586.obj > des-586.obj > ecp_nistz256-x86.obj > ghash-x86.obj > md5-586.obj > poly1305-x86.obj > rc4-586.obj > rmd-586.obj > sha1-586.obj > sha256-586.obj > sha512-586.obj > vpaes-x86.obj > wp-mmx.obj > x86-gf2m.obj > x86-mont.obj > x86cpuid.obj > > Any idea on how to resolve this problem or is it expected behavior. > > NOTE: > 1. Adding /GS flag and enabling debug mode did not resolve the problem. > 2. The same works fine with 64bit Windows 'libeay32.dll' > 3. For other OpenSSL library ' libssl32.dll', GSCheck passes for both > 32bit and 64bit. > > > Regards, > Vinay > > -- > 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] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
Hi all, I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg. Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31 Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this. Thus: Is the following approach correct ? So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328: - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ? - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ? - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ? - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ? - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ? Thanks a lot for any advice, Andreas -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
[openssl-users] GSCheck fails for Windows 32build 'libeay32.dll' library
Hi All, The 32bit OpenSSL 1.1.0i library 'libeay32.dll' fails for binscope GSCheck on Windows. E:\libeay32.dll: error BA2022: libeay32.dll was compiled with the following modules for which a language could not be identified. Ensure these were compiled with debug information and run BinScope again: aes-586.obj aesni-x86.obj bf-586.obj bn-586.obj chacha-x86.obj cmll-x86.obj co-586.obj crypt586.obj des-586.obj ecp_nistz256-x86.obj ghash-x86.obj md5-586.obj poly1305-x86.obj rc4-586.obj rmd-586.obj sha1-586.obj sha256-586.obj sha512-586.obj vpaes-x86.obj wp-mmx.obj x86-gf2m.obj x86-mont.obj x86cpuid.obj Any idea on how to resolve this problem or is it expected behavior. NOTE: 1. Adding /GS flag and enabling debug mode did not resolve the problem. 2. The same works fine with 64bit Windows 'libeay32.dll' 3. For other OpenSSL library ' libssl32.dll', GSCheck passes for both 32bit and 64bit. Regards, Vinay -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
